On Fri, Jul 24, 2020 at 09:20:08PM +0200, Andrew Lunn wrote:

quoted

We are at v7 of this patch series, and no authoritative ACPI Linux
maintainer appears to have reviewed this, so there is no clear sign of
this converging anywhere. This is looking a lot like busy work for
nothing. Given that the representation appears to be wildly
misunderstood and no one seems to come up with something that reaches
community agreement, what exactly is the plan here?

I think we need to NACK all attempts to add ACPI support to phylib and
phylink until an authoritative ACPI Linux maintainer makes an
appearance and actively steers the work. And not just this patchset,
but all patchsets in the networking domain which have an ACPI
component.

Unfortunately, this is one such problem that can never be solved easily
TBH.

We, in Linux kernel community had lots of discussion around _DSD and
how it can be misused if not moderated after the introduction of ACPI
support on Arm. It is useful property used by the kernel today both
on x86 and Arm. Even other OS vendors do use, but the standard body
recently deprecated the process we introduced few years back[1] as it
really never kicked off. All OS vendors have introduced the properties
as they need and have supported without a formal registry and this is
the argument made to deprecate that process.

As a general rule, we say no to any new property added unless there is
no existing solution for the same. It might just expand exponential if
not controlled. So if networking folks agree that there is a need for
it and there exists no alternative solution, then we may need to add
the support for the same. I don't have strong objection as I have least
knowledge in network domain.

But I agree, there exists a possibility of duplication of properties
amongst different OS vendors and could be argument on the other side.

--
Regards,
Sudeep

[1] http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf