Re: [PATCH net-next 12/12] arm64: dts: qcom: qcs6490-rb3gen2: enable TC9564 with a single QCS8081 phy

[Daniel Thompson <daniel@riscstar.com>]

On Thu, May 14, 2026 at 06:14:07PM +0200, Andrew Lunn wrote:
> > I’m afraid this must be necessarily long but to help navigate the
> > general structure is:
>
> Thanks for the long email.
>
> > Let’s turn our attention to MDIO.
> >
> > Following the pattern above where all the links related to power come
> > from the main device node, then the phy node for the qca8081 in an
> > rb3gen2 would look like something like this:
> >
> >     tc956x_emac1_phy: ethernet-phy@1c {
> >         compatible = "ethernet-phy-id004d.d101";
> >         reg = <0x1c>;
> >
> >         reset-gpios = <&tc956x_emac0 1 GPIO_ACTIVE_LOW>;
> >         # On RB3gen2 all supplies are controlled by a single GPIO
> >         # so we link all supplies to that single regulator
> >         avdd-supply = <&qep_1p8>;
> >         avdd18-supply = <&qep_1p8>;
> >         vdd-supply = <&qep_1p8>;
> >         vddldo-supply = <&qep_1p8>;
> >         vdd18-supply = <&qep_1p8>;
> >         vdd125-supply = <&qep_1p8>;
> >
> >         pinctrl-names = "default";
> >         pinctrl-0 = <&qep_irq_pin>;
> >         interrupts-extended = <&tlmm 101 IRQ_TYPE_LEVEL_LOW>;
> >     };

I nearly snipped this... but I referring to *-supplies so often below
I decided it was useful to keep it!


> > Once we have established what the DT looks like then the question
> > becomes where to put "something, written in C [or Rust], that contains
> > burned in knowledge of how to turn on a wcn6855^H^H^H^H^H^H^Hqca8081"?
> >
> > The qca8081 on rb3gen2 just gets a bunch of individual regulators and a
> > reset. As in the pci-pwrctrl-tc9563 example above, this means there is
> > nothing in the DT for a pwrseq driver to bind to.
>
> I don't understand that. We have a node in device tree for the PHY. We
> can put the needed properties there somehow.  Maybe similar to how
> pinctrl works. Before probing the device, the driver core looks for
> the pinctrl- properties, and activates them. We could have similar
> properties for power sequencing, before enumerating an address, do
> whatever the pwrseq-names requests? It might need help for the driver
> actually enumerating the bus, to point to core at the node.

pinctrl properties describe the relationship between the device and the
pin controller of its host. In the case above &qep_irq_pin it leads back
to something belonging to the pin controller.

Devicetree does have power domains and these are actually pretty similar
to pinctrl. power-domains properties are used to essentially used to
describe the relationship between the device and a power domain
controller.

However in this case power domains don't really fit. There is no power
domain controller to link to. Thus I'd still expect the phy power
supplies to be modelled in devicetree as I showed above.  pwrseq, PCI
and USB all adopt this approach for modelling onboard devices in DT.


> > Even if we could find
> > a way to do that, it is not obviously useful to decouple how to turn on
> > an MDIO device from how to drive it. Thus I think the right answer to
> > that is to put the code to fire up the regulators into the qca808x.c
> > driver and it looks to me like the existing probe/remove methods would
> > already work perfectly well as the place to put it.
>
> But you have a chicken/egg. Same as with PCI, with Ethernet PHYs, you
> ask the device what it is, and then find a driver to drive it, and
> then call the probe function. However, if its clock is off, its GPIO
> reset is held in reset, its power regulators are switch off, it never
> answers when you ask it, what are you? If you have no idea what it is,
> you cannot probe it. And if you cannot probe it, the probe function
> cannot turn all these things on.
>
> The standard reply we have is, ignore the fact the device can be
> enumerated, hard code in DT what its ID is. And that is what you have
> above in your DT fragment.

My comment above about it not being useful to decouple was very much
based on this "standard reply".

The *-supply properties will differ from phy to phy so we need the DT
to know what device is in order to supply the right properties. In other
words de-coupling the parsing of those supply properties (and anything
else) does not help MDIO with the chicken/egg problem.

However perhaps I was being a little shortsighted to say there are no
benefits (below).


> But you also need to live with the
> consequences of it being wrong, since that driver is going to be
> loaded, no questions asked. And don't think about having a rev A board
> and a rev B board which have different pin compatible PHYs, and want
> to use the enumeration to get the correct driver loaded.

Typically embedded platforms "solve" this by having a bootloader
retrieve the board revision (usually from whatever non-volatile storage
it keeps the mac address) and swap a status = "okay"/status =
"disabled" pair in the DT.

This is not great (hence quoting "solve") but it must also be added
that this approach does also work when the PHY isn't pin compatible and
needs to be powered up differently.


> DT developers continually want to make use of the enumeration feature,
> since it is there, part of 802.3, it is how it was done for the first
> 20 years of networking, etc. And they keep trying to extend the
> current code to get the PHY running to allow it to be enumerated.  And
> i keep rejecting it.

Has someone already tried to "sell" you on approach somewhat similar to
the onboard_usb_dev code?

onboard_usb_dev centralizes *all* knowledge of how to turn the regulators,
clocks, resets for all soldered down USB devices that need help to be
turned on. In the case of USB then it literally examines the list of
VID/PID pairs supported by onboard_usb_dev to decide whether to create
the platform device used to lubricate things.

This still relies on the "standard reply" meaning it doesn't solve the
chicken/egg and it doesn't avoid there being something written in C (or
Rust) that knows how to turn on devices. However it does do is move
the churn associated with enabling a new USB on an embedded platform
out of the USB drivers and into a single centralized place.

With the embedded churn on one place stops "embedded crap" from creeping
through the all the drivers. I suspect is also much easier to divide
review/maintenance responsibilities.

FWIW I think the relatively simple structure of the MDIO bus means we
don't actually have to mess about with platform devices. I think one
might be able to get it down to four function calls (which could easily
be stubbed out on !CONFIG_OF systems).


> Ideally, i would like some generic core code which can be given a list
> of resources, probably phandles, and timing information. And it will
> walk the list and turn them on, inserting the requested delays. And
> then we can enumerate the device.
>
> Until such code exists, i agree, forget the device is enumerable, hard
> code the ID, and get the probe function to enable the regulators, take
> the device out of reset, enable the clocks, etc. And repeat that in
> every PHY driver.

So, having spent a bit of time thinking about it I do wonder if creating
some kind of onboard_mdio.c to collect knowledge of how to turn specific
mdio devices on might be better than putting the same knowledge
directly into probe functions.

Should generic core code (or library functons) ever arrive then having
this code centralized between phys would make adopting the generic code
code easier.

I'm not overly attached to either idea but if you'd like me to sketch
out a prototype then let me know!


Daniel.