netdev - Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY 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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Feb 2017 02:54:16 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Lukasz Majewski <lukma@...x.de>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Mugunthan V N <mugunthanvnm@...com>,
        Karicheri Muralidharan <m-karicheri2@...com>,
        linux-kernel@...r.kernel.org, Eric Engestrom <eric@...estrom.ch>,
        netdev@...r.kernel.org, Kishon Vijay Abraham I <kishon@...com>,
        Grygorii Strashko <grygorii.strashko@...com>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867
 TI's PHY driver

On Wed, Feb 01, 2017 at 11:13:23PM +0100, Lukasz Majewski wrote:
> Hi Andrew,
> 
> > > We would need a tri-state device tree properly:
> > > 
> > > 1. Not defined - do nothing
> > > 2. Defined as 0 -> explicitly disable port mirroring
> > > 3. Defined as 1 -> explicitly enable port mirriring
> > > 
> > > The "net-phy-lane-swap" only fulfills points 1 and 3 above.
> > > 
> > > In my use case I do need point 2.
> > 
> > Looking at the datasheet, PORT_MIRROR_EN defaults to 0. So it seems
> > reasonable to unconditionally set it to 0 when the PHY driver
> > loads. Any device which needs a value of 1 can set "net-phy-lane-swap"
> 
> Unconditionally setting this field to 0 (as we expect the reset default
> setting) seems to me like a good solution. 
> 
> However, I was not sure if such approach is acceptable by the community.

So the issue here is, are there boards with bootloaders which set this
"lane swap" bit, and rely on Linux not changing it, because the
hardware design has such a swap?

It seems the bootloader you are using does this. But in your case, it
does it wrongly. I'm guessing you have a vendor bootloader? And no
easy access to the sources? Otherwise you would of fixed the
bootloader. So can we assume there are vendor designed boards which
require the swap? Do they run a mainline kernel? Or only the vendor
kernel?

If we know of mainline boards which are going to break, we should not
do this.

If however we do decide to reset it to default value, i think it would
be good to implement net-phy-lane-swap as well, so giving people an
easier path towards mainline.

       Andrew