Subject: Re: [PATCH net] net: usb: usbnet: fix name regression

From: Jakub Kicinski <[email-masked]>
Date: Mon, 2 Dec 2024 16:26:53 -0800

On Tue, 3 Dec 2024 08:39:47 +0900 'Dominique MARTINET' wrote:
> > > If that is what was intended, I am fine with this, but I think these
> > > local ppp usb interfaces are rather common in the cheap modem world.  
> > 
> > Which will work, as long as they are marked appropriately; that is
> > marked with FLAG_POINTTOPOINT.  
> 
> Hmm, but the check here was either FLAG_POINTTOPOINT being unset or not
> locally administered address, so to keep the usb0 name we need both?
> 
> >             if ((dev->driver_info->flags & FLAG_ETHER) != 0 &&
> >                 ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 ||
> > -                (net->dev_addr [0] & 0x02) == 0))
> > +                /* somebody touched it*/
> > +                !is_zero_ether_addr(net->dev_addr)))
> >                       strscpy(net->name, "eth%d", sizeof(net->name));  
> 
> i.e., something that didn't have FLAG_POINTTOPOINT in the first place
> would not get into this mac consideration, so it must be set.

Right! I missed the && plus ||

> My problematic device here has FLAG_POINTTOPOINT and a (locally
> admistered) mac address set, so it was not renamed up till now,
> but the new check makes the locally admistered mac address being set
> mean that it is no longer eligible to keep the usbX name.

Ideally, udev would be the best option, like Greg said.
This driver is already a fragile pile of workarounds.

If you really really want the old behavior tho, let's convert 
the zero check to  !is_zero_ether_addr() && !is_local_ether_addr().
Maybe factor out the P2P + address validation to a helper because
the && vs || is getting complicated.