Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Dan Callaghan <dan.callaghan@opengear.com>,
	Jeremy Linton <jeremy.linton@arm.com>,
	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>,
	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 14:40:37 -0700
Message-ID: <dc2aed0e-e2e0-0229-e97e-cc5ac5957a4d@gmail.com> (raw)
In-Reply-To: <CAHp75VejnW23LEfyEO6Py8=e3_W0YMomk8jQ3JQeHqYcaeDitg@mail.gmail.com>



On 7/28/2020 2:28 PM, Andy Shevchenko wrote:
> On Tue, Jul 28, 2020 at 11:56 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 7/28/2020 1:45 PM, Andrew Lunn wrote:
>>> On Tue, Jul 28, 2020 at 06:06:26PM +1000, 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.
>>>>
>>>> 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.
>>>
>>> Hi Dan
>>>
>>> I also have an x86 platform, but with a single switch. For that, i
>>> have a platform driver, which instantiates a bit banging MDIO bus, and
>>> sets up the switch using platform data. This works, but it is limited
>>> to internal Copper only PHYs.
>>
>> At some point I had a dsa2_platform_data implementation which was
>> intended to describe more complex switch set-ups and trees, the old code
>> is still there for your entertainment:
>>
>> https://github.com/ffainelli/linux/commits/dsa-pdata
> 
> Platform data in the modern kernel is definitely the wrong approach.
> Software nodes of firmware nodes can be much more appreciated.

Yes, yes, thank you. As you can see this was back from 2016 and it was
never submitted. The only viable alternative that I can think of, unless
the ACPI community at large finally decided to get its act together and
invest some serious efforts and time into understanding modern and
complex network topologies is to overlay a Device Tree onto a live system.

> 
>>>> 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.
>>>
>>> I would actually suggest you look at using DT. We are struggling to
>>> get ACPI maintainers involved with really simple things, like the ACPI
>>> equivalent of a phandle from the MAC to the PHY. A full DSA binding
>>> for Marvell switches is pretty complex, especially if you need SFP
>>> support. I expect the ACPI maintainers will actively run away
>>> screaming when you make your proposal.
>>>
>>> DT can be used on x86, and i suspect it is a much easier path of least
>>> resistance.
>>
>> And you can easily overlay Device Tree to an existing system by using
>> either a full Device Tree overlay (dtbo) or using CONFIG_OF_DYNAMIC and
>> creating nodes on the fly.
> 
> Why do you need DT on a system that runs without it and Linux has all
> means to extend to cover a lot of stuff DT provides for other types of
> firmware nodes?

Because ACPI is beyond useless at providing nearly the same level of
description as what DT can do today?

I am not trying to wage a war of DT is better than ACPI, but when it is
not even capable of describing a simple 1 to 1 mapping between an
Ethernet MAC and a PHY device sitting on an integrated or separate MDIO
bus, describing a full Ethernet switch fabric with 1 to 40 ports, each
with a variety of connectivity options, and you have an pressing need to
get your platform out to customers, then the choice is obvious.
-- 
Florian

  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
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 [this message]
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=dc2aed0e-e2e0-0229-e97e-cc5ac5957a4d@gmail.com \
    --to=f.fainelli@gmail.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=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