From: "Rafael J. Wysocki" <rafael@kernel.org> To: Andrew Lunn <andrew@lunn.ch> Cc: Sudeep Holla <sudeep.holla@arm.com>, Jeremy Linton <jeremy.linton@arm.com>, Calvin Johnson <calvin.johnson@oss.nxp.com>, Russell King - ARM Linux admin <linux@armlinux.org.uk>, Jon <jon@solid-run.com>, Cristi Sovaiala <cristian.sovaiala@nxp.com>, Ioana Ciornei <ioana.ciornei@nxp.com>, Andy Shevchenko <andy.shevchenko@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, Madalin Bucur <madalin.bucur@oss.nxp.com>, netdev <netdev@vger.kernel.org>, linux.cj@gmail.com, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, Vikas Singh <vikas.singh@puresoftware.com> 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: <CAJZ5v0i+a+MS+J_auuuMmq25c1HNb7oV2sqQ87WOtfBBQ6MF7w@mail.gmail.com> (raw) In-Reply-To: <20200728203437.GB1748118@lunn.ch> Hi Andrew, On Tue, Jul 28, 2020 at 10:34 PM Andrew Lunn <andrew@lunn.ch> 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 it. 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. Thanks!
next prev parent reply index Thread overview: 61+ 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] ` <1595922651-sup-5323@galangal.danc.bne.opengear.com> 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-09-29 5:17 ` Calvin Johnson 2020-09-29 13:43 ` Andrew Lunn 2020-09-29 13:55 ` Andy Shevchenko 2020-09-29 14:32 ` Andrew Lunn 2020-09-29 14:46 ` Andy Shevchenko 2020-09-29 15:06 ` Andrew Lunn 2020-09-29 15:29 ` Arnd Bergmann 2020-09-29 14:44 ` Arnd Bergmann 2020-09-29 14:59 ` Andrew Lunn 2020-09-29 15:59 ` Grant Likely 2020-09-29 15:53 ` Grant Likely 2020-09-29 16:04 ` 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: 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=CAJZ5v0i+a+MS+J_auuuMmq25c1HNb7oV2sqQ87WOtfBBQ6MF7w@mail.gmail.com \ --to=rafael@kernel.org \ --cc=andrew@lunn.ch \ --cc=andy.shevchenko@gmail.com \ --cc=calvin.johnson@oss.nxp.com \ --cc=cristian.sovaiala@nxp.com \ --cc=f.fainelli@gmail.com \ --cc=ioana.ciornei@nxp.com \ --cc=jeremy.linton@arm.com \ --cc=jon@solid-run.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux.cj@gmail.com \ --cc=linux@armlinux.org.uk \ --cc=madalin.bucur@oss.nxp.com \ --cc=netdev@vger.kernel.org \ --cc=sudeep.holla@arm.com \ --cc=vikas.singh@puresoftware.com \ /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-ACPI Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-acpi/0 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/ https://lore.kernel.org/linux-acpi \ linux-acpi@vger.kernel.org public-inbox-index linux-acpi Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi AGPL code for this site: git clone https://public-inbox.org/public-inbox.git