Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1420027 > unrolled thread

Re: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v6] r8152: Add support for setting pass through MAC  address on RTL8153-AD David Miller <davem@davemloft.net> - 2016-06-11 19:50 +0200
    RE: [PATCH v6] r8152: Add support for setting pass through MAC  address on RTL8153-AD <Mario_Limonciello@Dell.com> - 2016-06-14 17:10 +0200
    Re: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD Pali Rohár <pali.rohar@gmail.com> - 2016-06-14 18:30 +0200
      Re: [PATCH v6] r8152: Add support for setting pass through MAC  address on RTL8153-AD Greg KH <gregkh@linuxfoundation.org> - 2016-06-14 18:50 +0200
        Re: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD Pali Rohár <pali.rohar@gmail.com> - 2016-06-14 18:50 +0200
          RE: [PATCH v6] r8152: Add support for setting pass through MAC  address on RTL8153-AD <Mario_Limonciello@Dell.com> - 2016-06-14 19:00 +0200
            Re: [PATCH v6] r8152: Add support for setting pass through MAC  address on RTL8153-AD Andrew Lunn <andrew@lunn.ch> - 2016-06-14 19:30 +0200
              RE: [PATCH v6] r8152: Add support for setting pass through MAC  address on RTL8153-AD <Mario_Limonciello@Dell.com> - 2016-06-14 20:00 +0200
          Re: [PATCH v6] r8152: Add support for setting pass through MAC  address on RTL8153-AD David Miller <davem@davemloft.net> - 2016-06-14 20:40 +0200
            RE: [PATCH v6] r8152: Add support for setting pass through MAC  address on RTL8153-AD <Mario_Limonciello@Dell.com> - 2016-06-15 00:30 +0200
            RE: [PATCH v6] r8152: Add support for setting pass through MAC  address on RTL8153-AD <Mario_Limonciello@Dell.com> - 2016-06-23 00:20 +0200

#1420027 — Re: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD

From: Andrew Lunn <andrew@lunn.ch>
Date: Sat, 11 Jun 2016 17:39:21 +0200

> What is still open is do we want to accept it at all? Do we accept the
> concept of putting the same MAC address on multiple interfaces at
> hotplug time? Do we trust BIOS vendors to not keep changing DSDT
> property name, since it is not standardised?
> 
> Do we want this at all should be decided by somebody more senior then
> those passing comments on the code.

Indeed, I think the behavior of using the same MAC address on multiple
interfaces if we plug several of these in at once is not good.

We shouldn't behave this way just because the Microsoft driver does.

[toc] | [next] | [standalone]

#1421998

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Saturday, June 11, 2016 12:42 PM
> To: andrew@lunn.ch
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>;
> hayeswang@realtek.com; linux-kernel@vger.kernel.org;
> netdev@vger.kernel.org; linux-usb@vger.kernel.org; pali.rohar@gmail.com;
> anthony.wong@canonical.com; gregkh@linuxfoundation.org
> Subject: Re: [PATCH v6] r8152: Add support for setting pass through MAC
> address on RTL8153-AD
> 
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Sat, 11 Jun 2016 17:39:21 +0200
> 
> > What is still open is do we want to accept it at all? Do we accept the
> > concept of putting the same MAC address on multiple interfaces at
> > hotplug time? Do we trust BIOS vendors to not keep changing DSDT
> > property name, since it is not standardised?
> >

It's worth saying - standardized a property name doesn't indemnify it.
Properties change all the time from one version of a spec to another.

I can only speak for Dell, but it's in our best interest to keep the BIOS
side of the codebase around this simpler too.

> > Do we want this at all should be decided by somebody more senior then
> > those passing comments on the code.
> 
> Indeed, I think the behavior of using the same MAC address on multiple
> interfaces if we plug several of these in at once is not good.
> 
> We shouldn't behave this way just because the Microsoft driver does.

This is really grasping at an extreme corner case scenario.

Dell TB15 and WD15 docks are currently only ones on the market with
RTL8135-AD and MAC address pass through efuse bit set.  These docks
are not inexpensive.  If someone really wants multiple USB NIC's plugged
in, they can pick up a second USB NIC from the web for far cheaper than
buying a second dock.

Also for what it's worth, the docks don't allow daisy chaining.  The dock EC's 
will reject the second dock from functioning through the downstream 
connection.  The only way that two docks could be hooked up and
functional is on a machine with multiple type C ports.

If you still think it's worth solving, what would you like done as an 
alternative?  I would really like to have some implementation of this
that you guys are comfortable with upstream.

There was already discussion and an implementation in this 
thread about tracking if the aux MAC was assigned to something and only 
allowing one device to get that assignment.  There was a limitation that 
you won't be able to know which device gets the auxiliary MAC address.  
It will be based solely upon hotplug order.

