Hi Marek, On 7/12/2026 3:39 PM, Marek Vasut wrote: > On 7/12/26 12:14 PM, Jonas Karlman wrote: > > Hello Jonas, > >>> On 7/11/26 6:08 PM, Jonas Karlman wrote: >>>> The ASIX AX88179A, AX88772D and AX88279 USB Ethernet controller >>>> revisions has both CDC ECM and CDC NCM support. >>>> >>>> AX88179: 0b95:1790 1.00 >>>> AX88179A: 0b95:1790 2.00 >>>> AX88772D: 0b95:1790 3.00 >>>> AX88279: 0b95:1790 4.00 >>>> >>>> Prefer using the CDC NCM or CDC ECM driver for the 2.00-4.00 version >>>> range of the 0b95:1790 ASIX USB Ethernet controllers. >>> >>> Why this specific range ? >> >> Sorry, my commit message was not clear enough. Only the last three >> entries listed above have ECM/NCM support stated in their datasheet. >> >> The version seems to correlate with the different "generation" of the >> AX88179/AX88772 controllers. >> >> The initial AX88179/AX88772 revisions, tagged with version 1.00, does >> not state support for ECM/NCM in the datasheet. And all my dongles are >> tagged with version 2.00 or above, i.e. using AX88179A or a later >> revision or version in the family. >> >> The version matching also seems to match revision handling in vendor >> driver [1], so that suggest that these assumptions are correct. Based on >> [1] it looks like version 5.00 for AX88279A was added recently. >> >> [1] >> https://github.com/mmoya/asix-usb-nic-linux-driver/blob/main/ax_main.c#L2913-L2939 > > OK > >>> [...] >>> >>>> +++ b/drivers/usb/eth/asix88179.c >>>> @@ -691,7 +691,12 @@ U_BOOT_DRIVER(ax88179_eth) = { >>>> }; >>>> >>>> static const struct usb_device_id ax88179_eth_id_table[] = { >>>> +#if IS_ENABLED(CONFIG_USB_ETHER_CDC_ECM) || >>>> IS_ENABLED(CONFIG_USB_ETHER_CDC_NCM) >>> >>> This is USB, this should be auto-detected without any need for ifdeffery. >> >> As stated in the cover letter, U-Boot only support driver detection of the >> first (cfgno=0) configuration. >> >> U-Boot currently only has support for automatic binding of the first >> device configuration for devices, so this implementaion works by adding >> bindings for VID/PID pairs and letting the drivers try to change active >> configuration during probe. >> >> To work around this limitation, the VID/PID pair is added here. >> >> U-Boot USB core structs only have support for carrying information about >> a single configuration, so the cfgno=0 is set as active configuration >> and USB driver matches only on information of this first config. >> >> Initially I tried to add limited support for at least parsing all >> configuration descriptors and make usb command list all possible configs. >> >> However, there are other parts that only where saved during config desc >> parsing and where then overwritten by parsing of next config descriptor. >> >> Next hack was to just force setting the cfgno that matched NCM, and that >> made USB driver matching the new NCM driver, but this was not scalable. >> >> So to not having to re-work how USB core store config and handles driver >> matching, the cleanest way was to export the set config helper and use >> VID/PID matching in these drivers. >> >> Hopefully someone can add proper support for driver matching based on >> all possible device configurations in the future. Not something I plan >> to address, I just wanted my USB Ethernet dongles to work :-) > > Try and look at 575c68279c41 ("usb: kbd: support Apple Magic Keyboards > (2021)") , maybe that can help with some handling of second interface > descriptor ?
That seem to be an issue of Interface Descriptor. CDC ECM/NCM modes are described using dedicated Configuration Descriptors, typically there is: cfgno=0, class: Vendor Specific cfgno=1, class: Communications, NCM cfgno=2, class: Communications, ECM or similar, see [2] for a full descriptor print of AX88179A and RTL8156. And U-Boot only use information from the first Configuration Descriptor when matching drivers, it also never test/use any other configuration. This is why we need the VID/PID matching in CDC NCM/ECM drivers, unless someone first re-work USB core to fully support multiple configuration descriptors. Here I did minimal effort to help support multiple configurations. Do you think this should be handled differently? Is it the use of #if #else that is the problem? Please be specific on what and how you think it should be handled differently. [2] https://gist.github.com/Kwiboo/166f1ca8d9ea6cfd35f0ab17f719fa76 > >>>> + { USB_DEVICE_VER(0x0b95, 0x1790, 0, 0x0100), >>>> + .driver_info = FLAG_TYPE_AX88179 }, >>>> +#else >>>> { USB_DEVICE(0x0b95, 0x1790), .driver_info = FLAG_TYPE_AX88179 >>>> }, >>>> +#endif >>>> { USB_DEVICE(0x0b95, 0x178a), .driver_info = FLAG_TYPE_AX88178a >>>> }, >>> [...] >>> >>> I recall there was some USB URB size limit on this ASIX USB MAC, was >>> that ever sorted out ? >> >> Correct, the ax88179_eth driver is currently requesting a bigger RX >> buffer than what the MAC seem to be able to handle when EHCI controller >> is used. >> >> Trying to get a workaround that limited the size to 16 KiB, similar to >> what Linux uses, was partially rejected. >> >> This ultimately made me to look closer at NCM/ECM and the implementation >> of these drivers. And for U-Boot purpose using NCM/ECM mode seems more >> logical than continue trying to use the undocumented vendor magic :-) >> >> For ECM only a single packet is sent, so a 2 KiB buffer is used. And for >> NCM it defaults to 16 KiB and also uses the information provided from >> the descriptors to keep the the used buffer size within device limits. >> >> To conclude, using ECM/NCM mode resolved all issues I had related to USB >> URB size and this ASIX USB MAC so I have now fully switched to just >> using ECM/NCM driver for the boards in my personal lab. > Can we fix the EHCI driver too ? > > It feels like there is a bug, which is papered over by these patches. Yes, there are plenty of bugs, e.g.: - ax88179 vendor format store the "header" as a "footer" so it fully depends on the packets read back reporting correct size or bad data is treated as the "header" - ax88179 driver is requesting too much data so the "header" gets misaligned and packets gets dropped - ECHI core does not handle short qTD in same way as Linux and instead just appends data to return as much data as possible, causing "header" to be located in the middle of the returned data [3] There was also similar issues when an DWC3 host was used, so due to the vendor format being so sensitive to size being correctly reported forcing use of NCM/ECM and only keep using this driver for models that must use it to function was least resisting way to "solve" all these issues. [3] https://gist.github.com/Kwiboo/43c141390fe12dbf54f0652a32804e15 Regards, Jonas
