Re: PR 60404: Beaglebone Black: nonfunctional usb wifi

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

> On Jul 10, 2026, at 08:51, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
> 
> Brook Milligan <brook%biology.nmsu.edu@localhost> wrote:
>> 
>> 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.

Thanks for the example.  That will be helpful, I’m sure.

>> 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";
>> };
> 
> 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 = "ti,am335x-usb-phy";
>                                reg = <0x1300 0x100>;
>                                reg-names = "phy";
>                                ti,ctrl_mod = <&usb_ctrl_mod>;
>                                #phy-cells = <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’s 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’m 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