Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220620150225.1307946-1-mw@semihalf.com> <YrC0oKdDSjQTgUtM@lunn.ch>
 <YrC3ZKsMQK3PYKkR@smile.fi.intel.com> <YrDAMcGg1uF9m/L+@lunn.ch> <CAPv3WKeeZwNAs06thrYvgXaTPA9KP-9dQZNZsYWx3UXS8LStAQ@mail.gmail.com>
In-Reply-To: <CAPv3WKeeZwNAs06thrYvgXaTPA9KP-9dQZNZsYWx3UXS8LStAQ@mail.gmail.com>
From:   Marcin Wojtas <mw@semihalf.com>
Date:   Wed, 22 Jun 2022 17:40:29 +0200
Message-ID: <CAPv3WKeYBE=ybXQw_3Hn2NoLVzO0da1ecged73=frzQKhGh6OQ@mail.gmail.com>
Subject: Re: [net-next: PATCH 00/12] ACPI support for DSA
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Len Brown <lenb@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Russell King - ARM Linux <linux@armlinux.org.uk>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Grzegorz Bernacki <gjb@semihalf.com>,
        Grzegorz Jaszczyk <jaz@semihalf.com>,
        Tomasz Nowicki <tn@semihalf.com>,
        Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>,
        upstream@semihalf.com, Jon Nettleton <jon@solid-run.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi,

wt., 21 cze 2022 o 12:46 Marcin Wojtas <mw@semihalf.com> napisa=C5=82(a):
>
> pon., 20 cze 2022 o 20:45 Andrew Lunn <andrew@lunn.ch> napisa=C5=82(a):
> >
> > > You beat me up to this. I also was about to mention that the problem =
with such
> > > conversions (like this series does) is not in the code. It's simplest=
 part. The
> > > problem is bindings and how you get them to be a standard (at least d=
e facto).
> >
> > De facto is easy. Get it merged. After that, i will simply refuse
> > anything else, the same way i and other Maintainers would refuse a
> > different DT binding.
> >
> > If the ACPI committee approve and publish a binding, we will naturally
> > accept that as well. So in the end we might have two bindings. But so
> > far in this whole ACPI for networking story, i've not heard anybody
> > say they are going to submit anything for standardisation. So this
> > might be a mute point.
> >
>
> I understand your concern and of course it's better to be on a safe
> side from the beginning. Based on the hitherto discussion under this
> patchset, I would split the question about standardization to 2
> orthogonal topics:
>
> 1. Relation to the bus and enumeration:
>   * As pointed out in another patch some switches can be attached to
>     SPI or I2C. In such a case this is simple - SPISerialBus /
> I2CSerialBus structures
>     in _CRS are included in the ACPI Spec. They allow to comprise more
> bus specific
>     information and the code in acpi/scan.c marks those child devices
> as to be enumerated
>     by parent bus.
>   * MDIO bus doesn't have its own _CRS macro in the Spec, on the other
> hand the _ADR
>     seems to be the only object required for proper operation - this
> was my base for
>     proposed solution in patch 06/12.
>
> 2. The device description (unrelated to which bus it is attached)
>   * In Linux and other OS's there is a great amount of devices
> conforming the guidelines
>     and using only the standard device identification/configuration
> objects as per [1].
>   * Above do not contain custom items and entire information can be obtai=
ned by
>     existing, generic ACPI accessors - those devices (e.g. NICs,
> SD/MMC controllers and
>     many others) are not explicitly mentioned in official standards.
>   * The question, also related to this DSA case - is the ACPI device()
> hierarchical
>     structure of this kind a subject for standardization for including
> in official ACPI specification?
>   * In case not, where to document it? Is Linux' Documentation enough?
>     I agree that in the moment of merge it becomes de facto standard ABI =
and
>     it's worth to sort it out.
>
> Rafael, Len, any other ACPI expert - I would appreciate your inputs
> and clarification
> of the above. Your recommendation would be extremely helpful.
>

Thank you all for vivid discussions. As it may take some time for the
MDIOSerialBus _CRS macro review and approval, for now I plan to submit
v2 of_ -> fwnode_/device_ migration (patches 1-7,11/12) and skip
ACPI-specific additions until it is unblocked by spec extension.

Best regards,
Marcin