[PATCH 2/6] usb: eth: asix88179: Use a fixed URB buffer size of 16 KiB

[Marek Vasut]

On 1/30/26 11:54 AM, Jonas Karlman wrote:

Hello Jonas,

>>> Change to use a fixed URB buffer size of 16 KiB to fix use of Ethernet,
>>
>> Why 16 kiB and not something else ?
> 
> Using anything larger than 16 KiB resulted in issues, and a datasheet
> for the older AX88772 prior to the D revision mention default 16 KiB for
> "Maximum Frame Burst transfer on USB bus" so 16 KiB seemed like a safe
> size to use for newer revisions, and this also made it possible to use
> fragmented packets up to just below 16 KiB.

Please include this information in the commit message.

>> Is this a USB controller related problem/limitation ? Maybe the DWC2
>> driver needs fixing instead, to handler larger buffers ?
> 
> I accidentally mixed up what host controller was being used, the board in
> question is using a generic-echi controller not the DWC2 as I stated.
> 
> Below follow some debug prints, what can be observed is that when
> length=26624 is returned from ehci_submit_bulk_msg the ax88179_eth_recv
> will return len >16 KiB and that result in the rx_hdr at the end of
> the returned buffer being bogus data, e.g. for following:
> 
>    BOOTP broadcast 1
>    ** asix_send_common(), len 342
>    ehci_submit_bulk_msg: dev='usb at ff100000', udev=00000000f9f2c520
>    dev=00000000f9f2c520, pipe=c0018303, buffer=00000000f9ee0680, length=350, req=0000000000000000
>    TOKEN=0x80008c00
>    Tx: len = 346, actual = 350, err = 0
> 
>    ax88179_eth_recv: first try, len=0
>    ehci_submit_bulk_msg: dev='usb at ff100000', udev=00000000f9f2c520
>    dev=00000000f9f2c520, pipe=c0010383, buffer=00000000f9f2cf00, length=26624, req=0000000000000000
>    TOKEN=0xa7808d00
>    ax88179_eth_recv: second try, len=16512
>    ax88179_eth_recv: 2 packets received, pkt header at 112
>    ax88179_eth_recv: return packet of 106 bytes (1 packets left)
>    ax88179_eth_recv: return packet of 0 bytes (0 packets left)
> 
> The buffers returned from the AX88179 contains something like:
> 
>   <packet data N><N+1>... <packet header N><N+1>... <RX HDR>
> 
> Above the "2 packets received, pkt header at 112" seem to indicate that
> the pkt header is in the middle of the packet data, in other instances
> the rx_hdr seem to indicate that the buffer contains  thousands of
> packets, i.e. the rx_hdr is likely bogus when more than 16 KiB is
> returned from ehci_submit_bulk_msg.
Is this maybe some wrap-around ? 16 kiB x4 is 65536 , which is 16bit limit.