netdev - Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

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] [day] [month] [year] [list]

Message-ID: <20180121185559.GC9004@lunn.ch>
Date:   Sun, 21 Jan 2018 19:55:59 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Nadav Haklai <nadavh@...vell.com>,
        Neta Zur Hershkovits <neta@...vell.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Russell King - ARM Linux <linux@....linux.org.uk>,
        Grzegorz Jaszczyk <jaz@...ihalf.com>,
        Tomasz Nowicki <tn@...ihalf.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Gregory CLEMENT <gregory.clement@...e-electrons.com>,
        Marcin Wojtas <mw@...ihalf.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Graeme Gregory <graeme.gregory@...aro.org>,
        "<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
        Antoine T?nart <antoine.tenart@...e-electrons.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Hanjun Guo <hanjun.guo@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

> However interesting as an example, I'm not convinced this is what we
> should aim for.
> 
> ACPI is not a replacement for DT, and it is unlikely that people would
> be interested in running ACPI-only distros such as RHEL on their
> Ethernet switch. DT is excellent at describing this, and there is no
> need to replace it.

I however do know of somebody who is building an industrial wireless
access point, with a Marvell Ethernet switch. They have chosen to use
an Intel CPU, and want to run CentOS on it, because that is what they
know.

So they will be using ACPI whatever, for the basic board support. They
then have a choice of either ACPI for the switch, or having device
tree as well as ACPI for the switch. And it will be interesting to see
how that works. Can DT reference GPIOs and I2C busses in ACPI?

> Also, please bear in mind that the ACPI spec is owned by the UEFI/ACPI
> forum, and only members (who are all under a contract regarding
> reasonable and non-discriminatory (RAND) licensing terms to IP they
> own that is covered by the spec) can contribute. Individuals can
> become members for free AFAIR, but that doesn't mean individuals are
> typically interested in getting involved in a process that is rather
> tedious and bureaucratic.

And this is a bit what i'm worried about. How you represent MDIO
busses, PHYs, Ethernet switches is implemented once in the core Linux
code. So i would be interested in knowing what happens if the Linux
community defines and implements something, boards start using it, but
a year later the tedious and bureaucratic process rejects it,
re-writes it, in an incompatible way.

	     Andrew