Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Thu, 10 Jun 2021 20:31:38 +0200 | Subject | Re: [PATCH net-next v8 01/15] Documentation: ACPI: DSD: Document MDIO PHY |
| |
On Thu, Jun 10, 2021 at 8:23 PM Grant Likely <grant.likely@arm.com> wrote: > > On 10/06/2021 19:05, Rafael J. Wysocki wrote: > > On Thu, Jun 10, 2021 at 6:40 PM Ioana Ciornei <ciorneiioana@gmail.com> wrote: > >> > >> From: Calvin Johnson <calvin.johnson@oss.nxp.com> > >> > >> 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.
| |