On Thu, Jun 10, 2021 at 8:23 PM Grant Likely <grant.likely@xxxxxxx> wrote: > > On 10/06/2021 19:05, Rafael J. Wysocki wrote: > > On Thu, Jun 10, 2021 at 6:40 PM Ioana Ciornei <ciorneiioana@xxxxxxxxx> wrote: > >> > >> From: Calvin Johnson <calvin.johnson@xxxxxxxxxxx> > >> > >> Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > >> provide them to be connected to MAC. > > > > This is not an "ACPI mechanism", because it is not part of the ACPI > > specification or support documentation thereof. > > > > I would call it "a mechanism based on generic ACPI _DSD device > > properties definition []1]". And provide a reference to the _DSD > > properties definition document. > > > > With that changed, you can add > > > > Acked-by: Rafael J. Wysocki <rafael@xxxxxxxxxx> > > > > to this patch. > > > > Note, however, that within the traditional ACPI framework, the _DSD > > properties are consumed by the driver that binds to the device > > represented by the ACPI device object containing the _DSD in question > > in its scope, while in this case IIUC the properties are expected to > > be consumed by the general networking code in the kernel. That is not > > wrong in principle, but it means that operating systems other than > > Linux are not likely to be using them. > > > > Doesn't this land at the level of device drivers though? None of this > data needs to be consumed by the OS generic ACPI parsing code, but the > network device driver can use it to parse the MDIO and MAC configuraiton > and set itself up appropriately. That's right in general, which is why I said that doing it this way wasn't wrong.
