| 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
| ||
|
Message-ID: <VI1PR04MB572687F21D67F3910DD3CF9F99DD0@VI1PR04MB5726.eurprd04.prod.outlook.com>
Date: Fri, 16 Nov 2018 09:46:33 +0000
From: Yogesh Narayan Gaur <yogeshnarayan.gaur@....com>
To: Schrempf Frieder <frieder.schrempf@...tron.De>
CC: Boris Brezillon <boris.brezillon@...tlin.com>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
Marek Vasut <marek.vasut@...il.com>,
Mark Brown <broonie@...nel.org>, Han Xu <han.xu@....com>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"computersforpeace@...il.com" <computersforpeace@...il.com>,
"richard@....at" <richard@....at>,
"miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>,
David Wolfe <david.wolfe@....com>,
Fabio Estevam <fabio.estevam@....com>,
Prabhakar Kushwaha <prabhakar.kushwaha@....com>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v5 3/9] spi: Add a driver for the Freescale/NXP QuadSPI
controller
Hi Frieder,
> -----Original Message-----
> From: Schrempf Frieder [mailto:frieder.schrempf@...tron.De]
> Sent: Friday, November 16, 2018 3:12 PM
> To: Yogesh Narayan Gaur <yogeshnarayan.gaur@....com>
> Cc: Boris Brezillon <boris.brezillon@...tlin.com>; linux-mtd@...ts.infradead.org;
> linux-spi@...r.kernel.org; Marek Vasut <marek.vasut@...il.com>; Mark
> Brown <broonie@...nel.org>; Han Xu <han.xu@....com>;
> dwmw2@...radead.org; computersforpeace@...il.com; richard@....at;
> miquel.raynal@...tlin.com; David Wolfe <david.wolfe@....com>; Fabio
> Estevam <fabio.estevam@....com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@....com>; shawnguo@...nel.org; linux-
> kernel@...r.kernel.org
> Subject: Re: [PATCH v5 3/9] spi: Add a driver for the Freescale/NXP QuadSPI
> controller
>
> Hi Yogesh,
>
> On 16.11.18 06:41, Yogesh Narayan Gaur wrote:
> > Hi Frieder,
> >
> >> -----Original Message-----
> >> From: Schrempf Frieder [mailto:frieder.schrempf@...tron.De]
> >> Sent: Thursday, November 15, 2018 7:32 PM
> >> To: Yogesh Narayan Gaur <yogeshnarayan.gaur@....com>
> >> Cc: Boris Brezillon <boris.brezillon@...tlin.com>;
> >> linux-mtd@...ts.infradead.org; linux-spi@...r.kernel.org; Marek Vasut
> >> <marek.vasut@...il.com>; Mark Brown <broonie@...nel.org>; Han Xu
> >> <han.xu@....com>; dwmw2@...radead.org;
> computersforpeace@...il.com;
> >> richard@....at; miquel.raynal@...tlin.com; David Wolfe
> >> <david.wolfe@....com>; Fabio Estevam <fabio.estevam@....com>;
> >> Prabhakar Kushwaha <prabhakar.kushwaha@....com>;
> shawnguo@...nel.org;
> >> linux- kernel@...r.kernel.org
> >> Subject: Re: [PATCH v5 3/9] spi: Add a driver for the Freescale/NXP
> >> QuadSPI controller
> >>
> >> Hi Yogesh,
> >>
> >> On 15.11.18 14:12, Boris Brezillon wrote:
> >>> On Thu, 15 Nov 2018 11:43:05 +0000
> >>> Schrempf Frieder <frieder.schrempf@...tron.De> wrote:
> >>>
> >>>> On 15.11.18 07:22, Yogesh Narayan Gaur wrote:
> >>>>> Hi Frieder,
> >>>>>
> >>>>> With below patch on top of your v5, Read/Write/Erase on CS1 is
> >>>>> working
> >> fine for me.
> >>>>
> >>>> Ok, are you sure, that AHB read is working too with this patch?
> >>>> You are removing the memmap_phy offset from SFAR and the SFXXAD
> >>>> register values.
> >>>>
> >>>> I can understand that selection of the CS and IP commands will work
> >>>> like this, but I can't understand how AHB read should work without
> >>>> the base address of the mapped memory.
> >>>>
> >>>> I'm afraid I still don't fully understand the background of these
> >>>> things,
> >>>
> >>> Same here. Yogesh, can you give us more detail on why you decided to
> >>> drop the memmap_phy offset?
> >>
> >> Your changes do not work on my setup (i.MX6UL). It looks like your
> >> hardware is different.
> >>
> >> I found this patch for LS2080A: [1]. This would explain why you need
> >> to remove the offset to make it work.
> >>
> >> To verify this, could you please test your setup with the current
> >> spi-nor driver (fsl_quadspi.c). If our assumptions are right, it
> >> should only work on CS0 and CS1 with [1] applied.
> >>
> >
> > Yes, I need to remove the offset to make it work and this is required for the
> NXP Layerscape-2.x SoCs like LS208x/Ls108x etc.
> >
> > I have modified the patch and have introduced entry in quirks for ls2080a. With
> this Read/Write/Erase are working for me for both CS.
>
> Ok, what I was asking for is a test with the original, unmodified SPI NOR driver in
> mtd/spi-nor/fsl-quadspi.c. We need this to confirm that the problem is really
> what we think, or to find out if we missed something.
>
> Can you please do a quick test? If it confirms our assumptions, I will send a new
> version with the quirk and hopefully we can then move on.
>
Yes, problem exist with original un-modified upstread SPI-NOR driver also.
Actually, internally we are maintaining driver with some local change and one of the change is related to same i.e. making having map_addr as 0 for layerscape chips.
I have tested, that by removing that CS1 access shows error.
Please integrate these changes in your next version.
--
Regards
Yogesh Gaur
> Thanks,
> Frieder
>
> >
> > diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c
> > index ce45e8e..5d26f73 100644
> > --- a/drivers/spi/spi-fsl-qspi.c
> > +++ b/drivers/spi/spi-fsl-qspi.c
> > @@ -175,6 +175,9 @@
> > /* TKT245618, the controller cannot wake up from wait mode */
> > #define QUADSPI_QUIRK_TKT245618 BIT(3)
> >
> > +/* QSPI_AMBA_BASE is internally added by SOC design for LS-2.x architecture
> */
> > +#define QUADSPI_AMBA_BASE_INTERNAL BIT(4)
> > +
> > struct fsl_qspi_devtype_data {
> > unsigned int rxfifo;
> > unsigned int txfifo;
> > @@ -227,7 +230,7 @@ static const struct fsl_qspi_devtype_data
> ls2080a_data = {
> > .rxfifo = SZ_128,
> > .txfifo = SZ_64,
> > .ahb_buf_size = SZ_1K,
> > - .quirks = QUADSPI_QUIRK_TKT253890,
> > + .quirks = QUADSPI_QUIRK_TKT253890 |
> > + QUADSPI_AMBA_BASE_INTERNAL,
> > .little_endian = true,
> > };
> >
> > @@ -235,6 +238,7 @@ struct fsl_qspi {
> > void __iomem *iobase;
> > void __iomem *ahb_addr;
> > u32 memmap_phy;
> > + u32 amba_base_addr;
> > struct clk *clk, *clk_en;
> > struct device *dev;
> > struct completion c;
> > @@ -264,6 +268,11 @@ static inline int needs_wakeup_wait_mode(struct
> fsl_qspi *q)
> > return q->devtype_data->quirks & QUADSPI_QUIRK_TKT245618;
> > }
> >
> > +static inline int has_added_amba_base_internal(struct fsl_qspi *q) {
> > + return q->devtype_data->quirks & QUADSPI_AMBA_BASE_INTERNAL; }
> > +
> > /*
> > * An IC bug makes it necessary to rearrange the 32-bit data.
> > * Later chips, such as IMX6SLX, have fixed this bug.
> > @@ -489,29 +498,11 @@ static void fsl_qspi_invalidate(struct fsl_qspi *q)
> > static void fsl_qspi_select_mem(struct fsl_qspi *q, struct spi_device *spi)
> > {
> > unsigned long rate = spi->max_speed_hz;
> > - int ret, i;
> > - u32 map_addr;
> > + int ret;
> >
> > if (q->selected == spi->chip_select)
> > return;
> >
> > - /*
> > - * In HW there can be a maximum of four chips on two buses with
> > - * two chip selects on each bus. We use four chip selects in SW
> > - * to differentiate between the four chips.
> > - * We use the SFA1AD, SFA2AD, SFB1AD, SFB2AD registers to select
> > - * the chip we want to access.
> > - */
> > - for (i = 0; i < 4; i++) {
> > - if (i < spi->chip_select)
> > - map_addr = q->memmap_phy;
> > - else
> > - map_addr = q->memmap_phy +
> > - 2 * q->devtype_data->ahb_buf_size;
> > -
> > - qspi_writel(q, map_addr, q->iobase + QUADSPI_SFA1AD + (i * 4));
> > - }
> > -
> > if (needs_4x_clock(q))
> > rate *= 4;
> >
> > @@ -534,7 +525,9 @@ static void fsl_qspi_select_mem(struct fsl_qspi
> > *q, struct spi_device *spi)
> >
> > static void fsl_qspi_read_ahb(struct fsl_qspi *q, const struct spi_mem_op *op)
> > {
> > - memcpy_fromio(op->data.buf.in, q->ahb_addr, op->data.nbytes);
> > + memcpy_fromio(op->data.buf.in,
> > + q->ahb_addr + q->selected * q->devtype_data->ahb_buf_size,
> > + op->data.nbytes);
> > }
> >
> > static void fsl_qspi_fill_txfifo(struct fsl_qspi *q, @@ -634,7
> > +627,9 @@ static int fsl_qspi_exec_op(struct spi_mem *mem, const
> > struct spi_mem_op *op)
> >
> > fsl_qspi_select_mem(q, mem->spi);
> >
> > - qspi_writel(q, q->memmap_phy, base + QUADSPI_SFAR);
> > + qspi_writel(q, q->amba_base_addr +
> > + q->selected * q->devtype_data->ahb_buf_size,
> > + base + QUADSPI_SFAR);
> >
> > qspi_writel(q, qspi_readl(q, base + QUADSPI_MCR) |
> > QUADSPI_MCR_CLR_RXF_MASK |
> > QUADSPI_MCR_CLR_TXF_MASK, @@ -733,6 +728,23 @@ static int
> fsl_qspi_default_setup(struct fsl_qspi *q)
> > QUADSPI_BUF3CR_ADATSZ(q->devtype_data->ahb_buf_size / 8),
> > base + QUADSPI_BUF3CR);
> >
> > + /*
> > + * In HW there can be a maximum of four chips on two buses with
> > + * two chip selects on each bus. We use four chip selects in SW
> > + * to differentiate between the four chips.
> > + * We use the SFA1AD, SFA2AD, SFB1AD, SFB2AD registers to select
> > + * the chip we want to access.
> > + */
> > +
> > + qspi_writel(q, q->amba_base_addr + q->devtype_data->ahb_buf_size,
> > + base + QUADSPI_SFA1AD);
> > + qspi_writel(q, q->amba_base_addr + q->devtype_data->ahb_buf_size * 2,
> > + base + QUADSPI_SFA2AD);
> > + qspi_writel(q, q->amba_base_addr + q->devtype_data->ahb_buf_size * 3,
> > + base + QUADSPI_SFB1AD);
> > + qspi_writel(q, q->amba_base_addr + q->devtype_data->ahb_buf_size * 4,
> > + base + QUADSPI_SFB2AD);
> > +
> > q->selected = -1;
> >
> > /* Enable the module */
> > @@ -825,6 +837,11 @@ static int fsl_qspi_probe(struct platform_device
> > *pdev)
> >
> > q->memmap_phy = res->start;
> >
> > + if (has_added_amba_base_internal(q))
> > + q->amba_base_addr = 0;
> > + else
> > + q->amba_base_addr = q->memmap_phy;
> > +
> > /* find the clocks */
> > q->clk_en = devm_clk_get(dev, "qspi_en");
> > if (IS_ERR(q->clk_en)) {
> >
> > --
> > Regards
> > Yogesh Gaur
> > [...]
> >
Powered by blists - more mailing lists