There was also in one version of the patch a way to turn off this behavior
In a module parameter.  Greg KH wasn't fond of that, so it's not present
in the current version.

I can add either of those back in if they would help the case.

Another option I wanted to offer was turning this behavior on via kernel
configuration option and let the distros decide if they want to turn it on
for users.

[toc] | [prev] | [next] | [standalone]

#1422064 — Re: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD

[Multipart message — attachments visible in raw view] — view raw

On Saturday 11 June 2016 19:42:26 David Miller wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Sat, 11 Jun 2016 17:39:21 +0200
> 
> > What is still open is do we want to accept it at all? Do we accept
> > the concept of putting the same MAC address on multiple interfaces
> > at hotplug time? Do we trust BIOS vendors to not keep changing
> > DSDT property name, since it is not standardised?
> > 
> > Do we want this at all should be decided by somebody more senior
> > then those passing comments on the code.
> 
> Indeed, I think the behavior of using the same MAC address on
> multiple interfaces if we plug several of these in at once is not
> good.
> 
> We shouldn't behave this way just because the Microsoft driver does.

I agree, but in some cases it is night mare for local admins when 
booting different OS cause changing MAC address on local network.

Another similar situation: Imagine that you have two USB network cards 
and both have "burned" into their registers same MAC address. If you 
connect both those USB network cards, linux kernel bind appropriate 
driver which read MAC address for both those cards. But those addresses 
are same. What will linux kernel do in this case?

This is very similar situation as those Dell usb network cards told us 
"hey, use address which is in ACPI DSDT table".

Either we should trust what network card what told us, or not and then 
generate MAC addresses in better way.

Just my opinion...

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1422079

On Tue, Jun 14, 2016 at 06:28:10PM +0200, Pali Rohár wrote:
> On Saturday 11 June 2016 19:42:26 David Miller wrote:
> > From: Andrew Lunn <andrew@lunn.ch>
> > Date: Sat, 11 Jun 2016 17:39:21 +0200
> > 
> > > What is still open is do we want to accept it at all? Do we accept
> > > the concept of putting the same MAC address on multiple interfaces
> > > at hotplug time? Do we trust BIOS vendors to not keep changing
> > > DSDT property name, since it is not standardised?
> > > 
> > > Do we want this at all should be decided by somebody more senior
> > > then those passing comments on the code.
> > 
> > Indeed, I think the behavior of using the same MAC address on
> > multiple interfaces if we plug several of these in at once is not
> > good.
> > 
> > We shouldn't behave this way just because the Microsoft driver does.
> 
> I agree, but in some cases it is night mare for local admins when 
> booting different OS cause changing MAC address on local network.
> 
> Another similar situation: Imagine that you have two USB network cards 
> and both have "burned" into their registers same MAC address. If you 
> connect both those USB network cards, linux kernel bind appropriate 
> driver which read MAC address for both those cards. But those addresses 
> are same. What will linux kernel do in this case?

If you can find such a broken USB device, try it and see :)

(hint, might be hard to find, I've never seen such a device before.)

I don't see how that pertains to this issue, sorry, how does broken USB
hardware compare to a working Dell device?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1422084 — Re: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD

[Multipart message — attachments visible in raw view] — view raw

On Tuesday 14 June 2016 18:40:17 Greg KH wrote:
> On Tue, Jun 14, 2016 at 06:28:10PM +0200, Pali Rohár wrote:
> > On Saturday 11 June 2016 19:42:26 David Miller wrote:
> > > From: Andrew Lunn <andrew@lunn.ch>
> > > Date: Sat, 11 Jun 2016 17:39:21 +0200
> > > 
> > > > What is still open is do we want to accept it at all? Do we
> > > > accept the concept of putting the same MAC address on multiple
> > > > interfaces at hotplug time? Do we trust BIOS vendors to not
> > > > keep changing DSDT property name, since it is not
> > > > standardised?
> > > > 
> > > > Do we want this at all should be decided by somebody more
> > > > senior then those passing comments on the code.
> > > 
> > > Indeed, I think the behavior of using the same MAC address on
> > > multiple interfaces if we plug several of these in at once is not
> > > good.
> > > 
> > > We shouldn't behave this way just because the Microsoft driver
> > > does.
> > 
> > I agree, but in some cases it is night mare for local admins when
> > booting different OS cause changing MAC address on local network.
> > 
> > Another similar situation: Imagine that you have two USB network
> > cards and both have "burned" into their registers same MAC
> > address. If you connect both those USB network cards, linux kernel
> > bind appropriate driver which read MAC address for both those
> > cards. But those addresses are same. What will linux kernel do in
> > this case?
> 
> If you can find such a broken USB device, try it and see :)

What do you mean by broken USB device?

