> 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
