Linux-ACPI Archive on
 help / color / Atom feed
From: "Rafael J. Wysocki" <>
To: Andrew Lunn <>
Cc: Sudeep Holla <>,
	Jeremy Linton <>,
	Calvin Johnson <>,
	Russell King - ARM Linux admin <>,
	Jon <>,
	Cristi Sovaiala <>,
	Ioana Ciornei <>,
	Andy Shevchenko <>,
	Florian Fainelli <>,
	Madalin Bucur <>,
	netdev <>,,
	ACPI Devel Maling List <>,
	Vikas Singh <>
Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY
Date: Wed, 29 Jul 2020 18:00:39 +0200
Message-ID: <> (raw)
In-Reply-To: <>

Hi Andrew,

On Tue, Jul 28, 2020 at 10:34 PM Andrew Lunn <> wrote:
> Hi Everybody
> So i think it is time to try to bring this discussion to some sort of
> conclusion.
> No ACPI maintainer is willing to ACK any of these patches. Nor are
> they willing to NACK them.

Let's first clarify one thing: ACPI maintainers take care of the
generic code implementing the interactions between the OS and the
platform firmware in accordance with ACPI (which is an interface
specification to be precise).  They do not set rules on what
ACPI-related things device drivers can do.  Those rules are set in the
ACPI specification and other standard definitions (like PCI, USB,
etc.) and they just need to be followed.  So ACPI maintainers cannot
"bless" any new rule to be followed going forward.

An ACPI maintainer can tell you whether or not some driver code
follows the rules set by the ACPI specification (or conventions
related to using the ACPI support code in the kernel) and that's about

In this particular case, a bit of ACPI-related code is there in the
last two patches and it doesn't look broken.  It uses the ACPI side of
the device properties API correctly AFAICS.

Also, from a slightly broader perspective, this patch series adds an
ability to look up certain device properties in the ACPI namespace.
That appears to be done in accordance with all of the rules set so
far, so there is nothing wrong with it in principle.

However, if those properties are never going to be supplied via ACPI
on any production systems, the code added in order to be able to
process them will turn out to be useless and I don't think anyone
wants useless code in the kernel.

So the real question is whether or not there will be production
systems in which those properties will be supplied via ACPI and I
cannot answer that question.  Therefore I cannot ACK the patches
(because I don't know whether or not the code added by them is going
to be useful), but I cannot NACK them either, because the code added
by them looks correct to me.

> ACPI maintainers simply don't want to get
> involved in making use of ACPI in networking.

That's not about making use of ACPI in networking in general (which
already happens in many ways), but about a specific use of ACPI for a
specific purpose related to networking.

> I personally don't have the knowledge to do ACPI correctly, review
> patches, point people in the right direction. I suspect the same can
> be said for the other PHY maintainers.
> Having said that, there is clearly a wish from vendors to make use of
> ACPI in the networking subsystem to describe hardware.
> How do we go forward?

Basically, the interested vendors need to agree on how exactly they
want ACPI to be used and come up with a specification setting the
rules to be followed by the platform firmware on the one side and by
the code in the kernel on the other side.

> For the moment, we will need to NACK all patches adding ACPI support
> to the PHY subsystem.
> Vendors who really do want to use ACPI, not device tree, probably
> need to get involved in standardisation. Vendors need to submit a
> proposal to UEFI and get it accepted.

The UEFI Forum maintains the ACPI specification itself (so changes to
the specification need to be accepted by it), but it is not uncommon
for a group of vendors (or even one vendor in some cases) to come up
with additional rules and specify them separately.  Of course,
involving the UEFI Forum may help to simplify things from the legal
and spec hosting perspective, but I don't think it is mandatory.

In the particular case at hand the additional rules may just be based
on the analogous DT bindings, but they need to be officially defined.

> Developers should try to engage with the ACPI maintainers and see
> if they can get them involved in networking. Patches with an
> Acked-by from an ACPI maintainer will be accepted, assuming they
> fulfil all the other usual requirements. But please don't submit
> patches until you do have an ACPI maintainer on board. We don't
> want to spamming the lists with NACKs all the time.

