linux-kernel - Re: [PATCH net-next 3/3] net: phy: Enable C45 PHYs with vendor specific address space

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:   Wed, 18 Apr 2018 14:27:07 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vicenţiu Galanopulo <vicentiu.galanopulo@....com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        "robh@...nel.org" <robh@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "marcel@...tmann.org" <marcel@...tmann.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Madalin-cristian Bucur <madalin.bucur@....com>
Subject: Re: [PATCH net-next 3/3] net: phy: Enable C45 PHYs with vendor
 specific address space

On Wed, Apr 18, 2018 at 09:38:47AM +0000, Vicenţiu Galanopulo wrote:
> 
> 
> > > Having dev-addr stored in devices_addrs, in get_phy_c45_ids(), when
> > > probing the identifiers, dev-addr can be extracted from devices_addrs
> > > and probed if devices_addrs[current_identifier] is not 0.
> > 
> > I must clearly be missing something, but why are you introducing all these
> > conditionals instead of updating the existing code to be able to operate against
> > an arbitrary dev-addr value, and then just making sure the first thing you do is
> > fetch that property from Device Tree? There is no way someone is going to be
> > testing with your specific use case in the future (except yourselves) so unless you
> > make supporting an arbitrary "dev-addr" value become part of how the code
> > works, this is going to be breaking badly.
> >
> 
> Hi Florian,
> 
> My intention was to have this patch as "plugin" and modify the existing kernel API little to none.

Hi Vicenţiu

In Linux, kernel APIs are not sacred. If you need to change them, do
so.

We want a clear, well integrated solution, with minimal
duplication.

	Andrew