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]

Message-ID: <20200731150823.GH1712415@lunn.ch>
Date:   Fri, 31 Jul 2020 17:08:23 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Sudeep Holla <sudeep.holla@....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>,
        Florian Fainelli <f.fainelli@...il.com>,
        Madalin Bucur <madalin.bucur@....nxp.com>,
        netdev <netdev@...r.kernel.org>, linux.cj@...il.com,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Vikas Singh <vikas.singh@...esoftware.com>
Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO
 PHY

> However, if those properties are never going to be supplied via ACPI
> on any production systems, the code added in order to be able to
> process them will turn out to be useless and I don't think anyone
> wants useless code in the kernel.
> 
> So the real question is whether or not there will be production
> systems in which those properties will be supplied via ACPI and I
> cannot answer that question.

Hi Rafael

I suspect we are going to have a lot of newbie ACPI questions over the
next few weeks/months as vendors and the PHY maintainers get up to
speed on all this.

In the device tree world, we would expect a patch as part of the
patchset to a device tree file somewhere under arch/*/boot/dts to make
use of any new property added. We then know it is used.

How does this work in the ACPI world?  How does somebody show they are
supplying the property in a production system?

> Basically, the interested vendors need to agree on how exactly they
> want ACPI to be used and come up with a specification setting the
> rules to be followed by the platform firmware on the one side and by
> the code in the kernel on the other side.

...

> Besides, you really should be asking for a spec the work is based on,
> IMO, instead of asking for an ACPI maintainer ACK which is not going
> to be sufficient if the former is missing anyway.

Could you point us towards real world example specs? Giving us a good
best practice example would likely help us to do this work. And reduce
the amount of work you need to do keeping the process going in the
correct direction.

Thanks
	Andrew