Re: PR 60404: Beaglebone Black: nonfunctional usb wifi
Nick Hudson <[email protected]> Mon, 13 Jul 2026 13:31:26 +0100
| Newsgroups | gmane.os.netbsd.ports.arm |
|---|---|
| Message-ID | <[email protected]> |
On 12/07/2026 18:05, Brook Milligan wrote:
> With the help of yurix@, riastradh@, and rjs@ (thanks!), I have a
> working fix for the ti_motg driver (see below). With this applied,
> the BBB will detect USB devices, including both mass storage and wifi.
> However, while a mass storage device seems to work fine, wifi devices
> do not.
>=20
> I would greatly appreciate feedback before I commit this patch.
> Although all input is welcome, there are several questions I would
> appreciate answers for.
>=20
Not sure if anyone has mentioned, but you're code should conform to the
binding specification which is here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Docu=
mentation/devicetree/bindings/usb/am33xx-usb.txt?h=3Dv6.12.66
I think you might want to take a lead from
https://nxr.netbsd.org/xref/src/sys/arch/arm/amlogic/meson_usbctrl.c#=
292
or
https://nxr.netbsd.org/xref/src/sys/arch/riscv/starfive/jh71x0_usb.c#=
194
> First, this code gathers all information dynamically from the device
> tree, whereas there are hard-coded constants in, for example,
> ti_otgreg.h; for example, the number of supported USB devices can be
> determined dynamically or statically. What is the wisdom of one
> approach over the other?
Everything should be driven from the binding specification and its propert=
ies.
>=20
> Second, this patch was motivated by the problem outlined in PR 60404.
> However, that problem (nonfunctional wifi) turns out to be more
> complex and the solution will involve multiple steps. This patch
> addresses the first (USB device detection), but the wifi drivers still
> do not work correctly (e.g., panics are triggered, cannot load
> firmware errors, wpa_supplicant triggers errors, etc.). Most of the
> information currently in PR 60404 turns out to relate only to this
> first USB device detection problem. When this patch is committed,
> should PR 60404 be closed and a new one opened to focus on the new
> problems, or should it remain open, perhaps with additional
> information?
Sounds like a new PR to me.
>=20
> Thanks a lot for your help. I look forward to feedback.
>=20
> Cheers,
> Brook
>=20
>=20
> Index: ti_motg.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/src/sys/arch/arm/ti/ti_motg.c,v
> retrieving revision 1.5
> diff -u -r1.5 ti_motg.c
> --- ti_motg.c 2 Feb 2024 22:14:04 -0000 1.5
> +++ ti_motg.c 12 Jul 2026 16:44:11 -0000
> @@ -49,6 +49,8 @@
> =20
> #include <dev/fdt/fdtvar.h>
> =20
> +#include <libfdt.h>
> +
> #ifdef USB_DEBUG
> #ifndef MOTG_DEBUG
> #define motgdebug 0
> @@ -165,6 +167,47 @@
> =20
> aprint_normal_dev(self, "interrupting on %s\n", intrstr);
> =20
> + bus_addr_t phy_ctrl_addr;
> + bus_size_t phy_ctrl_size;
> + int phy_phandle =3D fdtbus_get_phandle(phandle, "phys");
> + int cm_phandle =3D fdtbus_get_phandle(phy_phandle, "ti,ctrl_mod");
> + fdtbus_get_reg_byname(cm_phandle, "phy_ctrl", &phy_ctrl_addr, &phy_ctr=
l_size);
> +
> +#define USB_ALIAS "usb"
> +#define USB_ALIAS_SIZE 16
> +
> + char usb_alias[USB_ALIAS_SIZE] =3D USB_ALIAS;
> + int usb_ctrl_offset =3D 0;
> + int n =3D 0;
> + const char * prop =3D 0;
> + do {
> + if ((n =3D snprintf(&usb_alias[sizeof(USB_ALIAS)-1],
> + USB_ALIAS_SIZE-(sizeof(USB_ALIAS)-1),
> + "%d", usb_ctrl_offset)) > 0
> + && (prop =3D fdt_get_alias(fdtbus_get_data(), usb_alias)) !=3D NU=
LL) {
> + if (OF_finddevice(prop) =3D=3D phandle) {
> + break;
> + }
> + ++usb_ctrl_offset;
> + }
> + } while (n > 0 && prop);
> + if (n <=3D 0 || !prop) {
> + aprint_error_dev(self, "cannot identify usb instance\n");
> + return;
> + }
> + usb_ctrl_offset *=3D CM_USBCTL_SIZE;
> +
> + bus_space_handle_t handle;
> + if (bus_space_map(faa->faa_bst, phy_ctrl_addr, phy_ctrl_size, 0, &hand=
le) !=3D 0) {
> + aprint_error_dev(self, "couldn't map control module USB registers\n"=
);
> + return;
> + }
Yeah, don't do this.
> Index: ti_otgreg.h
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/src/sys/arch/arm/ti/ti_otgreg.h,v
> retrieving revision 1.1
> diff -u -r1.1 ti_otgreg.h
> --- ti_otgreg.h 27 Oct 2019 16:31:26 -0000 1.1
> +++ ti_otgreg.h 12 Jul 2026 16:44:11 -0000
> @@ -72,3 +72,10 @@
> =20
> #define USB_CORE_OFFSET 0x400
> #define USB_CORE_SIZE 0x400
> +
> +/* Control module register: usb_ctlN */
> +#define CM_USBCTL_SIZE 8
> +#define CM_USBCTRL_CM_PWRDN (1 << 0)
> +#define CM_USBCTRL_OTG_PWRDN (1 << 1)
> +#define CM_USBCTRL_OTGVDET_EN (1 << 19)
> +#define CM_USBCTRL_OTGSESSENDEN (1 << 20)
Please use __BIT()
https://man.netbsd.org/__BITS.3