On Wed, Jun 22, 2022 at 6:12 PM Florian Fainelli [off-list ref] wrote:

On 6/22/22 05:05, Rafael J. Wysocki wrote:

quoted

On Mon, Jun 20, 2022 at 9:08 PM Andrew Lunn [off-list ref] wrote:

quoted

On Mon, Jun 20, 2022 at 05:02:21PM +0200, Marcin Wojtas wrote:

quoted

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"?

quoted

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.