Linux-USB Archive on lore.kernel.org
 help / color / Atom feed
From: <Mario.Limonciello@dell.com>
To: <Charles.Hyde@dellteam.com>, <bjorn@mork.no>
Cc: <linux-acpi@vger.kernel.org>, <oliver@neukum.org>,
	<nic_swsd@realtek.com>, <linux-usb@vger.kernel.org>
Subject: RE: [RFC 2/3] ACPI: move ACPI functionality out of r8152 driver
Date: Tue, 27 Aug 2019 22:19:06 +0000
Message-ID: <ae55e4a85d594e27a46cab32ad675208@AUSX13MPC101.AMER.DELL.COM> (raw)
In-Reply-To: <6e404c3d3c344342b09b475e64b4ff3e@AUSX13MPS303.AMER.DELL.COM>



> -----Original Message-----
> From: Hyde, Charles - Dell Team
> Sent: Tuesday, August 27, 2019 5:08 PM
> To: Limonciello, Mario; Bjørn Mork
> Cc: linux-acpi@vger.kernel.org; oliver@neukum.org; nic_swsd@realtek.com;
> linux-usb@vger.kernel.org
> Subject: RE: [RFC 2/3] ACPI: move ACPI functionality out of r8152 driver
> 
> 
> > > > 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 get_maintainer.pl 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
> 
> By moving acpi_mac_passthru.c into drivers/acpi/, what is the suggested edit to
> Makefile for this?  I am thinking it could be added immediately following the
> comment "These are (potentially) separate modules" with:
> 
> apic-y += acpi_mac_passthru.o
> 
> I removed extra spacing above for posting here.
> 

I believe that Bjørn specifically recommended to put it in drivers/acpi/x86.

Which that would mean it's:
acpi-$(CONFIG_X86)              += x86/acpi_mac_passthrough.o


  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
2019-08-27 22:08     ` Charles.Hyde
2019-08-27 22:19       ` Mario.Limonciello [this message]
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:
  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=ae55e4a85d594e27a46cab32ad675208@AUSX13MPC101.AMER.DELL.COM \
    --to=mario.limonciello@dell.com \
    --cc=Charles.Hyde@dellteam.com \
    --cc=bjorn@mork.no \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=nic_swsd@realtek.com \
    --cc=oliver@neukum.org \
    /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

Linux-USB Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-usb/0 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/ https://lore.kernel.org/linux-usb \
		linux-usb@vger.kernel.org linux-usb@archiver.kernel.org
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-usb


AGPL code for this site: git clone https://public-inbox.org/ public-inbox