linux-kernel - Re: [PATCH 06/17] dt-bindings: net: mscc-miim: Add resets property

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: <202405021322091c565595@mail.local>
Date: Thu, 2 May 2024 15:22:09 +0200
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Conor Dooley <conor.dooley@...rochip.com>,
	Herve Codina <herve.codina@...tlin.com>,
	Thomas Gleixner <tglx@...utronix.de>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Lee Jones <lee@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Horatiu Vultur <horatiu.vultur@...rochip.com>,
	UNGLinuxDriver@...rochip.com,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	Saravana Kannan <saravanak@...gle.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Lars Povlsen <lars.povlsen@...rochip.com>,
	Steen Hegelund <Steen.Hegelund@...rochip.com>,
	Daniel Machon <daniel.machon@...rochip.com>,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	netdev@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Allan Nielsen <allan.nielsen@...rochip.com>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 06/17] dt-bindings: net: mscc-miim: Add resets property

On 02/05/2024 14:26:36+0200, Andrew Lunn wrote:
> On Thu, May 02, 2024 at 11:31:00AM +0100, Conor Dooley wrote:
> > On Thu, May 02, 2024 at 11:50:43AM +0200, Herve Codina wrote:
> > > Hi Andrew,
> > > 
> > > On Tue, 30 Apr 2024 18:31:46 +0200
> > > Andrew Lunn <andrew@...n.ch> wrote:
> > > 
> > > > > We have the same construction with the pinctrl driver used in the LAN966x
> > > > >   Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml
> > > > > 
> > > > > The reset name is 'switch' in the pinctrl binding.
> > > > > I can use the same description here as the one present in the pinctrl binding:
> > > > >   description: Optional shared switch reset.
> > > > > and keep 'switch' as reset name here (consistent with pinctrl reset name).
> > > > > 
> > > > > What do you think about that ?  
> > > > 
> > > > It would be good to document what it is shared with. So it seems to be
> > > > the switch itself, pinctl and MDIO? Anything else?
> > > > 
> > > 
> > > To be honest, I know that the GPIO controller (microchip,sparx5-sgpio) is
> > > impacted but I don't know if anything else is impacted by this reset.
> > > I can update the description with:
> > >   description:
> > >     Optional shared switch reset.
> > >     This reset is shared with at least pinctrl, GPIO, MDIO and the switch
> > >     itself.
> > > 
> > > Does it sound better ?
> > 
> > $dayjob hat off, bindings hat on: If you don't know, can we get someone
> > from Microchip (there's some and a list in CC) to figure it out?
> 
> That is probably a good idea, there is potential for hard to find bugs
> here, when a device gets an unexpected reset. Change the order things
> probe, or an unexpected EPRODE_DEFER could be interesting.
> 


The datasheet states:
"The VCore system comprises all the blocks attached to the VCore Shared
Bus (SBA), including the PCIe, DDR, frame DMA, SI slave, and MIIM slave
blocks. The device includes all the blocks attached to the Switch Core
Register Bus (CSR) including the VRAP slave. For more information about
the VCore System blocks, see Figure 5-1."

However, the reset driver protects the VCORE itself by setting bit 5.
Everything else is going to be reset.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com