Linux-USB Archive on
 help / color / Atom feed
From: <>
To: <>, <>
Cc: <>, <>,
	<>, <>
Subject: RE: [RFC 2/3] ACPI: move ACPI functionality out of r8152 driver
Date: Sat, 24 Aug 2019 13:24:20 +0000
Message-ID: <b3062089954f43259f8dfce9076b78ad@AUSX13MPC101.AMER.DELL.COM> (raw)
In-Reply-To: <>

> -----Original Message-----
> From: Bjørn Mork <>
> Sent: Saturday, August 24, 2019 5:26 AM
> To: Hyde, Charles - Dell Team
> Cc:; Limonciello, Mario;;
> Subject: Re: [RFC 2/3] ACPI: move ACPI functionality out of r8152 driver
> <> writes:
> > This change moves ACPI functionality out of the Realtek r8152 driver
> > to its own source and header file, making it available to other
> > drivers as needed now and into the future.  At the time this ACPI
> > snippet was introduced in 2016, only the Realtek driver made use of it
> > in support of Dell's enterprise IT policy efforts.  There comes now a
> > need for this same support in a different driver, also in support of
> > Dell's enterprise IT policy efforts.
> Why not make a standalone driver out of this, making the MAC address (and
> other system specifc objects?) available to userspace? Then you can just
> distribute updated udev rules or systemd units or whatever for the next docking
> product.
> I don't think system specific policies should be put into device drivers.  Users will
> combine systems and devices in ways you don't foresee, and may have good
> reasons to want some non-default policy even for supported combinations.

I recall that when this was first done for r8152 we actually experimented with exactly
that and ran into two problems:

1) With userspace races with ethernet device renaming
2) The details needed to tell which devices this should apply to (such as eFuse settings
or other identifying factors) aren't exported to userspace.

We only want this applying to devices that keep the same policy in the firmware for
things like PXE or HTTP booting and dual booting other operating systems.
We've been very careful in r8152 that MAC passthrough only applies to the correct devices
with unique identifiers to be a Dell dock as such.

> If you really want to have this policy in the driver(s), then please consider
> extending eth_platform_get_mac_address() with an x86/acpi method.  This will
> make the device driver code support fetching the mac address from device tree
> and Sparc idproms too.  Provided the netdev folks things this is OK, of course.
> This needs to be discussed there, like would have told you.
> Making sure we can modify the MAC address of USB ethernet devices is
> obviously a good thing regardless of how/where you fetch it.
> Bjørn

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-23 22:28 Charles.Hyde
2019-08-24  2:41 ` Greg KH
2019-08-24 10:25 ` Bjørn Mork
2019-08-24 13:24   ` Mario.Limonciello [this message]
2019-08-27 22:08     ` Charles.Hyde
2019-08-27 22:19       ` Mario.Limonciello
2019-08-28 16:41         ` Charles.Hyde

Reply instructions:

You may reply publically 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:

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

  git send-email \
    --in-reply-to=b3062089954f43259f8dfce9076b78ad@AUSX13MPC101.AMER.DELL.COM \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-USB Archive on

Archives are clonable:
	git clone --mirror linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ \
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone