If the mac address can not be read from the device registers or the
devicetree, a random address is generated, but this was already done from
usbnet_probe, so it is not necessary to call eth_hw_addr_random from here
again to generate another random address.
Indeed, when reset was also executed from bind, generate another random mac
address invalidated the check from usbnet_probe to configure if the assigned
mac address for the interface was random or not, because it is comparing
with the initial generated random address. Now, with only a reset from open
operation, it is just a harmless simplification.
Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]>
---
v3:
- Send the patch separately to net-next and remove fixes and stable tags.
v2:
- Split the fix and the improvement in two patches and keep curly-brackets
as Simon Horman suggests.
v1: https://lore.kernel.org/netdev/[email protected]/
drivers/net/usb/ax88179_178a.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 8ca8ace93d9c..08c9b2ab9711 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1276,7 +1276,6 @@ static void ax88179_get_mac_addr(struct usbnet *dev)
dev->net->addr_assign_type = NET_ADDR_PERM;
} else {
netdev_info(dev->net, "invalid MAC address, using random\n");
- eth_hw_addr_random(dev->net);
}
ax88179_write_cmd(dev, AX_ACCESS_MAC, AX_NODE_ID, ETH_ALEN, ETH_ALEN,
--
2.44.0
On Mon, 1 Apr 2024 10:27:25 +0200 Jose Ignacio Tornos Martinez wrote:
> If the mac address can not be read from the device registers or the
> devicetree, a random address is generated, but this was already done from
> usbnet_probe, so it is not necessary to call eth_hw_addr_random from here
> again to generate another random address.
>
> Indeed, when reset was also executed from bind, generate another random mac
> address invalidated the check from usbnet_probe to configure if the assigned
> mac address for the interface was random or not, because it is comparing
> with the initial generated random address. Now, with only a reset from open
> operation, it is just a harmless simplification.
You need to wait for the other patch to get merged,
then on Thursday after that the trees will get merged
together, and then you can post this :(
Otherwise we'll have a conflict.
--
pw-bot: defer
Understood, I will repost when the other one is merged and with the new
context diff.
Thanks
Best regards
José Ignacio
If the mac address can not be read from the device registers or the
devicetree, a random address is generated, but this was already done from
usbnet_probe, so it is not necessary to call eth_hw_addr_random from here
again to generate another random address.
Indeed, when reset was also executed from bind, generate another random mac
address invalidated the check from usbnet_probe to configure if the assigned
mac address for the interface was random or not, because it is comparing
with the initial generated random address. Now, with only a reset from open
operation, it is just a harmless simplification.
Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]>
---
v4:
- Context diff due to first patch modification.
v3:
- Send the patch separately to net-next and remove fixes and stable tags.
v2:
- Split the fix and the improvement in two patches and keep curly-brackets
as Simon Horman suggests.
v1: https://lore.kernel.org/netdev/[email protected]/
drivers/net/usb/ax88179_178a.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index a9c418890a1c..69169842fa2f 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1277,7 +1277,6 @@ static void ax88179_get_mac_addr(struct usbnet *dev)
dev->net->addr_assign_type = NET_ADDR_PERM;
} else {
netdev_info(dev->net, "invalid MAC address, using random\n");
- eth_hw_addr_random(dev->net);
}
ax88179_write_cmd(dev, AX_ACCESS_MAC, AX_NODE_ID, ETH_ALEN, ETH_ALEN,
--
2.44.0
Hello:
This patch was applied to netdev/net-next.git (main)
by David S. Miller <[email protected]>:
On Fri, 5 Apr 2024 10:24:31 +0200 you wrote:
> If the mac address can not be read from the device registers or the
> devicetree, a random address is generated, but this was already done from
> usbnet_probe, so it is not necessary to call eth_hw_addr_random from here
> again to generate another random address.
>
> Indeed, when reset was also executed from bind, generate another random mac
> address invalidated the check from usbnet_probe to configure if the assigned
> mac address for the interface was random or not, because it is comparing
> with the initial generated random address. Now, with only a reset from open
> operation, it is just a harmless simplification.
>
> [...]
Here is the summary with links:
- [net-next,v4] net: usb: ax88179_178a: non necessary second random mac address
https://git.kernel.org/netdev/net-next/c/7c7be68346b9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html