netdev - Re: [PATCHv2 net-next 01/16] dt-bindings: net: update Marvell PPv2 binding for PPv2.2 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170214152503.602878cb@free-electrons.com>
Date:   Tue, 14 Feb 2017 15:25:03 +0100
From:   Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Rob Herring <robh@...nel.org>, Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org, Yehuda Yitschak <yehuday@...vell.com>,
        Jason Cooper <jason@...edaemon.net>,
        Pawel Moll <pawel.moll@....com>,
        Ian Campbell <ijc+devicetree@...lion.org.uk>,
        netdev@...r.kernel.org, Hanna Hawa <hannah@...vell.com>,
        Nadav Haklai <nadavh@...vell.com>,
        Andrew Lunn <andrew@...n.ch>,
        Kumar Gala <galak@...eaurora.org>,
        Gregory Clement <gregory.clement@...e-electrons.com>,
        Stefan Chulski <stefanc@...vell.com>,
        Marcin Wojtas <mw@...ihalf.com>,
        "David S. Miller" <davem@...emloft.net>,
        linux-arm-kernel@...ts.infradead.org,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCHv2 net-next 01/16] dt-bindings: net: update Marvell PPv2
 binding for PPv2.2 support

Hello,

On Fri, 3 Feb 2017 16:48:08 +0000, Russell King - ARM Linux wrote:
> On Thu, Feb 02, 2017 at 05:56:50PM +0100, Thomas Petazzoni wrote:
> > For PPv2.2, we wanted to simplify a little bit the register mappings,
> > and simply reflect the memory map of the SoC. In the SoC datasheet,
> > there are two memory areas for the networking subsystem, which are the
> > two areas reflected in:
> > 
> >         reg = <0x0 0x100000>,
> >               <0x100000 0x80000>;
> > 
> > The per-port registers are inside the second register area. But by
> > exposing the entire register area in the Device Tree binding, we allow
> > improvements in the driver that need additional registers to be made
> > without changing the Device Tree description of the device.  
> 
> Are you sure that this makes sense?  You have the serdes block at
> 0x120000-0x125fff, which sits within that range, and that needs to
> be configured for SATA and PCIe, so it's not strictly just a network
> thing.
> 
> I know from my experimentation that disabling the "serdes" by clearing
> the SD_EXTERNAL_CONFIG1_REG and SD_EXTERNAL_CONFIG0_REG for SATA
> channels prevents SATA working.

I have simply/stupidly followed the datasheet, which says:

 Packet processor:        0xf2000000, 0xf4000000 (i.e offset 0x0 in the CP)
 Networking interfaces:   0xf2100000, 0xf4100000 (i.e offset 0x100000 in the CP)
 IO Bridge Addr Decoding: 0xf2190000, 0xf4190000

And since there is no other block described, I assumed that the entire
range 0xf2000000 to 0xf2100000 was dedicated to the "Packet processor",
and that the range 0xf2100000 to 0xf2190000 was dedicated to the
"Networking interfaces" (and I realize the size is 0x90000, not
0x80000).

On the other hand, there are registers after 0x125fff that are really
networking related. For example, the driver is currently accessing
0x12a204, which is after the SERDES related registers.

I'll try to get some more information about this, but I suspect this is
one case where we don't yet fully understand how all the HW works and
what all registers are doing, so it's hard to do a perfect DT binding
from day 1.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com