Re: [PATCH v3 2/4] dt-bindings: serial: renesas,scif: Validate 'interrupts' and 'interrupt-names'

[Geert Uytterhoeven]

Hi Krzysztof,

On Tue, Mar 19, 2024 at 2:04 PM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
> On 19/03/2024 13:43, Lad, Prabhakar wrote:
> >>>> diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> >>>> index af72c3420453..53f18e9810fd 100644
> >>>> --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> >>>> +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> >>>> @@ -82,38 +82,6 @@ properties:
> >>>>    reg:
> >>>>      maxItems: 1
> >>>>
> >>>> -  interrupts:
> >>>
> >>> I don't understand what is happening with this patchset. Interrupts must
> >>> stay here. Where did you receive any different feedback?
> >>
> >> Look how it is done:
> >> https://elixir.bootlin.com/linux/v6.8/source/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml#L44
> >>
> > Thanks for the pointer, as the above binding doesn't have any
>
> Yeah, that's just an example to point you the concept: top level
> property comes with widest constraints (or widest matching items
> description) and each variant narrows the choice.
>
> > description items as compared to our case, to clarify I have updated
> > the binding is below. Is this the correct approach?
> >
> > option #1
> > ---------------
>
>
> Yes, it looks correct.

Why duplicate all the descriptions? The only differences are the number
of valid interrupts?
What was wrong with "[PATCH v2 2/2] dt-bindings: serial: renesas,scif:
Validate 'interrupts' and 'interrupt-names'"[1]?

https://lore.kernel.org/r/20240307114217.34784-3-prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds