linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Henning Schild <henning.schild@siemens.com>
Cc: Aaron Ma <aaron.ma@canonical.com>,
	Mario.Limonciello@amd.com, kuba@kernel.org,
	linux-usb@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
	davem@davemloft.net, hayeswang@realtek.com, tiwai@suse.de
Subject: Re: [PATCH v3] net: usb: r8152: Add MAC passthrough support for RTL8153BL
Date: Fri, 28 Jan 2022 19:06:31 +0100	[thread overview]
Message-ID: <YfQwpy1Kkz3wheTi@lunn.ch> (raw)
In-Reply-To: <20220128092103.1fa2a661@md1za8fc.ad001.siemens.net>

On Fri, Jan 28, 2022 at 09:21:03AM +0100, Henning Schild wrote:
> I am still very much against any patches in that direction. The feature
> as the vendors envision it does not seem to be really understood or
> even explained.
> Just narrowing down the device matching caters for vendor lock-in and
> confusion when that pass through is happening and when not. And seems
> to lead to unmaintainable spaghetti-code. 
> People that use this very dock today will see an unexpected mac-change
> once they update to a kernel with this patch applied.

I've not yet been convinced by replies that the proposed code really
does only match the given dock, and not random USB dongles. To be
convinced i would probably like to see code which positively
identifies the dock, and that the USB device is on the correct port of
the USB hub within the dock. I doubt you can actually do that in a
sane way inside an Ethernet driver. As you say, it will likely lead to
unmaintainable spaghetti-code.

I also don't really think the vendor would be keen on adding code
which they know will get reverted as soon as it is shown to cause a
regression.

So i would prefer to NACK this, and push it to udev rules where you
have a complete picture of the hardware and really can identify with
100% certainty it really is the docks NIC.

   Andrew

  reply	other threads:[~2022-01-28 18:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-27 10:01 [PATCH] net: usb: r8152: Add MAC passthrough support for RTL8153BL Aaron Ma
2022-01-27 10:10 ` Greg KH
2022-01-27 10:14   ` Aaron Ma
2022-01-27 11:07 ` Hayes Wang
2022-01-28  4:20   ` Aaron Ma
2022-01-27 14:19 ` Andrew Lunn
2022-01-28  4:19   ` Aaron Ma
2022-01-28  4:32 ` [PATCH v3] " Aaron Ma
2022-01-28  8:21   ` Henning Schild
2022-01-28 18:06     ` Andrew Lunn [this message]
2022-01-28 18:41       ` Limonciello, Mario
2022-01-28 20:20         ` Henning Schild
2022-01-28 20:29           ` Limonciello, Mario
2022-01-28 21:07             ` Henning Schild
2022-02-08  7:15         ` Hayes Wang

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=YfQwpy1Kkz3wheTi@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=Mario.Limonciello@amd.com \
    --cc=aaron.ma@canonical.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=hayeswang@realtek.com \
    --cc=henning.schild@siemens.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --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).