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
| ||
|
Date: Wed, 22 Jun 2022 18:21:31 +0200 From: "Rafael J. Wysocki" <rafael@...nel.org> To: Florian Fainelli <f.fainelli@...il.com> Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Andrew Lunn <andrew@...n.ch>, Marcin Wojtas <mw@...ihalf.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, netdev <netdev@...r.kernel.org>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Len Brown <lenb@...nel.org>, Vivien Didelot <vivien.didelot@...il.com>, Vladimir Oltean <olteanv@...il.com>, David 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 Subject: Re: [net-next: PATCH 08/12] ACPI: scan: prevent double enumeration of MDIO bus children On Wed, Jun 22, 2022 at 6:12 PM Florian Fainelli <f.fainelli@...il.com> wrote: > > On 6/22/22 05:05, Rafael J. Wysocki wrote: > > On Mon, Jun 20, 2022 at 9:08 PM Andrew Lunn <andrew@...n.ch> wrote: > >> > >> On Mon, Jun 20, 2022 at 05:02:21PM +0200, Marcin Wojtas wrote: > >>> The MDIO bus is responsible for probing and registering its respective > >>> children, such as PHYs or other kind of devices. > >>> > >>> It is required that ACPI scan code should not enumerate such > >>> devices, leaving this task for the generic MDIO bus routines, > >>> which are initiated by the controller driver. > >> > >> I suppose the question is, should you ignore the ACPI way of doing > >> things, or embrace the ACPI way? > > > > What do you mean by "the ACPI way"? > > > >> At least please add a comment why the ACPI way is wrong, despite this > >> being an ACPI binding. > > > > The question really is whether or not it is desirable to create > > platform devices for all of the objects found in the ACPI tables that > > correspond to the devices on the MDIO bus. > > If we have devices hanging off a MDIO bus then they are mdio_device (and > possibly a more specialized object with the phy_device which does embedd > a mdio_device object), not platform devices, since MDIO is a bus in itself. Well, that's what I'm saying. And when the ACPI subsystem finds those device objects present in the ACPI tables, the mdio_device things have not been created yet and it doesn't know which ACPI device object will correspond to mdio_device eventually unless it is told about that somehow. One way of doing that is to use a list of device IDs in the kernel. The other is to have the firmware tell it about that which is what we are discussing.
Powered by blists - more mailing lists