Re: [net-next: PATCH 08/12] ACPI: scan: prevent double enumeration of MDIO bus children
From: Rafael J. Wysocki
Date: Wed Jun 22 2022 - 12:21:50 EST
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.