Date: Tue, 9 Jan 2024 11:31:24 -0600
From: Rob Herring <robh@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>, Yoshinori Sato <ysato@...rs.sourceforge.jp>
Cc: linux-sh@...r.kernel.org, Damien Le Moal <dlemoal@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, Geert Uytterhoeven <geert+renesas@...der.be>, Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, Thomas Gleixner <tglx@...utronix.de>, Lorenzo Pieralisi <lpieralisi@...nel.org>, Krzysztof Wilczyński <kw@...ux.com>, Bjorn Helgaas <bhelgaas@...gle.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>, Magnus Damm <magnus.damm@...il.com>, Daniel Lezcano <daniel.lezcano@...aro.org>, Rich Felker <dalias@...c.org>, John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, Lee Jones <lee@...nel.org>, Helge Deller <deller@....de>, Heiko Stuebner <heiko@...ech.de
 >, Jernej Skrabec <jernej.skrabec@...il.com>, Chris Morgan <macromorgan@...mail.com>, Yang Xiwen <forbidden405@...mail.com>, Sebastian Reichel <sre@...nel.org>, Randy Dunlap <rdunlap@...radead.org>, Arnd Bergmann <arnd@...db.de>, Vlastimil Babka <vbabka@...e.cz>, Hyeonggon Yoo <42.hyeyoo@...il.com>, David Rientjes <rientjes@...gle.com>, Baoquan He <bhe@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>, Guenter Roeck <linux@...ck-us.net>, Stephen Rothwell <sfr@...b.auug.org.au>, Azeem Shaikh <azeemshaikh38@...il.com>, Javier Martinez Canillas <javierm@...hat.com>, Max Filippov <jcmvbkbc@...il.com>, Palmer Dabbelt <palmer@...osinc.com>, Bin Meng <bmeng@...ylab.org>, Jonathan Corbet <corbet@....net>, Jacky Huang <ychuang3@...oton.com>, Lukas Bulwahn <lukas.bulwahn@...il.com>, Biju Das <biju.das.jz@...renesas.com>, Uwe Kleine-König <u.kleine-koenig@...gutronix.de>, Sam Ravnborg <sam@...nborg.org>, Sergey Shtylyov <s.shtylyov@....ru>, Michael Karcher <kernel@...rc
 her.dialup.fu-berlin.de>, Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>, linux-ide@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org, linux-clk@...r.kernel.org, dri-devel@...ts.freedesktop.org, linux-pci@...r.kernel.org, linux-serial@...r.kernel.org, linux-fbdev@...r.kernel.org
Subject: Re: [DO NOT MERGE v6 12/37] dt-bindings: pci: pci-sh7751: Add SH7751
 PCI

On Tue, Jan 09, 2024 at 01:42:53PM +0100, Linus Walleij wrote:
> Hi Yoshinori,
> 
> thanks for your patch!
> 
> On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
> <ysato@...rs.sourceforge.jp> wrote:
> 
> > Renesas SH7751 PCI Controller json-schema.
> >
> > Signed-off-by: Yoshinori Sato <ysato@...rs.sourceforge.jp>
> (...)
> > +  renesas,bus-arbit-round-robin:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set DMA bus arbitration to round robin.
> > +
> > +  pci-command-reg-fast-back-to-back:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set for PCI command register Fast Back-to-Back enable bit.
> > +
> > +  pci-command-reg-serr:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set for PCI command register SERR# enable.
> > +
> > +  pci-command-reg-wait-cycle-control:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set for PCI command register Wait cycle control bit.
> > +
> > +  pci-command-reg-parity-error-response:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set for PCI Command register Parity error response bit.
> > +
> > +  pci-command-reg-vga-snoop:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set for PCI Command register VGA palette snoop bit.
> > +
> > +  pci-command-reg-write-invalidate:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set for PCI Command register Memory write and invaldate enable bit.
> > +
> > +  pci-command-reg-special-cycle:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set for PCI Command register Special cycle bit.
> > +
> > +  pci-command-reg-bus-master:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set for PCI Command register Bus master bit.
> > +
> > +  pci-command-reg-memory-space:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set for PCI Command register Memory space bit.
> > +
> > +  pci-command-reg-io-space:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description: |
> > +      Set for PCI Command register I/O space bit.
> 
> Do you really need to configure all these things? It seems they are
> just set to default values anyway?
> 
> Can't you just look at the compatible "renesas,sh7751-pci" and
> set it to the values you know are needed for that compatible?

Yes. Please drop all these.

> 
> > +  pci-bar:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +    description: Overwrite to  PCI CONFIG Base Address Registers value.
> > +    items:
> > +      items:
> > +        - description: BAR register number
> > +        - description: BAR register value
> > +    minItems: 1
> > +    maxItems: 6
> 
> Same with this, isn't this always the same (hardcoded) values
> for "renesas,sh7751-pci" if used?

The OpenFirmware PCI bus supplement already defines how to specify BAR 
values in DT in "reg" or "assigned-addresses". If you need to specify 
these, use that. Note don't expect the kernel to do anything with them.

Rob

> 
> > +            interrupt-map = <0x0000 0 0 1 &julianintc 5>,
> > +                            <0x0000 0 0 2 &julianintc 6>,
> > +                            <0x0000 0 0 3 &julianintc 7>,
> > +                            <0x0000 0 0 4 &julianintc 8>,
> > +                            <0x0800 0 0 1 &julianintc 6>,
> > +                            <0x0800 0 0 2 &julianintc 7>,
> > +                            <0x0800 0 0 3 &julianintc 8>,
> > +                            <0x0800 0 0 4 &julianintc 5>,
> > +                            <0x1000 0 0 1 &julianintc 7>,
> > +                            <0x1000 0 0 2 &julianintc 8>,
> > +                            <0x1000 0 0 3 &julianintc 5>,
> > +                            <0x1000 0 0 4 &julianintc 6>;
> 
> This interrupt-map looks very strange, usually the last cell is the polarity
> flag and here it is omitted? I would expect something like:
> 
> <0x0000 0 0 1 &julianintc 5 IRQ_TYPE_LEVEL_LOW>, (...)
> 
> The interrupt-map schema in dtschema isn't really looking at this
> so it is easy to get it wrong.

dtc should IIRC. Maybe not in the example being incomplete.

Rob

Powered by blists - more mailing lists