linux-kernel - RE: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian 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]

Date:	Fri, 30 Oct 2015 09:49:41 +0000
From:	Yao Yuan <yao.yuan@...escale.com>
To:	Fabio Estevam <festevam@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	Li Leo <LeoLi@...escale.com>,
	Scott Wood <scottwood@...escale.com>,
	Xu Han <han.xu@...escale.com>
CC:	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

Hi Fabio Estevam,

Thanks for your suggestion.
We have an internal discussions for that.

We think that:
According to the initial commit message of regmap, it is targeting non-memory mapped buses. (regmap: Add generic non-memory mapped register access API)  But in the imx2_wdt driver, it is used for memory-mapped register space.  So it seems that using such a complex framework just to deal with endian is an over-kill.

when it is not necessary to enable the clock every time we access the register.  
We don't think it is obvious to us how to use it for handling endianness, especially not the way imx2_wdt uses regmap.  __regmap_init_mmio_clk() calls regmap_mmio_gen_context() which errors out if reg_format_endian is not REGMAP_ENDIAN_DEFAULT or REGMAP_ENDIAN_NATIVE, and elsewhere regmap-mmio.c It seems only little-endian accessors.

Although it is possible to add the endianness support in the regmap_mmio driver, we don't see too much value in using it especially 

So we think:
static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
*addr) {
      if (q->big_endian)
              iowrite32be(val, addr);
      else
              iowrite32(val, addr);
}
This way is an easier, more effective solution to do the endian issue.

How about your think?

Best Regards,
Yuan Yao

On Sat, Oct 24, 2015 at 11:47 PM, Fabio Estevam <festevam@...il.com> wrote:
> On Fri, Oct 23, 2015 at 5:53 AM, Yuan Yao <yao.yuan@...escale.com> wrote:
> 
> > +static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > +*addr) {
> > +       if (q->big_endian)
> > +               iowrite32be(val, addr);
> > +       else
> > +               iowrite32(val, addr);
> > +}
> 
> I suggest you to implement regmap support for this driver instead.
> 
> Take a look at drivers/watchdog/imx2_wdt.c for a reference.
> 
> Then you only need to pass 'big-endian' as a property for the qspi in the .dtsi
> file and regmap core will take care of endianness.