lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdX_2Tgm2LLM1TgFrkLdokD99gAeKHJWrKy9Y2A+wtf5RA@mail.gmail.com>
Date: Wed, 17 Jan 2024 11:06:02 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Yoshinori Sato <ysato@...rs.sourceforge.jp>
Cc: Linus Walleij <linus.walleij@...aro.org>, linux-sh@...r.kernel.org, 
	Damien Le Moal <dlemoal@...nel.org>, Rob Herring <robh+dt@...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@...rcher.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 17/37] dt-bindings: interrupt-controller:
 renesas,sh7751-intc: Add json-schema

Hi Sato-san,

On Wed, Jan 17, 2024 at 10:46 AM Yoshinori Sato
<ysato@...rs.sourceforge.jp> wrote:
> On Tue, 09 Jan 2024 21:30:34 +0900,
> Linus Walleij wrote:
> > On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
> > <ysato@...rs.sourceforge.jp> wrote:
> >
> > > +  renesas,icr-irlm:
> > > +    $ref: /schemas/types.yaml#/definitions/flag
> > > +    description: If true four independent interrupt requests mode (ICR.IRLM is 1).
> > > +
> > > +  renesas,ipr-map:
> > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > +    description: |
> > > +      IRQ to IPR mapping definition.
> > > +      1st - INTEVT code
> > > +      2nd - Register
> > > +      3rd - bit index
> >
> > (...)
> >
> > > +            renesas,ipr-map = <0x240 IPRD IPR_B12>, /* IRL0 */
> > > +                              <0x2a0 IPRD IPR_B8>,  /* IRL1 */
> > > +                              <0x300 IPRD IPR_B4>,  /* IRL2 */
> > > +                              <0x360 IPRD IPR_B0>,  /* IRL3 */
> > (...)
> >
> > Is it really necessary to have all this in the device tree?
> >
> > You know from the compatible that this is "renesas,sh7751-intc"
> > and I bet this table will be the same for any sh7751 right?
> >
> > Then just put it in a table in the driver instead and skip this from
> > the device tree and bindings. If more interrupt controllers need
> > to be supported by the driver, you can simply look up the table from
> > the compatible string.
>
> The SH interrupt controller has the same structure, only this part is different for each SoC.
> Currently, we are targeting only the 7751, but in the future we plan to handle all SoCs.
> Is it better to differentiate SoC only by compatible?

Yes, it is better to differentiate SoC only by compatible value.

When you describe all differences explicitly using properties, you
might discover later that you missed something important, causing
backwards compatibility issues with old DTBs.
DT is a stable ABI, while you can always update a driver when needed.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