netdev - Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 Jul 2020 18:03:14 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Jeremy Linton <jeremy.linton@....com>,
        Calvin Johnson <calvin.johnson@....nxp.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Jon <jon@...id-run.com>,
        Cristi Sovaiala <cristian.sovaiala@....com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Madalin Bucur <madalin.bucur@....nxp.com>,
        netdev@...r.kernel.org, Sudeep Holla <sudeep.holla@....com>,
        linux.cj@...il.com, linux-acpi@...r.kernel.org
Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO
 PHY

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