linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Limonciello, Mario" <mario.limonciello@amd.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>,
	Andrew Lunn <andrew@lunn.ch>, Oliver Neukum <oneukum@suse.com>,
	Aaron Ma <aaron.ma@canonical.com>,
	henning.schild@siemens.com, linux-usb@vger.kernel.org,
	netdev@vger.kernel.org, davem@davemloft.net,
	hayeswang@realtek.com, tiwai@suse.de
Subject: Re: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address
Date: Tue, 11 Jan 2022 10:54:50 -0600	[thread overview]
Message-ID: <2b779fef-459f-79bb-4005-db4fd3fd057f@amd.com> (raw)
In-Reply-To: <20220111084348.7e897af9@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>

On 1/11/2022 10:43, Jakub Kicinski wrote:
> On Tue, 11 Jan 2022 10:33:39 -0600 Limonciello, Mario wrote:
>> If you end up having only your pass through MAC used for Windows and
>> UEFI your hoteling system might not work properly if your corporation
>> also supports employees to use Linux and this feature was removed from
>> the kernel.
> 
> Right, I think the utility of the feature is clear now. Let me clarify
> what I was after - 

Thanks, I was looped into this thread late so I didn't have any context.

You prompted me to look at this patch series on patchwork.

We talked about this when the initial patch series was developed and the 
intention was to align what Windows does.  That means that all dongles 
or docks with the appropriate effuse blown take the same pass through 
address.

Anything else and you lose the element of predictability and all those 
use cases I mentioned stop working.

> I was wondering which component is responsible for
> the address inheritance in Windows or UEFI. 

The Realtek driver for Windows and the Realtek DXE for UEFI.

> Is it also hardcoded into
> the realtek driver or is there a way to export the ACPI information to
> the network management component?

On Windows there is no indication outside of the driver that this 
feature has been used.  It's "invisible" to the user.

> 
> Also knowing how those OSes handle the new docks which don't have
> unique device IDs would obviously be great..

I'm sorry, can you give me some more context on this?  What unique 
device IDs?

  reply	other threads:[~2022-01-11 16:55 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05 15:14 [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address Aaron Ma
2022-01-05 15:14 ` [PATCH 2/3] net: usb: r8152: Set probe mode to sync Aaron Ma
2022-01-05 15:33   ` Greg KH
2022-01-05 15:14 ` [PATCH 3/3] net: usb: r8152: remove unused definition Aaron Ma
2022-01-05 15:34   ` Greg KH
2022-01-05 15:31 ` [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address Greg KH
2022-01-05 15:57 ` Henning Schild
2022-01-05 17:30 ` Andrew Lunn
2022-01-05 17:40   ` Henning Schild
2022-01-05 21:49   ` Oliver Neukum
2022-01-05 22:27     ` Andrew Lunn
2022-01-06  2:10       ` Kai-Heng Feng
2022-01-06 13:27         ` Andrew Lunn
2022-01-07  2:01           ` Kai-Heng Feng
2022-01-07  2:31             ` Jakub Kicinski
2022-01-10  3:32               ` Kai-Heng Feng
2022-01-10 16:51                 ` Jakub Kicinski
2022-01-11  1:51                   ` Kai-Heng Feng
2022-01-11 14:57                     ` Limonciello, Mario
2022-01-11 16:26                       ` Jakub Kicinski
2022-01-11 16:33                         ` Limonciello, Mario
2022-01-11 16:43                           ` Jakub Kicinski
2022-01-11 16:54                             ` Limonciello, Mario [this message]
2022-01-11 17:06                               ` Jakub Kicinski
2022-01-11 17:10                                 ` Limonciello, Mario
2022-01-12 19:21                                   ` Henning Schild
2022-01-12 19:27                                     ` Limonciello, Mario
2022-01-13  3:23                                       ` Aaron Ma
2022-01-27  2:51                                         ` Aaron Ma
2022-01-27  8:06                                           ` Hayes Wang
2022-01-27  8:13                                             ` Aaron Ma
2022-01-27  8:42                                               ` Hayes Wang
2022-01-27 12:53                                             ` Andrew Lunn
2022-01-07 13:32             ` Andrew Lunn
2022-01-10  3:39               ` Kai-Heng Feng
2022-01-10 11:39 ` Oliver Neukum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b779fef-459f-79bb-4005-db4fd3fd057f@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=aaron.ma@canonical.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=hayeswang@realtek.com \
    --cc=henning.schild@siemens.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=kuba@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).