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