On Thu, Jun 10, 2021 at 8:23 PM Grant Likely [off-list ref] wrote:

On 10/06/2021 19:05, Rafael J. Wysocki wrote:

quoted

On Thu, Jun 10, 2021 at 6:40 PM Ioana Ciornei [off-list ref] wrote:

quoted

From: Calvin Johnson <redacted>

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@kernel.org>

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.