Re: [PATCH 1/2] net: asix: add 0b95:1790 to AX88179A device list

[Grant Grundler]

On Sat, Feb 10, 2024 at 11:11 AM Christian Hewitt
<christianshewitt@xxxxxxxxx> wrote:
..
> > 1) The USB output is telling you this device is a AX88179A : the
> > changes most likely should be in ax88179_178a.c using the
> > ax881798_info:
> >   https://elixir.bootlin.com/linux/latest/source/drivers/net/usb/ax88179_178a.c#L1690
>
> Yup, having sent the patch some git grep’ing showed me the newer driver
> already has the ID for the card included.
>
> > 2) What Andrew Lunn said. I'll add the asix driver should not be
> > probing (or claiming) this device - or at least be quiet about it when
> > it does.
>
> So the problem now is .. I have both drivers enabled in kernel config:
>
> https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/RPi/devices/RPi5/linux/linux.aarch64.conf#L2324-L2325


You have:
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_AX88179_178A=m
 CONFIG_NET_VENDOR_ASIX=y

and
   CONFIG_INPUT_MOUSEDEV=y

But also loads of other modules ("=m").

> And This is a Linux 6.6.10 kernel boot (without this patch):
> https://paste.libreelec.tv/oriented-mastodon.log
>
> The card is visible on the USB bus but why isn’t the correct (newer)
> driver probing? ¯\_(ツ)_/¯

I'm a bit confused too since the original email showed both asix and
ax88179_178a drivers getting invoked. You should have seen the same
previous failure with "Failed to read reg index 0x0040: -32". But
since the kernel timestamps were clipped in that email, I'm now
assuming the two messages were not printed at boot time (but rather
much later). Perhaps someone forgot to load the ax88179_178a driver
module after rebooting to their latest kernel build?

My guess is the root file system (linux distro?) doesn't include udev
at the moment. Normally, udev (user space) will "discover" the USB
device and load the appropriate device driver *module* (based on
device IDs listed in e.g. "modinfo ax88179_178a")

Note that asix driver is built-in. If CONFIG_USB_NET_AX88179_178A=y
were used instead, the system won't depend on udev.

If my guess is correct, you might want to review the entire list of
CONFIG...=m entries and determine which ones udev can help
automatically load (I would not assume all of them) and which ones
should always be loaded anyway (make them "=y").

cheers,
grant

>
> Christian
>