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@xxxxxxx> 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. Andrew