On Wed, Jun 22, 2022 at 6:12 PM Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: > > On 6/22/22 05:05, Rafael J. Wysocki wrote: > > On Mon, Jun 20, 2022 at 9:08 PM Andrew Lunn <andrew@xxxxxxx> 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.
