Hello Simon,
In addition, if mac address can not be read from the driver, a random address is configured again, so it is not necessary to call eth_hw_addr_random from here. Indeed, in this situtatuon, when reset was also executed from bind, this was invalidating the check to configure if the assigned mac address for the interface was random or not.
I also agree with your analysis here. However it does seem to be a separate problem. And perhaps warrants a separate patch. I am also wondering if this is more of a clean-up than a fix: does it cause a bug that is observable by users?
You are right, really it is a separate improvement or simplification. Right now, it is not affecting the users and it is not producing any problem, just a second random address is generated if there is any problem, and this is not necessary, because there is a random address generated previously. When the extra reset was done during binding operation, as we were modifying the pregenerated random address, the check in usbnet_probe was useless. Ok, I will split the patch in two to be considered separately, the first with the important fix and the second with the commented improvement or clean-up.
nit: AFAIK, if one arm of a conditional has curly-brackets, then all should. So there is no need to drop them here.
I didn't know the related criteria, I will do as you say.
Thank you
Best regards José Ignacio