Re: PR 60404: Beaglebone Black: nonfunctional usb wifi
Robert Swindells <[email protected]> Fri, 10 Jul 2026 13:25:52 +0100
| Newsgroups | gmane.os.netbsd.ports.arm,gmane.os.netbsd.current |
|---|---|
| Message-ID | <[email protected]> |
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. > > 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().