Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.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>,
	Madalin Bucur <madalin.bucur@oss.nxp.com>,
	netdev@vger.kernel.org, Sudeep Holla <sudeep.holla@arm.com>,
	linux.cj@gmail.com, linux-acpi@vger.kernel.org
Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY
Date: Mon, 27 Jul 2020 18:03:14 +0100
Message-ID: <20200727170314.GB8003@bogus> (raw)
In-Reply-To: <20200724192008.GI1594328@lunn.ch>

On Fri, Jul 24, 2020 at 09:20:08PM +0200, Andrew Lunn wrote:
> > We are at v7 of this patch series, and no authoritative ACPI Linux
> > maintainer appears to have reviewed this, so there is no clear sign of
> > this converging anywhere. This is looking a lot like busy work for
> > nothing. Given that the representation appears to be wildly
> > misunderstood and no one seems to come up with something that reaches
> > community agreement, what exactly is the plan here?
>
> I think we need to NACK all attempts to add ACPI support to phylib and
> phylink until an authoritative ACPI Linux maintainer makes an
> appearance and actively steers the work. And not just this patchset,
> but all patchsets in the networking domain which have an ACPI
> component.
>

Unfortunately, this is one such problem that can never be solved easily
TBH.

We, in Linux kernel community had lots of discussion around _DSD and
how it can be misused if not moderated after the introduction of ACPI
support on Arm. It is useful property used by the kernel today both
on x86 and Arm. Even other OS vendors do use, but the standard body
recently deprecated the process we introduced few years back[1] as it
really never kicked off. All OS vendors have introduced the properties
as they need and have supported without a formal registry and this is
the argument made to deprecate that process.

As a general rule, we say no to any new property added unless there is
no existing solution for the same. It might just expand exponential if
not controlled. So if networking folks agree that there is a need for
it and there exists no alternative solution, then we may need to add
the support for the same. I don't have strong objection as I have least
knowledge in network domain.

But I agree, there exists a possibility of duplication of properties
amongst different OS vendors and could be argument on the other side.

--
Regards,
Sudeep

[1] http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf

  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 [this message]
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
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=20200727170314.GB8003@bogus \
    --to=sudeep.holla@arm.com \
    --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 \
    /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