lkml.org 
[lkml]   [2022]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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@gmail.com> wrote:
>
> On 6/22/22 05:05, Rafael J. Wysocki wrote:
> > On Mon, Jun 20, 2022 at 9:08 PM Andrew Lunn <andrew@lunn.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.

\
 
 \ /
  Last update: 2022-06-22 18:22    [W:1.276 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site