From: Jeremy Linton <jeremy.linton@arm.com>
To: Dan Callaghan <dan.callaghan@opengear.com>, Andrew Lunn <andrew@lunn.ch>
Cc: Calvin Johnson <calvin.johnson@oss.nxp.com>,
Russell King <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" <linux.cj@gmail.com>,
linux-acpi <linux-acpi@vger.kernel.org>
Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY
Date: Tue, 28 Jul 2020 17:30:26 -0500 [thread overview]
Message-ID: <9e63aabf-8993-9ce0-1274-c29d7a5fc267@arm.com> (raw)
In-Reply-To: <1595922651-sup-5323@galangal.danc.bne.opengear.com>
Hi,
On 7/28/20 3:06 AM, Dan Callaghan wrote:
> Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
>> 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?
>
> As an extra data point: right now I am working on an x86 embedded
> appliance (ACPI not Device Tree) with 3x integrated Marvell switches.
> I have been watching this patch series with great interest, because
> right now there is no way for me to configure a complex switch topology
> in DSA without Device Tree.
DSA though, the switch is hung off a normal MAC/MDIO, right? (ignoring
whether that NIC/MAC is actually hug off PCIe for the moment).
It just has a bunch of phy devices strung out on that single MAC/MDIO.
So in ACPI land it would still have a relationship similar to the one
Andrew pointed out with his DT example where the eth0->mdio->phy are all
contained in their physical parent. The phy in that case associated with
the parent adapter would be the first direct decedent of the mdio, the
switch itself could then be represented with another device, with a
further string of device/phys representing the devices. (I dislike
drawing acsii art, but if this isn't clear I will, its also worthwhile
to look at the dpaa2 docs for how the mac/phys work on this device for
contrast.).
If so, then its probably possible to represent with a fairly regular
looking set of ACPI objects and avoids part of the core discussion here
about whether we need a standardized way to pick phy's out of arbitrary
parts of the hierarchy using a part of the spec intended for one off
problems.
Am I missing something?
>
> For the device I am working on, we will have units shipping before these
> questions about how to represent Ethernet switches in ACPI can be
> resolved. So realistically, we will have to actually configure the
> switches using software_node structures supplied by an out-of-tree
> platform driver, or some hackery like that, rather than configuring them
> through ACPI.
>
> An approach I have been toying with is to port all of DSA to use the
> fwnode_handle abstraction instead of Device Tree nodes, but that is
> obviously a large task, and frankly I was not sure whether such a patch
> series would be welcomed.
>
next prev parent reply other threads:[~2020-07-28 22:30 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
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 [this message]
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=9e63aabf-8993-9ce0-1274-c29d7a5fc267@arm.com \
--to=jeremy.linton@arm.com \
--cc=andrew@lunn.ch \
--cc=andy.shevchenko@gmail.com \
--cc=calvin.johnson@oss.nxp.com \
--cc=cristian.sovaiala@nxp.com \
--cc=dan.callaghan@opengear.com \
--cc=f.fainelli@gmail.com \
--cc=ioana.ciornei@nxp.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).