Message-ID: <ca34e1ad-1170-4398-beb6-28559a270908@lunn.ch>
Date: Mon, 3 Jul 2023 19:35:11 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Fernando Eckhardt Valle (FIPT)" <fevalle@....br>
Cc: "davem@...emloft.net" <davem@...emloft.net>,
	"jesse.brandeburg@...el.com" <jesse.brandeburg@...el.com>,
	"anthony.l.nguyen@...el.com" <anthony.l.nguyen@...el.com>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] igc: enable Mac Address Passthrough in Lenovo
 Thunderbolt 4 Docks

On Mon, Jul 03, 2023 at 04:58:42PM +0000, Fernando Eckhardt Valle (FIPT) wrote:
> 
>     MAC address passthrought seems in general to be a big collection of
>     vendor hacks which in general are broken in most corner cases, and
>     even in the middle cases. What really needs to happen is that the
>     vendors get together and standardize on one solution, and make sure
>     they involved the kernel developers in the design.
> 
>     O.K, so why is the kernel involved? It sounds like userspace should be
>     solving this. It is easy for userspace to get a notification when the
>     dock pops into existence. It can then walk the tree of devices and
>     find that the IGC is in a dock, its the first dock, not the 42nd dock
>     in a long chain. User space also has access to the BIOS version so it
>     knows the BIOS will at some point execute this proprietary extension
>     and copy the MAC address to one of the docks, maybe even the correct
>     one in the chain of 42. It can wait 1 seconds, and then down/up the
>     interface?
> 
> I've been thinking about creating a user space application for mac address
> passthrough. I thought about creating a udev rule for it, but some questions
> seemed quite complicated. For example, some ThinkPad laptops don't have a
> network device but have a mac address specifically for mac address passthrough.

Where is it stored? In an ACPI table? Can you get at it via dmidecode
and friends? Or vpddecode?

> My idea for a udev rule would be to copy the mac address from the laptop's
> network device, but since there is no network device, I'm not sure how I would
> make that copy because there is no network device in /sys/class/net to copy
> from.

I udev rule is the start. You want a trigger when a network device
pops into existence.

You then need some sort of code to walk up the device tree and detect
the dock. So want some sort of database of IDs to identify docks.

And you need some sort of code which continues walking up the tree to
determine if this is the first dock.

And you need another database, probably based on BIOS Machine
Type/Model data which tells you how to find the MAC address.

And then some glue to combine all the parts.

> Other vendors, like Realtek, have mac address passthrough implemented in the
> module code (for example, in r8152.c), and I think this makes it easier for
> different vendors (like Dell, Lenovo, etc.) to make mac address passthrough
> work for more people.

And because they did not think about it properly, it often goes
wrong. We have had problems reported of a USB-Ethernet dongle getting
the same MAC address as the dock, etc. The ethernet driver has too
small a view of the world to know if is really should have the pass
through MAC address.

Also, vendors tend to think of themselves and nobody else. So each
vendor does it differently and each get it wrong in their own way.  So
this really needs to be solved in a vendor agnostic way, e.g. the
collection of databases i suggested. Maybe even a submission to the
ACPI standards for where to store this MAC address.

	Andrew

Powered by blists - more mailing lists