On Fri, Jul 24, 2020 at 09:20:08PM +0200, Andrew Lunn wrote: > > 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
