lkml.org 
[lkml]   [2021]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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.

\
 
 \ /
  Last update: 2021-06-10 20:32    [W:0.053 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site