Re: PR 60404: Beaglebone Black: nonfunctional usb wifi

> On Jul 10, 2026, at 08:51, Robert Swindells <[email protected]> wrote:
>=20
> Brook Milligan <[email protected]> wrote:
>>=20
>> 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?
>=20
> There is an example of a MOTG USB PHY in sys/arch/sunxi, and of how
> the USB controller makes use of it.

Thanks for the example.  That will be helpful, I=E2=80=99m sure.

>> Third, the device tree for the phy contains only the following:
>>=20
>> usb_ctrl_mod: control@620 {
>>      compatible =3D "ti,am335x-usb-ctrl-module";
>>      reg =3D <0x620 0x10>,
>>            <0x648 0x4>;
>>      reg-names =3D "phy_ctrl", "wakeup";
>> };
>=20
> That isn't the PHY, it gets referenced by the PHY.
>=20
> An entry for one of the PHYs is this:
>=20
>                        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>;
>                        };

Yes, my mistake.  Nevertheless, the PHY registers are at offset 0x1300, =
which agrees with the BBB TRM memory map ([1] page 178) corresponding to =
USB0_PHY; the full address of is 0x47401300, which is within a larger =
block for all of USB0 starting at 0x47400000.  I believe that these =
blocks are defined hierarchically in the various driver parents and so =
they can be accessed, each within its parent=E2=80=99s block.

In addition to these registers, however, the BBB has an entirely =
different set of control registers that start at address 0x44e10000.  =
Among other things these control aspects of USB (that I=E2=80=99m trying =
to set here) and the configuration of GPIO pins.  The 0x620 referred to =
in usb_ctrl_mod above is within this other block, not within the main =
USB0 registers.  As a result, the 0x44e10000 base address for this is =
not in any of the USB PHY parent nodes.

How should this split address map be handled in drivers that need to =
access registers from two different blocks?

Cheers,
Brook

[1] https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf