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> <20220620150225.1307946-10-mw@semihalf.com>
 <YrDO05TMK8SVgnBP@lunn.ch> <YrGm2jmR7ijHyQjJ@smile.fi.intel.com>
 <YrGpDgtm4rPkMwnl@lunn.ch> <YrGukfw4uiQz0NpW@smile.fi.intel.com>
 <CAPv3WKf_2QYh0F2LEr1DeErvnMeQqT0M5t40ROP2G6HSUwKpQQ@mail.gmail.com>
 <YrL3DQD92ijLam2V@smile.fi.intel.com> <YrL7Z6/ghTO/9wlx@lunn.ch> <YrMlEcKwpTmR5qj6@smile.fi.intel.com>
In-Reply-To: <YrMlEcKwpTmR5qj6@smile.fi.intel.com>
From:   Marcin Wojtas <mw@semihalf.com>
Date:   Wed, 22 Jun 2022 17:00:21 +0200
Message-ID: <CAPv3WKeT_OaTS6es=WKx8gmQ=zuzv0EqfW=vPafNA2hYbhQJ6g@mail.gmail.com>
Subject: Re: [net-next: PATCH 09/12] Documentation: ACPI: DSD: introduce DSA description
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Len Brown <lenb@kernel.org>, 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>, 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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

=C5=9Br., 22 cze 2022 o 16:20 Andy Shevchenko
<andriy.shevchenko@linux.intel.com> napisa=C5=82(a):
>
> On Wed, Jun 22, 2022 at 01:22:15PM +0200, Andrew Lunn wrote:
> > > > It's not device on MDIO bus, but the MDIO controller's register its=
elf
> > > > (this _CSR belongs to the parent, subnodes do not refer to it in an=
y
> > > > way). The child device requires only _ADR (or whatever else is need=
ed
> > > > for the case the DSA device is attached to SPI/I2C controllers).
> > >
> > > More and more the idea of standardizing the MDIOSerialBus() resource =
looks
> > > plausible. The _ADR() usage is a bit grey area in ACPI specification.=
 Maybe
> > > someone can also make it descriptive, so Microsoft and others won't u=
tilize
> > > _ADR() in any level of weirdness.
> >
> > I don't know if it makes any difference, but there are two protocols
> > spoken over MDIO, c22 and c45, specified in clause 22 and clause 45 of
> > the 802.3 specification. In some conditions, you need to specify which
> > protocol to speak to a device at a particular address. In DT we
> > indicate this with the compatible string, when maybe it should really
> > be considered as an extension of the address.
> >
> > If somebody does produce a draft for MDIOSerialBus() i'm happy to
> > review it.
>
> I also can review it. Marcin, would it be hard for you to prepare a forma=
l
> proposal for ACPI specification?
>

I've just consulted this to get an understanding of the process.
* I will initiate it with the code-first ECR using the linux-acpi
mailing list, where all the technical review will take place.
* At the same time a ticket and the formal process for this will be
triggered within UEFI Forum.
* Once everything gets approved, an official confirmation will be
provided and from that moment, it would allow us to proceed with
implementation without need of waiting months for another ACPI
Specification release.

Unless anyone objects, I will include this thread recipients to take
part in review of the proposed MDIOSerialBus _CRS resource macro
contents, so it contains all relevant information.

Note: Once this hopefully gets accepted one day and allow us proceed
with Linux handling, it should be easy to satisfy backward
compatibility with current users of MDIO+PHY in ACPI.

Best regards,
Marcin