Re: PR 60404: Beaglebone Black: nonfunctional usb wifi

[Brook Milligan <brook%biology.nmsu.edu@localhost>]

> On Jul 10, 2026, at 06:25, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
> 
> Brook Milligan <brook%biology.nmsu.edu@localhost> 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.
>> 
>> 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.
>> 
>> 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.
> 
> 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.
> 
> 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’m 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 = "ti,am335x-usb-ctrl-module";
	reg = <0x620 0x10>,
	      <0x648 0x4>;
	reg-names = "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