Re: PR 60404: Beaglebone Black: nonfunctional usb wifi

> On Jul 10, 2026, at 06:25, Robert Swindells <[email protected]> wrote:
>=20
> Brook Milligan <[email protected]> wrote:
>> The attached patch (see below) fixes the non-functional USB =
controller
>> on the Beaglebone Black.  With this patch, mass storage devices seem =
to
>> work fine, and wifi devices are detected by both the run and urtwn
>> drivers.
>>=20
>> At the moment, this patch is really verbose, because I am reporting
>> various bits along the way.  Thus, there are obvious cleanups to be
>> made.
>>=20
>> More importantly, however, I would very much appreciate feedback on =
how
>> to improve the functional code parts.  For example, it seems that it
>> should be possible to access some of the relevant contants from the
>> device tree, but I am not seeing how that can be done.  The BBB =
memory
>> map separates control registers from the main device registers, so =
the
>> same mapped memory cannot be used for both, and the device tree seems
>> not to have a way to extract the base address of the control module.  =
I
>> may, however, be not understanding or there may be other ways to =
access
>> these registers or to differentiate between the instances of the =
driver
>> attachments.  All code improvements welcome.
>=20
> 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?

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?

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";
};

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.

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?

Thanks a lot for your help.

Cheers,
Brook