linux-kernel - Re: [PATCH net-next 1/2] net: renesas: rswitch: use per-port irq handlers

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: <7c8c1baf-f398-4439-b974-b7d1425942b1@lunn.ch>
Date: Fri, 20 Dec 2024 10:31:51 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Nikita Yushchenko <nikita.yoush@...entembedded.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Michael Dege <michael.dege@...esas.com>,
	Christian Mardmoeller <christian.mardmoeller@...esas.com>,
	Dennis Ostermann <dennis.ostermann@...esas.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>
Subject: Re: [PATCH net-next 1/2] net: renesas: rswitch: use per-port irq
 handlers

On Fri, Dec 20, 2024 at 02:23:31PM +0500, Nikita Yushchenko wrote:
> > > > Sorry, but I can't find where this property is documented?
> > > 
> > > I will add this.
> > 
> > Device tree properties should be a hardware description. However,
> > about the "irq-index", it seems a software configuration. So, even if we would
> > like to submit such a patch to add the property, it will be rejected.
> 
> Hmm...
> 
> Indeed it is a software configuration.
> 
> I was not aware of such a rule.
> 
> I believe there shall be plenty of situations when a per-hardware-node
> software configuration is desired. What method do other use, if not device
> tree?
> 
> > Also, even if we can add a new device tree property, we should keep backward compatible.
> > However, this patch seems to break a backward compatibility.
> 
> It does not.
> If this new property is not defined, then it will default to 0, which will
> result exactly into previous behavior.

This is where the DT binding patch would of been useful, because you
would of stated that in the binding...

Backwards compatibility is something reviewers always look for, so it
is good to make it obvious that it has been considered.

Even if it is backwards compatible, lets see if we can think of a way
to not require the property. Maybe you can explain the hardware in
more details, and what you are trying to achieve.

	Andrew