Re: PR 60404: Beaglebone Black: nonfunctional usb wifi

Brook Milligan <[email protected]> wrote:
> On Jul 10, 2026, at 06:25, Robert Swindells <[email protected]> wrote:
>> I think the expected way to handle this is to create a separate driver
>> for the PHY, it would then map its own register set as defined in
>> the device tree.
>>=20
>> The USB driver would then call fdtbus_phy_get() with the appropriate
>> node name then fdtbus_phy_enable().
>
> Thanks for your input.  That makes sense.  I have several questions:
>
> First, I=E2=80=99m guessing that using fdtbus_phy_get()/fdtbus_phy_enable=
() is
> instead of having the normal config process find/attach it.  Is that
> correct?

No, the PHY would have xxx_match() & xxx_attach() functions and would
get configured normally.

Your USB controller driver would call fdtbus_phy_get() etc...

> Second, what exactly would the phy driver do?  Does it just provide a
> means for other kernel code to access and map the appropriate registers,
> so that for example the USB driver could call some phy driver function
> to set bits?

There is an example of a MOTG USB PHY in sys/arch/sunxi, and of how
the USB controller makes use of it.

> Third, the device tree for the phy contains only the following:
>
> usb_ctrl_mod: control@620 {
>	compatible =3D "ti,am335x-usb-ctrl-module";
>	reg =3D <0x620 0x10>,
>	      <0x648 0x4>;
>	reg-names =3D "phy_ctrl", "wakeup";
> };

That isn't the PHY, it gets referenced by the PHY.

An entry for one of the PHYs is this:

                        usb0_phy: usb-phy@1300 {
                                compatible =3D "ti,am335x-usb-phy";
                                reg =3D <0x1300 0x100>;
                                reg-names =3D "phy";
                                ti,ctrl_mod =3D <&usb_ctrl_mod>;
                                #phy-cells =3D <0>;
                        };


> Specifically, there is no information (here or anywhere else in the tree
> as far as I can tell) about what the address base for 0x620 and 0x648
> is.

The address base comes from the parent nodes of the one you are
referencing, functions like fdtbus_get_reg_byname() handle this for you.

> Is it ok to change the device tree to provide that information?  If so,
> how can that be done in a way that makes maintenance easy?  Or, should
> the address base be coded into the phy driver?

Don't change the device tree.