Hello Simon,

quoted

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