From: Florinel Iordache <florinel.iordache@nxp.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"corbet@lwn.net" <corbet@lwn.net>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
Leo Li <leoyang.li@nxp.com>,
"Madalin Bucur (OSS)" <madalin.bucur@oss.nxp.com>,
Ioana Ciornei <ioana.ciornei@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Florinel Iordache <florinel.iordache@nxp.com>
Subject: RE: [EXT] Re: [PATCH net-next 6/9] net: phy: add backplane kr driver support
Date: Fri, 27 Mar 2020 13:02:17 +0000 [thread overview]
Message-ID: <AM0PR04MB5443C1142ABE578ACC641FC5FBCC0@AM0PR04MB5443.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20200327010706.GN3819@lunn.ch>
> > +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.
next prev parent reply other threads:[~2020-03-27 13:02 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 13:51 [PATCH net-next 0/9] net: ethernet backplane support Florinel Iordache
2020-03-26 13:51 ` [PATCH net-next 1/9] doc: net: add backplane documentation Florinel Iordache
2020-03-26 13:51 ` [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings Florinel Iordache
2020-03-27 1:04 ` Andrew Lunn
2020-03-27 12:06 ` Russell King - ARM Linux admin
2020-03-27 15:00 ` [EXT] " Florinel Iordache
2020-03-27 15:28 ` Russell King - ARM Linux admin
2020-03-27 15:44 ` Andrew Lunn
2020-03-27 17:35 ` Russell King - ARM Linux admin
2020-03-30 5:43 ` Madalin Bucur (OSS)
2020-03-30 15:39 ` Rob Herring
2020-03-26 13:51 ` [PATCH net-next 3/9] net: phy: add kr phy connection type Florinel Iordache
2020-03-27 0:15 ` Andrew Lunn
2020-03-27 12:01 ` Russell King - ARM Linux admin
2020-03-27 12:12 ` Madalin Bucur (OSS)
2020-03-27 12:40 ` Russell King - ARM Linux admin
2020-03-29 8:22 ` [EXT] " Florinel Iordache
2020-03-29 9:01 ` Russell King - ARM Linux admin
2020-03-27 0:32 ` Florian Fainelli
2020-03-26 13:51 ` [PATCH net-next 4/9] net: fman: add kr support for dpaa1 mac Florinel Iordache
2020-03-26 13:51 ` [PATCH net-next 5/9] net: dpaa2: add kr support for dpaa2 mac Florinel Iordache
2020-03-26 13:51 ` [PATCH net-next 7/9] net: phy: enable qoriq backplane support Florinel Iordache
2020-03-26 20:03 ` Joe Perches
2020-03-26 20:13 ` Andrew Lunn
2020-03-26 20:27 ` Joe Perches
2020-03-26 13:51 ` [PATCH net-next 8/9] net: phy: add bee algorithm for kr training Florinel Iordache
2020-03-26 13:51 ` [PATCH net-next 9/9] arm64: dts: add serdes and mdio description Florinel Iordache
2020-03-27 12:09 ` Russell King - ARM Linux admin
[not found] ` <1585230682-24417-7-git-send-email-florinel.iordache@nxp.com>
2020-03-26 18:53 ` [PATCH net-next 6/9] net: phy: add backplane kr driver support David Miller
2020-03-26 18:55 ` Joe Perches
2020-03-26 19:07 ` David Miller
2020-03-26 19:42 ` Joe Perches
2020-03-27 1:07 ` Andrew Lunn
2020-03-27 13:02 ` Florinel Iordache [this message]
2020-03-27 13:23 ` [EXT] " Andrew Lunn
2020-03-27 17:43 ` Florian Fainelli
2020-03-27 14:22 ` Andrew Lunn
2020-03-27 18:25 ` Joe Perches
2020-03-27 14:28 ` Andrew Lunn
2020-03-27 14:33 ` Andrew Lunn
2020-03-27 14:38 ` Andrew Lunn
2020-04-01 13:35 Florinel Iordache
2020-04-01 13:51 ` Andrew Lunn
2020-04-01 14:21 ` [EXT] " Florinel Iordache
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM0PR04MB5443C1142ABE578ACC641FC5FBCC0@AM0PR04MB5443.eurprd04.prod.outlook.com \
--to=florinel.iordache@nxp.com \
--cc=andrew@lunn.ch \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=ioana.ciornei@nxp.com \
--cc=kuba@kernel.org \
--cc=leoyang.li@nxp.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=madalin.bucur@oss.nxp.com \
--cc=mark.rutland@arm.com \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).