linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Florinel Iordache <florinel.iordache@nxp.com>
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>
Subject: Re: [EXT] Re: [PATCH net-next 6/9] net: phy: add backplane kr driver support
Date: Fri, 27 Mar 2020 14:23:13 +0100	[thread overview]
Message-ID: <20200327132313.GO3819@lunn.ch> (raw)
In-Reply-To: <AM0PR04MB5443C1142ABE578ACC641FC5FBCC0@AM0PR04MB5443.eurprd04.prod.outlook.com>

On Fri, Mar 27, 2020 at 01:02:17PM +0000, Florinel Iordache wrote:
> > > +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. 

All devices which are using mmio. I assume the standard does not say
anything about memory mapped IO. It talks just about MDIO registers.

I would expect the generic code to just have generic accessors, which
could work for MMIO, yet more MDIO registers, i2c, spi, etc.

So add another support file which adds an MMIO implementation of these
generic access functions. Any driver which uses MMIO can pull it in.
The same should be true for the DT binding. Don't assume MMIO in the
generic binding.

> This portion of code is just preparing these four static IO routines 
> for specific endianness access LE/BE

Linux has a lot of MMIO accessors. Are you sure there is not one which
will do the right thing, making use of cpu_le32() or cpu_be32()
etc. Or are there different variants of the hardware, with some using
BE registers and some using LE registers? Note, this is all about the
endianness of the register, not the endianness of the cpu. cpu_le32()
will be a NOP when the CPU is running LE.

     Andrew

  reply	other threads:[~2020-03-27 13:23 UTC|newest]

Thread overview: 43+ 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 6/9] net: phy: add backplane kr driver support Florinel Iordache
2020-03-26 18:53   ` 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     ` [EXT] " Florinel Iordache
2020-03-27 13:23       ` Andrew Lunn [this message]
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-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
2020-04-01 13:35 [PATCH net-next 6/9] net: phy: add backplane kr driver support 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=20200327132313.GO3819@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=florinel.iordache@nxp.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).