You have never seen two ethernet cards with same MAC addresses? Right I 
have not seen two USB, but there is non zero chance that could happen. 
Specially now when more and more people starts using USB network cards.

> (hint, might be hard to find, I've never seen such a device before.)
> 
> I don't see how that pertains to this issue, sorry, how does broken
> USB hardware compare to a working Dell device?

It is same, how to handle two network cards which tell us, that they 
have same MAC addresses.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1422093

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Tuesday, June 14, 2016 11:48 AM
> To: Greg KH <gregkh@linuxfoundation.org>
> Cc: David Miller <davem@davemloft.net>; andrew@lunn.ch; Limonciello,
> Mario <Mario_Limonciello@Dell.com>; hayeswang@realtek.com; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org; linux-
> usb@vger.kernel.org; anthony.wong@canonical.com
> Subject: Re: [PATCH v6] r8152: Add support for setting pass through MAC
> address on RTL8153-AD
> 
> On Tuesday 14 June 2016 18:40:17 Greg KH wrote:
> > On Tue, Jun 14, 2016 at 06:28:10PM +0200, Pali Rohár wrote:
> > > On Saturday 11 June 2016 19:42:26 David Miller wrote:
> > > > From: Andrew Lunn <andrew@lunn.ch>
> > > > Date: Sat, 11 Jun 2016 17:39:21 +0200
> > > >
> > > > > What is still open is do we want to accept it at all? Do we
> > > > > accept the concept of putting the same MAC address on multiple
> > > > > interfaces at hotplug time? Do we trust BIOS vendors to not
> > > > > keep changing DSDT property name, since it is not
> > > > > standardised?
> > > > >
> > > > > Do we want this at all should be decided by somebody more
> > > > > senior then those passing comments on the code.
> > > >
> > > > Indeed, I think the behavior of using the same MAC address on
> > > > multiple interfaces if we plug several of these in at once is not
> > > > good.
> > > >
> > > > We shouldn't behave this way just because the Microsoft driver
> > > > does.
> > >
> > > I agree, but in some cases it is night mare for local admins when
> > > booting different OS cause changing MAC address on local network.
> > >
> > > Another similar situation: Imagine that you have two USB network
> > > cards and both have "burned" into their registers same MAC
> > > address. If you connect both those USB network cards, linux kernel
> > > bind appropriate driver which read MAC address for both those
> > > cards. But those addresses are same. What will linux kernel do in
> > > this case?
> >
> > If you can find such a broken USB device, try it and see :)
> 
> What do you mean by broken USB device?
> 
> You have never seen two ethernet cards with same MAC addresses? Right I
> have not seen two USB, but there is non zero chance that could happen.
> Specially now when more and more people starts using USB network cards.
> 
> > (hint, might be hard to find, I've never seen such a device before.)
> >
> > I don't see how that pertains to this issue, sorry, how does broken
> > USB hardware compare to a working Dell device?
> 
> It is same, how to handle two network cards which tell us, that they
> have same MAC addresses.
> 

The kernel handles this just fine.  In doing this patch I checked to see
what it does in that scenario.  Two devices are made.  systemd doesn't
rename the second device via the MAC name (eg enxAABBCCDDEEFF).

[toc] | [prev] | [next] | [standalone]

#1422128

> > It is same, how to handle two network cards which tell us, that they
> > have same MAC addresses.
> > 
> 
> The kernel handles this just fine.  In doing this patch I checked to see
> what it does in that scenario.  Two devices are made.  systemd doesn't
> rename the second device via the MAC name (eg enxAABBCCDDEEFF).

What does you dhcp server do? Does it gives out the same IP address?
You then have two interfaces on the same network, with the same MAC
address and IP address. Then what happens?

     Andrew

[toc] | [prev] | [next] | [standalone]

#1422153

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Tuesday, June 14, 2016 12:23 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: pali.rohar@gmail.com; gregkh@linuxfoundation.org;
> davem@davemloft.net; hayeswang@realtek.com; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org; linux-
> usb@vger.kernel.org; anthony.wong@canonical.com
> Subject: Re: [PATCH v6] r8152: Add support for setting pass through MAC
> address on RTL8153-AD
> 
> > > It is same, how to handle two network cards which tell us, that they
> > > have same MAC addresses.
> > >
> >
> > The kernel handles this just fine.  In doing this patch I checked to see
> > what it does in that scenario.  Two devices are made.  systemd doesn't
> > rename the second device via the MAC name (eg enxAABBCCDDEEFF).
> 
> What does you dhcp server do? Does it gives out the same IP address?
> You then have two interfaces on the same network, with the same MAC
> address and IP address. Then what happens?
> 
>      Andrew

I didn't test it on the same network, I used two separate networks.

I expect that the DHCP server would be awfully confused and you'd
run down an interesting problem path if it got the same MAC twice.

[toc] | [prev] | [next] | [standalone]

#1422194

From: Pali Rohár <pali.rohar@gmail.com>
Date: Tue, 14 Jun 2016 18:47:36 +0200

> You have never seen two ethernet cards with same MAC addresses? Right I 
> have not seen two USB, but there is non zero chance that could happen. 

It would be an error scenerio, and something to be avoided.

It is a valid and correct assumption that one is able to put
several devices at the same time on the same physical network
and expect it to work.

The behavior added by the change in question invalidates that.

I'm trying to consider the long term aspects of this, which is that if
more devices adopt this scheme we're in trouble if we blindly
interpret the MAC address in this way.

This firmware MAC property facility seems to be designed with only an
extremely narrow use case being considered.

[toc] | [prev] | [next] | [standalone]

#1422404

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, June 14, 2016 1:35 PM
> To: pali.rohar@gmail.com
> Cc: gregkh@linuxfoundation.org; andrew@lunn.ch; Limonciello, Mario
> <Mario_Limonciello@Dell.com>; hayeswang@realtek.com; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org; linux-
> usb@vger.kernel.org; anthony.wong@canonical.com
> Subject: Re: [PATCH v6] r8152: Add support for setting pass through MAC
> address on RTL8153-AD
> 
> From: Pali Rohár <pali.rohar@gmail.com>
> Date: Tue, 14 Jun 2016 18:47:36 +0200
> 
> > You have never seen two ethernet cards with same MAC addresses? Right
> I
> > have not seen two USB, but there is non zero chance that could happen.
> 
> It would be an error scenerio, and something to be avoided.
> 
> It is a valid and correct assumption that one is able to put
> several devices at the same time on the same physical network
> and expect it to work.
> 
> The behavior added by the change in question invalidates that.
> 
> I'm trying to consider the long term aspects of this, which is that if
> more devices adopt this scheme we're in trouble if we blindly
> interpret the MAC address in this way.
> 

Do you mean if other manufacturers start to ship devices with 
RTL8135-AD's w/ this pass through bit set and people start to try to 
mix and match?

> This firmware MAC property facility seems to be designed with only an
> extremely narrow use case being considered.

Yes, as I understand it this is the reason that it's only on such specific devices
that the mac address pass through bit is actually set on the efuse.

[toc] | [prev] | [next] | [standalone]

#1429137

> -----Original Message-----
> From: Limonciello, Mario
> Sent: Tuesday, June 14, 2016 5:27 PM
> To: 'David Miller' <davem@davemloft.net>; pali.rohar@gmail.com
> Cc: gregkh@linuxfoundation.org; andrew@lunn.ch;
> hayeswang@realtek.com; linux-kernel@vger.kernel.org;
> netdev@vger.kernel.org; linux-usb@vger.kernel.org;
> anthony.wong@canonical.com
> Subject: RE: [PATCH v6] r8152: Add support for setting pass through MAC
> address on RTL8153-AD
> 
> > -----Original Message-----
> > From: David Miller [mailto:davem@davemloft.net]
> > Sent: Tuesday, June 14, 2016 1:35 PM
> > To: pali.rohar@gmail.com
> > Cc: gregkh@linuxfoundation.org; andrew@lunn.ch; Limonciello, Mario
> > <Mario_Limonciello@Dell.com>; hayeswang@realtek.com; linux-
> > kernel@vger.kernel.org; netdev@vger.kernel.org; linux-
> > usb@vger.kernel.org; anthony.wong@canonical.com
> > Subject: Re: [PATCH v6] r8152: Add support for setting pass through MAC
> > address on RTL8153-AD
> >
> > From: Pali Rohár <pali.rohar@gmail.com>
> > Date: Tue, 14 Jun 2016 18:47:36 +0200
> >
> > > You have never seen two ethernet cards with same MAC addresses?
> Right
> > I
> > > have not seen two USB, but there is non zero chance that could happen.
> >
> > It would be an error scenerio, and something to be avoided.
> >
> > It is a valid and correct assumption that one is able to put
> > several devices at the same time on the same physical network
> > and expect it to work.
> >
> > The behavior added by the change in question invalidates that.
> >
> > I'm trying to consider the long term aspects of this, which is that if
> > more devices adopt this scheme we're in trouble if we blindly
> > interpret the MAC address in this way.
> >
> 
> Do you mean if other manufacturers start to ship devices with
> RTL8135-AD's w/ this pass through bit set and people start to try to
> mix and match?
> 
> > This firmware MAC property facility seems to be designed with only an
> > extremely narrow use case being considered.
> 
> Yes, as I understand it this is the reason that it's only on such specific devices
> that the mac address pass through bit is actually set on the efuse.

David,

Did you have any more thoughts about this?  I'm happy to make some other
adjustments to the patch, if you have some recommendations.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web