linux-kernel - Re: [net-next: PATCH 00/12] ACPI support for DSA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 22 Jun 2022 18:14:52 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Marcin Wojtas <mw@...ihalf.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Grzegorz Bernacki <gjb@...ihalf.com>,
        Grzegorz Jaszczyk <jaz@...ihalf.com>,
        Tomasz Nowicki <tn@...ihalf.com>,
        Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@....com>,
        upstream@...ihalf.com, Jon Nettleton <jon@...id-run.com>
Subject: Re: [net-next: PATCH 00/12] ACPI support for DSA

On Wed, Jun 22, 2022 at 5:44 PM Marcin Wojtas <mw@...ihalf.com> wrote:
>
> Hi,
>
> wt., 21 cze 2022 o 12:46 Marcin Wojtas <mw@...ihalf.com> napisał(a):
> >
> > pon., 20 cze 2022 o 20:45 Andrew Lunn <andrew@...n.ch> napisał(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 de 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 obtained 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.

Sounds good to me (as from fwnode perspective).

-- 
With Best Regards,
Andy Shevchenko