Well, do you ask for a PCI maintainer ACK on a patch adding a PCI
driver for a NIC as a rule?  If not, I don't see a reason for making
ACPI an exception.

Besides, you really should be asking for a spec the work is based on,
IMO, instead of asking for an ACPI maintainer ACK which is not going
to be sufficient if the former is missing anyway.


  parent reply index

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15  9:03 [net-next PATCH v7 0/6] ACPI support for dpaa2 MAC driver Calvin Johnson
2020-07-15  9:03 ` [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY Calvin Johnson
2020-07-16  3:04   ` Florian Fainelli
2020-07-16  3:11     ` Andrew Lunn
2020-07-23 23:26   ` Jeremy Linton
2020-07-24 13:39     ` Andrew Lunn
2020-07-24 17:26       ` Jeremy Linton
2020-07-24 17:39         ` Florian Fainelli
2020-07-24 19:20           ` Andrew Lunn
2020-07-24 20:12             ` Andy Shevchenko
2020-07-24 20:13               ` Florian Fainelli
2020-07-24 20:20                 ` Andy Shevchenko
2020-07-25  7:36                   ` Calvin Johnson
2020-07-25 10:48                     ` Andy Shevchenko
2020-07-24 21:06               ` Russell King - ARM Linux admin
2020-07-27 17:03             ` Sudeep Holla
2020-07-24 19:14         ` Andrew Lunn
2020-07-27 17:21           ` Sudeep Holla
2020-07-28 20:34             ` Andrew Lunn
2020-07-28 20:59               ` Russell King - ARM Linux admin
2020-07-28 21:26                 ` Andy Shevchenko
2020-07-29 16:00               ` Rafael J. Wysocki [this message]
2020-07-31 15:08                 ` Andrew Lunn
2020-07-27 17:32           ` Jon Nettleton
     [not found]           ` <>
2020-07-28 20:45             ` Andrew Lunn
2020-07-28 20:56               ` Florian Fainelli
2020-07-28 21:28                 ` Andy Shevchenko
2020-07-28 21:40                   ` Florian Fainelli
2020-07-31 15:14                   ` Andrew Lunn
2020-09-25 13:22                     ` Grant Likely
2020-07-28 22:30             ` Jeremy Linton
2020-07-29  0:39               ` Florian Fainelli
2020-07-29  2:53                 ` Jeremy Linton
2020-07-29  3:16                   ` Florian Fainelli
2020-07-29  8:43                   ` Jon Nettleton
2020-07-29  9:39                     ` Calvin Johnson
2020-09-25 13:34   ` Grant Likely
2020-09-26  4:30     ` Calvin Johnson
2020-07-15  9:03 ` [net-next PATCH v7 2/6] net: phy: introduce device_mdiobus_register() Calvin Johnson
2020-07-16  3:05   ` Florian Fainelli
2020-07-15  9:03 ` [net-next PATCH v7 3/6] net/fsl: use device_mdiobus_register() Calvin Johnson
2020-07-16  3:05   ` Florian Fainelli
2020-07-15  9:03 ` [net-next PATCH v7 4/6] net: phy: introduce phy_find_by_mdio_handle() Calvin Johnson
2020-07-16  3:06   ` Florian Fainelli
2020-07-15  9:03 ` [net-next PATCH v7 5/6] phylink: introduce phylink_fwnode_phy_connect() Calvin Johnson
2020-07-15  9:04 ` [net-next PATCH v7 6/6] net: dpaa2-mac: Add ACPI support for DPAA2 MAC driver Calvin Johnson
2020-09-25 13:39 ` [net-next PATCH v7 0/6] ACPI support for dpaa2 " Grant Likely
2020-09-26  4:34   ` Calvin Johnson
2020-07-25 14:23 Calvin Johnson
2020-07-25 14:23 ` [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY Calvin Johnson

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

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

Linux-ACPI Archive on

Archives are clonable:
	git clone --mirror linux-acpi/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-acpi linux-acpi/ \
	public-inbox-index linux-acpi

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone