Re: [PATCH v8 14/14] dt-bindings: net: ar803x: add qca8084 PHY properties

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Fri, Dec 15, 2023 at 08:16:53PM +0800, Jie Luo wrote:
> On 12/15/2023 7:25 PM, Andrew Lunn wrote:
> > > The "maxItems: 1" of the property resets is defined in ethernet-phy.yaml
> > > that is referenced by qca,ar803x.yaml, but i have 11 reset instances
> > > used for qca8084 PHY
> > 
> > 11!?!?? Really? Why?
> > 
> > I assume the order and timer matters, otherwise why would you need
> > 11? So the PHY driver needs to handle this, not phylib framework. So
> > you will be adding vendor properties to describe all 11 of them. So
> > ethernet-phy.yaml does not matter.
> > 
> > 	Andrew
> 
> Since these resets need to be configured in the special sequence, and
> these clocks need to be configured with different clock rate.
> 
> But the clock instance get, the property name is fixed to "clock-names"
> according to the function of_parse_clkspec, and the reset property name
> is also fixed to "reset-names" from function __of_reset_control_get.

I think you need to give more details about this.

Where are these 11 resets located? What is the sequence? Why does the
PHY driver need to deal with each individual reset?

IMHO, a PHY driver should _not_ be dealing with the resets outside of
the PHY device itself, and I find it hard to imagine that qca8084
would have 11 external resets.

If these are 11 internal resets (to qca8084) then why are you using the
reset subsystem, and why do you need to describe them in DT? Surely if
they are internal to the PHY, that can be encapsulated within the PHY
driver?

This is an example of why it is useful to have an _example_ of the use
of this binding, because it would answer some of the above questions.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!