netdev - Re: [net-next PATCH v1] net: dpaa2-mac: Add ACPI support for DPAA2 MAC driver

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: <20200626140247.GA17041@lsv03152.swis.in-blr01.nxp.com>
Date:   Fri, 26 Jun 2020 19:32:47 +0530
From:   Calvin Johnson <calvin.johnson@....nxp.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Jeremy Linton <jeremy.linton@....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>,
        linux-acpi@...r.kernel.org, linux.cj@...il.com,
        netdev@...r.kernel.org,
        "Rajesh V. Bikkina" <rajesh.bikkina@....com>
Subject: Re: [net-next PATCH v1] net: dpaa2-mac: Add ACPI support for DPAA2
 MAC driver

Hi Andrew

On Fri, Jun 26, 2020 at 03:39:42PM +0200, Andrew Lunn wrote:
> > Hi Andrew
> > 
> > As you know, making this code generic would bring us back to waiting for
> > ACPI team's approval which is very difficult to get as the ACPI doesn't
> > have any opinion on MDIO bus.
> > 
> > Like other ACPI ethernet drivers, can't we keep it local to this driver to
> > avoid the above issue?
> 
> Hi Calvin
> 
> That does not scale. Every driver doing its own thing. Each having its
> own bugs, maintenance overheads, documentation problems, no meta
> validation of the ACPI tables because every table is different,
> etc. Where is the Advanced in that? It sounds more like Primitive,
> Chaotic, Antiquated?
> 
> Plus having it generic means there is one place which needs
> modifications when the ACPI standards committee does decide how this
> should be done.

I'm very much aligned with your thoughts. Making this generic is the right
approach according to me. Is it sufficient, if we get net subsystem approval?

> 
> > If we plan to make this approach generic, then it may have to be put in:
> > Documentation/firmware-guide/acpi/
> 
> So looking in this directory, we have defacto standards,
> e.g. linux/Documentation/firmware-guide/acpi/dsd/leds.rst.
> 
> So lets add another defacto standard, how you find a PHY.
Sure will add.

Thanks
Calvin