Message-ID: <YrQZOX4n0ZuTSANP@lunn.ch>
Date:   Thu, 23 Jun 2022 09:41:45 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        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

> 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.

Device IDs is a complex subject with MDIO devices. It has somewhat
evolved over time, and it could also be that ACPI decides to do
something different, or simpler, to what DT does.

If the device is an Ethernet PHY, and it follows C22, it has two
registers in a well defined location, which when combined give you a
vendor model and version. So we scan the bus, look at each address on
the bus, try to read these registers and if we don't get 0xffff back,
we assume it is a PHY, create an mdio_device, sub type it to
phy_device, and then load and probe the driver based on the ID
registers.

If the device is using C45, we currently will not be able to enumerate
it this way. We have a number of MDIO bus drivers which don't
implement C45, but also don't return -EOPNOTSUPP. They will perform a
malformed C22 transaction, or go wrong in some other horrible way. So
in DT, we have a compatible string to indicate there is a C45 devices
at the address. We then do look around in the C45 address space at the
different locations where the ID registers can be, and if we get a
valid looking ID, probe the driver using that.

We also have some chicken/egg problems. Some PHYs won't respond when
you read there ID registers until you have turned on clocks, disabled
reset lines, enable regulators etc. For these devices, we place the ID
as you would read from the ID registers in DT as the compatible
string. The mdio_device is created, sub-types as a PHY and the probe
happens using the ID register found in DT. The driver can then do what
it needs to do to get the device to respond on the bus.

Then we have devices on the bus which are not PHYs, but generic
mdio_devices. These are mostly Ethernet switches, but Broadcom have
some other MDIO devices which are not switches. For these, we have
compatible strings which identifies the device as a normal string,
which then probes the correct driver in the normal way for a
compatible string.

So giving the kernel a list of device IDs is not simple. I expect
dealing with this will be a big part of defining how MDIOSerialBus
works.

   Andrew

Powered by blists - more mailing lists