netdev - RE: [EXT] Re: [PATCH net-next 6/9] net: phy: add backplane kr driver 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: <AM0PR04MB5443C1142ABE578ACC641FC5FBCC0@AM0PR04MB5443.eurprd04.prod.outlook.com>
Date:   Fri, 27 Mar 2020 13:02:17 +0000
From:   Florinel Iordache <florinel.iordache@....com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "corbet@....net" <corbet@....net>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        Leo Li <leoyang.li@....com>,
        "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Florinel Iordache <florinel.iordache@....com>
Subject: RE: [EXT] Re: [PATCH net-next 6/9] net: phy: add backplane kr driver
 support

> > +static u32 le_ioread32(void __iomem *reg) {
> > +     return ioread32(reg);
> > +}
> > +
> > +static void le_iowrite32(u32 value, void __iomem *reg) {
> > +     iowrite32(value, reg);
> > +}
> > +
> > +static u32 be_ioread32(void __iomem *reg) {
> > +     return ioread32be(reg);
> > +}
> > +
> > +static void be_iowrite32(u32 value, void __iomem *reg) {
> > +     iowrite32be(value, reg);
> > +}
> 
> This is very surprising to me. I've not got my head around the structure of this
> code yet, but i'm surprised to see memory mapped access functions in generic
> code.
> 
>        Andrew

Hi Andrew,

This is part of the framework used to automatically setup desired I/O 
callbacks for memory access according to device specific endianness 
which is specified in the specific device tree (DTS).
This approach (explained below) was used to avoid the potential 
redundant code related to memory access LE/BE which should be 
similar for all devices. 

This portion of code is just preparing these four static IO routines 
for specific endianness access LE/BE which are then installed as 
callbacks by the generic driver on generic DT parsing routine: 
backplane_parse_dt according to endianness flag:
+    /* setup ioread/iowrite according to endianness */
+    if (bp_phy->bp_dev.is_little_endian) {
+        bp_phy->bp_dev.io.read32 = le_ioread32;
+        bp_phy->bp_dev.io.write32 = le_iowrite32;
+    } else {
+        bp_phy->bp_dev.io.read32 = be_ioread32;
+        bp_phy->bp_dev.io.write32 = be_iowrite32;
+    }

These io callbacks are setup in the following structure:
+/* Endianness specific memory I/O operations */ 
struct mem_io_ops {

which is part of generic structure:
+/* Backplane device info */
+struct backplane_dev_info {
+. . . 
+    struct mem_io_ops io;

which in the end will be used directly by the device specific code for 
specific memory access according to specific endianness specified 
in the DTS. 

The endianness flag must be correctly set by the device specific code 
before calling the generic function backplane_parse_dt, according to 
device specific endianness specified in the specific device tree DTS:
+bp_phy->bp_dev.is_little_endian = of_property_read_bool(serdes_node,
                            "little-endian");

This action to setup desired IO callbacks could also be performed in the 
specific device code but by using this framework the process is more 
automatic, it's reusing the logic and therefore decreasing the overall 
LOC required.
If any specific device is doing this action by itself (which is a similar 
action regardless the specific device) then we will end up with a lot of 
redundant code.

Florin.