After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two
consecutive device resets"), reset operation, in which the default mac
address from the device is read, is not executed from bind operation and
the random address, that is pregenerated just in case, is direclty written
the first time in the device, so the default one from the device is not
even read. This writing is not dangerous because is volatile and the
default mac address is not missed.
In order to avoid this and keep the simplification to have only one
reset and reduce the delays, restore the reset from bind operation and
remove the reset that is commanded from open operation. The behavior is
the same but everything is ready for usbnet_probe.
Tested with ASIX AX88179 USB Gigabit Ethernet devices.
Restore the old behavior for the rest of possible devices because I don't
have the hardware to test.
cc: [email protected] # 6.6+
Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets")
Reported-by: Jarkko Palviainen <[email protected]>
Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]>
---
v2:
- Restore reset from bind operation to avoid problems with usbnet_probe.
v1: https://lore.kernel.org/netdev/[email protected]/
drivers/net/usb/ax88179_178a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 69169842fa2f..a493fde1af3f 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1316,6 +1316,8 @@ static int ax88179_bind(struct usbnet *dev, struct usb_interface *intf)
netif_set_tso_max_size(dev->net, 16384);
+ ax88179_reset(dev);
+
return 0;
}
@@ -1694,7 +1696,6 @@ static const struct driver_info ax88179_info = {
.unbind = ax88179_unbind,
.status = ax88179_status,
.link_reset = ax88179_link_reset,
- .reset = ax88179_reset,
.stop = ax88179_stop,
.flags = FLAG_ETHER | FLAG_FRAMING_AX,
.rx_fixup = ax88179_rx_fixup,
@@ -1707,7 +1708,6 @@ static const struct driver_info ax88178a_info = {
.unbind = ax88179_unbind,
.status = ax88179_status,
.link_reset = ax88179_link_reset,
- .reset = ax88179_reset,
.stop = ax88179_stop,
.flags = FLAG_ETHER | FLAG_FRAMING_AX,
.rx_fixup = ax88179_rx_fixup,
--
2.44.0
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <[email protected]>:
On Wed, 17 Apr 2024 10:55:13 +0200 you wrote:
> After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two
> consecutive device resets"), reset operation, in which the default mac
> address from the device is read, is not executed from bind operation and
> the random address, that is pregenerated just in case, is direclty written
> the first time in the device, so the default one from the device is not
> even read. This writing is not dangerous because is volatile and the
> default mac address is not missed.
>
> [...]
Here is the summary with links:
- [v2] net: usb: ax88179_178a: avoid writing the mac address before first reading
https://git.kernel.org/netdev/net/c/56f78615bcb1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Hello,
I am using a TP-Link UE306 USB Ethernet adapter. The kernel detects it as an ASIX AX88179A USB Ethernet adapter. When using a different MAC address than the adapter's own (i.e. MAC address randomization), I am unable to send or receive packets unless set to promiscuous mode.
I am using NetworkManager to manage my connections. When I set 802-3-ethernet.cloned-mac-address to the device's MAC address in the connection settings (i.e. `nmcli con edit), the device works as expected. When that property is not set (null value), the device is only able to receive packets when set to promiscuous mode.
uname -a output: Linux hostname 6.8.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 28 Apr 2024 18:53:26 +0000 x86_64 GNU/Linux
This is Arch Linux's kernel. The patches applied are here: <https://github.com/archlinux/linux/releases/tag/v6.8.8-arch1>
dmesg:
[37988.917741] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd
[37989.208722] usb 2-2: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 2.00
[37989.208744] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37989.208753] usb 2-2: Product: AX88179A
[37989.208760] usb 2-2: Manufacturer: ASIX
[37989.208766] usb 2-2: SerialNumber: 0003B40D
[37989.481930] cdc_ncm 2-2:2.0: MAC-Address: <removed>
[37989.481949] cdc_ncm 2-2:2.0: setting rx_max = 16384
[37989.494646] cdc_ncm 2-2:2.0: setting tx_max = 16384
[37989.506072] cdc_ncm 2-2:2.0 eth1: register 'cdc_ncm' at usb-0000:00:14.0-2, CDC NCM (NO ZLP), <removed>
journalctl (from when not in promiscuous mode):
Apr 29 17:34:47 hostname kernel: usb 2-1: new SuperSpeed USB device number 5 using xhci_hcd
Apr 29 17:34:48 hostname kernel: usb 2-1: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 2.00
Apr 29 17:34:48 hostname kernel: usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 29 17:34:48 hostname kernel: usb 2-1: Product: AX88179A
Apr 29 17:34:48 hostname kernel: usb 2-1: Manufacturer: ASIX
Apr 29 17:34:48 hostname kernel: usb 2-1: SerialNumber: 0003B40D
Apr 29 17:34:48 hostname kernel: cdc_ncm 2-1:2.0: MAC-Address: <removed>
Apr 29 17:34:48 hostname kernel: cdc_ncm 2-1:2.0: setting rx_max = 16384
Apr 29 17:34:48 hostname kernel: cdc_ncm 2-1:2.0: setting tx_max = 16384
Apr 29 17:34:48 hostname kernel: cdc_ncm 2-1:2.0 eth1: register 'cdc_ncm' at usb-0000:00:14.0-1, CDC NCM (NO ZLP), <removed>
Apr 29 17:34:48 hostname NetworkManager[5652]: <info> [1714430088.5005] manager: (eth1): new Ethernet device (/org/freedesktop/NetworkManager/Devices/14)
Apr 29 17:34:48 hostname mtp-probe[6423]: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1"
Apr 29 17:34:48 hostname mtp-probe[6423]: bus: 2, device: 5 was not an MTP device
Apr 29 17:34:49 hostname (udev-worker)[6422]: Network interface NamePolicy= disabled on kernel command line.
Apr 29 17:34:49 hostname NetworkManager[5652]: <info> [1714430089.1558] device (eth1): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Apr 29 17:34:49 hostname mtp-probe[6456]: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1"
Apr 29 17:34:49 hostname mtp-probe[6456]: bus: 2, device: 5 was not an MTP device
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2247] device (eth1): carrier: link connected
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2255] device (eth1): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2275] policy: auto-activating connection 'Wired connection 2' (e1106b48-8695-3ed4-b512-a0909ddaa247)
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2279] device (eth1): Activation: starting connection 'Wired connection 2' (e1106b48-8695-3ed4-b512-a0909ddaa247)
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2280] device (eth1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.2282] manager: NetworkManager state is now CONNECTING
Apr 29 17:34:51 hostname NetworkManager[5652]: <warn> [1714430091.2284] platform-linux: do-change-link[9]: failure 16 (Device or resource busy)
Apr 29 17:34:51 hostname systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.3634] device (eth1): set-hw-addr: set-cloned MAC address to 6A:0D:A2:E2:9D:A6 (random)
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.3646] device (eth1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.3729] device (eth1): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.3740] dhcp4 (eth1): activation: beginning transaction (timeout in 45 seconds)
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.3791] dhcp4 (eth1): dhclient started with pid 6459
Apr 29 17:34:51 hostname dhclient[6459]: DHCPREQUEST for 192.168.1.169 on eth1 to 255.255.255.255 port 67
Apr 29 17:34:51 hostname dhclient[6459]: DHCPNAK from 192.168.1.1
Apr 29 17:34:51 hostname NetworkManager[5652]: <info> [1714430091.4578] dhcp4 (eth1): state changed no lease
Thanks,
Isaac Ganoung
On Mon, 29 Apr 2024 18:16:05 -0500 Isaac Ganoung wrote:
> uname -a output: Linux hostname 6.8.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 28 Apr 2024 18:53:26 +0000 x86_64 GNU/Linux
> This is Arch Linux's kernel. The patches applied are here: <https://github.com/archlinux/linux/releases/tag/v6.8.8-arch1>
v6.8.8 has 56f78615b already. We need another patch, Jose?
> v6.8.8 has 56f78615b already. We need another patch, Jose?
Hello Jakub,
I will try to analyze it during the next week (I will be out until then).
In the meantime, in order to get more information about the possible
regression:
Isaac,
Which version was it working in?
Do you know if it was working before d2689b6a86b9 ("net: usb: ax88179_178a:
avoid two consecutive device resets")?
Best regards
José Ignacio
Hi, Jose
On Wed, 1 May 2024 at 00:01, Jose Ignacio Tornos Martinez
<[email protected]> wrote:
>
> > v6.8.8 has 56f78615b already. We need another patch, Jose?
>
> Hello Jakub,
>
> I will try to analyze it during the next week (I will be out until then).
>
Not sure if you have checked it already, this commit causes an issue for the
db845c + ACK android15-6.6[1] + AOSP main Android configuration, the
ethernet does not work,
there is no ip address assigned, like:
db845c:/ # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 02:00:89:7a:fb:61 Driver ax88179_178a
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 TX bytes:0
db845c:/ #
if I have this change reverted, then it will work again:
db845c:/ # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 02:00:89:7a:fb:61 Driver ax88179_178a
inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: 240e:305:2c88:4700:4b6d:926d:1592:fc5e/64
Scope: Global
inet6 addr: 240e:305:2c88:4700:edc9:86ec:7c5e:b028/64
Scope: Global
inet6 addr: fe80::32ce:8a2e:269d:e53f/64 Scope: Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:966 errors:0 dropped:33 overruns:0 frame:0
TX packets:475 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:51193 TX bytes:39472
db845c:/ #
One thing to be noted here is that, during the boot, the MAC address
will be reassigned
to make sure each board has its own unique MAC address with the
following commands:
/vendor/bin/ifconfig eth0 down
/vendor/bin/ifconfig eth0 hw ether "${ETHADDR}"
/vendor/bin/ifconfig eth0 up
Could you please help have a check and fix or give some suggestions on
this issue?
[1]: https://android.googlesource.com/kernel/common/+/refs/heads/android15-6.6
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-android
Hello Yongqin,
Sorry for the inconveniences.
I don't have the db845c, could you provide information about the type of
device and protocol used?
Related driver logs would be very helpful for this.
Best regards
José Ignacio
Hi, Jose
On Wed, 8 May 2024 at 15:57, Jose Ignacio Tornos Martinez
<[email protected]> wrote:
>
> Hello Yongqin,
>
> Sorry for the inconveniences.
>
> I don't have the db845c, could you provide information about the type of
> device and protocol used?
The db845c uses an RJ45 as the physical interface.
It has the translation from PCIe0 to USB and USB to Gigabit Ethernet controller.
For details, maybe you could check the hardware details from the documents here:
https://www.96boards.org/documentation/consumer/dragonboard/dragonboard845c/hardware-docs/
> Related driver logs would be very helpful for this.
Here is the log from the serial console side:
https://gist.github.com/liuyq/809247d8a12aa1d9e03058e8371a4d44
Please let me know if I could try and provide more information for the
investigation.
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-android
Hello José,
I'm testing on the 6.6 kernel with a "0b95:1790 ASIX Electronics Corp.
AX88179 Gigabit Ethernet" device.
after applying commit 56f78615bcb1 ("net: usb: ax88179_178a: avoid
writing the mac address before first reading")
the network will no longer work after brining the device down.
After plugging in the device, it generally will work with ifconfig:
$ ifconfig eth0 <ip address>
However, if I then try bringing the devcie down and back up, it no longer works.
$ ifconfig eth0 down
$ ifconfig eth0 <ip address>
$ ethtool eth0 | grep detected
Link detected: no
The link will continue to report as undetected.
If I revert 56f78615bcb1 the device will work after bringing it down
and back up.
If I build at commit d7a319889498 ("net: usb: ax88179_178a: avoid two
consecutive device resets") and its
parent d7a319889498^ these also work.
Is this something you have seen before with your test devices?
Regards,
Jeff
Hello Jeffery,
Sorry for the inconveniences.
I am working on it, the fix will be very soon.
Best regards
José Ignacio
Hi, Jose
On Wed, 8 May 2024 at 12:41, Yongqin Liu <[email protected]> wrote:
>
> Hi, Jose
>
> On Wed, 8 May 2024 at 15:57, Jose Ignacio Tornos Martinez
> <[email protected]> wrote:
> >
> > Hello Yongqin,
> >
> > Sorry for the inconveniences.
> >
> > I don't have the db845c, could you provide information about the type of
> > device and protocol used?
>
> The db845c uses an RJ45 as the physical interface.
> It has the translation from PCIe0 to USB and USB to Gigabit Ethernet controller.
>
> For details, maybe you could check the hardware details from the documents here:
> https://www.96boards.org/documentation/consumer/dragonboard/dragonboard845c/hardware-docs/
>
> > Related driver logs would be very helpful for this.
>
> Here is the log from the serial console side:
> https://gist.github.com/liuyq/809247d8a12aa1d9e03058e8371a4d44
>
> Please let me know if I could try and provide more information for the
> investigation.
Just want to check, not sure if you have checked the serial log file,
or do you have other suggestions about what we should try next,
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-android
Hello Yongqin,
I could not get a lot of information from the logs, but at least I
identified the device.
Anyway, I found the issue and the solution is being applied:
https://lore.kernel.org/netdev/171564122955.1634.5508968909715338167.git-patchwork-notify@kernel.org/
Best regards
José Ignacio
Hi Jose
On Tue, 14 May 2024 at 09:00, Jose Ignacio Tornos Martinez
<[email protected]> wrote:
>
> Hello Yongqin,
>
> I could not get a lot of information from the logs, but at least I
> identified the device.
> Anyway, I found the issue and the solution is being applied:
> https://lore.kernel.org/netdev/171564122955.1634.5508968909715338167.git-patchwork-notify@kernel.org/
Ah, I was not aware of it:(
Thanks a lot for the work!
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-android
Hi, Jose
On Tue, 14 May 2024 at 17:14, Yongqin Liu <[email protected]> wrote:
>
> Hi Jose
> On Tue, 14 May 2024 at 09:00, Jose Ignacio Tornos Martinez
> <[email protected]> wrote:
> >
> > Hello Yongqin,
> >
> > I could not get a lot of information from the logs, but at least I
> > identified the device.
> > Anyway, I found the issue and the solution is being applied:
> > https://lore.kernel.org/netdev/171564122955.1634.5508968909715338167.git-patchwork-notify@kernel.org/
> Ah, I was not aware of it:(
>
Sorry, I was in a trip last week, and not able to test it,
But the patch does not help for my case, here is the output on the
serial console side
after I cherry picked the above patch you shared with me.
Could you please help to check more?
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-android
Hello Jose,
I can confirm that
https://lore.kernel.org/netdev/[email protected]/
resolves the up/down link issue for me when applied to my 6.6 kernel.
Thank you for resolving the issue.
Regards,
Jeff