linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: 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@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:21:36 +0100	[thread overview]
Message-ID: <20200727172136.GC8003@bogus> (raw)
In-Reply-To: <20200724191436.GH1594328@lunn.ch>

On Fri, Jul 24, 2020 at 09:14:36PM +0200, Andrew Lunn wrote:
> > Hence my previous comment that we should consider this an escape
> > hatch rather than the last word in how to describe networking on
> > ACPI/SBSA platforms.
>
> One problem i have is that this patch set suggests ACPI can be used to
> describe complex network hardware. It is opening the door for others
> to follow and add more ACPI support in networking. How long before it
> is not considered an escape hatch, but the front door?
>

I understand your concerns here. But as I mentioned in other email in
the same thread, it is very tricky problem to solve as no one is ready
to take up and maintain these.

> For an example, see
>
> https://patchwork.ozlabs.org/project/netdev/patch/1595417547-18957-3-git-send-email-vikas.singh@puresoftware.com/
>
> It is hard to see what the big picture is here. The [0/2] patch is not
> particularly good. But it makes it clear that people are wanting to
> add fixed-link PHYs into ACPI. These are pseudo devices, used to make
> the MAC think it is connected to a PHY when it is not. The MAC still
> gets informed of link speed, etc via the standard PHYLIB API. They are
> mostly used for when the Ethernet MAC is directly connected to an
> Ethernet Switch, at a MAC to MAC level.
>
> Now i could be wrong, but are Ethernet switches something you expect
> to see on ACPI/SBSA platforms? Or is this a legitimate use of the
> escape hatch?
>

My guess is that similar products running on other architectures(namely
x86) might be running ACPI and hence the push to have ACPI on such ARM
systems. It may weak argument for that and I agree with it. I want to
think it as legitimate use here but I am well aware and afraid that this
may become front door instead of escape hatch.

Sorry, I am not helpful at all, but I am just sharing my personal opinion
on this matter.

--
Regards,
Sudeep

  reply	other threads:[~2020-07-27 17:21 UTC|newest]

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 [this message]
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=20200727172136.GC8003@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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).