Re: [PATCH v4 0/5] spi: spi-mem: Add driver for NXP FlexSPI controller
On Mon, 22 Oct 2018 11:43:40 + Yogesh Narayan Gaur wrote: > + Mark Brown > > Complete patch series[1] > [1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70210 Please resend the patch series with a "PATCH RESEND v4" prefix and explain why you resend it in the cover letter. > > -- > Regards, > Yogesh Gaur > > > -Original Message- > > From: Yogesh Narayan Gaur [mailto:yogeshnarayan.g...@nxp.com] > > Sent: Thursday, October 11, 2018 4:30 PM > > To: linux-...@lists.infradead.org; boris.brezil...@bootlin.com; > > marek.va...@gmail.com; linux-...@vger.kernel.org; > > devicet...@vger.kernel.org > > Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux- > > arm-ker...@lists.infradead.org; computersforpe...@gmail.com; > > frieder.schre...@exceet.de; linux-kernel@vger.kernel.org; Yogesh Narayan > > Gaur > > Subject: [PATCH v4 0/5] spi: spi-mem: Add driver for NXP FlexSPI controller > > > > - Add driver for NXP FlexSPI host controller > > > > FlexSPI is a flexsible SPI host controller [1], Chapter 30 page 1475, > > which > > supports two SPI channels and up to 4 external devices. > > Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 > > bidirectional data lines) i.e. FlexSPI acts as an interface to external > > devices, > > maximum 4, each with up to 8 bidirectional data lines. > > > > - Tested this driver with mtd_debug(Erase/Write/Read) utility and JFFS2 > > filesystem mounting and booting on NXP LX2160ARDB[2] and LX2160AQDS > > targets. > > LX2160ARDB is having two NOR slave device connected on single bus A i.e. > > A0 > > and A1 (CS0 and CS1). > > LX2160AQDS is having two NOR slave device connected on separate buses one > > flash on A0 and second on B1 i.e. (CS0 and CS3). > > Verified this driver on following SPI NOR flashes: > >Micron, mt35xu512aba[3], [Read - 1 bit mode] > >Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > > > [1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf > > [2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=26689 > > [3] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70179 > > > > Yogesh Gaur (5): > > spi: spi-mem: Add driver for NXP FlexSPI controller > > dt-bindings: spi: add binding file for NXP FlexSPI controller > > arm64: dts: lx2160a: add FlexSPI node property > > arm64: defconfig: enable NXP FlexSPI driver > > MAINTAINERS: add maintainers for the NXP FlexSPI driver > > > > Changes for v4: > > - Incorporated review comments for > > patch 'spi: spi-mem: Add driver for NXP FlexSPI controller'. > > - Incorporated binding file review comments. > > Changes for v3: > > - Incorporated review comments for > > patch 'spi: spi-mem: Add driver for NXP FlexSPI controller'. > > Changes for v2: > > - Incorporated Boris review comments and drop below patches as per the > > comments. > > - Patch 'spi: add slave device size in spi_device struct' > > - Patch 'spi: add flags for octal I/O data transfer' > > - Incorporated DTS and Binding file review comments of Shawn Guo and Rob > > Herring. > > > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 39 + > > MAINTAINERS|6 + > > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 22 + > > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 + > > arch/arm64/configs/defconfig |1 + > > drivers/spi/Kconfig| 10 + > > drivers/spi/Makefile |1 + > > drivers/spi/spi-nxp-fspi.c | 1158 > > > > 8 files changed, 1249 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > create mode 100644 drivers/spi/spi-nxp-fspi.c > > > > -- > > 2.7.4 >
Re: [PATCH v4 0/5] spi: spi-mem: Add driver for NXP FlexSPI controller
On Mon, 22 Oct 2018 11:43:40 + Yogesh Narayan Gaur wrote: > + Mark Brown > > Complete patch series[1] > [1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70210 Please resend the patch series with a "PATCH RESEND v4" prefix and explain why you resend it in the cover letter. > > -- > Regards, > Yogesh Gaur > > > -Original Message- > > From: Yogesh Narayan Gaur [mailto:yogeshnarayan.g...@nxp.com] > > Sent: Thursday, October 11, 2018 4:30 PM > > To: linux-...@lists.infradead.org; boris.brezil...@bootlin.com; > > marek.va...@gmail.com; linux-...@vger.kernel.org; > > devicet...@vger.kernel.org > > Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux- > > arm-ker...@lists.infradead.org; computersforpe...@gmail.com; > > frieder.schre...@exceet.de; linux-kernel@vger.kernel.org; Yogesh Narayan > > Gaur > > Subject: [PATCH v4 0/5] spi: spi-mem: Add driver for NXP FlexSPI controller > > > > - Add driver for NXP FlexSPI host controller > > > > FlexSPI is a flexsible SPI host controller [1], Chapter 30 page 1475, > > which > > supports two SPI channels and up to 4 external devices. > > Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 > > bidirectional data lines) i.e. FlexSPI acts as an interface to external > > devices, > > maximum 4, each with up to 8 bidirectional data lines. > > > > - Tested this driver with mtd_debug(Erase/Write/Read) utility and JFFS2 > > filesystem mounting and booting on NXP LX2160ARDB[2] and LX2160AQDS > > targets. > > LX2160ARDB is having two NOR slave device connected on single bus A i.e. > > A0 > > and A1 (CS0 and CS1). > > LX2160AQDS is having two NOR slave device connected on separate buses one > > flash on A0 and second on B1 i.e. (CS0 and CS3). > > Verified this driver on following SPI NOR flashes: > >Micron, mt35xu512aba[3], [Read - 1 bit mode] > >Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > > > [1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf > > [2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=26689 > > [3] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70179 > > > > Yogesh Gaur (5): > > spi: spi-mem: Add driver for NXP FlexSPI controller > > dt-bindings: spi: add binding file for NXP FlexSPI controller > > arm64: dts: lx2160a: add FlexSPI node property > > arm64: defconfig: enable NXP FlexSPI driver > > MAINTAINERS: add maintainers for the NXP FlexSPI driver > > > > Changes for v4: > > - Incorporated review comments for > > patch 'spi: spi-mem: Add driver for NXP FlexSPI controller'. > > - Incorporated binding file review comments. > > Changes for v3: > > - Incorporated review comments for > > patch 'spi: spi-mem: Add driver for NXP FlexSPI controller'. > > Changes for v2: > > - Incorporated Boris review comments and drop below patches as per the > > comments. > > - Patch 'spi: add slave device size in spi_device struct' > > - Patch 'spi: add flags for octal I/O data transfer' > > - Incorporated DTS and Binding file review comments of Shawn Guo and Rob > > Herring. > > > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 39 + > > MAINTAINERS|6 + > > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 22 + > > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 + > > arch/arm64/configs/defconfig |1 + > > drivers/spi/Kconfig| 10 + > > drivers/spi/Makefile |1 + > > drivers/spi/spi-nxp-fspi.c | 1158 > > > > 8 files changed, 1249 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > create mode 100644 drivers/spi/spi-nxp-fspi.c > > > > -- > > 2.7.4 >
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 11:03:09 + Yogesh Narayan Gaur wrote: > Hi, > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > Sent: Monday, October 22, 2018 4:23 PM > > To: Yogesh Narayan Gaur ; > > cristian.bir...@microchip.com > > Cc: Tudor Ambarus ; rich...@nod.at; Mark > > Brown ; linux-kernel@vger.kernel.org; > > nicolas.fe...@microchip.com; marek.va...@gmail.com; > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille > > Pitchen > > ; computersforpe...@gmail.com; > > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP > > SPI > > NOR flash memories > > > > On Mon, 22 Oct 2018 12:46:27 +0200 > > Boris Brezillon wrote: > > > > > On Mon, 22 Oct 2018 10:39:48 + > > > Yogesh Narayan Gaur wrote: > > > > > > > > > > > [1.632190] Start [addr_width:, read_dumy:08, > > read_opcode:] > > > > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > > > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > > read_opcode:] > > > > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > > > > > You still don't print read_dummy correctly: %0x8 -> %08x. > > > > > > Can you add > > > > > > if (!nor->addr_width) > > > nor->addr_width = 3; > > > > > > After the > > > > > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); > > > > > > line. > > > > And you should also try to force ->read_dummy to 8, because according to the > > spec, the default read_latency is 8 for this chip. With that in place, you > > should > > get an map_id of 1, 3 or 5. > > > > Below is the log output. > I have forced the read_dummy as 8 and addr_width is programmed as 3. > > [1.625176] m25p80 spi0.0: found s25fl512s, expected m25p80 > > [1.630875] Start [addr_width:, read_dumy:, > read_opcode:] > [1.638352] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.643658] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.648963] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.654266] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.659569] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.664872] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.670175] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.675477] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 11:03:09 + Yogesh Narayan Gaur wrote: > Hi, > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > Sent: Monday, October 22, 2018 4:23 PM > > To: Yogesh Narayan Gaur ; > > cristian.bir...@microchip.com > > Cc: Tudor Ambarus ; rich...@nod.at; Mark > > Brown ; linux-kernel@vger.kernel.org; > > nicolas.fe...@microchip.com; marek.va...@gmail.com; > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille > > Pitchen > > ; computersforpe...@gmail.com; > > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP > > SPI > > NOR flash memories > > > > On Mon, 22 Oct 2018 12:46:27 +0200 > > Boris Brezillon wrote: > > > > > On Mon, 22 Oct 2018 10:39:48 + > > > Yogesh Narayan Gaur wrote: > > > > > > > > > > > [1.632190] Start [addr_width:, read_dumy:08, > > read_opcode:] > > > > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > > > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > > read_opcode:] > > > > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > > > > > You still don't print read_dummy correctly: %0x8 -> %08x. > > > > > > Can you add > > > > > > if (!nor->addr_width) > > > nor->addr_width = 3; > > > > > > After the > > > > > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); > > > > > > line. > > > > And you should also try to force ->read_dummy to 8, because according to the > > spec, the default read_latency is 8 for this chip. With that in place, you > > should > > get an map_id of 1, 3 or 5. > > > > Below is the log output. > I have forced the read_dummy as 8 and addr_width is programmed as 3. > > [1.625176] m25p80 spi0.0: found s25fl512s, expected m25p80 > > [1.630875] Start [addr_width:, read_dumy:, > read_opcode:] > [1.638352] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.643658] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.648963] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.654266] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.659569] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.664872] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.670175] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.675477] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 12:46:27 +0200 Boris Brezillon wrote: > On Mon, 22 Oct 2018 10:39:48 + > Yogesh Narayan Gaur wrote: > > > > > [1.632190] Start [addr_width:, read_dumy:08, > > read_opcode:] > > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > > read_opcode:] > > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > You still don't print read_dummy correctly: %0x8 -> %08x. > > Can you add > > if (!nor->addr_width) > nor->addr_width = 3; > > After the > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); > > line. And you should also try to force ->read_dummy to 8, because according to the spec, the default read_latency is 8 for this chip. With that in place, you should get an map_id of 1, 3 or 5. > > > [1.745932] spi_nor_get_map_in_use:2911 map_id=0 smpt_len:16 i=:3 > > > > [1.752018] End [addr_width:, read_dumy:08, > > read_opcode:0065] > > > > Also, one more thing when we are returning from the function, we are > > over-writing the values of addr_widthm read_dummy and read_opcode. > > Is this correct? > > Yes, that's correct. > > > > > out: > > nor->addr_width = addr_width; > > nor->read_dummy = read_dummy; > > nor->read_opcode = read_opcode; > > return ret; > > } > > > >
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 12:46:27 +0200 Boris Brezillon wrote: > On Mon, 22 Oct 2018 10:39:48 + > Yogesh Narayan Gaur wrote: > > > > > [1.632190] Start [addr_width:, read_dumy:08, > > read_opcode:] > > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > > read_opcode:] > > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > You still don't print read_dummy correctly: %0x8 -> %08x. > > Can you add > > if (!nor->addr_width) > nor->addr_width = 3; > > After the > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); > > line. And you should also try to force ->read_dummy to 8, because according to the spec, the default read_latency is 8 for this chip. With that in place, you should get an map_id of 1, 3 or 5. > > > [1.745932] spi_nor_get_map_in_use:2911 map_id=0 smpt_len:16 i=:3 > > > > [1.752018] End [addr_width:, read_dumy:08, > > read_opcode:0065] > > > > Also, one more thing when we are returning from the function, we are > > over-writing the values of addr_widthm read_dummy and read_opcode. > > Is this correct? > > Yes, that's correct. > > > > > out: > > nor->addr_width = addr_width; > > nor->read_dummy = read_dummy; > > nor->read_opcode = read_opcode; > > return ret; > > } > > > >
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur wrote: > > [1.632190] Start [addr_width:, read_dumy:08, > read_opcode:] > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > read_opcode:0065] > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > read_opcode:] > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > read_opcode:0065] You still don't print read_dummy correctly: %0x8 -> %08x. Can you add if (!nor->addr_width) nor->addr_width = 3; After the nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); line. > [1.745932] spi_nor_get_map_in_use:2911 map_id=0 smpt_len:16 i=:3 > > [1.752018] End [addr_width:, read_dumy:08, read_opcode:0065] > > > Also, one more thing when we are returning from the function, we are > over-writing the values of addr_widthm read_dummy and read_opcode. > Is this correct? Yes, that's correct. > > out: > nor->addr_width = addr_width; > nor->read_dummy = read_dummy; > nor->read_opcode = read_opcode; > return ret; > } >
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur wrote: > > [1.632190] Start [addr_width:, read_dumy:08, > read_opcode:] > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > read_opcode:0065] > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > read_opcode:] > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > read_opcode:0065] You still don't print read_dummy correctly: %0x8 -> %08x. Can you add if (!nor->addr_width) nor->addr_width = 3; After the nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); line. > [1.745932] spi_nor_get_map_in_use:2911 map_id=0 smpt_len:16 i=:3 > > [1.752018] End [addr_width:, read_dumy:08, read_opcode:0065] > > > Also, one more thing when we are returning from the function, we are > over-writing the values of addr_widthm read_dummy and read_opcode. > Is this correct? Yes, that's correct. > > out: > nor->addr_width = addr_width; > nor->read_dummy = read_dummy; > nor->read_opcode = read_opcode; > return ret; > } >
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> * @nor: pointer to a 'struct spi_nor'
> * @smpt: pointer to the sector map parameter table
> */
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
^ i += 2) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> addr = smpt[i + 1];
>
> err = spi_nor_read_raw(nor, addr, 1, _byte);
> @@ -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
Drop the above line (i = i + 2).
> }
>
> - /* Find the matching configuration map */
> - while (SMPT_MAP_ID(smpt[i]) != map_id) {
> - if (smpt[i] & SMPT_DESC_END)
> - goto out;
> + if (map_id_is_valid)
> + pr_info("%s:%i map_id=%d\n", __func__, __LINE__, map_id);
> + else
> + pr_info("%s:%i NO map_id\n", __func__, __LINE__);
> +
> + for (nmaps = 0; i< smpt_len; nmaps++) {
> + if((smpt[i] & SMPT_DESC_TYPE_MAP))
> + continue;
> +
> + if(!map_id_is_valid) {
> + if (nmaps) {
> + ret = NULL;
> + break;
> + }
> +
> + ret = smpt+i;
> + } else if (map_id == SMPT_MAP_ID(smpt[i])) {
> + ret = smpt+i;
> + break;
> + }
> +
> /* increment the table index to the next map */
> i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
> }
>
> - ret = smpt + i;
> + pr_info("End [addr_width:%08x, read_dumy:%0x8, read_opcode:%08x]\n",
> nor->addr_width, nor->read_dummy, nor->read_opcode);
> /* fall through */
> out:
> nor->addr_width = addr_width;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> * @nor: pointer to a 'struct spi_nor'
> * @smpt: pointer to the sector map parameter table
> */
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
^ i += 2) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> addr = smpt[i + 1];
>
> err = spi_nor_read_raw(nor, addr, 1, _byte);
> @@ -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
Drop the above line (i = i + 2).
> }
>
> - /* Find the matching configuration map */
> - while (SMPT_MAP_ID(smpt[i]) != map_id) {
> - if (smpt[i] & SMPT_DESC_END)
> - goto out;
> + if (map_id_is_valid)
> + pr_info("%s:%i map_id=%d\n", __func__, __LINE__, map_id);
> + else
> + pr_info("%s:%i NO map_id\n", __func__, __LINE__);
> +
> + for (nmaps = 0; i< smpt_len; nmaps++) {
> + if((smpt[i] & SMPT_DESC_TYPE_MAP))
> + continue;
> +
> + if(!map_id_is_valid) {
> + if (nmaps) {
> + ret = NULL;
> + break;
> + }
> +
> + ret = smpt+i;
> + } else if (map_id == SMPT_MAP_ID(smpt[i])) {
> + ret = smpt+i;
> + break;
> + }
> +
> /* increment the table index to the next map */
> i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
> }
>
> - ret = smpt + i;
> + pr_info("End [addr_width:%08x, read_dumy:%0x8, read_opcode:%08x]\n",
> nor->addr_width, nor->read_dummy, nor->read_opcode);
> /* fall through */
> out:
> nor->addr_width = addr_width;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:17:58 + Yogesh Narayan Gaur wrote: > It works, Not really. > [1.628162] m25p80 spi0.0: found s25fl512s, expected m25p80 > > [1.633854] Start [addr_width:, read_dumy:08, > read_opcode:] > [1.640811] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.646117] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.651421] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.656724] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.662028] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.667331] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.672635] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.677937] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > [1.683240] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > [1.688542] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > [1.693845] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > [1.699234] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > [1.704625] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > [1.710014] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > [1.715403] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > [1.720791] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > [1.726180] smpt[0]=[addr_width:, read_dumy:08, > read_opcode:0065] There's still a problem here: you should see this trace 3 times since we have 3 command descriptors. And of course, the addr_width and read_dummy are wrong. > [1.733320] spi_nor_get_map_in_use:2912 map_id=0 smpt_len:16 i=:3 > > [1.739406] End [addr_width:, read_dumy:08, read_opcode:0065] > > [1.746204] m25p80 spi0.0: s25fl512s (65536 Kbytes)
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:17:58 + Yogesh Narayan Gaur wrote: > It works, Not really. > [1.628162] m25p80 spi0.0: found s25fl512s, expected m25p80 > > [1.633854] Start [addr_width:, read_dumy:08, > read_opcode:] > [1.640811] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.646117] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.651421] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.656724] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.662028] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.667331] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.672635] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.677937] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > [1.683240] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > [1.688542] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > [1.693845] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > [1.699234] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > [1.704625] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > [1.710014] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > [1.715403] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > [1.720791] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > [1.726180] smpt[0]=[addr_width:, read_dumy:08, > read_opcode:0065] There's still a problem here: you should see this trace 3 times since we have 3 command descriptors. And of course, the addr_width and read_dummy are wrong. > [1.733320] spi_nor_get_map_in_use:2912 map_id=0 smpt_len:16 i=:3 > > [1.739406] End [addr_width:, read_dumy:08, read_opcode:0065] > > [1.746204] m25p80 spi0.0: s25fl512s (65536 Kbytes)
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> [1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
> [1.630377] Start [addr_width:, read_dumy:08, read_opcode:]
> [1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
> [1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
> [1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
> [1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
> [1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
> [1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
> [1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
> [1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
> [1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
> [1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
> [1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
> [1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
> [1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
> [1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
> [1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
> [1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
> [1.722720] smpt[0]=[addr_width:, read_dumy:08,
> read_opcode:0065]
Okay, so addr_width is wrong here (I guess read_dummy is wrong too).
That's probably because we fall in the SMPT_CMD_ADDRESS_LEN_USE_CURRENT
case and nor->addr_width has not yet been initialize when we reach this
function.
> [1.729861] spi_nor_get_map_in_use:2912 map_id=1
>
>
[...]
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
^ %08x
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> [1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
> [1.630377] Start [addr_width:, read_dumy:08, read_opcode:]
> [1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
> [1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
> [1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
> [1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
> [1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
> [1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
> [1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
> [1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
> [1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
> [1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
> [1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
> [1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
> [1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
> [1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
> [1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
> [1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
> [1.722720] smpt[0]=[addr_width:, read_dumy:08,
> read_opcode:0065]
Okay, so addr_width is wrong here (I guess read_dummy is wrong too).
That's probably because we fall in the SMPT_CMD_ADDRESS_LEN_USE_CURRENT
case and nor->addr_width has not yet been initialize when we reach this
function.
> [1.729861] spi_nor_get_map_in_use:2912 map_id=1
>
>
[...]
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
^ %08x
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> Hi,
>
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 2:46 PM
> > To: Yogesh Narayan Gaur
> > Cc: Tudor Ambarus ; rich...@nod.at; Mark
> > Brown ; linux-kernel@vger.kernel.org;
> > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > cristian.bir...@microchip.com; Cyrille Pitchen ;
> > computersforpe...@gmail.com; dw...@infradead.org; linux-arm-
> > ker...@lists.infradead.org
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 06:04:13 +
> > Yogesh Narayan Gaur wrote:
> >
> >
> With below patch, it gets stuck in for loop of "+ for (nmaps = 0; i<
> smpt_len; nmaps++) {".
>
> [1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
> [1.630377] Start [addr_width:, read_dumy:08, read_opcode:]
> [1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
> [1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
> [1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
> [1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
> [1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
> [1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
> [1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
> [1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
> [1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
> [1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
> [1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
> [1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
> [1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
> [1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
> [1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
> [1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
> [1.722720] smpt[0]=[addr_width:, read_dumy:08,
> read_opcode:0065]
> [1.729861] spi_nor_get_map_in_use:2912 map_id=1
>
>
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> * @nor: pointer to a 'struct spi_nor'
> * @smpt: pointer to the sector map parameter table
> */
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> addr = smpt[i + 1];
>
> err = spi_nor_read_raw(nor, addr, 1, _byte);
> @@ -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
> }
>
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> Hi,
>
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 2:46 PM
> > To: Yogesh Narayan Gaur
> > Cc: Tudor Ambarus ; rich...@nod.at; Mark
> > Brown ; linux-kernel@vger.kernel.org;
> > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > cristian.bir...@microchip.com; Cyrille Pitchen ;
> > computersforpe...@gmail.com; dw...@infradead.org; linux-arm-
> > ker...@lists.infradead.org
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 06:04:13 +
> > Yogesh Narayan Gaur wrote:
> >
> >
> With below patch, it gets stuck in for loop of "+ for (nmaps = 0; i<
> smpt_len; nmaps++) {".
>
> [1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
> [1.630377] Start [addr_width:, read_dumy:08, read_opcode:]
> [1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
> [1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
> [1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
> [1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
> [1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
> [1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
> [1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
> [1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
> [1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
> [1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
> [1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
> [1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
> [1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
> [1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
> [1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
> [1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
> [1.722720] smpt[0]=[addr_width:, read_dumy:08,
> read_opcode:0065]
> [1.729861] spi_nor_get_map_in_use:2912 map_id=1
>
>
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> * @nor: pointer to a 'struct spi_nor'
> * @smpt: pointer to the sector map parameter table
> */
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> addr = smpt[i + 1];
>
> err = spi_nor_read_raw(nor, addr, 1, _byte);
> @@ -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
> }
>
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> - /* Find the matching configuration map */
> - while (SMPT_MAP_ID(smpt[i]) != map_id) {
> - if (smpt[i] & SMPT_DESC_END)
> - goto out;
> + if (map_id_is_valid)
> + pr_info("%s:%i map_id=%d\n", __func__, __LINE__, map_id);
> + else
> + pr_info("%s:%i NO map_id\n", __func__, __LINE__);
> +
> + for (nmaps = 0; nmaps< smpt_len; nmaps++) {
Why did you change this for loop?
> + if(!(smpt[nmaps] & SMPT_DESC_TYPE_MAP))
> + continue;
> +
> + if(!map_id_is_valid) {
> + if (nmaps) {
With your change in the for () block, this test is no longer valid...
Please keep the original patch and patch the if () condition as
suggested.
> + ret = NULL;
> + break;
> + }
> +
> + ret = smpt+nmaps;
> + } else if (map_id == SMPT_MAP_ID(smpt[nmaps])) {
> + ret = smpt+nmaps;
> + break;
> + }
> +
> /* increment the table index to the next map */
> - i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
> + nmaps += SMPT_MAP_REGION_COUNT(smpt[nmaps]) + 1;
> }
>
> - ret = smpt + i;
> /* fall through */
> out:
> nor->addr_width = addr_width;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> - /* Find the matching configuration map */
> - while (SMPT_MAP_ID(smpt[i]) != map_id) {
> - if (smpt[i] & SMPT_DESC_END)
> - goto out;
> + if (map_id_is_valid)
> + pr_info("%s:%i map_id=%d\n", __func__, __LINE__, map_id);
> + else
> + pr_info("%s:%i NO map_id\n", __func__, __LINE__);
> +
> + for (nmaps = 0; nmaps< smpt_len; nmaps++) {
Why did you change this for loop?
> + if(!(smpt[nmaps] & SMPT_DESC_TYPE_MAP))
> + continue;
> +
> + if(!map_id_is_valid) {
> + if (nmaps) {
With your change in the for () block, this test is no longer valid...
Please keep the original patch and patch the if () condition as
suggested.
> + ret = NULL;
> + break;
> + }
> +
> + ret = smpt+nmaps;
> + } else if (map_id == SMPT_MAP_ID(smpt[nmaps])) {
> + ret = smpt+nmaps;
> + break;
> + }
> +
> /* increment the table index to the next map */
> - i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
> + nmaps += SMPT_MAP_REGION_COUNT(smpt[nmaps]) + 1;
> }
>
> - ret = smpt + i;
> /* fall through */
> out:
> nor->addr_width = addr_width;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 08:32:21 +
Yogesh Narayan Gaur wrote:
> HI,
>
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 1:32 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com; Mark Brown
> >
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 06:04:13 +
> > Yogesh Narayan Gaur wrote:
> >
> > > -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > > u32 *smpt)
> > > +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > > +u32 *smpt, u32 smpt_len)
> > > {
> > > const u32 *ret = NULL;
> > > - u32 i, addr;
> > > + u32 i, addr, nmaps;
> > > int err;
> > > u8 addr_width, read_opcode, read_dummy;
> > > u8 read_data_mask, data_byte, map_id;
> > > + bool map_id_is_valid = false;
> > >
> > > addr_width = nor->addr_width;
> > > read_dummy = nor->read_dummy;
> > > read_opcode = nor->read_opcode;
> > >
> > > + for (i = 0; i > > + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__,
> > > + i, smpt[i]);
> > > +
> > > map_id = 0;
> > > - i = 0;
> > > /* Determine if there are any optional Detection Command
> > > Descriptors */
> > > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > > + for (i = 0; i< smpt_len; i++) {
> > > + if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
> > > + break;
> > > +
> > > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > > nor->read_dummy = spi_nor_smpt_read_dummy(nor,
> > > smpt[i]);
> >
> > Could you also print the ->addr_width, ->read_dummy and ->read_opcode here?
> >
> It didn't showing any print messages here, did above line " if
> (!(smpt[i] & SMPT_DESC_TYPE_MAP))" also needs to be changes to "if
> ((smpt[i] & SMPT_DESC_TYPE_MAP))"?
Yes.
>
> Below is the log, with the suggested change of modifying as
> > + for (nmaps = 0; nmaps< smpt_len; nmaps++) {
> > + if((smpt[nmaps] & SMPT_DESC_TYPE_MAP))
>
> [1.625992] m25p80 spi0.0: found s25fl512s, expected m25p80
>
> [1.631681] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
>
> [1.636988] spi_nor_get_map_in_use:2880 smpt[1]=0004
>
> [1.642292] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
>
> [1.647596] spi_nor_get_map_in_use:2880 smpt[3]=0002
>
> [1.652898] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
>
> [1.658200] spi_nor_get_map_in_use:2880 smpt[5]=0004
>
> [1.663503] spi_nor_get_map_in_use:2880 smpt[6]=ff0201fe
>
> [1.668806] spi_nor_get_map_in_use:2880 smpt[7]=7ff1
>
> [1.674108] spi_nor_get_map_in_use:2880 smpt[8]=00037ff4
>
> [1.679412] spi_nor_get_map_in_use:2880 smpt[9]=03fbfff4
>
> [1.684715] spi_nor_get_map_in_use:2880 smpt[10]=ff0203fe
>
> [1.690105] spi_nor_get_map_in_use:2880 smpt[11]=03fbfff4
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 08:32:21 +
Yogesh Narayan Gaur wrote:
> HI,
>
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 1:32 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com; Mark Brown
> >
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 06:04:13 +
> > Yogesh Narayan Gaur wrote:
> >
> > > -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > > u32 *smpt)
> > > +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > > +u32 *smpt, u32 smpt_len)
> > > {
> > > const u32 *ret = NULL;
> > > - u32 i, addr;
> > > + u32 i, addr, nmaps;
> > > int err;
> > > u8 addr_width, read_opcode, read_dummy;
> > > u8 read_data_mask, data_byte, map_id;
> > > + bool map_id_is_valid = false;
> > >
> > > addr_width = nor->addr_width;
> > > read_dummy = nor->read_dummy;
> > > read_opcode = nor->read_opcode;
> > >
> > > + for (i = 0; i > > + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__,
> > > + i, smpt[i]);
> > > +
> > > map_id = 0;
> > > - i = 0;
> > > /* Determine if there are any optional Detection Command
> > > Descriptors */
> > > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > > + for (i = 0; i< smpt_len; i++) {
> > > + if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
> > > + break;
> > > +
> > > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > > nor->read_dummy = spi_nor_smpt_read_dummy(nor,
> > > smpt[i]);
> >
> > Could you also print the ->addr_width, ->read_dummy and ->read_opcode here?
> >
> It didn't showing any print messages here, did above line " if
> (!(smpt[i] & SMPT_DESC_TYPE_MAP))" also needs to be changes to "if
> ((smpt[i] & SMPT_DESC_TYPE_MAP))"?
Yes.
>
> Below is the log, with the suggested change of modifying as
> > + for (nmaps = 0; nmaps< smpt_len; nmaps++) {
> > + if((smpt[nmaps] & SMPT_DESC_TYPE_MAP))
>
> [1.625992] m25p80 spi0.0: found s25fl512s, expected m25p80
>
> [1.631681] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
>
> [1.636988] spi_nor_get_map_in_use:2880 smpt[1]=0004
>
> [1.642292] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
>
> [1.647596] spi_nor_get_map_in_use:2880 smpt[3]=0002
>
> [1.652898] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
>
> [1.658200] spi_nor_get_map_in_use:2880 smpt[5]=0004
>
> [1.663503] spi_nor_get_map_in_use:2880 smpt[6]=ff0201fe
>
> [1.668806] spi_nor_get_map_in_use:2880 smpt[7]=7ff1
>
> [1.674108] spi_nor_get_map_in_use:2880 smpt[8]=00037ff4
>
> [1.679412] spi_nor_get_map_in_use:2880 smpt[9]=03fbfff4
>
> [1.684715] spi_nor_get_map_in_use:2880 smpt[10]=ff0203fe
>
> [1.690105] spi_nor_get_map_in_use:2880 smpt[11]=03fbfff4
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
Could you also print the ->addr_width, ->read_dummy and ->read_opcode
here?
> @@ -2894,18 +2900,35 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
> }
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
Could you also print the ->addr_width, ->read_dummy and ->read_opcode
here?
> @@ -2894,18 +2900,35 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
> }
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> Hi Boris, Tudor,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Wednesday, October 17, 2018 3:23 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Wed, 17 Oct 2018 07:46:30 +
> > Yogesh Narayan Gaur wrote:
> >
> > > Hi Boris,
> > >
> > > > -Original Message-
> > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > Sent: Wednesday, October 17, 2018 1:00 PM
> > > > To: Yogesh Narayan Gaur
> > > > Cc: Cyrille Pitchen ; Tudor Ambarus
> > > > ; marek.va...@gmail.com;
> > > > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > > > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > > SFDP SPI NOR flash memories
> > > >
> > > > On Wed, 17 Oct 2018 09:10:45 +0200
> > > > Boris Brezillon wrote:
> > > >
> > > > > On Wed, 17 Oct 2018 09:07:24 +0200 Boris Brezillon
> > > > > wrote:
> > > > >
> > > > > > On Wed, 17 Oct 2018 02:07:43 + Yogesh Narayan Gaur
> > > > > > wrote:
> > > > > >
> > > > > > > >
> > > > > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > > > > For my connected flash part, jedec ID read points to
> > > > > > > s25fl512s. I have asked my board team to confirm the name of
> > > > > > > exact connected flash part. When I check the data sheet of
> > > > > > > s25fs512s, it also points to the same Jedec ID information. {
> > > > > > > "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > > > > > * 1024, 256, }
> > > > > > >
> > > > > > > But as stated earlier, if I skip reading SFDP or read using
> > > > > > > 1-1-1 protocol then read are always correct. For 1-4-4
> > > > > > > protocol read are wrong and on further debugging found that
> > > > > > > Read code of 0x6C is being send as opcode instead of 0xEC.
> > > > > > >
> > > > > > > If I revert this patch, reads are working fine.
> > > > > >
> > > > > > Can you try with the following patch?
> > > > > >
> > > > >
> > > > > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > > > > mode but 1-1-4 vs 1-4-4 modes.
> > > Yes, that's only I have stated in my first mail that instead of 1-4-4
> > > mode read
> > opcode is being sent for 1-1-4 mode.
> > > > >
> > > >
> > > > Can you try with this patch applied?
> > > >
> > > With suggested patch, read for protocol 1-4-4 working correctly.
> > >
> > > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> > >
> >
> > Okay, let's try this one to see why the SMPT parsing fails.
> >
>
> Please find the below info for the SMPT table read from the flash
> [1.631085] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
> [1.636393] spi_nor_get_map_in_use:2880 smpt[1]=0004
> [1.641696] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
> [1.646998] spi_nor_get_map_in_use:2880 smpt[3]=0002
> [1.652302] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
> [1.657606] spi_nor_get
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> Hi Boris, Tudor,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Wednesday, October 17, 2018 3:23 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Wed, 17 Oct 2018 07:46:30 +
> > Yogesh Narayan Gaur wrote:
> >
> > > Hi Boris,
> > >
> > > > -Original Message-
> > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > Sent: Wednesday, October 17, 2018 1:00 PM
> > > > To: Yogesh Narayan Gaur
> > > > Cc: Cyrille Pitchen ; Tudor Ambarus
> > > > ; marek.va...@gmail.com;
> > > > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > > > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > > SFDP SPI NOR flash memories
> > > >
> > > > On Wed, 17 Oct 2018 09:10:45 +0200
> > > > Boris Brezillon wrote:
> > > >
> > > > > On Wed, 17 Oct 2018 09:07:24 +0200 Boris Brezillon
> > > > > wrote:
> > > > >
> > > > > > On Wed, 17 Oct 2018 02:07:43 + Yogesh Narayan Gaur
> > > > > > wrote:
> > > > > >
> > > > > > > >
> > > > > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > > > > For my connected flash part, jedec ID read points to
> > > > > > > s25fl512s. I have asked my board team to confirm the name of
> > > > > > > exact connected flash part. When I check the data sheet of
> > > > > > > s25fs512s, it also points to the same Jedec ID information. {
> > > > > > > "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > > > > > * 1024, 256, }
> > > > > > >
> > > > > > > But as stated earlier, if I skip reading SFDP or read using
> > > > > > > 1-1-1 protocol then read are always correct. For 1-4-4
> > > > > > > protocol read are wrong and on further debugging found that
> > > > > > > Read code of 0x6C is being send as opcode instead of 0xEC.
> > > > > > >
> > > > > > > If I revert this patch, reads are working fine.
> > > > > >
> > > > > > Can you try with the following patch?
> > > > > >
> > > > >
> > > > > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > > > > mode but 1-1-4 vs 1-4-4 modes.
> > > Yes, that's only I have stated in my first mail that instead of 1-4-4
> > > mode read
> > opcode is being sent for 1-1-4 mode.
> > > > >
> > > >
> > > > Can you try with this patch applied?
> > > >
> > > With suggested patch, read for protocol 1-4-4 working correctly.
> > >
> > > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> > >
> >
> > Okay, let's try this one to see why the SMPT parsing fails.
> >
>
> Please find the below info for the SMPT table read from the flash
> [1.631085] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
> [1.636393] spi_nor_get_map_in_use:2880 smpt[1]=0004
> [1.641696] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
> [1.646998] spi_nor_get_map_in_use:2880 smpt[3]=0002
> [1.652302] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
> [1.657606] spi_nor_get
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Fri, 19 Oct 2018 16:29:40 +0800
Liang Yang wrote:
> On 2018/10/19 4:50, Boris Brezillon wrote:
> > On Thu, 18 Oct 2018 13:09:05 +0800
> > Jianxin Pan wrote:
> >
> >> +static int meson_nfc_buffer_init(struct mtd_info *mtd)
> >> +{
> >> + struct nand_chip *nand = mtd_to_nand(mtd);
> >> + struct meson_nfc *nfc = nand_get_controller_data(nand);
> >> + static int max_page_bytes, max_info_bytes;
> >> + int page_bytes, info_bytes;
> >> + int nsectors;
> >> +
> >> + nsectors = mtd->writesize / nand->ecc.size;
> >> + page_bytes = mtd->writesize + mtd->oobsize;
> >> + info_bytes = nsectors * PER_INFO_BYTE;
> >> +
> >> + if (nfc->data_buf && nfc->info_buf) {
> >> + if (max_page_bytes < page_bytes)
> >> + meson_nfc_free_buffer(nfc);
> >> + else
> >> + return 0;
> >> + }
> >> +
> >> + max_page_bytes = max_t(int, max_page_bytes, page_bytes);
> >> + max_info_bytes = max_t(int, max_info_bytes, info_bytes);
> >> +
> >> + nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);
> >
> > Is there a good reason for not using chip->data_buf and allocating a
> > new buffer here?
> >
> when calling read_oob or write_oob, i need a mid-buffer which is used in
> meson_nfc_prase_data_oob(). i.e. after reading a page data into
> nfc->data_buf, I will format it and transfer to chip->data_buf.
>
>
> >> + if (!nfc->data_buf)
> >> + return -ENOMEM;
> >> +
> >> + nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
> >> + if (!nfc->info_buf) {
> >> + kfree(nfc->data_buf);
> >> + return -ENOMEM;
> >> + }
> >
> > I'd recommend moving this info_buf in the priv chip struct, otherwise
> > you'll have to protect nfc->info_buf with a lock to prevent an already
> > register chip from using this pointer while you're reallocating the
> > buffer. Also, I think you have a memleak here.
> >
> ok, i will move it in the chip struct .
>
> but how memleak happens even i have called meson_nfc_free_buffer before
> and free data_buf if info_buf alloc faied.
You're right, I missed the call to meson_nfc_free_buffer() when
max_page_bytes < page_bytes. Still, this part is racy, just like the
nfc->data_buf replacement is if you have several NAND chips. I'd
recommend moving those bufs to the priv chip struct.
>
> >> +
> >> + return 0;
> >> +}
> >
> > .
> >
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Fri, 19 Oct 2018 16:29:40 +0800
Liang Yang wrote:
> On 2018/10/19 4:50, Boris Brezillon wrote:
> > On Thu, 18 Oct 2018 13:09:05 +0800
> > Jianxin Pan wrote:
> >
> >> +static int meson_nfc_buffer_init(struct mtd_info *mtd)
> >> +{
> >> + struct nand_chip *nand = mtd_to_nand(mtd);
> >> + struct meson_nfc *nfc = nand_get_controller_data(nand);
> >> + static int max_page_bytes, max_info_bytes;
> >> + int page_bytes, info_bytes;
> >> + int nsectors;
> >> +
> >> + nsectors = mtd->writesize / nand->ecc.size;
> >> + page_bytes = mtd->writesize + mtd->oobsize;
> >> + info_bytes = nsectors * PER_INFO_BYTE;
> >> +
> >> + if (nfc->data_buf && nfc->info_buf) {
> >> + if (max_page_bytes < page_bytes)
> >> + meson_nfc_free_buffer(nfc);
> >> + else
> >> + return 0;
> >> + }
> >> +
> >> + max_page_bytes = max_t(int, max_page_bytes, page_bytes);
> >> + max_info_bytes = max_t(int, max_info_bytes, info_bytes);
> >> +
> >> + nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);
> >
> > Is there a good reason for not using chip->data_buf and allocating a
> > new buffer here?
> >
> when calling read_oob or write_oob, i need a mid-buffer which is used in
> meson_nfc_prase_data_oob(). i.e. after reading a page data into
> nfc->data_buf, I will format it and transfer to chip->data_buf.
>
>
> >> + if (!nfc->data_buf)
> >> + return -ENOMEM;
> >> +
> >> + nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
> >> + if (!nfc->info_buf) {
> >> + kfree(nfc->data_buf);
> >> + return -ENOMEM;
> >> + }
> >
> > I'd recommend moving this info_buf in the priv chip struct, otherwise
> > you'll have to protect nfc->info_buf with a lock to prevent an already
> > register chip from using this pointer while you're reallocating the
> > buffer. Also, I think you have a memleak here.
> >
> ok, i will move it in the chip struct .
>
> but how memleak happens even i have called meson_nfc_free_buffer before
> and free data_buf if info_buf alloc faied.
You're right, I missed the call to meson_nfc_free_buffer() when
max_page_bytes < page_bytes. Still, this part is racy, just like the
nfc->data_buf replacement is if you have several NAND chips. I'd
recommend moving those bufs to the priv chip struct.
>
> >> +
> >> + return 0;
> >> +}
> >
> > .
> >
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Fri, 19 Oct 2018 15:29:05 +0800
Liang Yang wrote:
> > How about defining that the HW returns an array of __le64 instead and then
> > define the following macros which you can use after converting in the
> > CPU endianness
> >
> > #define ECC_GET_PROTECTED_OOB_BYTE(x, y)(((x) >> (8 * (1 + y)) &
> > GENMASK(7, 0))
> > #define ECC_COMPLETEBIT(31)
> > #define ECC_ERR_CNT(x) (((x) >> 24) & GENMASK(5, 0))
> >
> > (I'm not entirely sure the field positions are correct, but I'll let you
> > check that).
> >
> ok. i think it should be:
>
> #define ECC_GET_PROTECTED_OOB_BYTE(x, y) (((x) >> (8 * y) &
> GENMASK(7, 0))
>
> if x represents the u64 and y represents the index of the u64.
Absolutely.
>
>
>
> >> +
> >> +#define PER_INFO_BYTE (sizeof(struct meson_nfc_info_format))
> >> +
> >> +struct meson_nfc_nand_chip {
> >> + struct list_head node;
> >> + struct nand_chip nand;
> >> + bool is_scramble;
> >
> > I think I already mentioned the NAND_NEED_SCRAMBLING flag []. Please
> > drop this field and test (chip->flags & NAND_NEED_SCRAMBLING) instead.
> >
> em, i use NAND_NEED_SCRAMBLING and is_scramble is set:
> static int meson_nand_attach_chip(struct nand_chip *nand)
> {
> ..
> meson_chip->is_scramble =
> (nand->options & NAND_NEED_SCRAMBLING) ? 1 : 0;
> ..
> }
Why do you need to add a new field then? Just test
nand->options & NAND_NEED_SCRAMBLING directly or provide a helper
function that does that.
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Fri, 19 Oct 2018 15:29:05 +0800
Liang Yang wrote:
> > How about defining that the HW returns an array of __le64 instead and then
> > define the following macros which you can use after converting in the
> > CPU endianness
> >
> > #define ECC_GET_PROTECTED_OOB_BYTE(x, y)(((x) >> (8 * (1 + y)) &
> > GENMASK(7, 0))
> > #define ECC_COMPLETEBIT(31)
> > #define ECC_ERR_CNT(x) (((x) >> 24) & GENMASK(5, 0))
> >
> > (I'm not entirely sure the field positions are correct, but I'll let you
> > check that).
> >
> ok. i think it should be:
>
> #define ECC_GET_PROTECTED_OOB_BYTE(x, y) (((x) >> (8 * y) &
> GENMASK(7, 0))
>
> if x represents the u64 and y represents the index of the u64.
Absolutely.
>
>
>
> >> +
> >> +#define PER_INFO_BYTE (sizeof(struct meson_nfc_info_format))
> >> +
> >> +struct meson_nfc_nand_chip {
> >> + struct list_head node;
> >> + struct nand_chip nand;
> >> + bool is_scramble;
> >
> > I think I already mentioned the NAND_NEED_SCRAMBLING flag []. Please
> > drop this field and test (chip->flags & NAND_NEED_SCRAMBLING) instead.
> >
> em, i use NAND_NEED_SCRAMBLING and is_scramble is set:
> static int meson_nand_attach_chip(struct nand_chip *nand)
> {
> ..
> meson_chip->is_scramble =
> (nand->options & NAND_NEED_SCRAMBLING) ? 1 : 0;
> ..
> }
Why do you need to add a new field then? Just test
nand->options & NAND_NEED_SCRAMBLING directly or provide a helper
function that does that.
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
> +static int meson_nfc_buffer_init(struct mtd_info *mtd)
> +{
> + struct nand_chip *nand = mtd_to_nand(mtd);
> + struct meson_nfc *nfc = nand_get_controller_data(nand);
> + static int max_page_bytes, max_info_bytes;
> + int page_bytes, info_bytes;
> + int nsectors;
> +
> + nsectors = mtd->writesize / nand->ecc.size;
> + page_bytes = mtd->writesize + mtd->oobsize;
> + info_bytes = nsectors * PER_INFO_BYTE;
> +
> + if (nfc->data_buf && nfc->info_buf) {
> + if (max_page_bytes < page_bytes)
> + meson_nfc_free_buffer(nfc);
> + else
> + return 0;
> + }
> +
> + max_page_bytes = max_t(int, max_page_bytes, page_bytes);
> + max_info_bytes = max_t(int, max_info_bytes, info_bytes);
> +
> + nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);
Is there a good reason for not using chip->data_buf and allocating a
new buffer here?
> + if (!nfc->data_buf)
> + return -ENOMEM;
> +
> + nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
> + if (!nfc->info_buf) {
> + kfree(nfc->data_buf);
> + return -ENOMEM;
> + }
I'd recommend moving this info_buf in the priv chip struct, otherwise
you'll have to protect nfc->info_buf with a lock to prevent an already
register chip from using this pointer while you're reallocating the
buffer. Also, I think you have a memleak here.
> +
> + return 0;
> +}
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
> +static int meson_nfc_buffer_init(struct mtd_info *mtd)
> +{
> + struct nand_chip *nand = mtd_to_nand(mtd);
> + struct meson_nfc *nfc = nand_get_controller_data(nand);
> + static int max_page_bytes, max_info_bytes;
> + int page_bytes, info_bytes;
> + int nsectors;
> +
> + nsectors = mtd->writesize / nand->ecc.size;
> + page_bytes = mtd->writesize + mtd->oobsize;
> + info_bytes = nsectors * PER_INFO_BYTE;
> +
> + if (nfc->data_buf && nfc->info_buf) {
> + if (max_page_bytes < page_bytes)
> + meson_nfc_free_buffer(nfc);
> + else
> + return 0;
> + }
> +
> + max_page_bytes = max_t(int, max_page_bytes, page_bytes);
> + max_info_bytes = max_t(int, max_info_bytes, info_bytes);
> +
> + nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);
Is there a good reason for not using chip->data_buf and allocating a
new buffer here?
> + if (!nfc->data_buf)
> + return -ENOMEM;
> +
> + nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
> + if (!nfc->info_buf) {
> + kfree(nfc->data_buf);
> + return -ENOMEM;
> + }
I'd recommend moving this info_buf in the priv chip struct, otherwise
you'll have to protect nfc->info_buf with a lock to prevent an already
register chip from using this pointer while you're reallocating the
buffer. Also, I think you have a memleak here.
> +
> + return 0;
> +}
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
> +static int meson_nfc_calc_set_timing(struct meson_nfc *nfc,
> + const struct nand_sdr_timings *timings)
> +{
> + struct nand_timing *timing = >timing;
> + int div, bt_min, bt_max, bus_timing;
> + int ret;
> +
> + div = DIV_ROUND_UP((timings->tRC_min / 1000), NFC_CLK_CYCLE);
> + ret = clk_set_rate(nfc->device_clk, 10 / div);
> + if (ret) {
> + dev_err(nfc->dev, "failed to set nand clock rate\n");
> + return ret;
> + }
> +
> + timing->twb = DIV_ROUND_UP(PSEC_TO_NSEC(timings->tWB_max),
> +div * NFC_CLK_CYCLE);
> + timing->tadl = DIV_ROUND_UP(PSEC_TO_NSEC(timings->tADL_min),
> + div * NFC_CLK_CYCLE);
> + timing->twhr = DIV_ROUND_UP(PSEC_TO_NSEC(timings->tWHR_min),
> + div * NFC_CLK_CYCLE);
> +
> + bt_min = (timings->tREA_max + NFC_DEFAULT_DELAY) / div;
> + bt_max = (NFC_DEFAULT_DELAY + timings->tRHOH_min
> + + timings->tRC_min / 2) / div;
> +
> + bt_min = DIV_ROUND_UP(bt_min, 1000);
> + bt_max = DIV_ROUND_UP(bt_max, 1000);
> +
> + if (bt_max < bt_min)
> + return -EINVAL;
> +
> + bus_timing = (bt_min + bt_max) / 2 + 1;
> +
> + writel((1 << 21), nfc->reg_base + NFC_REG_CFG);
> + writel((NFC_CLK_CYCLE - 1) | (bus_timing << 5),
> +nfc->reg_base + NFC_REG_CFG);
> +
> + writel((1 << 31), nfc->reg_base + NFC_REG_CMD);
> +
> + return 0;
> +}
> +
> +static int
> +meson_nfc_setup_data_interface(struct nand_chip *nand, int csline,
> +const struct nand_data_interface *conf)
> +{
> + struct meson_nfc *nfc = nand_get_controller_data(nand);
> + const struct nand_sdr_timings *timings;
> +
> + timings = nand_get_sdr_timings(conf);
> + if (IS_ERR(timings))
> + return -ENOTSUPP;
> +
> + if (csline == NAND_DATA_IFACE_CHECK_ONLY)
> + return 0;
Hm, before saying you supporting the requested timing, you should make
sure they are actually supported. I'd recommend splitting this in 2
steps:
1/ calc timings
2/ store the timings in the chip priv struct so that they can be
applied next time ->select_chip() is called.
> +
> + meson_nfc_calc_set_timing(nfc, timings);
You should not set the timing from ->setup_data_interface(), just
calculate them, make sure they are supported and store the state in the
private chip struct. Applying those timings should be done in
->select_chip(), so that you can support 2 chips with different timings.
> + return 0;
> +}
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
> +static int meson_nfc_calc_set_timing(struct meson_nfc *nfc,
> + const struct nand_sdr_timings *timings)
> +{
> + struct nand_timing *timing = >timing;
> + int div, bt_min, bt_max, bus_timing;
> + int ret;
> +
> + div = DIV_ROUND_UP((timings->tRC_min / 1000), NFC_CLK_CYCLE);
> + ret = clk_set_rate(nfc->device_clk, 10 / div);
> + if (ret) {
> + dev_err(nfc->dev, "failed to set nand clock rate\n");
> + return ret;
> + }
> +
> + timing->twb = DIV_ROUND_UP(PSEC_TO_NSEC(timings->tWB_max),
> +div * NFC_CLK_CYCLE);
> + timing->tadl = DIV_ROUND_UP(PSEC_TO_NSEC(timings->tADL_min),
> + div * NFC_CLK_CYCLE);
> + timing->twhr = DIV_ROUND_UP(PSEC_TO_NSEC(timings->tWHR_min),
> + div * NFC_CLK_CYCLE);
> +
> + bt_min = (timings->tREA_max + NFC_DEFAULT_DELAY) / div;
> + bt_max = (NFC_DEFAULT_DELAY + timings->tRHOH_min
> + + timings->tRC_min / 2) / div;
> +
> + bt_min = DIV_ROUND_UP(bt_min, 1000);
> + bt_max = DIV_ROUND_UP(bt_max, 1000);
> +
> + if (bt_max < bt_min)
> + return -EINVAL;
> +
> + bus_timing = (bt_min + bt_max) / 2 + 1;
> +
> + writel((1 << 21), nfc->reg_base + NFC_REG_CFG);
> + writel((NFC_CLK_CYCLE - 1) | (bus_timing << 5),
> +nfc->reg_base + NFC_REG_CFG);
> +
> + writel((1 << 31), nfc->reg_base + NFC_REG_CMD);
> +
> + return 0;
> +}
> +
> +static int
> +meson_nfc_setup_data_interface(struct nand_chip *nand, int csline,
> +const struct nand_data_interface *conf)
> +{
> + struct meson_nfc *nfc = nand_get_controller_data(nand);
> + const struct nand_sdr_timings *timings;
> +
> + timings = nand_get_sdr_timings(conf);
> + if (IS_ERR(timings))
> + return -ENOTSUPP;
> +
> + if (csline == NAND_DATA_IFACE_CHECK_ONLY)
> + return 0;
Hm, before saying you supporting the requested timing, you should make
sure they are actually supported. I'd recommend splitting this in 2
steps:
1/ calc timings
2/ store the timings in the chip priv struct so that they can be
applied next time ->select_chip() is called.
> +
> + meson_nfc_calc_set_timing(nfc, timings);
You should not set the timing from ->setup_data_interface(), just
calculate them, make sure they are supported and store the state in the
private chip struct. Applying those timings should be done in
->select_chip(), so that you can support 2 chips with different timings.
> + return 0;
> +}
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
> +static int meson_nand_bch_mode(struct nand_chip *nand)
> +{
> + struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
> + struct meson_nand_ecc meson_ecc[] = {
> + MESON_ECC_DATA(NFC_ECC_BCH8_1K, 8),
> + MESON_ECC_DATA(NFC_ECC_BCH24_1K, 24),
> + MESON_ECC_DATA(NFC_ECC_BCH30_1K, 30),
> + MESON_ECC_DATA(NFC_ECC_BCH40_1K, 40),
> + MESON_ECC_DATA(NFC_ECC_BCH50_1K, 50),
> + MESON_ECC_DATA(NFC_ECC_BCH60_1K, 60),
> + };
> + int i, ret = 0;
> +
> + if (nand->ecc.strength > 60 || nand->ecc.strength < 8)
> + return -EINVAL;
> +
> + for (i = 0; i < sizeof(meson_ecc); i++) {
> + if (meson_ecc[i].strength == nand->ecc.strength) {
> + meson_chip->bch_mode = meson_ecc[i].bch;
> + break;
return 0;
> + }
> + }
> +
> + return ret;
return -EINVAL;
> +}
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
> +static int meson_nand_bch_mode(struct nand_chip *nand)
> +{
> + struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
> + struct meson_nand_ecc meson_ecc[] = {
> + MESON_ECC_DATA(NFC_ECC_BCH8_1K, 8),
> + MESON_ECC_DATA(NFC_ECC_BCH24_1K, 24),
> + MESON_ECC_DATA(NFC_ECC_BCH30_1K, 30),
> + MESON_ECC_DATA(NFC_ECC_BCH40_1K, 40),
> + MESON_ECC_DATA(NFC_ECC_BCH50_1K, 50),
> + MESON_ECC_DATA(NFC_ECC_BCH60_1K, 60),
> + };
> + int i, ret = 0;
> +
> + if (nand->ecc.strength > 60 || nand->ecc.strength < 8)
> + return -EINVAL;
> +
> + for (i = 0; i < sizeof(meson_ecc); i++) {
> + if (meson_ecc[i].strength == nand->ecc.strength) {
> + meson_chip->bch_mode = meson_ecc[i].bch;
> + break;
return 0;
> + }
> + }
> +
> + return ret;
return -EINVAL;
> +}
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800 Jianxin Pan wrote: > From: Liang Yang > > Add initial support for the Amlogic NAND flash controller which found > in the Meson-GXBB/GXL/AXG SoCs. > > Signed-off-by: Liang Yang > Signed-off-by: Yixun Lan > Signed-off-by: Jianxin Pan > --- > drivers/mtd/nand/raw/Kconfig | 10 + > drivers/mtd/nand/raw/Makefile |1 + > drivers/mtd/nand/raw/meson_nand.c | 1370 > + > 3 files changed, 1381 insertions(+) > create mode 100644 drivers/mtd/nand/raw/meson_nand.c > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig > index c7efc31..223b041 100644 > --- a/drivers/mtd/nand/raw/Kconfig > +++ b/drivers/mtd/nand/raw/Kconfig > @@ -541,4 +541,14 @@ config MTD_NAND_TEGRA > is supported. Extra OOB bytes when using HW ECC are currently > not supported. > > +config MTD_NAND_MESON > + tristate "Support for NAND controller on Amlogic's Meson SoCs" > + depends on ARCH_MESON || COMPILE_TEST > + depends on COMMON_CLK_AMLOGIC > + select COMMON_CLK_REGMAP_MESON > + select MFD_SYSCON > + help > + Enables support for NAND controller on Amlogic's Meson SoCs. > + This controller is found on Meson GXBB, GXL, AXG SoCs. > + > endif # MTD_NAND > diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile > index 57159b3..a2cc2fe 100644 > --- a/drivers/mtd/nand/raw/Makefile > +++ b/drivers/mtd/nand/raw/Makefile > @@ -56,6 +56,7 @@ obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ > obj-$(CONFIG_MTD_NAND_QCOM) += qcom_nandc.o > obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o > obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o > +obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o > > nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o > nand-objs += nand_onfi.o > diff --git a/drivers/mtd/nand/raw/meson_nand.c > b/drivers/mtd/nand/raw/meson_nand.c > new file mode 100644 > index 000..bcaac53 > --- /dev/null > +++ b/drivers/mtd/nand/raw/meson_nand.c > @@ -0,0 +1,1370 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > +/* > + * Amlogic Meson Nand Flash Controller Driver > + * > + * Copyright (c) 2018 Amlogic, inc. > + * Author: Liang Yang > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define NFC_REG_CMD 0x00 > +#define NFC_CMD_DRD (0x8 << 14) > +#define NFC_CMD_IDLE (0xc << 14) > +#define NFC_CMD_DWR (0x4 << 14) > +#define NFC_CMD_CLE (0x5 << 14) > +#define NFC_CMD_ALE (0x6 << 14) > +#define NFC_CMD_ADL ((0 << 16) | (3 << 20)) > +#define NFC_CMD_ADH ((1 << 16) | (3 << 20)) > +#define NFC_CMD_AIL ((2 << 16) | (3 << 20)) > +#define NFC_CMD_AIH ((3 << 16) | (3 << 20)) > +#define NFC_CMD_SEED ((8 << 16) | (3 << 20)) > +#define NFC_CMD_M2N ((0 << 17) | (2 << 20)) > +#define NFC_CMD_N2M ((1 << 17) | (2 << 20)) > +#define NFC_CMD_RB BIT(20) > +#define NFC_CMD_IO6 ((0xb << 10) | (1 << 18)) > + > +#define NFC_REG_CFG 0x04 > +#define NFC_REG_DADR 0x08 > +#define NFC_REG_IADR 0x0c > +#define NFC_REG_BUF 0x10 > +#define NFC_REG_INFO 0x14 > +#define NFC_REG_DC 0x18 > +#define NFC_REG_ADR 0x1c > +#define NFC_REG_DL 0x20 > +#define NFC_REG_DH 0x24 > +#define NFC_REG_CADR 0x28 > +#define NFC_REG_SADR 0x2c > +#define NFC_REG_PINS 0x30 > +#define NFC_REG_VER 0x38 > + > +#define NFC_RB_IRQ_ENBIT(21) > +#define NFC_INT_MASK (3 << 20) > + > +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages)\ > + ( \ > + (cmd_dir) | \ > + ((ran) << 19) | \ > + ((bch) << 14) | \ > + ((short_mode) << 13)| \ > + (((page_size) & 0x7f) << 6) | \ > + ((pages) & 0x3f)\ > + ) > + > +#define GENCMDDADDRL(adl, addr) ((adl) | ((addr) & 0x)) > +#define GENCMDDADDRH(adh, addr) ((adh) | (((addr) >> 16) & > 0x)) > +#define GENCMDIADDRL(ail, addr) ((ail) | ((addr) & 0x)) > +#define GENCMDIADDRH(aih, addr) ((aih) | (((addr) >> 16) & > 0x)) > + > +#define RB_STA(x)(1 << (26 + (x))) > +#define DMA_DIR(dir) ((dir) ? NFC_CMD_N2M : NFC_CMD_M2N) > + > +#define ECC_CHECK_RETURN_FF (-1) > + > +#define NAND_CE0 (0xe << 10) > +#define NAND_CE1 (0xd << 10) >
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800 Jianxin Pan wrote: > From: Liang Yang > > Add initial support for the Amlogic NAND flash controller which found > in the Meson-GXBB/GXL/AXG SoCs. > > Signed-off-by: Liang Yang > Signed-off-by: Yixun Lan > Signed-off-by: Jianxin Pan > --- > drivers/mtd/nand/raw/Kconfig | 10 + > drivers/mtd/nand/raw/Makefile |1 + > drivers/mtd/nand/raw/meson_nand.c | 1370 > + > 3 files changed, 1381 insertions(+) > create mode 100644 drivers/mtd/nand/raw/meson_nand.c > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig > index c7efc31..223b041 100644 > --- a/drivers/mtd/nand/raw/Kconfig > +++ b/drivers/mtd/nand/raw/Kconfig > @@ -541,4 +541,14 @@ config MTD_NAND_TEGRA > is supported. Extra OOB bytes when using HW ECC are currently > not supported. > > +config MTD_NAND_MESON > + tristate "Support for NAND controller on Amlogic's Meson SoCs" > + depends on ARCH_MESON || COMPILE_TEST > + depends on COMMON_CLK_AMLOGIC > + select COMMON_CLK_REGMAP_MESON > + select MFD_SYSCON > + help > + Enables support for NAND controller on Amlogic's Meson SoCs. > + This controller is found on Meson GXBB, GXL, AXG SoCs. > + > endif # MTD_NAND > diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile > index 57159b3..a2cc2fe 100644 > --- a/drivers/mtd/nand/raw/Makefile > +++ b/drivers/mtd/nand/raw/Makefile > @@ -56,6 +56,7 @@ obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ > obj-$(CONFIG_MTD_NAND_QCOM) += qcom_nandc.o > obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o > obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o > +obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o > > nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o > nand-objs += nand_onfi.o > diff --git a/drivers/mtd/nand/raw/meson_nand.c > b/drivers/mtd/nand/raw/meson_nand.c > new file mode 100644 > index 000..bcaac53 > --- /dev/null > +++ b/drivers/mtd/nand/raw/meson_nand.c > @@ -0,0 +1,1370 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > +/* > + * Amlogic Meson Nand Flash Controller Driver > + * > + * Copyright (c) 2018 Amlogic, inc. > + * Author: Liang Yang > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define NFC_REG_CMD 0x00 > +#define NFC_CMD_DRD (0x8 << 14) > +#define NFC_CMD_IDLE (0xc << 14) > +#define NFC_CMD_DWR (0x4 << 14) > +#define NFC_CMD_CLE (0x5 << 14) > +#define NFC_CMD_ALE (0x6 << 14) > +#define NFC_CMD_ADL ((0 << 16) | (3 << 20)) > +#define NFC_CMD_ADH ((1 << 16) | (3 << 20)) > +#define NFC_CMD_AIL ((2 << 16) | (3 << 20)) > +#define NFC_CMD_AIH ((3 << 16) | (3 << 20)) > +#define NFC_CMD_SEED ((8 << 16) | (3 << 20)) > +#define NFC_CMD_M2N ((0 << 17) | (2 << 20)) > +#define NFC_CMD_N2M ((1 << 17) | (2 << 20)) > +#define NFC_CMD_RB BIT(20) > +#define NFC_CMD_IO6 ((0xb << 10) | (1 << 18)) > + > +#define NFC_REG_CFG 0x04 > +#define NFC_REG_DADR 0x08 > +#define NFC_REG_IADR 0x0c > +#define NFC_REG_BUF 0x10 > +#define NFC_REG_INFO 0x14 > +#define NFC_REG_DC 0x18 > +#define NFC_REG_ADR 0x1c > +#define NFC_REG_DL 0x20 > +#define NFC_REG_DH 0x24 > +#define NFC_REG_CADR 0x28 > +#define NFC_REG_SADR 0x2c > +#define NFC_REG_PINS 0x30 > +#define NFC_REG_VER 0x38 > + > +#define NFC_RB_IRQ_ENBIT(21) > +#define NFC_INT_MASK (3 << 20) > + > +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages)\ > + ( \ > + (cmd_dir) | \ > + ((ran) << 19) | \ > + ((bch) << 14) | \ > + ((short_mode) << 13)| \ > + (((page_size) & 0x7f) << 6) | \ > + ((pages) & 0x3f)\ > + ) > + > +#define GENCMDDADDRL(adl, addr) ((adl) | ((addr) & 0x)) > +#define GENCMDDADDRH(adh, addr) ((adh) | (((addr) >> 16) & > 0x)) > +#define GENCMDIADDRL(ail, addr) ((ail) | ((addr) & 0x)) > +#define GENCMDIADDRH(aih, addr) ((aih) | (((addr) >> 16) & > 0x)) > + > +#define RB_STA(x)(1 << (26 + (x))) > +#define DMA_DIR(dir) ((dir) ? NFC_CMD_N2M : NFC_CMD_M2N) > + > +#define ECC_CHECK_RETURN_FF (-1) > + > +#define NAND_CE0 (0xe << 10) > +#define NAND_CE1 (0xd << 10) >
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
> +static int meson_nfc_exec_op(struct nand_chip *chip,
> + const struct nand_operation *op, bool check_only)
> +{
> + struct mtd_info *mtd = nand_to_mtd(chip);
> + struct meson_nfc *nfc = nand_get_controller_data(chip);
> + const struct nand_op_instr *instr = NULL;
> + int ret = 0, cmd;
> + unsigned int op_id;
> + int i;
> +
> + for (op_id = 0; op_id < op->ninstrs; op_id++) {
> + instr = >instrs[op_id];
> + switch (instr->type) {
> + case NAND_OP_CMD_INSTR:
> + if (instr->ctx.cmd.opcode == NAND_CMD_STATUS)
> + meson_nfc_cmd_idle(nfc, nfc->timing.twb);
Hm, I don't want drivers to base their decisions on the opcode value.
There's a ->delay_ns field in the instruction object, can't you use
that one instead? Also, I don't understand why this is only needed for
the STATUS command. It should normally be applied to all instructions.
> + cmd = nfc->param.chip_select | NFC_CMD_CLE;
> + cmd |= instr->ctx.cmd.opcode & 0xff;
> + writel(cmd, nfc->reg_base + NFC_REG_CMD);
> + if (instr->ctx.cmd.opcode == NAND_CMD_STATUS)
> + meson_nfc_cmd_idle(nfc, nfc->timing.twhr);
> + break;
> +
> + case NAND_OP_ADDR_INSTR:
> + for (i = 0; i < instr->ctx.addr.naddrs; i++) {
> + cmd = nfc->param.chip_select | NFC_CMD_ALE;
> + cmd |= instr->ctx.addr.addrs[i] & 0xff;
> + writel(cmd, nfc->reg_base + NFC_REG_CMD);
> + }
> + break;
> +
> + case NAND_OP_DATA_IN_INSTR:
> + meson_nfc_read_buf(mtd, instr->ctx.data.buf.in,
> +instr->ctx.data.len);
> + break;
> +
> + case NAND_OP_DATA_OUT_INSTR:
> + meson_nfc_write_buf(mtd, instr->ctx.data.buf.out,
> + instr->ctx.data.len);
> + break;
> +
> + case NAND_OP_WAITRDY_INSTR:
> + meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms);
> + break;
> + }
> + }
> + return ret;
> +}
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
> +static int meson_nfc_exec_op(struct nand_chip *chip,
> + const struct nand_operation *op, bool check_only)
> +{
> + struct mtd_info *mtd = nand_to_mtd(chip);
> + struct meson_nfc *nfc = nand_get_controller_data(chip);
> + const struct nand_op_instr *instr = NULL;
> + int ret = 0, cmd;
> + unsigned int op_id;
> + int i;
> +
> + for (op_id = 0; op_id < op->ninstrs; op_id++) {
> + instr = >instrs[op_id];
> + switch (instr->type) {
> + case NAND_OP_CMD_INSTR:
> + if (instr->ctx.cmd.opcode == NAND_CMD_STATUS)
> + meson_nfc_cmd_idle(nfc, nfc->timing.twb);
Hm, I don't want drivers to base their decisions on the opcode value.
There's a ->delay_ns field in the instruction object, can't you use
that one instead? Also, I don't understand why this is only needed for
the STATUS command. It should normally be applied to all instructions.
> + cmd = nfc->param.chip_select | NFC_CMD_CLE;
> + cmd |= instr->ctx.cmd.opcode & 0xff;
> + writel(cmd, nfc->reg_base + NFC_REG_CMD);
> + if (instr->ctx.cmd.opcode == NAND_CMD_STATUS)
> + meson_nfc_cmd_idle(nfc, nfc->timing.twhr);
> + break;
> +
> + case NAND_OP_ADDR_INSTR:
> + for (i = 0; i < instr->ctx.addr.naddrs; i++) {
> + cmd = nfc->param.chip_select | NFC_CMD_ALE;
> + cmd |= instr->ctx.addr.addrs[i] & 0xff;
> + writel(cmd, nfc->reg_base + NFC_REG_CMD);
> + }
> + break;
> +
> + case NAND_OP_DATA_IN_INSTR:
> + meson_nfc_read_buf(mtd, instr->ctx.data.buf.in,
> +instr->ctx.data.len);
> + break;
> +
> + case NAND_OP_DATA_OUT_INSTR:
> + meson_nfc_write_buf(mtd, instr->ctx.data.buf.out,
> + instr->ctx.data.len);
> + break;
> +
> + case NAND_OP_WAITRDY_INSTR:
> + meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms);
> + break;
> + }
> + }
> + return ret;
> +}
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 07:46:30 +
Yogesh Narayan Gaur wrote:
> Hi Boris,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Wednesday, October 17, 2018 1:00 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Wed, 17 Oct 2018 09:10:45 +0200
> > Boris Brezillon wrote:
> >
> > > On Wed, 17 Oct 2018 09:07:24 +0200
> > > Boris Brezillon wrote:
> > >
> > > > On Wed, 17 Oct 2018 02:07:43 +
> > > > Yogesh Narayan Gaur wrote:
> > > >
> > > > > >
> > > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > > > have asked my board team to confirm the name of exact connected
> > > > > flash part. When I check the data sheet of s25fs512s, it also
> > > > > points to the same Jedec ID information. { "s25fl512s",
> > > > > INFO(0x010220, 0x4d00, 256
> > > > > * 1024, 256, }
> > > > >
> > > > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > > > protocol then read are always correct. For 1-4-4 protocol read are
> > > > > wrong and on further debugging found that Read code of 0x6C is
> > > > > being send as opcode instead of 0xEC.
> > > > >
> > > > > If I revert this patch, reads are working fine.
> > > >
> > > > Can you try with the following patch?
> > > >
> > >
> > > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > > mode but 1-1-4 vs 1-4-4 modes.
> Yes, that's only I have stated in my first mail that instead of 1-4-4 mode
> read opcode is being sent for 1-1-4 mode.
> > >
> >
> > Can you try with this patch applied?
> >
> With suggested patch, read for protocol 1-4-4 working correctly.
>
> [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
>
> [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
>
> [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
>
> [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
>
> [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
>
Okay, let's try this one to see why the SMPT parsing fails.
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..564882c87641 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2855,23 +2855,31 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor
*nor, const u32 settings)
* spi_nor_get_map_in_use() - get the configuration map in use
* @nor: pointer to a 'struct spi_nor'
* @smpt: pointer to the sector map parameter table
+ * @smpt_len: number of entries in the smpt array
*/
-static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt)
+static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
+u32 smpt_len)
{
const u32 *ret = NULL;
- u32 i, addr;
+ u32 i, addr, nmaps;
int err;
u8 addr_width, read_opcode, read_dummy;
u8 read_data_mask, data_byte, map_id;
+ bool map_id_is_valid = false;
addr_width = nor->addr_width;
read_dummy = nor->read_dummy;
read_opcode = nor->read_opcode;
+ for (i = 0; i < smpt_len; i++)
+ pr_info("%s:%i smpt[%d] = %08x\n", __func__, __LINE__, i,
smpt[i]);
+
map_id = 0;
- i = 0;
/* Determine if there are any optional Detection Command Descriptors */
- while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
+ for (i = 0; i < smpt_len; i++) {
+ if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
+ break;
+
read_da
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 07:46:30 +
Yogesh Narayan Gaur wrote:
> Hi Boris,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Wednesday, October 17, 2018 1:00 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Wed, 17 Oct 2018 09:10:45 +0200
> > Boris Brezillon wrote:
> >
> > > On Wed, 17 Oct 2018 09:07:24 +0200
> > > Boris Brezillon wrote:
> > >
> > > > On Wed, 17 Oct 2018 02:07:43 +
> > > > Yogesh Narayan Gaur wrote:
> > > >
> > > > > >
> > > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > > > have asked my board team to confirm the name of exact connected
> > > > > flash part. When I check the data sheet of s25fs512s, it also
> > > > > points to the same Jedec ID information. { "s25fl512s",
> > > > > INFO(0x010220, 0x4d00, 256
> > > > > * 1024, 256, }
> > > > >
> > > > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > > > protocol then read are always correct. For 1-4-4 protocol read are
> > > > > wrong and on further debugging found that Read code of 0x6C is
> > > > > being send as opcode instead of 0xEC.
> > > > >
> > > > > If I revert this patch, reads are working fine.
> > > >
> > > > Can you try with the following patch?
> > > >
> > >
> > > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > > mode but 1-1-4 vs 1-4-4 modes.
> Yes, that's only I have stated in my first mail that instead of 1-4-4 mode
> read opcode is being sent for 1-1-4 mode.
> > >
> >
> > Can you try with this patch applied?
> >
> With suggested patch, read for protocol 1-4-4 working correctly.
>
> [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
>
> [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
>
> [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
>
> [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
>
> [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
>
Okay, let's try this one to see why the SMPT parsing fails.
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..564882c87641 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2855,23 +2855,31 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor
*nor, const u32 settings)
* spi_nor_get_map_in_use() - get the configuration map in use
* @nor: pointer to a 'struct spi_nor'
* @smpt: pointer to the sector map parameter table
+ * @smpt_len: number of entries in the smpt array
*/
-static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt)
+static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
+u32 smpt_len)
{
const u32 *ret = NULL;
- u32 i, addr;
+ u32 i, addr, nmaps;
int err;
u8 addr_width, read_opcode, read_dummy;
u8 read_data_mask, data_byte, map_id;
+ bool map_id_is_valid = false;
addr_width = nor->addr_width;
read_dummy = nor->read_dummy;
read_opcode = nor->read_opcode;
+ for (i = 0; i < smpt_len; i++)
+ pr_info("%s:%i smpt[%d] = %08x\n", __func__, __LINE__, i,
smpt[i]);
+
map_id = 0;
- i = 0;
/* Determine if there are any optional Detection Command Descriptors */
- while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
+ for (i = 0; i < smpt_len; i++) {
+ if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
+ break;
+
read_da
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 08:20:19 +
Yogesh Narayan Gaur wrote:
> Hi Tudor,
>
> > -Original Message-
> > From: Tudor Ambarus [mailto:tudor.amba...@microchip.com]
> > Sent: Wednesday, October 17, 2018 1:31 PM
> > To: Yogesh Narayan Gaur ; Boris Brezillon
> >
> > Cc: Cyrille Pitchen ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > Hi, Yogesh,
> >
> > On 10/17/2018 10:46 AM, Yogesh Narayan Gaur wrote:
> > > Hi Boris,
> > >
> > >> -Original Message-
> > >> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > >> Sent: Wednesday, October 17, 2018 1:00 PM
> > >> To: Yogesh Narayan Gaur
> > >> Cc: Cyrille Pitchen ; Tudor Ambarus
> > >> ; marek.va...@gmail.com;
> > >> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > >> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > >> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > >> linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > >> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > >> SFDP SPI NOR flash memories
> > >>
> > >> On Wed, 17 Oct 2018 09:10:45 +0200
> > >> Boris Brezillon wrote:
> > >>
> > >>> On Wed, 17 Oct 2018 09:07:24 +0200
> > >>> Boris Brezillon wrote:
> > >>>
> > >>>> On Wed, 17 Oct 2018 02:07:43 +
> > >>>> Yogesh Narayan Gaur wrote:
> > >>>>
> > >>>>>>
> > >>>>> Actually there is no entry of s25fs512s in current spi-nor.c file.
> > >>>>> For my connected flash part, jedec ID read points to s25fl512s. I
> > >>>>> have asked my board team to confirm the name of exact connected
> > >>>>> flash part. When I check the data sheet of s25fs512s, it also
> > >>>>> points to the same Jedec ID information. { "s25fl512s",
> > >>>>> INFO(0x010220, 0x4d00, 256
> > >>>>> * 1024, 256, }
> > >>>>>
> > >>>>> But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > >>>>> protocol then read are always correct. For 1-4-4 protocol read are
> > >>>>> wrong and on further debugging found that Read code of 0x6C is
> > >>>>> being send as opcode instead of 0xEC.
> > >>>>>
> > >>>>> If I revert this patch, reads are working fine.
> > >>>>
> > >>>> Can you try with the following patch?
> > >>>>
> > >>>
> > >>> Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > >>> mode but 1-1-4 vs 1-4-4 modes.
> > > Yes, that's only I have stated in my first mail that instead of 1-4-4
> > > mode read
> > opcode is being sent for 1-1-4 mode.
> > >>>
> > >>
> > >> Can you try with this patch applied?
> > >>
> > > With suggested patch, read for protocol 1-4-4 working correctly.
> > >
> > > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> > >
> > > Without this patch, param_headers are getting freed and restoring
> > > previous
> > erase map i.e. opcode related to 1-1-4 protocol.
> > >
> >
> > Can you add some prints in spi_nor_parse_smpt() to isolate what's failing?
> > We
> > should understand whether it's something wrong in spi_nor_parse_smpt() or
> > the
> > s25fs512s smpt table does not respect the standard.
> >
>
> It's returning failure from below point in func spi_nor_get_map_in_use()
>
> /* Find the matching configuration map */
> while (SMPT_MAP_ID(smpt[i]) != map_id) {
> if (smpt[i] & SMPT_DESC_END) {
> printk("%d %s \n", __LINE__, __func__);
> goto out;
> }
Can you dump the smpt array just before calling
spi_nor_get_map_in_use()?
> --
> Regards
> Yogesh Gaur.
>
> > Thanks,
> > ta
> >
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 08:20:19 +
Yogesh Narayan Gaur wrote:
> Hi Tudor,
>
> > -Original Message-
> > From: Tudor Ambarus [mailto:tudor.amba...@microchip.com]
> > Sent: Wednesday, October 17, 2018 1:31 PM
> > To: Yogesh Narayan Gaur ; Boris Brezillon
> >
> > Cc: Cyrille Pitchen ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > Hi, Yogesh,
> >
> > On 10/17/2018 10:46 AM, Yogesh Narayan Gaur wrote:
> > > Hi Boris,
> > >
> > >> -Original Message-
> > >> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > >> Sent: Wednesday, October 17, 2018 1:00 PM
> > >> To: Yogesh Narayan Gaur
> > >> Cc: Cyrille Pitchen ; Tudor Ambarus
> > >> ; marek.va...@gmail.com;
> > >> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > >> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > >> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > >> linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > >> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > >> SFDP SPI NOR flash memories
> > >>
> > >> On Wed, 17 Oct 2018 09:10:45 +0200
> > >> Boris Brezillon wrote:
> > >>
> > >>> On Wed, 17 Oct 2018 09:07:24 +0200
> > >>> Boris Brezillon wrote:
> > >>>
> > >>>> On Wed, 17 Oct 2018 02:07:43 +
> > >>>> Yogesh Narayan Gaur wrote:
> > >>>>
> > >>>>>>
> > >>>>> Actually there is no entry of s25fs512s in current spi-nor.c file.
> > >>>>> For my connected flash part, jedec ID read points to s25fl512s. I
> > >>>>> have asked my board team to confirm the name of exact connected
> > >>>>> flash part. When I check the data sheet of s25fs512s, it also
> > >>>>> points to the same Jedec ID information. { "s25fl512s",
> > >>>>> INFO(0x010220, 0x4d00, 256
> > >>>>> * 1024, 256, }
> > >>>>>
> > >>>>> But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > >>>>> protocol then read are always correct. For 1-4-4 protocol read are
> > >>>>> wrong and on further debugging found that Read code of 0x6C is
> > >>>>> being send as opcode instead of 0xEC.
> > >>>>>
> > >>>>> If I revert this patch, reads are working fine.
> > >>>>
> > >>>> Can you try with the following patch?
> > >>>>
> > >>>
> > >>> Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > >>> mode but 1-1-4 vs 1-4-4 modes.
> > > Yes, that's only I have stated in my first mail that instead of 1-4-4
> > > mode read
> > opcode is being sent for 1-1-4 mode.
> > >>>
> > >>
> > >> Can you try with this patch applied?
> > >>
> > > With suggested patch, read for protocol 1-4-4 working correctly.
> > >
> > > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> > >
> > > Without this patch, param_headers are getting freed and restoring
> > > previous
> > erase map i.e. opcode related to 1-1-4 protocol.
> > >
> >
> > Can you add some prints in spi_nor_parse_smpt() to isolate what's failing?
> > We
> > should understand whether it's something wrong in spi_nor_parse_smpt() or
> > the
> > s25fs512s smpt table does not respect the standard.
> >
>
> It's returning failure from below point in func spi_nor_get_map_in_use()
>
> /* Find the matching configuration map */
> while (SMPT_MAP_ID(smpt[i]) != map_id) {
> if (smpt[i] & SMPT_DESC_END) {
> printk("%d %s \n", __LINE__, __func__);
> goto out;
> }
Can you dump the smpt array just before calling
spi_nor_get_map_in_use()?
> --
> Regards
> Yogesh Gaur.
>
> > Thanks,
> > ta
> >
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:10:45 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 09:07:24 +0200
> Boris Brezillon wrote:
>
> > On Wed, 17 Oct 2018 02:07:43 +
> > Yogesh Narayan Gaur wrote:
> >
> > > >
> > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > have asked my board team to confirm the name of exact connected flash
> > > part. When I check the data sheet of s25fs512s, it also points to the
> > > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > * 1024, 256, }
> > >
> > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > protocol then read are always correct. For 1-4-4 protocol read are
> > > wrong and on further debugging found that Read code of 0x6C is being
> > > send as opcode instead of 0xEC.
> > >
> > > If I revert this patch, reads are working fine.
> >
> > Can you try with the following patch?
> >
>
> Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
> but 1-1-4 vs 1-4-4 modes.
>
Can you try with this patch applied?
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..cf33d834698c 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -3132,6 +3132,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
switch (SFDP_PARAM_HEADER_ID(param_header)) {
case SFDP_SECTOR_MAP_ID:
err = spi_nor_parse_smpt(nor, param_header);
+ if (err) {
+ dev_warn(dev,
+"failed to parse SMPT (err = %d)\n",
+err);
+ /*
+* SMPT parsing is optional, let's not drop
+* all information we extracted so far just
+* because it failed.
+*/
+ err = 0;
+ }
break;
default:
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:10:45 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 09:07:24 +0200
> Boris Brezillon wrote:
>
> > On Wed, 17 Oct 2018 02:07:43 +
> > Yogesh Narayan Gaur wrote:
> >
> > > >
> > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > have asked my board team to confirm the name of exact connected flash
> > > part. When I check the data sheet of s25fs512s, it also points to the
> > > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > * 1024, 256, }
> > >
> > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > protocol then read are always correct. For 1-4-4 protocol read are
> > > wrong and on further debugging found that Read code of 0x6C is being
> > > send as opcode instead of 0xEC.
> > >
> > > If I revert this patch, reads are working fine.
> >
> > Can you try with the following patch?
> >
>
> Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
> but 1-1-4 vs 1-4-4 modes.
>
Can you try with this patch applied?
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..cf33d834698c 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -3132,6 +3132,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
switch (SFDP_PARAM_HEADER_ID(param_header)) {
case SFDP_SECTOR_MAP_ID:
err = spi_nor_parse_smpt(nor, param_header);
+ if (err) {
+ dev_warn(dev,
+"failed to parse SMPT (err = %d)\n",
+err);
+ /*
+* SMPT parsing is optional, let's not drop
+* all information we extracted so far just
+* because it failed.
+*/
+ err = 0;
+ }
break;
default:
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:10:45 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 09:07:24 +0200
> Boris Brezillon wrote:
>
> > On Wed, 17 Oct 2018 02:07:43 +
> > Yogesh Narayan Gaur wrote:
> >
> > > >
> > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > have asked my board team to confirm the name of exact connected flash
> > > part. When I check the data sheet of s25fs512s, it also points to the
> > > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > * 1024, 256, }
> > >
> > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > protocol then read are always correct. For 1-4-4 protocol read are
> > > wrong and on further debugging found that Read code of 0x6C is being
> > > send as opcode instead of 0xEC.
> > >
> > > If I revert this patch, reads are working fine.
> >
> > Can you try with the following patch?
> >
>
> Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
> but 1-1-4 vs 1-4-4 modes.
>
Can you add traces in this loop [1] to see which features are flagged
as supported and which ones are not.
[1]https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/mtd/spi-nor/spi-nor.c#L2259
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:10:45 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 09:07:24 +0200
> Boris Brezillon wrote:
>
> > On Wed, 17 Oct 2018 02:07:43 +
> > Yogesh Narayan Gaur wrote:
> >
> > > >
> > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > have asked my board team to confirm the name of exact connected flash
> > > part. When I check the data sheet of s25fs512s, it also points to the
> > > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > * 1024, 256, }
> > >
> > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > protocol then read are always correct. For 1-4-4 protocol read are
> > > wrong and on further debugging found that Read code of 0x6C is being
> > > send as opcode instead of 0xEC.
> > >
> > > If I revert this patch, reads are working fine.
> >
> > Can you try with the following patch?
> >
>
> Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
> but 1-1-4 vs 1-4-4 modes.
>
Can you add traces in this loop [1] to see which features are flagged
as supported and which ones are not.
[1]https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/mtd/spi-nor/spi-nor.c#L2259
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:07:24 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 02:07:43 +
> Yogesh Narayan Gaur wrote:
>
> > >
> > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > For my connected flash part, jedec ID read points to s25fl512s. I
> > have asked my board team to confirm the name of exact connected flash
> > part. When I check the data sheet of s25fs512s, it also points to the
> > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > * 1024, 256, }
> >
> > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > protocol then read are always correct. For 1-4-4 protocol read are
> > wrong and on further debugging found that Read code of 0x6C is being
> > send as opcode instead of 0xEC.
> >
> > If I revert this patch, reads are working fine.
>
> Can you try with the following patch?
>
Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
but 1-1-4 vs 1-4-4 modes.
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:07:24 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 02:07:43 +
> Yogesh Narayan Gaur wrote:
>
> > >
> > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > For my connected flash part, jedec ID read points to s25fl512s. I
> > have asked my board team to confirm the name of exact connected flash
> > part. When I check the data sheet of s25fs512s, it also points to the
> > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > * 1024, 256, }
> >
> > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > protocol then read are always correct. For 1-4-4 protocol read are
> > wrong and on further debugging found that Read code of 0x6C is being
> > send as opcode instead of 0xEC.
> >
> > If I revert this patch, reads are working fine.
>
> Can you try with the following patch?
>
Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
but 1-1-4 vs 1-4-4 modes.
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 02:07:43 +
Yogesh Narayan Gaur wrote:
> >
> Actually there is no entry of s25fs512s in current spi-nor.c file.
> For my connected flash part, jedec ID read points to s25fl512s. I
> have asked my board team to confirm the name of exact connected flash
> part. When I check the data sheet of s25fs512s, it also points to the
> same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> * 1024, 256, }
>
> But as stated earlier, if I skip reading SFDP or read using 1-1-1
> protocol then read are always correct. For 1-4-4 protocol read are
> wrong and on further debugging found that Read code of 0x6C is being
> send as opcode instead of 0xEC.
>
> If I revert this patch, reads are working fine.
Can you try with the following patch?
Also, can you add a trace to check whether you're reaching this point
[1] or not.
[1]https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/mtd/spi-nor/spi-nor.c#L2227
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..49278c1491a6 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2643,6 +2643,8 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
break;
case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY:
+ case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
+ nor->flags |= SNOR_F_4B_OPCODES;
nor->addr_width = 4;
break;
@@ -3552,7 +3554,7 @@ static int spi_nor_init(struct spi_nor *nor)
if ((nor->addr_width == 4) &&
(JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
- !(nor->info->flags & SPI_NOR_4B_OPCODES)) {
+ !(nor->flags & SNOR_F_4B_OPCODES)) {
/*
* If the RESET# pin isn't hooked up properly, or the system
* otherwise doesn't perform a reset command in the boot
@@ -3586,7 +3588,7 @@ void spi_nor_restore(struct spi_nor *nor)
/* restore the addressing mode */
if ((nor->addr_width == 4) &&
(JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
- !(nor->info->flags & SPI_NOR_4B_OPCODES) &&
+ !(nor->flags & SNOR_F_4B_OPCODES) &&
(nor->flags & SNOR_F_BROKEN_RESET))
set_4byte(nor, nor->info, 0);
}
@@ -3724,6 +3726,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
if (info->flags & SPI_NOR_NO_FR)
params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
+ if (info->flags & SPI_NOR_4B_OPCODES)
+ nor->flags |= SNOR_F_4B_OPCODES;
+
/*
* Configure the SPI memory:
* - select op codes for (Fast) Read, Page Program and Sector Erase.
@@ -3742,13 +3747,16 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
} else if (mtd->size > 0x100) {
/* enable 4-byte addressing if the device exceeds 16MiB */
nor->addr_width = 4;
- if (JEDEC_MFR(info) == SNOR_MFR_SPANSION ||
- info->flags & SPI_NOR_4B_OPCODES)
- spi_nor_set_4byte_opcodes(nor, info);
+ if (JEDEC_MFR(info) == SNOR_MFR_SPANSION)
+ nor->flags |= SNOR_F_4B_OPCODES;
} else {
nor->addr_width = 3;
}
+ if (info->addr_width == 4 &&
+ nor->flags & SNOR_F_4B_OPCODES)
+ spi_nor_set_4byte_opcodes(nor, info);
+
if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
dev_err(dev, "address width is too large: %u\n",
nor->addr_width);
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 7f0c7303575e..4ffb165f4f85 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -236,6 +236,7 @@ enum spi_nor_option_flags {
SNOR_F_READY_XSR_RDY= BIT(4),
SNOR_F_USE_CLSR = BIT(5),
SNOR_F_BROKEN_RESET = BIT(6),
+ SNOR_F_4B_OPCODES = BIT(7)
};
/**
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 02:07:43 +
Yogesh Narayan Gaur wrote:
> >
> Actually there is no entry of s25fs512s in current spi-nor.c file.
> For my connected flash part, jedec ID read points to s25fl512s. I
> have asked my board team to confirm the name of exact connected flash
> part. When I check the data sheet of s25fs512s, it also points to the
> same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> * 1024, 256, }
>
> But as stated earlier, if I skip reading SFDP or read using 1-1-1
> protocol then read are always correct. For 1-4-4 protocol read are
> wrong and on further debugging found that Read code of 0x6C is being
> send as opcode instead of 0xEC.
>
> If I revert this patch, reads are working fine.
Can you try with the following patch?
Also, can you add a trace to check whether you're reaching this point
[1] or not.
[1]https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/mtd/spi-nor/spi-nor.c#L2227
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..49278c1491a6 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2643,6 +2643,8 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
break;
case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY:
+ case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
+ nor->flags |= SNOR_F_4B_OPCODES;
nor->addr_width = 4;
break;
@@ -3552,7 +3554,7 @@ static int spi_nor_init(struct spi_nor *nor)
if ((nor->addr_width == 4) &&
(JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
- !(nor->info->flags & SPI_NOR_4B_OPCODES)) {
+ !(nor->flags & SNOR_F_4B_OPCODES)) {
/*
* If the RESET# pin isn't hooked up properly, or the system
* otherwise doesn't perform a reset command in the boot
@@ -3586,7 +3588,7 @@ void spi_nor_restore(struct spi_nor *nor)
/* restore the addressing mode */
if ((nor->addr_width == 4) &&
(JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
- !(nor->info->flags & SPI_NOR_4B_OPCODES) &&
+ !(nor->flags & SNOR_F_4B_OPCODES) &&
(nor->flags & SNOR_F_BROKEN_RESET))
set_4byte(nor, nor->info, 0);
}
@@ -3724,6 +3726,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
if (info->flags & SPI_NOR_NO_FR)
params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
+ if (info->flags & SPI_NOR_4B_OPCODES)
+ nor->flags |= SNOR_F_4B_OPCODES;
+
/*
* Configure the SPI memory:
* - select op codes for (Fast) Read, Page Program and Sector Erase.
@@ -3742,13 +3747,16 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
} else if (mtd->size > 0x100) {
/* enable 4-byte addressing if the device exceeds 16MiB */
nor->addr_width = 4;
- if (JEDEC_MFR(info) == SNOR_MFR_SPANSION ||
- info->flags & SPI_NOR_4B_OPCODES)
- spi_nor_set_4byte_opcodes(nor, info);
+ if (JEDEC_MFR(info) == SNOR_MFR_SPANSION)
+ nor->flags |= SNOR_F_4B_OPCODES;
} else {
nor->addr_width = 3;
}
+ if (info->addr_width == 4 &&
+ nor->flags & SNOR_F_4B_OPCODES)
+ spi_nor_set_4byte_opcodes(nor, info);
+
if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
dev_err(dev, "address width is too large: %u\n",
nor->addr_width);
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 7f0c7303575e..4ffb165f4f85 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -236,6 +236,7 @@ enum spi_nor_option_flags {
SNOR_F_READY_XSR_RDY= BIT(4),
SNOR_F_USE_CLSR = BIT(5),
SNOR_F_BROKEN_RESET = BIT(6),
+ SNOR_F_4B_OPCODES = BIT(7)
};
/**
Re: [PATCH v6 1/2] spi: Add MXIC controller driver
On Wed, 17 Oct 2018 10:08:11 +0800 masonccy...@mxic.com.tw wrote: > From: Mason Yang > > Add a driver for Macronix SPI controller IP. > > Signed-off-by: Mason Yang Reviewed-by: Boris Brezillon > --- > drivers/spi/Kconfig| 6 + > drivers/spi/Makefile | 1 + > drivers/spi/spi-mxic.c | 619 > + > 3 files changed, 626 insertions(+) > create mode 100644 drivers/spi/spi-mxic.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index ad5d68e..7e900b5 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -633,6 +633,12 @@ config SPI_SUN6I > help > This enables using the SPI controller on the Allwinner A31 SoCs. > > +config SPI_MXIC > +tristate "Macronix MX25F0A SPI controller" > +depends on SPI_MASTER > +help > + This selects the Macronix MX25F0A SPI controller driver. > + > config SPI_MXS > tristate "Freescale MXS SPI controller" > depends on ARCH_MXS > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index cb1f437..d7a1ceb 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -57,6 +57,7 @@ obj-$(CONFIG_SPI_MPC512x_PSC) += > spi-mpc512x-psc.o > obj-$(CONFIG_SPI_MPC52xx_PSC)+= spi-mpc52xx-psc.o > obj-$(CONFIG_SPI_MPC52xx)+= spi-mpc52xx.o > obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o > +obj-$(CONFIG_SPI_MXIC) += spi-mxic.o > obj-$(CONFIG_SPI_MXS)+= spi-mxs.o > obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o > obj-$(CONFIG_SPI_OC_TINY)+= spi-oc-tiny.o > diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c > new file mode 100644 > index 000..e41ae6e > --- /dev/null > +++ b/drivers/spi/spi-mxic.c > @@ -0,0 +1,619 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (C) 2018 Macronix International Co., Ltd. > +// > +// Authors: > +// Mason Yang > +// zhengxunli > +// Boris Brezillon > +// > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define HC_CFG 0x0 > +#define HC_CFG_IF_CFG(x) ((x) << 27) > +#define HC_CFG_DUAL_SLAVEBIT(31) > +#define HC_CFG_INDIVIDUALBIT(30) > +#define HC_CFG_NIO(x)(((x) / 4) << 27) > +#define HC_CFG_TYPE(s, t)((t) << (23 + ((s) * 2))) > +#define HC_CFG_TYPE_SPI_NOR 0 > +#define HC_CFG_TYPE_SPI_NAND 1 > +#define HC_CFG_TYPE_SPI_RAM 2 > +#define HC_CFG_TYPE_RAW_NAND 3 > +#define HC_CFG_SLV_ACT(x)((x) << 21) > +#define HC_CFG_CLK_PH_EN BIT(20) > +#define HC_CFG_CLK_POL_INV BIT(19) > +#define HC_CFG_BIG_ENDIANBIT(18) > +#define HC_CFG_DATA_PASS BIT(17) > +#define HC_CFG_IDLE_SIO_LVL(x) ((x) << 16) > +#define HC_CFG_MAN_START_EN BIT(3) > +#define HC_CFG_MAN_START BIT(2) > +#define HC_CFG_MAN_CS_EN BIT(1) > +#define HC_CFG_MAN_CS_ASSERT BIT(0) > + > +#define INT_STS 0x4 > +#define INT_STS_EN 0x8 > +#define INT_SIG_EN 0xc > +#define INT_STS_ALL GENMASK(31, 0) > +#define INT_RDY_PIN BIT(26) > +#define INT_RDY_SR BIT(25) > +#define INT_LNR_SUSP BIT(24) > +#define INT_ECC_ERR BIT(17) > +#define INT_CRC_ERR BIT(16) > +#define INT_LWR_DIS BIT(12) > +#define INT_LRD_DIS BIT(11) > +#define INT_SDMA_INT BIT(10) > +#define INT_DMA_FINISH BIT(9) > +#define INT_RX_NOT_FULL BIT(3) > +#define INT_RX_NOT_EMPTY BIT(2) > +#define INT_TX_NOT_FULL BIT(1) > +#define INT_TX_EMPTY BIT(0) > + > +#define HC_EN0x10 > +#define HC_EN_BITBIT(0) > + > +#define TXD(x) (0x14 + ((x) * 4)) > +#define RXD 0x24 > + > +#define SS_CTRL(s) (0x30 + ((s) * 4)) > +#define LRD_CFG 0x44 > +#define LWR_CFG 0x80 > +#define RWW_CFG 0x70 > +#define OP_READ BIT(23) > +#define OP_DUMMY_CYC(x) ((x) << 17) > +#define OP_ADDR_BYTES(x) ((x) << 14) > +#define OP_CMD_BYTES(x) (((x) - 1) << 13) > +#define OP_OCTA_CRC_EN BIT(12) > +#define OP_DQS_ENBIT(11) > +#define OP_ENHC_EN BIT(10) > +#define OP_PREAMBLE_EN BIT(9) > +#define OP_DATA_DDR BIT(8) > +#define OP_DATA_BUSW(x) ((x) << 6) &
Re: [PATCH v6 1/2] spi: Add MXIC controller driver
On Wed, 17 Oct 2018 10:08:11 +0800 masonccy...@mxic.com.tw wrote: > From: Mason Yang > > Add a driver for Macronix SPI controller IP. > > Signed-off-by: Mason Yang Reviewed-by: Boris Brezillon > --- > drivers/spi/Kconfig| 6 + > drivers/spi/Makefile | 1 + > drivers/spi/spi-mxic.c | 619 > + > 3 files changed, 626 insertions(+) > create mode 100644 drivers/spi/spi-mxic.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index ad5d68e..7e900b5 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -633,6 +633,12 @@ config SPI_SUN6I > help > This enables using the SPI controller on the Allwinner A31 SoCs. > > +config SPI_MXIC > +tristate "Macronix MX25F0A SPI controller" > +depends on SPI_MASTER > +help > + This selects the Macronix MX25F0A SPI controller driver. > + > config SPI_MXS > tristate "Freescale MXS SPI controller" > depends on ARCH_MXS > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index cb1f437..d7a1ceb 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -57,6 +57,7 @@ obj-$(CONFIG_SPI_MPC512x_PSC) += > spi-mpc512x-psc.o > obj-$(CONFIG_SPI_MPC52xx_PSC)+= spi-mpc52xx-psc.o > obj-$(CONFIG_SPI_MPC52xx)+= spi-mpc52xx.o > obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o > +obj-$(CONFIG_SPI_MXIC) += spi-mxic.o > obj-$(CONFIG_SPI_MXS)+= spi-mxs.o > obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o > obj-$(CONFIG_SPI_OC_TINY)+= spi-oc-tiny.o > diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c > new file mode 100644 > index 000..e41ae6e > --- /dev/null > +++ b/drivers/spi/spi-mxic.c > @@ -0,0 +1,619 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (C) 2018 Macronix International Co., Ltd. > +// > +// Authors: > +// Mason Yang > +// zhengxunli > +// Boris Brezillon > +// > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define HC_CFG 0x0 > +#define HC_CFG_IF_CFG(x) ((x) << 27) > +#define HC_CFG_DUAL_SLAVEBIT(31) > +#define HC_CFG_INDIVIDUALBIT(30) > +#define HC_CFG_NIO(x)(((x) / 4) << 27) > +#define HC_CFG_TYPE(s, t)((t) << (23 + ((s) * 2))) > +#define HC_CFG_TYPE_SPI_NOR 0 > +#define HC_CFG_TYPE_SPI_NAND 1 > +#define HC_CFG_TYPE_SPI_RAM 2 > +#define HC_CFG_TYPE_RAW_NAND 3 > +#define HC_CFG_SLV_ACT(x)((x) << 21) > +#define HC_CFG_CLK_PH_EN BIT(20) > +#define HC_CFG_CLK_POL_INV BIT(19) > +#define HC_CFG_BIG_ENDIANBIT(18) > +#define HC_CFG_DATA_PASS BIT(17) > +#define HC_CFG_IDLE_SIO_LVL(x) ((x) << 16) > +#define HC_CFG_MAN_START_EN BIT(3) > +#define HC_CFG_MAN_START BIT(2) > +#define HC_CFG_MAN_CS_EN BIT(1) > +#define HC_CFG_MAN_CS_ASSERT BIT(0) > + > +#define INT_STS 0x4 > +#define INT_STS_EN 0x8 > +#define INT_SIG_EN 0xc > +#define INT_STS_ALL GENMASK(31, 0) > +#define INT_RDY_PIN BIT(26) > +#define INT_RDY_SR BIT(25) > +#define INT_LNR_SUSP BIT(24) > +#define INT_ECC_ERR BIT(17) > +#define INT_CRC_ERR BIT(16) > +#define INT_LWR_DIS BIT(12) > +#define INT_LRD_DIS BIT(11) > +#define INT_SDMA_INT BIT(10) > +#define INT_DMA_FINISH BIT(9) > +#define INT_RX_NOT_FULL BIT(3) > +#define INT_RX_NOT_EMPTY BIT(2) > +#define INT_TX_NOT_FULL BIT(1) > +#define INT_TX_EMPTY BIT(0) > + > +#define HC_EN0x10 > +#define HC_EN_BITBIT(0) > + > +#define TXD(x) (0x14 + ((x) * 4)) > +#define RXD 0x24 > + > +#define SS_CTRL(s) (0x30 + ((s) * 4)) > +#define LRD_CFG 0x44 > +#define LWR_CFG 0x80 > +#define RWW_CFG 0x70 > +#define OP_READ BIT(23) > +#define OP_DUMMY_CYC(x) ((x) << 17) > +#define OP_ADDR_BYTES(x) ((x) << 14) > +#define OP_CMD_BYTES(x) (((x) - 1) << 13) > +#define OP_OCTA_CRC_EN BIT(12) > +#define OP_DQS_ENBIT(11) > +#define OP_ENHC_EN BIT(10) > +#define OP_PREAMBLE_EN BIT(9) > +#define OP_DATA_DDR BIT(8) > +#define OP_DATA_BUSW(x) ((x) << 6) &
Re: [PATCH v6 2/2] dt-binding: spi: Document Macronix controller bindings
+Rob and the DT ML
Hi Mason,
Remember to Cc the DT mailing list and maintainers when you add/update a
binding.
On Wed, 17 Oct 2018 10:08:12 +0800
masonccy...@mxic.com.tw wrote:
> From: Mason Yang
>
> Document the bindings used by the Macronix controller.
>
> Signed-off-by: Mason Yang
> ---
> Documentation/devicetree/bindings/spi/spi-mxic.txt | 34
> ++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-mxic.txt
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-mxic.txt
> b/Documentation/devicetree/bindings/spi/spi-mxic.txt
> new file mode 100644
> index 000..529f2da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/spi-mxic.txt
> @@ -0,0 +1,34 @@
> +Macronix SPI controller Device Tree Bindings
> +
> +
> +Required properties:
> +- compatible: should be "mxicy,mx25f0a-spi"
> +- #address-cells: should be 1
> +- #size-cells: should be 0
> +- reg: should contain 2 entries, one for the registers and one for the direct
> + mapping area
> +- reg-names: should contain "regs" and "dirmap"
> +- interrupts: interrupt line connected to the SPI controller
> +- clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk"
The _clk suffix is unnecessary in my opinion. How about:
- clock-names: should contain "ps", "send" and "send_dly"
Other than that,
Reviewed-by: Boris Brezillon
> +- clocks: should contain 3 entries for the "ps_clk", "send_clk" and
> + "send_dly_clk" clocks
> +
> +Example:
> +
> + spi@43c3 {
> + compatible = "mxicy,mx25f0a-spi";
> + reg = <0x43c3 0x1>, <0xa000 0x2000>;
> + reg-names = "regs", "dirmap";
> + clocks = < 0>, < 1>, < 18>;
> + clock-names = "send_clk", "send_dly_clk", "ps_clk";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + };
> + };
Re: [PATCH v6 2/2] dt-binding: spi: Document Macronix controller bindings
+Rob and the DT ML
Hi Mason,
Remember to Cc the DT mailing list and maintainers when you add/update a
binding.
On Wed, 17 Oct 2018 10:08:12 +0800
masonccy...@mxic.com.tw wrote:
> From: Mason Yang
>
> Document the bindings used by the Macronix controller.
>
> Signed-off-by: Mason Yang
> ---
> Documentation/devicetree/bindings/spi/spi-mxic.txt | 34
> ++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-mxic.txt
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-mxic.txt
> b/Documentation/devicetree/bindings/spi/spi-mxic.txt
> new file mode 100644
> index 000..529f2da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/spi-mxic.txt
> @@ -0,0 +1,34 @@
> +Macronix SPI controller Device Tree Bindings
> +
> +
> +Required properties:
> +- compatible: should be "mxicy,mx25f0a-spi"
> +- #address-cells: should be 1
> +- #size-cells: should be 0
> +- reg: should contain 2 entries, one for the registers and one for the direct
> + mapping area
> +- reg-names: should contain "regs" and "dirmap"
> +- interrupts: interrupt line connected to the SPI controller
> +- clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk"
The _clk suffix is unnecessary in my opinion. How about:
- clock-names: should contain "ps", "send" and "send_dly"
Other than that,
Reviewed-by: Boris Brezillon
> +- clocks: should contain 3 entries for the "ps_clk", "send_clk" and
> + "send_dly_clk" clocks
> +
> +Example:
> +
> + spi@43c3 {
> + compatible = "mxicy,mx25f0a-spi";
> + reg = <0x43c3 0x1>, <0xa000 0x2000>;
> + reg-names = "regs", "dirmap";
> + clocks = < 0>, < 1>, < 18>;
> + clock-names = "send_clk", "send_dly_clk", "ps_clk";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + };
> + };
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 16 Oct 2018 14:04:11 +0200
Boris Brezillon wrote:
> On Tue, 16 Oct 2018 09:51:47 +
> Yogesh Narayan Gaur wrote:
>
> > Hi Tudor,
> >
> > This patch is breaking the 1-4-4 Read protocol for the spansion flash
> > "s25fl512s".
> >
> > Without this patch read request command for Quad mode, 4-byte enable, is
> > coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> > But after applying this patch, read request command for Quad mode is coming
> > as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
> >
> > This flash also supports non-uniform erase.
> > Can you please check and provide some suggestion?
>
> Are you sure the regression comes from this patch? I suspect your bug
> comes from 41fe242979e4 ("mtd: spi-nor: fsl-quadspi: fix read error for
> flash size larger than 16MB").
I guess you're testing with an fsl-qspi controller, right? Can you try
with this patch?
--->8---
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 1ff3430f82c8..c47fe70c9f98 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -477,9 +477,6 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
{
switch (cmd) {
- case SPINOR_OP_READ_1_1_4:
- case SPINOR_OP_READ_1_1_4_4B:
- return SEQID_READ;
case SPINOR_OP_WREN:
return SEQID_WREN;
case SPINOR_OP_WRDI:
@@ -490,8 +487,6 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
return SEQID_SE;
case SPINOR_OP_CHIP_ERASE:
return SEQID_CHIP_ERASE;
- case SPINOR_OP_PP:
- return SEQID_PP;
case SPINOR_OP_RDID:
return SEQID_RDID;
case SPINOR_OP_WRSR:
@@ -503,7 +498,11 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
case SPINOR_OP_BRWR:
return SEQID_BRWR;
default:
- if (cmd == q->nor[0].erase_opcode)
+ if (cmd == q->nor[0].read_opcode)
+ return SEQID_READ;
+ else if (cmd == q->nor[0].program_opcode)
+ return SEQID_PP;
+ else if (cmd == q->nor[0].erase_opcode)
return SEQID_SE;
dev_err(q->dev, "Unsupported cmd 0x%.2x\n", cmd);
break;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 16 Oct 2018 14:04:11 +0200
Boris Brezillon wrote:
> On Tue, 16 Oct 2018 09:51:47 +
> Yogesh Narayan Gaur wrote:
>
> > Hi Tudor,
> >
> > This patch is breaking the 1-4-4 Read protocol for the spansion flash
> > "s25fl512s".
> >
> > Without this patch read request command for Quad mode, 4-byte enable, is
> > coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> > But after applying this patch, read request command for Quad mode is coming
> > as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
> >
> > This flash also supports non-uniform erase.
> > Can you please check and provide some suggestion?
>
> Are you sure the regression comes from this patch? I suspect your bug
> comes from 41fe242979e4 ("mtd: spi-nor: fsl-quadspi: fix read error for
> flash size larger than 16MB").
I guess you're testing with an fsl-qspi controller, right? Can you try
with this patch?
--->8---
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 1ff3430f82c8..c47fe70c9f98 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -477,9 +477,6 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
{
switch (cmd) {
- case SPINOR_OP_READ_1_1_4:
- case SPINOR_OP_READ_1_1_4_4B:
- return SEQID_READ;
case SPINOR_OP_WREN:
return SEQID_WREN;
case SPINOR_OP_WRDI:
@@ -490,8 +487,6 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
return SEQID_SE;
case SPINOR_OP_CHIP_ERASE:
return SEQID_CHIP_ERASE;
- case SPINOR_OP_PP:
- return SEQID_PP;
case SPINOR_OP_RDID:
return SEQID_RDID;
case SPINOR_OP_WRSR:
@@ -503,7 +498,11 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
case SPINOR_OP_BRWR:
return SEQID_BRWR;
default:
- if (cmd == q->nor[0].erase_opcode)
+ if (cmd == q->nor[0].read_opcode)
+ return SEQID_READ;
+ else if (cmd == q->nor[0].program_opcode)
+ return SEQID_PP;
+ else if (cmd == q->nor[0].erase_opcode)
return SEQID_SE;
dev_err(q->dev, "Unsupported cmd 0x%.2x\n", cmd);
break;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 16 Oct 2018 09:51:47 +
Yogesh Narayan Gaur wrote:
> Hi Tudor,
>
> This patch is breaking the 1-4-4 Read protocol for the spansion flash
> "s25fl512s".
>
> Without this patch read request command for Quad mode, 4-byte enable, is
> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> But after applying this patch, read request command for Quad mode is coming
> as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
>
> This flash also supports non-uniform erase.
> Can you please check and provide some suggestion?
Are you sure the regression comes from this patch? I suspect your bug
comes from 41fe242979e4 ("mtd: spi-nor: fsl-quadspi: fix read error for
flash size larger than 16MB").
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 16 Oct 2018 09:51:47 +
Yogesh Narayan Gaur wrote:
> Hi Tudor,
>
> This patch is breaking the 1-4-4 Read protocol for the spansion flash
> "s25fl512s".
>
> Without this patch read request command for Quad mode, 4-byte enable, is
> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> But after applying this patch, read request command for Quad mode is coming
> as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
>
> This flash also supports non-uniform erase.
> Can you please check and provide some suggestion?
Are you sure the regression comes from this patch? I suspect your bug
comes from 41fe242979e4 ("mtd: spi-nor: fsl-quadspi: fix read error for
flash size larger than 16MB").
Re: [PATCH] mtd: rawnand: denali: include instead of
On Tue, 16 Oct 2018 13:33:21 +0900
Masahiro Yamada wrote:
> The reason of including here is just for BIT() and
> GENMASK macros.
>
> Since commit 8bd9cb51daac8 ("locking/atomics, asm-generic: Move some
> macros from to a new file"),
> is enough for such compile-time macros.
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Boris Brezillon
> ---
>
> drivers/mtd/nand/raw/denali.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/denali.h b/drivers/mtd/nand/raw/denali.h
> index 57a5498..25c0060 100644
> --- a/drivers/mtd/nand/raw/denali.h
> +++ b/drivers/mtd/nand/raw/denali.h
> @@ -7,7 +7,7 @@
> #ifndef __DENALI_H__
> #define __DENALI_H__
>
> -#include
> +#include
> #include
> #include
> #include
Re: [PATCH] mtd: rawnand: denali: include instead of
On Tue, 16 Oct 2018 13:33:21 +0900
Masahiro Yamada wrote:
> The reason of including here is just for BIT() and
> GENMASK macros.
>
> Since commit 8bd9cb51daac8 ("locking/atomics, asm-generic: Move some
> macros from to a new file"),
> is enough for such compile-time macros.
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Boris Brezillon
> ---
>
> drivers/mtd/nand/raw/denali.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/denali.h b/drivers/mtd/nand/raw/denali.h
> index 57a5498..25c0060 100644
> --- a/drivers/mtd/nand/raw/denali.h
> +++ b/drivers/mtd/nand/raw/denali.h
> @@ -7,7 +7,7 @@
> #ifndef __DENALI_H__
> #define __DENALI_H__
>
> -#include
> +#include
> #include
> #include
> #include
Re: [PATCH] jffs2: free jffs2_sb_info through jffs2_kill_sb()
On Tue, 16 Oct 2018 18:26:34 +0800
Hou Tao wrote:
> On 2018/10/16 14:41, Richard Weinberger wrote:
> > On Tue, Oct 16, 2018 at 7:53 AM Hou Tao wrote:
> >>
> >> ping ?
> >>
> >> On 2018/10/6 17:09, Hou Tao wrote:
> >>> When an invalid mount option is passed to jffs2, jffs2_parse_options()
> >>> will fail and jffs2_sb_info will be freed, but then jffs2_sb_info will
> >>> be used (use-after-free) and freeed (double-free) in jffs2_kill_sb().
> >>>
> >>> Fix it by removing the buggy invocation of kfree() when getting invalid
> >>> mount options.
> >>>
> >>> Cc: sta...@kernel.org
> >>> Signed-off-by: Hou Tao
> >>> ---
> >>> fs/jffs2/super.c | 4 +---
> >>> 1 file changed, 1 insertion(+), 3 deletions(-)
> >>>
> >>> diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
> >>> index 87bdf0f4cba1..902a7dd10e5c 100644
> >>> --- a/fs/jffs2/super.c
> >>> +++ b/fs/jffs2/super.c
> >>> @@ -285,10 +285,8 @@ static int jffs2_fill_super(struct super_block *sb,
> >>> void *data, int silent)
> >>> sb->s_fs_info = c;
> >>>
> >>> ret = jffs2_parse_options(c, data);
> >>> - if (ret) {
> >>> - kfree(c);
> >>> + if (ret)
> >>> return -EINVAL;
> >>> - }
> >
> > Reviewed-by: Richard Weinberger
> >
> > We can carry this via the MTD tree.
> Thanks for that.
Applied after adding
Fixes: 92abc475d8de ("jffs2: implement mount option parsing and compression
overriding")
>
> Regards,
> Tao
>
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
Re: [PATCH] jffs2: free jffs2_sb_info through jffs2_kill_sb()
On Tue, 16 Oct 2018 18:26:34 +0800
Hou Tao wrote:
> On 2018/10/16 14:41, Richard Weinberger wrote:
> > On Tue, Oct 16, 2018 at 7:53 AM Hou Tao wrote:
> >>
> >> ping ?
> >>
> >> On 2018/10/6 17:09, Hou Tao wrote:
> >>> When an invalid mount option is passed to jffs2, jffs2_parse_options()
> >>> will fail and jffs2_sb_info will be freed, but then jffs2_sb_info will
> >>> be used (use-after-free) and freeed (double-free) in jffs2_kill_sb().
> >>>
> >>> Fix it by removing the buggy invocation of kfree() when getting invalid
> >>> mount options.
> >>>
> >>> Cc: sta...@kernel.org
> >>> Signed-off-by: Hou Tao
> >>> ---
> >>> fs/jffs2/super.c | 4 +---
> >>> 1 file changed, 1 insertion(+), 3 deletions(-)
> >>>
> >>> diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
> >>> index 87bdf0f4cba1..902a7dd10e5c 100644
> >>> --- a/fs/jffs2/super.c
> >>> +++ b/fs/jffs2/super.c
> >>> @@ -285,10 +285,8 @@ static int jffs2_fill_super(struct super_block *sb,
> >>> void *data, int silent)
> >>> sb->s_fs_info = c;
> >>>
> >>> ret = jffs2_parse_options(c, data);
> >>> - if (ret) {
> >>> - kfree(c);
> >>> + if (ret)
> >>> return -EINVAL;
> >>> - }
> >
> > Reviewed-by: Richard Weinberger
> >
> > We can carry this via the MTD tree.
> Thanks for that.
Applied after adding
Fixes: 92abc475d8de ("jffs2: implement mount option parsing and compression
overriding")
>
> Regards,
> Tao
>
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
Re: [PATCH v2 0/7] spi: add support for octal mode
Hi Yogesh, On Mon, 15 Oct 2018 11:47:55 + Yogesh Narayan Gaur wrote: > Add support for octal mode IO data transfer. > Micron flash, mt35xu512aba, supports octal mode data transfer and > NXP FlexSPI controller supports 8 data lines for data transfer (Rx/Tx). > > Patch series > * Add support for octal mode flags and parsing of same in spi driver. > * Add opcodes for octal I/O commands in spi-nor framework, Read and Write > proto for (1-1-8/1-8-8) mode. > Opcodes are added as per octal data IO commands required for mt35xu512aba > [1] flash. > * Add parsing logic for spi-mem framework and m25p80.c device file. > * Add mode bit required for octal mode in nxp-fspi driver [2]. > * Define binding property 'spi-rx/tx-bus-width' for LX2160ARDB target [2]. > > Cherry pick below 2 patches (from: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git): > c639f871febe6667d9afce28108c634e5636c735 spi: spi-mem: Fix inverted logic > in op sanity check > db122eb8a749a1eff038f9a282c620ab16c4be1d spi: spi-mem: Add extra sanity > checks on the op param > > Tested on LX2160ARDB target with nxp-fspi driver, below are > Read performance number of 1-1-1 and 1-1-8 read protocol. > > root@lxxx:~# cat /proc/mtd > dev:size erasesize name > mtd0: 0400 1000 "spi0.0" > mtd1: 0400 1000 "spi0.1" > root@lxxx:~# time mtd_debug read /dev/mtd0 0x0 0x100 0read > Copied 16777216 bytes from address 0x in flash to 0read > > real0m2.792s > user0m0.000s > sys 0m2.790s > root@lxxx:~# time mtd_debug read /dev/mtd1 0x0 0x100 0read > Copied 16777216 bytes from address 0x in flash to 0read > > real0m0.441s > user0m0.000s > sys 0m0.440s > root@ls1012ardb:~# > > Flash device MTD0 configured in 1-1-1 protocol. > Flash device MTD1 configured in 1-1-8 protocol. > > [1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70384 > [2] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70210 > > Yogesh Gaur (7): > spi: add support for octal I/O data transfer > mtd: spi-nor: add opcodes for octal Read/Write commands > mtd: spi-nor: add octal read flag for flash mt35xu512aba > mtd: m25p80: add support of octal I/O transfer > spi: spi-mem: add support for octal I/O data transfer Patch 5 should be moved before patch 4 (ideally in 2nd position) if you want this series to be bisectable. Regards, Boris > spi: nxp-fspi: add mode flag bit for octal support > arm64: dts: lx2160a: update fspi node > > Changes for v2: > Incorporated review comments of Boris and Vignesh. > > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 > drivers/mtd/devices/m25p80.c | 9 - > drivers/mtd/spi-nor/spi-nor.c | 15 ++- > drivers/spi/spi-mem.c | 9 - > drivers/spi/spi-nxp-fspi.c| 4 ++-- > drivers/spi/spi.c | 6 ++ > include/linux/mtd/spi-nor.h | 8 > include/linux/spi/spi.h | 2 ++ > 8 files changed, 52 insertions(+), 5 deletions(-) >
Re: [PATCH v2 0/7] spi: add support for octal mode
Hi Yogesh, On Mon, 15 Oct 2018 11:47:55 + Yogesh Narayan Gaur wrote: > Add support for octal mode IO data transfer. > Micron flash, mt35xu512aba, supports octal mode data transfer and > NXP FlexSPI controller supports 8 data lines for data transfer (Rx/Tx). > > Patch series > * Add support for octal mode flags and parsing of same in spi driver. > * Add opcodes for octal I/O commands in spi-nor framework, Read and Write > proto for (1-1-8/1-8-8) mode. > Opcodes are added as per octal data IO commands required for mt35xu512aba > [1] flash. > * Add parsing logic for spi-mem framework and m25p80.c device file. > * Add mode bit required for octal mode in nxp-fspi driver [2]. > * Define binding property 'spi-rx/tx-bus-width' for LX2160ARDB target [2]. > > Cherry pick below 2 patches (from: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git): > c639f871febe6667d9afce28108c634e5636c735 spi: spi-mem: Fix inverted logic > in op sanity check > db122eb8a749a1eff038f9a282c620ab16c4be1d spi: spi-mem: Add extra sanity > checks on the op param > > Tested on LX2160ARDB target with nxp-fspi driver, below are > Read performance number of 1-1-1 and 1-1-8 read protocol. > > root@lxxx:~# cat /proc/mtd > dev:size erasesize name > mtd0: 0400 1000 "spi0.0" > mtd1: 0400 1000 "spi0.1" > root@lxxx:~# time mtd_debug read /dev/mtd0 0x0 0x100 0read > Copied 16777216 bytes from address 0x in flash to 0read > > real0m2.792s > user0m0.000s > sys 0m2.790s > root@lxxx:~# time mtd_debug read /dev/mtd1 0x0 0x100 0read > Copied 16777216 bytes from address 0x in flash to 0read > > real0m0.441s > user0m0.000s > sys 0m0.440s > root@ls1012ardb:~# > > Flash device MTD0 configured in 1-1-1 protocol. > Flash device MTD1 configured in 1-1-8 protocol. > > [1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70384 > [2] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70210 > > Yogesh Gaur (7): > spi: add support for octal I/O data transfer > mtd: spi-nor: add opcodes for octal Read/Write commands > mtd: spi-nor: add octal read flag for flash mt35xu512aba > mtd: m25p80: add support of octal I/O transfer > spi: spi-mem: add support for octal I/O data transfer Patch 5 should be moved before patch 4 (ideally in 2nd position) if you want this series to be bisectable. Regards, Boris > spi: nxp-fspi: add mode flag bit for octal support > arm64: dts: lx2160a: update fspi node > > Changes for v2: > Incorporated review comments of Boris and Vignesh. > > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 > drivers/mtd/devices/m25p80.c | 9 - > drivers/mtd/spi-nor/spi-nor.c | 15 ++- > drivers/spi/spi-mem.c | 9 - > drivers/spi/spi-nxp-fspi.c| 4 ++-- > drivers/spi/spi.c | 6 ++ > include/linux/mtd/spi-nor.h | 8 > include/linux/spi/spi.h | 2 ++ > 8 files changed, 52 insertions(+), 5 deletions(-) >
Re: [PATCH v5 1/2] spi: Add MXIC controller driver
Hi Mason,
On Mon, 15 Oct 2018 16:26:15 +0800
masonccy...@mxic.com.tw wrote:
> +
> +static int mxic_spi_setup(struct spi_device *spi)
> +{
> + return 0;
> +}
Drop this empty function and leave ->setup to NULL.
> +
> +static int mxic_spi_probe(struct platform_device *pdev)
> +{
> + struct spi_master *master;
> + struct resource *res;
> + struct mxic_spi *mxic;
> + int ret;
> +
> + master = spi_alloc_master(>dev, sizeof(struct mxic_spi));
> + if (!master)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, master);
> +
> + mxic = spi_master_get_devdata(master);
> +
> + master->dev.of_node = pdev->dev.of_node;
> +
> + mxic->ps_clk = devm_clk_get(>dev, "ps_clk");
> + if (IS_ERR(mxic->ps_clk))
> + return PTR_ERR(mxic->ps_clk);
> +
> + mxic->send_clk = devm_clk_get(>dev, "send_clk");
> + if (IS_ERR(mxic->send_clk))
> + return PTR_ERR(mxic->send_clk);
> +
> + mxic->send_dly_clk = devm_clk_get(>dev, "send_dly_clk");
> + if (IS_ERR(mxic->send_dly_clk))
> + return PTR_ERR(mxic->send_dly_clk);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> + mxic->regs = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(mxic->regs))
> + return PTR_ERR(mxic->regs);
> +
> + pm_runtime_enable(>dev);
> + master->auto_runtime_pm = true;
> +
> + master->num_chipselect = 1;
> + master->setup = mxic_spi_setup;
> + master->mem_ops = _spi_mem_ops;
> +
> + master->set_cs = mxic_spi_set_cs;
> + master->transfer_one = mxic_spi_transfer_one;
> + master->bits_per_word_mask = SPI_BPW_MASK(8);
> + master->mode_bits = SPI_CPOL | SPI_CPHA |
> + SPI_RX_DUAL | SPI_TX_DUAL |
> + SPI_RX_QUAD | SPI_TX_QUAD;
> +
> + mxic_spi_hw_init(mxic);
Don't you need at least the ps_clk to be enabled to write to the MXIC
regs? Also, what happens when the ps_clk is disabled? Is reg content
preserved? If not, then you should probably move the mxic_spi_hw_init()
in the mxic_spi_runtime_resume() function so that you always start from
a known state.
> +
> + ret = spi_register_master(master);
> + if (ret) {
> + dev_err(>dev, "spi_register_master failed\n");
> + goto err_put_master;
> + }
> +
> + return 0;
> +
> +err_put_master:
> + spi_master_put(master);
> + pm_runtime_disable(>dev);
> +
> + return ret;
> +}
> +
> +static int mxic_spi_remove(struct platform_device *pdev)
> +{
> + struct spi_master *master = platform_get_drvdata(pdev);
> +
> + pm_runtime_disable(>dev);
> + spi_unregister_master(master);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id mxic_spi_of_ids[] = {
> + { .compatible = "mxicy,mx25f0a-spi", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mxic_spi_of_ids);
> +
> +static struct platform_driver mxic_spi_driver = {
> + .probe = mxic_spi_probe,
> + .remove = mxic_spi_remove,
> + .driver = {
> + .name = "mxic-spi",
> + .of_match_table = mxic_spi_of_ids,
> + .pm = _spi_dev_pm_ops,
> + },
> +};
> +module_platform_driver(mxic_spi_driver);
> +
> +MODULE_AUTHOR("Mason Yang ");
> +MODULE_DESCRIPTION("MX25F0A SPI controller driver");
> +MODULE_LICENSE("GPL v2");
> +
Drop this blank line.
Regards,
Boris
Re: [PATCH v5 1/2] spi: Add MXIC controller driver
Hi Mason,
On Mon, 15 Oct 2018 16:26:15 +0800
masonccy...@mxic.com.tw wrote:
> +
> +static int mxic_spi_setup(struct spi_device *spi)
> +{
> + return 0;
> +}
Drop this empty function and leave ->setup to NULL.
> +
> +static int mxic_spi_probe(struct platform_device *pdev)
> +{
> + struct spi_master *master;
> + struct resource *res;
> + struct mxic_spi *mxic;
> + int ret;
> +
> + master = spi_alloc_master(>dev, sizeof(struct mxic_spi));
> + if (!master)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, master);
> +
> + mxic = spi_master_get_devdata(master);
> +
> + master->dev.of_node = pdev->dev.of_node;
> +
> + mxic->ps_clk = devm_clk_get(>dev, "ps_clk");
> + if (IS_ERR(mxic->ps_clk))
> + return PTR_ERR(mxic->ps_clk);
> +
> + mxic->send_clk = devm_clk_get(>dev, "send_clk");
> + if (IS_ERR(mxic->send_clk))
> + return PTR_ERR(mxic->send_clk);
> +
> + mxic->send_dly_clk = devm_clk_get(>dev, "send_dly_clk");
> + if (IS_ERR(mxic->send_dly_clk))
> + return PTR_ERR(mxic->send_dly_clk);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> + mxic->regs = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(mxic->regs))
> + return PTR_ERR(mxic->regs);
> +
> + pm_runtime_enable(>dev);
> + master->auto_runtime_pm = true;
> +
> + master->num_chipselect = 1;
> + master->setup = mxic_spi_setup;
> + master->mem_ops = _spi_mem_ops;
> +
> + master->set_cs = mxic_spi_set_cs;
> + master->transfer_one = mxic_spi_transfer_one;
> + master->bits_per_word_mask = SPI_BPW_MASK(8);
> + master->mode_bits = SPI_CPOL | SPI_CPHA |
> + SPI_RX_DUAL | SPI_TX_DUAL |
> + SPI_RX_QUAD | SPI_TX_QUAD;
> +
> + mxic_spi_hw_init(mxic);
Don't you need at least the ps_clk to be enabled to write to the MXIC
regs? Also, what happens when the ps_clk is disabled? Is reg content
preserved? If not, then you should probably move the mxic_spi_hw_init()
in the mxic_spi_runtime_resume() function so that you always start from
a known state.
> +
> + ret = spi_register_master(master);
> + if (ret) {
> + dev_err(>dev, "spi_register_master failed\n");
> + goto err_put_master;
> + }
> +
> + return 0;
> +
> +err_put_master:
> + spi_master_put(master);
> + pm_runtime_disable(>dev);
> +
> + return ret;
> +}
> +
> +static int mxic_spi_remove(struct platform_device *pdev)
> +{
> + struct spi_master *master = platform_get_drvdata(pdev);
> +
> + pm_runtime_disable(>dev);
> + spi_unregister_master(master);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id mxic_spi_of_ids[] = {
> + { .compatible = "mxicy,mx25f0a-spi", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mxic_spi_of_ids);
> +
> +static struct platform_driver mxic_spi_driver = {
> + .probe = mxic_spi_probe,
> + .remove = mxic_spi_remove,
> + .driver = {
> + .name = "mxic-spi",
> + .of_match_table = mxic_spi_of_ids,
> + .pm = _spi_dev_pm_ops,
> + },
> +};
> +module_platform_driver(mxic_spi_driver);
> +
> +MODULE_AUTHOR("Mason Yang ");
> +MODULE_DESCRIPTION("MX25F0A SPI controller driver");
> +MODULE_LICENSE("GPL v2");
> +
Drop this blank line.
Regards,
Boris
Re: [PATCH v2 2/2] mtd: rawnand: ams-delta: Use ->exec_op()
Hi Janusz,
On Fri, 12 Oct 2018 22:41:01 +0200
Janusz Krzysztofik wrote:
> Replace legacy callbacks with ->select_chip() and ->exec_op().
>
> In order to remove any references to legacy structure members, use of
> .IO_ADDR_R/W has been replaced wit runtime calculations based on
^ with
> priv->io_base.
Can we do that in 2 steps?
1/ Stop using .IO_ADDR_R/W
2/ Convert the driver to ->exec_op()
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Janusz Krzysztofik
> ---
[...]
> -static int ams_delta_nand_ready(struct nand_chip *this)
> +static int ams_delta_exec_op(struct nand_chip *this,
> + const struct nand_operation *op, bool check_only)
> {
> struct ams_delta_nand *priv = nand_get_controller_data(this);
> + const struct nand_op_instr *instr;
> + int ret = 0;
> +
You should have:
if (check_only)
return 0;
Other than that, the conversion looks good, so you can add
Reviewed-by: Boris Brezillon once you've
addressed my comments.
Regards,
Boris
> + for (instr = op->instrs; instr < op->instrs + op->ninstrs; instr++) {
> +
> + switch (instr->type) {
> + case NAND_OP_CMD_INSTR:
> + gpiod_set_value(priv->gpiod_cle, 1);
> + ams_delta_write_buf(priv, >ctx.cmd.opcode, 1);
> + gpiod_set_value(priv->gpiod_cle, 0);
> + break;
> +
> + case NAND_OP_ADDR_INSTR:
> + gpiod_set_value(priv->gpiod_ale, 1);
> + ams_delta_write_buf(priv, instr->ctx.addr.addrs,
> + instr->ctx.addr.naddrs);
> + gpiod_set_value(priv->gpiod_ale, 0);
> + break;
> +
> + case NAND_OP_DATA_IN_INSTR:
> + ams_delta_read_buf(priv, instr->ctx.data.buf.in,
> +instr->ctx.data.len);
> + break;
> +
> + case NAND_OP_DATA_OUT_INSTR:
> + ams_delta_write_buf(priv, instr->ctx.data.buf.out,
> + instr->ctx.data.len);
> + break;
> +
> + case NAND_OP_WAITRDY_INSTR:
> + ret = priv->gpiod_rdy ?
> + nand_gpio_waitrdy(this, priv->gpiod_rdy,
> + instr->ctx.waitrdy.timeout_ms) :
> + nand_soft_waitrdy(this,
> + instr->ctx.waitrdy.timeout_ms);
> + break;
> + }
> +
> + if (ret)
> + break;
> + }
>
> - return gpiod_get_value(priv->gpiod_rdy);
> + return ret;
> }
Re: [PATCH v2 2/2] mtd: rawnand: ams-delta: Use ->exec_op()
Hi Janusz,
On Fri, 12 Oct 2018 22:41:01 +0200
Janusz Krzysztofik wrote:
> Replace legacy callbacks with ->select_chip() and ->exec_op().
>
> In order to remove any references to legacy structure members, use of
> .IO_ADDR_R/W has been replaced wit runtime calculations based on
^ with
> priv->io_base.
Can we do that in 2 steps?
1/ Stop using .IO_ADDR_R/W
2/ Convert the driver to ->exec_op()
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Janusz Krzysztofik
> ---
[...]
> -static int ams_delta_nand_ready(struct nand_chip *this)
> +static int ams_delta_exec_op(struct nand_chip *this,
> + const struct nand_operation *op, bool check_only)
> {
> struct ams_delta_nand *priv = nand_get_controller_data(this);
> + const struct nand_op_instr *instr;
> + int ret = 0;
> +
You should have:
if (check_only)
return 0;
Other than that, the conversion looks good, so you can add
Reviewed-by: Boris Brezillon once you've
addressed my comments.
Regards,
Boris
> + for (instr = op->instrs; instr < op->instrs + op->ninstrs; instr++) {
> +
> + switch (instr->type) {
> + case NAND_OP_CMD_INSTR:
> + gpiod_set_value(priv->gpiod_cle, 1);
> + ams_delta_write_buf(priv, >ctx.cmd.opcode, 1);
> + gpiod_set_value(priv->gpiod_cle, 0);
> + break;
> +
> + case NAND_OP_ADDR_INSTR:
> + gpiod_set_value(priv->gpiod_ale, 1);
> + ams_delta_write_buf(priv, instr->ctx.addr.addrs,
> + instr->ctx.addr.naddrs);
> + gpiod_set_value(priv->gpiod_ale, 0);
> + break;
> +
> + case NAND_OP_DATA_IN_INSTR:
> + ams_delta_read_buf(priv, instr->ctx.data.buf.in,
> +instr->ctx.data.len);
> + break;
> +
> + case NAND_OP_DATA_OUT_INSTR:
> + ams_delta_write_buf(priv, instr->ctx.data.buf.out,
> + instr->ctx.data.len);
> + break;
> +
> + case NAND_OP_WAITRDY_INSTR:
> + ret = priv->gpiod_rdy ?
> + nand_gpio_waitrdy(this, priv->gpiod_rdy,
> + instr->ctx.waitrdy.timeout_ms) :
> + nand_soft_waitrdy(this,
> + instr->ctx.waitrdy.timeout_ms);
> + break;
> + }
> +
> + if (ret)
> + break;
> + }
>
> - return gpiod_get_value(priv->gpiod_rdy);
> + return ret;
> }
Re: [PATCH v2 1/2] mtd: rawnand: Provide helper for polling GPIO R/B pin
Hi Janusz,
On Fri, 12 Oct 2018 22:41:00 +0200
Janusz Krzysztofik wrote:
> Each controller driver with access to NAND R/B pin over GPIO would have
> to reimplement the polling loop otherwise.
>
> Signed-off-by: Janusz Krzysztofik
> ---
> Changelog:
> v2:
> New patch - v1 consisted of only one patch (the followning one)
>
>
> drivers/mtd/nand/raw/nand_base.c | 38 ++
> include/linux/mtd/rawnand.h | 10 ++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index 05bd0779fe9b..ff1ac4a3c647 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -45,6 +45,9 @@
> #include
> #include
> #include
> +#ifdef CONFIG_GPIOLIB
> +#include
> +#endif
The ifdef is not needed here, linux/gpio/consumer.h already has dummy
wrappers when CONFIG_GPIOLIB is not enabled.
>
> #include "internals.h"
>
> @@ -531,6 +534,41 @@ int nand_soft_waitrdy(struct nand_chip *chip, unsigned
> long timeout_ms)
> };
> EXPORT_SYMBOL_GPL(nand_soft_waitrdy);
>
> +#ifdef CONFIG_GPIOLIB
> +/**
> + * nand_gpio_waitrdy - Poll R/B GPIO pin until ready
> + * @chip: NAND chip structure
> + * @gpiod: GPIO descriptor of R/B pin
> + * @timeout_ms: Timeout in ms
> + *
> + * Poll the R/B GPIO pin until it becomes ready. If that does not happen
> + * whitin the specified timeout, -ETIMEDOUT is returned.
> + *
> + * This helper is intended to be used when the controller has access to the
> + * NAND R/B pin over GPIO.
> + *
> + * Be aware that calling this helper from an ->exec_op() implementation means
> + * ->exec_op() must be re-entrant.
This is not true for this function: it does not call nand_exec_op().
> + *
> + * Return 0 if the R/B pin indicates chip is ready, a negative error
> otherwise.
> + */
> +int nand_gpio_waitrdy(struct nand_chip *chip, struct gpio_desc *gpiod,
> + unsigned long timeout_ms)
> +{
> + /* Wait until command is processed or timeout occurs */
> + timeout_ms = jiffies + msecs_to_jiffies(timeout_ms);
> + do {
> + if (gpiod_get_value_cansleep(gpiod))
> + return 0;
> +
> + cond_resched();
> + } while (time_before(jiffies, timeout_ms));
> +
> + return gpiod_get_value_cansleep(gpiod) ? 0 : -ETIMEDOUT;
> +};
> +EXPORT_SYMBOL_GPL(nand_gpio_waitrdy);
> +#endif
Hm, I don't see any other helpers defined in #ifdef blocks though most
of them are optionals and are most of the time not used by drivers.
Let's keep things consistent (at the expense of embedding unused code
in nand.o) and remove the #ifdef here. If someone starts complaining
about the size of the rawnand core, we'll consider doing that.
> +
> /**
> * panic_nand_get_device - [GENERIC] Get chip for selected access
> * @chip: the nand chip descriptor
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index e10b126e148f..09f0ed1345b1 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -1346,4 +1346,14 @@ void nand_release(struct nand_chip *chip);
> */
> int nand_soft_waitrdy(struct nand_chip *chip, unsigned long timeout_ms);
>
> +#ifdef CONFIG_GPIOLIB
> +struct gpio_desc;
> +/*
> + * External helper for controller drivers that have to implement the WAITRDY
> + * instruction and do have GPIO pin to check it.
> + */
You can drop this comment, this is already explained in the kerneldoc
header above the function def.
> +int nand_gpio_waitrdy(struct nand_chip *chip, struct gpio_desc *gpiod,
> + unsigned long timeout_ms);
> +#endif
> +
> #endif /* __LINUX_MTD_RAWNAND_H */
Regards,
Boris
Re: [PATCH v2 1/2] mtd: rawnand: Provide helper for polling GPIO R/B pin
Hi Janusz,
On Fri, 12 Oct 2018 22:41:00 +0200
Janusz Krzysztofik wrote:
> Each controller driver with access to NAND R/B pin over GPIO would have
> to reimplement the polling loop otherwise.
>
> Signed-off-by: Janusz Krzysztofik
> ---
> Changelog:
> v2:
> New patch - v1 consisted of only one patch (the followning one)
>
>
> drivers/mtd/nand/raw/nand_base.c | 38 ++
> include/linux/mtd/rawnand.h | 10 ++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index 05bd0779fe9b..ff1ac4a3c647 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -45,6 +45,9 @@
> #include
> #include
> #include
> +#ifdef CONFIG_GPIOLIB
> +#include
> +#endif
The ifdef is not needed here, linux/gpio/consumer.h already has dummy
wrappers when CONFIG_GPIOLIB is not enabled.
>
> #include "internals.h"
>
> @@ -531,6 +534,41 @@ int nand_soft_waitrdy(struct nand_chip *chip, unsigned
> long timeout_ms)
> };
> EXPORT_SYMBOL_GPL(nand_soft_waitrdy);
>
> +#ifdef CONFIG_GPIOLIB
> +/**
> + * nand_gpio_waitrdy - Poll R/B GPIO pin until ready
> + * @chip: NAND chip structure
> + * @gpiod: GPIO descriptor of R/B pin
> + * @timeout_ms: Timeout in ms
> + *
> + * Poll the R/B GPIO pin until it becomes ready. If that does not happen
> + * whitin the specified timeout, -ETIMEDOUT is returned.
> + *
> + * This helper is intended to be used when the controller has access to the
> + * NAND R/B pin over GPIO.
> + *
> + * Be aware that calling this helper from an ->exec_op() implementation means
> + * ->exec_op() must be re-entrant.
This is not true for this function: it does not call nand_exec_op().
> + *
> + * Return 0 if the R/B pin indicates chip is ready, a negative error
> otherwise.
> + */
> +int nand_gpio_waitrdy(struct nand_chip *chip, struct gpio_desc *gpiod,
> + unsigned long timeout_ms)
> +{
> + /* Wait until command is processed or timeout occurs */
> + timeout_ms = jiffies + msecs_to_jiffies(timeout_ms);
> + do {
> + if (gpiod_get_value_cansleep(gpiod))
> + return 0;
> +
> + cond_resched();
> + } while (time_before(jiffies, timeout_ms));
> +
> + return gpiod_get_value_cansleep(gpiod) ? 0 : -ETIMEDOUT;
> +};
> +EXPORT_SYMBOL_GPL(nand_gpio_waitrdy);
> +#endif
Hm, I don't see any other helpers defined in #ifdef blocks though most
of them are optionals and are most of the time not used by drivers.
Let's keep things consistent (at the expense of embedding unused code
in nand.o) and remove the #ifdef here. If someone starts complaining
about the size of the rawnand core, we'll consider doing that.
> +
> /**
> * panic_nand_get_device - [GENERIC] Get chip for selected access
> * @chip: the nand chip descriptor
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index e10b126e148f..09f0ed1345b1 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -1346,4 +1346,14 @@ void nand_release(struct nand_chip *chip);
> */
> int nand_soft_waitrdy(struct nand_chip *chip, unsigned long timeout_ms);
>
> +#ifdef CONFIG_GPIOLIB
> +struct gpio_desc;
> +/*
> + * External helper for controller drivers that have to implement the WAITRDY
> + * instruction and do have GPIO pin to check it.
> + */
You can drop this comment, this is already explained in the kerneldoc
header above the function def.
> +int nand_gpio_waitrdy(struct nand_chip *chip, struct gpio_desc *gpiod,
> + unsigned long timeout_ms);
> +#endif
> +
> #endif /* __LINUX_MTD_RAWNAND_H */
Regards,
Boris
Re: [PATCH v3] mtd: spi-nor: fsl-quadspi: fix read error for flash size larger than 16MB
On Tue, 28 Aug 2018 22:32:57 +0800
Liu Xiang wrote:
> If the size of spi-nor flash is larger than 16MB, the read_opcode
> is set to SPINOR_OP_READ_1_1_4_4B, and fsl_qspi_get_seqid() will
> return -EINVAL when cmd is SPINOR_OP_READ_1_1_4_4B. This can
> cause read operation fail.
>
> Fixes: e46ecda764dc ("mtd: spi-nor: Add Freescale QuadSPI driver")
> Cc:
> Signed-off-by: Liu Xiang
Queued to spi-nor/next.
Thanks,
Boris
> ---
>
> Changes in v3:
> move changelog position.
>
> drivers/mtd/spi-nor/fsl-quadspi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 7d9620c..64304a3 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -478,6 +478,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
> {
> switch (cmd) {
> case SPINOR_OP_READ_1_1_4:
> + case SPINOR_OP_READ_1_1_4_4B:
> return SEQID_READ;
> case SPINOR_OP_WREN:
> return SEQID_WREN;
Re: [PATCH v3] mtd: spi-nor: fsl-quadspi: fix read error for flash size larger than 16MB
On Tue, 28 Aug 2018 22:32:57 +0800
Liu Xiang wrote:
> If the size of spi-nor flash is larger than 16MB, the read_opcode
> is set to SPINOR_OP_READ_1_1_4_4B, and fsl_qspi_get_seqid() will
> return -EINVAL when cmd is SPINOR_OP_READ_1_1_4_4B. This can
> cause read operation fail.
>
> Fixes: e46ecda764dc ("mtd: spi-nor: Add Freescale QuadSPI driver")
> Cc:
> Signed-off-by: Liu Xiang
Queued to spi-nor/next.
Thanks,
Boris
> ---
>
> Changes in v3:
> move changelog position.
>
> drivers/mtd/spi-nor/fsl-quadspi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 7d9620c..64304a3 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -478,6 +478,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
> {
> switch (cmd) {
> case SPINOR_OP_READ_1_1_4:
> + case SPINOR_OP_READ_1_1_4_4B:
> return SEQID_READ;
> case SPINOR_OP_WREN:
> return SEQID_WREN;
Re: [PATCH] mtd: sa1100: avoid VLA in sa1100_setup_mtd
On Fri, 12 Oct 2018 11:19:52 +0200 Arnd Bergmann wrote: > On Fri, Oct 12, 2018 at 11:16 AM Boris Brezillon > wrote: > > > > Hi Arnd, > > > > On Wed, 10 Oct 2018 20:44:50 +0200 > > Arnd Bergmann wrote: > > > > > Enabling -Wvla found another variable-length array with randconfig > > > testing: > > > > > > drivers/mtd/maps/sa1100-flash.c: In function 'sa1100_setup_mtd': > > > drivers/mtd/maps/sa1100-flash.c:224:10: error: ISO C90 forbids variable > > > length array 'cdev' [-Werror=vla] > > > > > > As far as I can tell, there is an upper bound on the number of resources > > > that can be passed, based on the number of CS lines on the bus. > > > In practice, all boards we support have either one or two resources, > > > but using six to be on the safe side has no extra cost. > > > > Why not dynamically allocate cdev instead? That removes any kind of > > guessing on the max value, and it shouldn't hurt much since this code is > > in the probe path. > > Fine with me as well, If you prefer that one, please just add > Reported-by: Arnd Bergmann Oh, I thought I'd let you send a v2, but I can do it if you prefer.
Re: [PATCH] mtd: sa1100: avoid VLA in sa1100_setup_mtd
On Fri, 12 Oct 2018 11:19:52 +0200 Arnd Bergmann wrote: > On Fri, Oct 12, 2018 at 11:16 AM Boris Brezillon > wrote: > > > > Hi Arnd, > > > > On Wed, 10 Oct 2018 20:44:50 +0200 > > Arnd Bergmann wrote: > > > > > Enabling -Wvla found another variable-length array with randconfig > > > testing: > > > > > > drivers/mtd/maps/sa1100-flash.c: In function 'sa1100_setup_mtd': > > > drivers/mtd/maps/sa1100-flash.c:224:10: error: ISO C90 forbids variable > > > length array 'cdev' [-Werror=vla] > > > > > > As far as I can tell, there is an upper bound on the number of resources > > > that can be passed, based on the number of CS lines on the bus. > > > In practice, all boards we support have either one or two resources, > > > but using six to be on the safe side has no extra cost. > > > > Why not dynamically allocate cdev instead? That removes any kind of > > guessing on the max value, and it shouldn't hurt much since this code is > > in the probe path. > > Fine with me as well, If you prefer that one, please just add > Reported-by: Arnd Bergmann Oh, I thought I'd let you send a v2, but I can do it if you prefer.
Re: [PATCH] mtd: sa1100: avoid VLA in sa1100_setup_mtd
Hi Arnd,
On Wed, 10 Oct 2018 20:44:50 +0200
Arnd Bergmann wrote:
> Enabling -Wvla found another variable-length array with randconfig
> testing:
>
> drivers/mtd/maps/sa1100-flash.c: In function 'sa1100_setup_mtd':
> drivers/mtd/maps/sa1100-flash.c:224:10: error: ISO C90 forbids variable
> length array 'cdev' [-Werror=vla]
>
> As far as I can tell, there is an upper bound on the number of resources
> that can be passed, based on the number of CS lines on the bus.
> In practice, all boards we support have either one or two resources,
> but using six to be on the safe side has no extra cost.
Why not dynamically allocate cdev instead? That removes any kind of
guessing on the max value, and it shouldn't hurt much since this code is
in the probe path.
--->8---
diff --git a/drivers/mtd/maps/sa1100-flash.c b/drivers/mtd/maps/sa1100-flash.c
index 784c6e1a0391..fd5fe12d7461 100644
--- a/drivers/mtd/maps/sa1100-flash.c
+++ b/drivers/mtd/maps/sa1100-flash.c
@@ -221,7 +221,14 @@ static struct sa_info *sa1100_setup_mtd(struct
platform_device *pdev,
info->mtd = info->subdev[0].mtd;
ret = 0;
} else if (info->num_subdev > 1) {
- struct mtd_info *cdev[nr];
+ struct mtd_info **cdev;
+
+ cdev = kmalloc_array(nr, sizeof(*cdev), GFP_KERNEL);
+ if (!cdev) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
/*
* We detected multiple devices. Concatenate them together.
*/
@@ -230,6 +237,7 @@ static struct sa_info *sa1100_setup_mtd(struct
platform_device *pdev,
info->mtd = mtd_concat_create(cdev, info->num_subdev,
plat->name);
+ kfree(cdev);
if (info->mtd == NULL) {
ret = -ENXIO;
goto err;
Re: [PATCH] mtd: sa1100: avoid VLA in sa1100_setup_mtd
Hi Arnd,
On Wed, 10 Oct 2018 20:44:50 +0200
Arnd Bergmann wrote:
> Enabling -Wvla found another variable-length array with randconfig
> testing:
>
> drivers/mtd/maps/sa1100-flash.c: In function 'sa1100_setup_mtd':
> drivers/mtd/maps/sa1100-flash.c:224:10: error: ISO C90 forbids variable
> length array 'cdev' [-Werror=vla]
>
> As far as I can tell, there is an upper bound on the number of resources
> that can be passed, based on the number of CS lines on the bus.
> In practice, all boards we support have either one or two resources,
> but using six to be on the safe side has no extra cost.
Why not dynamically allocate cdev instead? That removes any kind of
guessing on the max value, and it shouldn't hurt much since this code is
in the probe path.
--->8---
diff --git a/drivers/mtd/maps/sa1100-flash.c b/drivers/mtd/maps/sa1100-flash.c
index 784c6e1a0391..fd5fe12d7461 100644
--- a/drivers/mtd/maps/sa1100-flash.c
+++ b/drivers/mtd/maps/sa1100-flash.c
@@ -221,7 +221,14 @@ static struct sa_info *sa1100_setup_mtd(struct
platform_device *pdev,
info->mtd = info->subdev[0].mtd;
ret = 0;
} else if (info->num_subdev > 1) {
- struct mtd_info *cdev[nr];
+ struct mtd_info **cdev;
+
+ cdev = kmalloc_array(nr, sizeof(*cdev), GFP_KERNEL);
+ if (!cdev) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
/*
* We detected multiple devices. Concatenate them together.
*/
@@ -230,6 +237,7 @@ static struct sa_info *sa1100_setup_mtd(struct
platform_device *pdev,
info->mtd = mtd_concat_create(cdev, info->num_subdev,
plat->name);
+ kfree(cdev);
if (info->mtd == NULL) {
ret = -ENXIO;
goto err;
Re: [PATCH 0/3] spi-nor: Add Octal SPI support
Hi Vignesh, On Mon, 8 Oct 2018 21:06:02 +0530 Vignesh R wrote: > Hi Boris, > > Sorry I missed this mail. > > On Thursday 04 October 2018 04:47 PM, Boris Brezillon wrote: > > On Thu, 4 Oct 2018 16:05:36 +0530 > > Vignesh R wrote: > > > >>>> > >>>> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > >>>> drivers/mtd/spi-nor/cadence-quadspi.c | 9 + > >>> > >>> On a slightly different topic, do you plan to convert the Cadence > >>> driver to spi-mem? And if you don't, is it because you don't have time > >>> or because some features are missing in spi-mem (I remember you > >>> mentioned a few things back when you were reviewing the spi-mem series)? > >>> > >> > >> I do not have plans to convert cadence QSPI driver to spi-mem yet, > >> mainly due to lack of time. Also, not sure if original author Marek and > >> other altera people are okay with that. > >> > >> I see couple of issues in the way of conversion: > >> 1. I would wait to know what direction would direct mapping APIs[1] go > >> before starting spi-mem conversion for Cadence QSPI driver. Else, we > >> have may to re write again if direct mapping APIs are merged. > > > > I'd suggest reviewing the proposal I posted so that you can influence > > the design of this new API ;-). > > > > I did take a look and proposal seems fine. Will try to prototype and > test cadence QSPI driver with these. Thanks for the patches! That's great news! Let me know how it goes, and don't hesitate to ask if you have any questions. > > > >> 2. New Cadence OSPI IP has an integrated PHY to support high throughput > >> OSPI flashes operating up 200MHz in Octal DDR mode. In order to work > >> with such flashes, PHY DLLs need to be calibrated. Highly simplified > >> calibration sequence is as below(See [2] for actual sequence): > >> -Read flash ID at low speed and store it. > >> -Enable PHY and set DLLs to a defined initial value > >> -Increment RX DLL value > >> -Read flash ID and check for correctness of data read > >> -repeat above two steps until a band of passing values is obtained for > >> RX DLL where flash ID is correctly read. > >> -DLL needs to set to middle of the passing band. > > > > Is the Read ID operation hardcoded or do you just use it as a way to > > trigger predictable transfers on the IO bus? > > > > Just a way to trigger predictable data reads. Good. > > >> > >> I am trying to figure out how to fit this into the spi-mem framework as > >> controller would to need to store READ ID opcode and expected JEDEC ID > >> before starting calibration sequence. > > > > I think this should be split in 2: > > > > - the SPI NOR framework passing the operation to use to do the > > calibration (here a READ ID) > > - the SPI controller framework replaying the same operation with > > different DLL configs until it finds the best match > > > > So, it would basically be added as a new hook: > > > > int (*calibrate)(struct spi_mem *mem, > > const struct spi_mem_op *tmpl); > > > > and a new function provided by the spi-mem API > > > > int spi_mem_calibrate(struct spi_mem *mem, > > const struct spi_mem_op *tmpl); > > > > and calibration outcome would be somehow attached to the spi_mem > > object. > > > > This way we stay memory agnostic but still provide the necessary blocks > > at the spi-mem level to do such callibrations. > > > > Would that work? > > > > That would work and hopefully is not intrusive to spi-mem framework. > Okay. Don't hesitate to post a proposal along those lines and I'll try to review it. Thanks, Boris
Re: [PATCH 0/3] spi-nor: Add Octal SPI support
Hi Vignesh, On Mon, 8 Oct 2018 21:06:02 +0530 Vignesh R wrote: > Hi Boris, > > Sorry I missed this mail. > > On Thursday 04 October 2018 04:47 PM, Boris Brezillon wrote: > > On Thu, 4 Oct 2018 16:05:36 +0530 > > Vignesh R wrote: > > > >>>> > >>>> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > >>>> drivers/mtd/spi-nor/cadence-quadspi.c | 9 + > >>> > >>> On a slightly different topic, do you plan to convert the Cadence > >>> driver to spi-mem? And if you don't, is it because you don't have time > >>> or because some features are missing in spi-mem (I remember you > >>> mentioned a few things back when you were reviewing the spi-mem series)? > >>> > >> > >> I do not have plans to convert cadence QSPI driver to spi-mem yet, > >> mainly due to lack of time. Also, not sure if original author Marek and > >> other altera people are okay with that. > >> > >> I see couple of issues in the way of conversion: > >> 1. I would wait to know what direction would direct mapping APIs[1] go > >> before starting spi-mem conversion for Cadence QSPI driver. Else, we > >> have may to re write again if direct mapping APIs are merged. > > > > I'd suggest reviewing the proposal I posted so that you can influence > > the design of this new API ;-). > > > > I did take a look and proposal seems fine. Will try to prototype and > test cadence QSPI driver with these. Thanks for the patches! That's great news! Let me know how it goes, and don't hesitate to ask if you have any questions. > > > >> 2. New Cadence OSPI IP has an integrated PHY to support high throughput > >> OSPI flashes operating up 200MHz in Octal DDR mode. In order to work > >> with such flashes, PHY DLLs need to be calibrated. Highly simplified > >> calibration sequence is as below(See [2] for actual sequence): > >> -Read flash ID at low speed and store it. > >> -Enable PHY and set DLLs to a defined initial value > >> -Increment RX DLL value > >> -Read flash ID and check for correctness of data read > >> -repeat above two steps until a band of passing values is obtained for > >> RX DLL where flash ID is correctly read. > >> -DLL needs to set to middle of the passing band. > > > > Is the Read ID operation hardcoded or do you just use it as a way to > > trigger predictable transfers on the IO bus? > > > > Just a way to trigger predictable data reads. Good. > > >> > >> I am trying to figure out how to fit this into the spi-mem framework as > >> controller would to need to store READ ID opcode and expected JEDEC ID > >> before starting calibration sequence. > > > > I think this should be split in 2: > > > > - the SPI NOR framework passing the operation to use to do the > > calibration (here a READ ID) > > - the SPI controller framework replaying the same operation with > > different DLL configs until it finds the best match > > > > So, it would basically be added as a new hook: > > > > int (*calibrate)(struct spi_mem *mem, > > const struct spi_mem_op *tmpl); > > > > and a new function provided by the spi-mem API > > > > int spi_mem_calibrate(struct spi_mem *mem, > > const struct spi_mem_op *tmpl); > > > > and calibration outcome would be somehow attached to the spi_mem > > object. > > > > This way we stay memory agnostic but still provide the necessary blocks > > at the spi-mem level to do such callibrations. > > > > Would that work? > > > > That would work and hopefully is not intrusive to spi-mem framework. > Okay. Don't hesitate to post a proposal along those lines and I'll try to review it. Thanks, Boris
[GIT PULL] mtd: Fix for 4.19-rc8
Hello Greg, Here is a PR containing a fix for a bug introduced in 4.19-rc1. Regards, Boris The following changes since commit 0238df646e6224016a45505d2c111a24669ebe21: Linux 4.19-rc7 (2018-10-07 17:26:02 +0200) are available in the git repository at: git://git.infradead.org/linux-mtd.git tags/mtd/fixes-for-4.19-rc8 for you to fetch changes up to f0fe77f601c3d6a821198f88f7adb0a05b8fe03e: lib/bch: fix possible stack overrun (2018-10-12 09:17:46 +0200) * Fix a stack overflow in lib/bch.c Arnd Bergmann (1): lib/bch: fix possible stack overrun lib/Makefile | 1 - lib/bch.c| 17 + 2 files changed, 13 insertions(+), 5 deletions(-) -- Boris Brezillon, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[GIT PULL] mtd: Fix for 4.19-rc8
Hello Greg, Here is a PR containing a fix for a bug introduced in 4.19-rc1. Regards, Boris The following changes since commit 0238df646e6224016a45505d2c111a24669ebe21: Linux 4.19-rc7 (2018-10-07 17:26:02 +0200) are available in the git repository at: git://git.infradead.org/linux-mtd.git tags/mtd/fixes-for-4.19-rc8 for you to fetch changes up to f0fe77f601c3d6a821198f88f7adb0a05b8fe03e: lib/bch: fix possible stack overrun (2018-10-12 09:17:46 +0200) * Fix a stack overflow in lib/bch.c Arnd Bergmann (1): lib/bch: fix possible stack overrun lib/Makefile | 1 - lib/bch.c| 17 + 2 files changed, 13 insertions(+), 5 deletions(-) -- Boris Brezillon, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v3 1/2] mtd: spi-nor: add macros related to MICRON flash
On Fri, 12 Oct 2018 02:23:08 +
Yogesh Narayan Gaur wrote:
> Some MICRON related macros in spi-nor domain were ST.
> Rename entries related to STMicroelectronics under macro SNOR_MFR_ST.
>
> Added entry of MFR Id for Micron flashes, 0x002C.
>
> Signed-off-by: Yogesh Gaur
> Reviewed-by: Tudor Ambarus
> ---
> Changes for v3:
> - None
> Changes for v2:
> - None
>
> drivers/mtd/spi-nor/spi-nor.c | 9 ++---
> include/linux/mtd/cfi.h | 1 +
> include/linux/mtd/spi-nor.h | 3 ++-
> 3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 9407ca5..b8b494f 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -284,6 +284,7 @@ static inline int set_4byte(struct spi_nor *nor, const
> struct flash_info *info,
> u8 cmd;
>
> switch (JEDEC_MFR(info)) {
> + case SNOR_MFR_ST:
> case SNOR_MFR_MICRON:
> /* Some Micron need WREN command; all will accept it */
> need_wren = true;
> @@ -1388,7 +1389,7 @@ static int spi_nor_is_locked(struct mtd_info *mtd,
> loff_t ofs, uint64_t len)
> { "mx66l1g45g", INFO(0xc2201b, 0, 64 * 1024, 2048, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "mx66l1g55g", INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ)
> },
>
> - /* Micron */
> + /* Micron <--> ST Micro */
> { "n25q016a",INFO(0x20bb15, 0, 64 * 1024, 32, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { "n25q032", INFO(0x20ba16, 0, 64 * 1024, 64, SPI_NOR_QUAD_READ)
> },
> { "n25q032a",INFO(0x20bb16, 0, 64 * 1024, 64, SPI_NOR_QUAD_READ)
> },
> @@ -3223,6 +3224,7 @@ static int spi_nor_init_params(struct spi_nor *nor,
> params->quad_enable = macronix_quad_enable;
> break;
>
> + case SNOR_MFR_ST:
> case SNOR_MFR_MICRON:
> break;
>
> @@ -3671,8 +3673,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> mtd->_resume = spi_nor_resume;
>
> /* NOR protection support for STmicro/Micron chips and similar */
> - if (JEDEC_MFR(info) == SNOR_MFR_MICRON ||
> - info->flags & SPI_NOR_HAS_LOCK) {
> + if (JEDEC_MFR(info) == SNOR_MFR_ST ||
> + JEDEC_MFR(info) == SNOR_MFR_MICRON ||
> + info->flags & SPI_NOR_HAS_LOCK) {
> nor->flash_lock = stm_lock;
> nor->flash_unlock = stm_unlock;
> nor->flash_is_locked = stm_is_locked;
Are you sure ST and Micron NORs work the same way WRT locking, 4-byte
addressing mode and Quad enable?
> diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
> index 9b57a9b..cbf7716 100644
> --- a/include/linux/mtd/cfi.h
> +++ b/include/linux/mtd/cfi.h
> @@ -377,6 +377,7 @@ struct cfi_fixup {
> #define CFI_MFR_SHARP0x00B0
> #define CFI_MFR_SST 0x00BF
> #define CFI_MFR_ST 0x0020 /* STMicroelectronics */
> +#define CFI_MFR_MICRON 0x002C /* Micron */
> #define CFI_MFR_TOSHIBA 0x0098
> #define CFI_MFR_WINBOND 0x00DA
>
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 7f0c730..8b1acf6 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -23,7 +23,8 @@
> #define SNOR_MFR_ATMEL CFI_MFR_ATMEL
> #define SNOR_MFR_GIGADEVICE 0xc8
> #define SNOR_MFR_INTEL CFI_MFR_INTEL
> -#define SNOR_MFR_MICRON CFI_MFR_ST /* ST Micro <--> Micron */
> +#define SNOR_MFR_ST CFI_MFR_ST /* ST Micro */
> +#define SNOR_MFR_MICRON CFI_MFR_MICRON /* Micron */
> #define SNOR_MFR_MACRONIXCFI_MFR_MACRONIX
> #define SNOR_MFR_SPANSIONCFI_MFR_AMD
> #define SNOR_MFR_SST CFI_MFR_SST
Re: [PATCH v3 1/2] mtd: spi-nor: add macros related to MICRON flash
On Fri, 12 Oct 2018 02:23:08 +
Yogesh Narayan Gaur wrote:
> Some MICRON related macros in spi-nor domain were ST.
> Rename entries related to STMicroelectronics under macro SNOR_MFR_ST.
>
> Added entry of MFR Id for Micron flashes, 0x002C.
>
> Signed-off-by: Yogesh Gaur
> Reviewed-by: Tudor Ambarus
> ---
> Changes for v3:
> - None
> Changes for v2:
> - None
>
> drivers/mtd/spi-nor/spi-nor.c | 9 ++---
> include/linux/mtd/cfi.h | 1 +
> include/linux/mtd/spi-nor.h | 3 ++-
> 3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 9407ca5..b8b494f 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -284,6 +284,7 @@ static inline int set_4byte(struct spi_nor *nor, const
> struct flash_info *info,
> u8 cmd;
>
> switch (JEDEC_MFR(info)) {
> + case SNOR_MFR_ST:
> case SNOR_MFR_MICRON:
> /* Some Micron need WREN command; all will accept it */
> need_wren = true;
> @@ -1388,7 +1389,7 @@ static int spi_nor_is_locked(struct mtd_info *mtd,
> loff_t ofs, uint64_t len)
> { "mx66l1g45g", INFO(0xc2201b, 0, 64 * 1024, 2048, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "mx66l1g55g", INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ)
> },
>
> - /* Micron */
> + /* Micron <--> ST Micro */
> { "n25q016a",INFO(0x20bb15, 0, 64 * 1024, 32, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { "n25q032", INFO(0x20ba16, 0, 64 * 1024, 64, SPI_NOR_QUAD_READ)
> },
> { "n25q032a",INFO(0x20bb16, 0, 64 * 1024, 64, SPI_NOR_QUAD_READ)
> },
> @@ -3223,6 +3224,7 @@ static int spi_nor_init_params(struct spi_nor *nor,
> params->quad_enable = macronix_quad_enable;
> break;
>
> + case SNOR_MFR_ST:
> case SNOR_MFR_MICRON:
> break;
>
> @@ -3671,8 +3673,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> mtd->_resume = spi_nor_resume;
>
> /* NOR protection support for STmicro/Micron chips and similar */
> - if (JEDEC_MFR(info) == SNOR_MFR_MICRON ||
> - info->flags & SPI_NOR_HAS_LOCK) {
> + if (JEDEC_MFR(info) == SNOR_MFR_ST ||
> + JEDEC_MFR(info) == SNOR_MFR_MICRON ||
> + info->flags & SPI_NOR_HAS_LOCK) {
> nor->flash_lock = stm_lock;
> nor->flash_unlock = stm_unlock;
> nor->flash_is_locked = stm_is_locked;
Are you sure ST and Micron NORs work the same way WRT locking, 4-byte
addressing mode and Quad enable?
> diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
> index 9b57a9b..cbf7716 100644
> --- a/include/linux/mtd/cfi.h
> +++ b/include/linux/mtd/cfi.h
> @@ -377,6 +377,7 @@ struct cfi_fixup {
> #define CFI_MFR_SHARP0x00B0
> #define CFI_MFR_SST 0x00BF
> #define CFI_MFR_ST 0x0020 /* STMicroelectronics */
> +#define CFI_MFR_MICRON 0x002C /* Micron */
> #define CFI_MFR_TOSHIBA 0x0098
> #define CFI_MFR_WINBOND 0x00DA
>
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 7f0c730..8b1acf6 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -23,7 +23,8 @@
> #define SNOR_MFR_ATMEL CFI_MFR_ATMEL
> #define SNOR_MFR_GIGADEVICE 0xc8
> #define SNOR_MFR_INTEL CFI_MFR_INTEL
> -#define SNOR_MFR_MICRON CFI_MFR_ST /* ST Micro <--> Micron */
> +#define SNOR_MFR_ST CFI_MFR_ST /* ST Micro */
> +#define SNOR_MFR_MICRON CFI_MFR_MICRON /* Micron */
> #define SNOR_MFR_MACRONIXCFI_MFR_MACRONIX
> #define SNOR_MFR_SPANSIONCFI_MFR_AMD
> #define SNOR_MFR_SST CFI_MFR_SST
Re: [PATCH 3/4] drm/v3d: Add some better documentation of the in_sync arguments.
On Fri, 28 Sep 2018 16:21:25 -0700
Eric Anholt wrote:
> Since this is UAPI, it's good to document what exactly the guarantees
> we're providing are.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> include/uapi/drm/v3d_drm.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/uapi/drm/v3d_drm.h b/include/uapi/drm/v3d_drm.h
> index 7b6627783608..f446656d00b1 100644
> --- a/include/uapi/drm/v3d_drm.h
> +++ b/include/uapi/drm/v3d_drm.h
> @@ -58,6 +58,11 @@ struct drm_v3d_submit_cl {
>* coordinate shader to determine where primitives land on the screen,
>* then writes out the state updates and draw calls necessary per tile
>* to the tile allocation BO.
> + *
> + * This BCL will block on any previous BCL submitted on the
> + * same FD, but not on any RCL or BCLs submitted by other
> + * clients -- that is left up to the submitter to control
> + * using in_sync_bcl if necessary.
>*/
> __u32 bcl_start;
>
> @@ -69,6 +74,11 @@ struct drm_v3d_submit_cl {
>* This is the second set of commands executed, which will either
>* execute the tiles that have been set up by the BCL, or a fixed set
>* of tiles (in the case of RCL-only blits).
> + *
> + * This RCL will block on this submit's BCL, and any previous
> + * RCL submitted on the same FD, but not on any RCL or BCLs
> + * submitted by other clients -- that is left up to the
> + * submitter to control using in_sync_rcl if necessary.
>*/
> __u32 rcl_start;
>
Re: [PATCH 3/4] drm/v3d: Add some better documentation of the in_sync arguments.
On Fri, 28 Sep 2018 16:21:25 -0700
Eric Anholt wrote:
> Since this is UAPI, it's good to document what exactly the guarantees
> we're providing are.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> include/uapi/drm/v3d_drm.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/uapi/drm/v3d_drm.h b/include/uapi/drm/v3d_drm.h
> index 7b6627783608..f446656d00b1 100644
> --- a/include/uapi/drm/v3d_drm.h
> +++ b/include/uapi/drm/v3d_drm.h
> @@ -58,6 +58,11 @@ struct drm_v3d_submit_cl {
>* coordinate shader to determine where primitives land on the screen,
>* then writes out the state updates and draw calls necessary per tile
>* to the tile allocation BO.
> + *
> + * This BCL will block on any previous BCL submitted on the
> + * same FD, but not on any RCL or BCLs submitted by other
> + * clients -- that is left up to the submitter to control
> + * using in_sync_bcl if necessary.
>*/
> __u32 bcl_start;
>
> @@ -69,6 +74,11 @@ struct drm_v3d_submit_cl {
>* This is the second set of commands executed, which will either
>* execute the tiles that have been set up by the BCL, or a fixed set
>* of tiles (in the case of RCL-only blits).
> + *
> + * This RCL will block on this submit's BCL, and any previous
> + * RCL submitted on the same FD, but not on any RCL or BCLs
> + * submitted by other clients -- that is left up to the
> + * submitter to control using in_sync_rcl if necessary.
>*/
> __u32 rcl_start;
>
Re: [PATCH 2/4] drm/v3d: Add a little debugfs entry for measuring the core clock.
On Fri, 28 Sep 2018 16:21:24 -0700
Eric Anholt wrote:
> This adds just enough performance counter support to measure the
> clock. We don't have linux kernel drivers for the clock driving the
> HW, and this was useful for determining that the V3D HW is running on
> a slow clock, not that the driver was slow.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/v3d/v3d_debugfs.c | 35 +++
> drivers/gpu/drm/v3d/v3d_regs.h| 30 ++
> 2 files changed, 65 insertions(+)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
> b/drivers/gpu/drm/v3d/v3d_debugfs.c
> index 4db62c545748..d48008adb085 100644
> --- a/drivers/gpu/drm/v3d/v3d_debugfs.c
> +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
> @@ -176,9 +176,44 @@ static int v3d_debugfs_bo_stats(struct seq_file *m, void
> *unused)
> return 0;
> }
>
> +static int v3d_measure_clock(struct seq_file *m, void *unused)
> +{
> + struct drm_info_node *node = (struct drm_info_node *)m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct v3d_dev *v3d = to_v3d_dev(dev);
> + uint32_t cycles;
> + int core = 0;
> + int measure_ms = 1000;
> +
> + if (v3d->ver >= 40) {
> + V3D_CORE_WRITE(core, V3D_V4_PCTR_0_SRC_0_3,
> +V3D_SET_FIELD(V3D_PCTR_CYCLE_COUNT,
> + V3D_PCTR_S0));
> + V3D_CORE_WRITE(core, V3D_V4_PCTR_0_CLR, 1);
> + V3D_CORE_WRITE(core, V3D_V4_PCTR_0_EN, 1);
> + } else {
> + V3D_CORE_WRITE(core, V3D_V3_PCTR_0_PCTRS0,
> +V3D_PCTR_CYCLE_COUNT);
> + V3D_CORE_WRITE(core, V3D_V3_PCTR_0_CLR, 1);
> + V3D_CORE_WRITE(core, V3D_V3_PCTR_0_EN,
> +V3D_V3_PCTR_0_EN_ENABLE |
> +1);
> + }
> + msleep(measure_ms);
> + cycles = V3D_CORE_READ(core, V3D_PCTR_0_PCTR0);
> +
> + seq_printf(m, "cycles: %d (%d.%d Mhz)\n",
> +cycles,
> +cycles / (measure_ms * 1000),
> +(cycles / (measure_ms * 100)) % 10);
> +
> + return 0;
> +}
> +
> static const struct drm_info_list v3d_debugfs_list[] = {
> {"v3d_ident", v3d_v3d_debugfs_ident, 0},
> {"v3d_regs", v3d_v3d_debugfs_regs, 0},
> + {"measure_clock", v3d_measure_clock, 0},
> {"bo_stats", v3d_debugfs_bo_stats, 0},
> };
>
> diff --git a/drivers/gpu/drm/v3d/v3d_regs.h b/drivers/gpu/drm/v3d/v3d_regs.h
> index 854046565989..c3a5e4e44f73 100644
> --- a/drivers/gpu/drm/v3d/v3d_regs.h
> +++ b/drivers/gpu/drm/v3d/v3d_regs.h
> @@ -267,6 +267,36 @@
> # define V3D_PTB_BXCF_RWORDERDISA BIT(1)
> # define V3D_PTB_BXCF_CLIPDISA BIT(0)
>
> +#define V3D_V3_PCTR_0_EN 0x00674
> +#define V3D_V3_PCTR_0_EN_ENABLEBIT(31)
> +#define V3D_V4_PCTR_0_EN 0x00650
> +/* When a bit is set, resets the counter to 0. */
> +#define V3D_V3_PCTR_0_CLR 0x00670
> +#define V3D_V4_PCTR_0_CLR 0x00654
> +#define V3D_PCTR_0_OVERFLOW0x00658
> +
> +#define V3D_V3_PCTR_0_PCTRS0 0x00684
> +#define V3D_V3_PCTR_0_PCTRS15 0x00660
> +#define V3D_V3_PCTR_0_PCTRSX(x)(V3D_V3_PCTR_0_PCTRS0
> + \
> + 4 * (x))
> +/* Each src reg muxes four counters each. */
> +#define V3D_V4_PCTR_0_SRC_0_3 0x00660
> +#define V3D_V4_PCTR_0_SRC_28_310x0067c
> +# define V3D_PCTR_S0_MASK V3D_MASK(6, 0)
> +# define V3D_PCTR_S0_SHIFT 0
> +# define V3D_PCTR_S1_MASK V3D_MASK(14, 8)
> +# define V3D_PCTR_S1_SHIFT 8
> +# define V3D_PCTR_S2_MASK V3D_MASK(22, 16)
> +# define V3D_PCTR_S2_SHIFT 16
> +# define V3D_PCTR_S3_MASK V3D_MASK(30, 24)
> +# define V3D_PCTR_S3_SHIFT 24
> +# define V3D_PCTR_CYCLE_COUNT 32
> +
> +/* Output values of the counters. */
> +#define V3D_PCTR_0_PCTR0 0x00680
> +#define V3D_PCTR_0_PCTR31 0x006fc
> +#define V3D_PCTR_0_PCTRX(x)(V3D_PCTR_0_PCTR0 + \
> + 4 * (x))
> #define V3D_GMP_STATUS 0x00800
> # define V3D_GMP_STATUS_GMPRST BIT(31)
> # define V3D_GMP_STATUS_WR_COUNT_MASK V3D_MASK(30, 24)
Re: [PATCH 2/4] drm/v3d: Add a little debugfs entry for measuring the core clock.
On Fri, 28 Sep 2018 16:21:24 -0700
Eric Anholt wrote:
> This adds just enough performance counter support to measure the
> clock. We don't have linux kernel drivers for the clock driving the
> HW, and this was useful for determining that the V3D HW is running on
> a slow clock, not that the driver was slow.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/v3d/v3d_debugfs.c | 35 +++
> drivers/gpu/drm/v3d/v3d_regs.h| 30 ++
> 2 files changed, 65 insertions(+)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
> b/drivers/gpu/drm/v3d/v3d_debugfs.c
> index 4db62c545748..d48008adb085 100644
> --- a/drivers/gpu/drm/v3d/v3d_debugfs.c
> +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
> @@ -176,9 +176,44 @@ static int v3d_debugfs_bo_stats(struct seq_file *m, void
> *unused)
> return 0;
> }
>
> +static int v3d_measure_clock(struct seq_file *m, void *unused)
> +{
> + struct drm_info_node *node = (struct drm_info_node *)m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct v3d_dev *v3d = to_v3d_dev(dev);
> + uint32_t cycles;
> + int core = 0;
> + int measure_ms = 1000;
> +
> + if (v3d->ver >= 40) {
> + V3D_CORE_WRITE(core, V3D_V4_PCTR_0_SRC_0_3,
> +V3D_SET_FIELD(V3D_PCTR_CYCLE_COUNT,
> + V3D_PCTR_S0));
> + V3D_CORE_WRITE(core, V3D_V4_PCTR_0_CLR, 1);
> + V3D_CORE_WRITE(core, V3D_V4_PCTR_0_EN, 1);
> + } else {
> + V3D_CORE_WRITE(core, V3D_V3_PCTR_0_PCTRS0,
> +V3D_PCTR_CYCLE_COUNT);
> + V3D_CORE_WRITE(core, V3D_V3_PCTR_0_CLR, 1);
> + V3D_CORE_WRITE(core, V3D_V3_PCTR_0_EN,
> +V3D_V3_PCTR_0_EN_ENABLE |
> +1);
> + }
> + msleep(measure_ms);
> + cycles = V3D_CORE_READ(core, V3D_PCTR_0_PCTR0);
> +
> + seq_printf(m, "cycles: %d (%d.%d Mhz)\n",
> +cycles,
> +cycles / (measure_ms * 1000),
> +(cycles / (measure_ms * 100)) % 10);
> +
> + return 0;
> +}
> +
> static const struct drm_info_list v3d_debugfs_list[] = {
> {"v3d_ident", v3d_v3d_debugfs_ident, 0},
> {"v3d_regs", v3d_v3d_debugfs_regs, 0},
> + {"measure_clock", v3d_measure_clock, 0},
> {"bo_stats", v3d_debugfs_bo_stats, 0},
> };
>
> diff --git a/drivers/gpu/drm/v3d/v3d_regs.h b/drivers/gpu/drm/v3d/v3d_regs.h
> index 854046565989..c3a5e4e44f73 100644
> --- a/drivers/gpu/drm/v3d/v3d_regs.h
> +++ b/drivers/gpu/drm/v3d/v3d_regs.h
> @@ -267,6 +267,36 @@
> # define V3D_PTB_BXCF_RWORDERDISA BIT(1)
> # define V3D_PTB_BXCF_CLIPDISA BIT(0)
>
> +#define V3D_V3_PCTR_0_EN 0x00674
> +#define V3D_V3_PCTR_0_EN_ENABLEBIT(31)
> +#define V3D_V4_PCTR_0_EN 0x00650
> +/* When a bit is set, resets the counter to 0. */
> +#define V3D_V3_PCTR_0_CLR 0x00670
> +#define V3D_V4_PCTR_0_CLR 0x00654
> +#define V3D_PCTR_0_OVERFLOW0x00658
> +
> +#define V3D_V3_PCTR_0_PCTRS0 0x00684
> +#define V3D_V3_PCTR_0_PCTRS15 0x00660
> +#define V3D_V3_PCTR_0_PCTRSX(x)(V3D_V3_PCTR_0_PCTRS0
> + \
> + 4 * (x))
> +/* Each src reg muxes four counters each. */
> +#define V3D_V4_PCTR_0_SRC_0_3 0x00660
> +#define V3D_V4_PCTR_0_SRC_28_310x0067c
> +# define V3D_PCTR_S0_MASK V3D_MASK(6, 0)
> +# define V3D_PCTR_S0_SHIFT 0
> +# define V3D_PCTR_S1_MASK V3D_MASK(14, 8)
> +# define V3D_PCTR_S1_SHIFT 8
> +# define V3D_PCTR_S2_MASK V3D_MASK(22, 16)
> +# define V3D_PCTR_S2_SHIFT 16
> +# define V3D_PCTR_S3_MASK V3D_MASK(30, 24)
> +# define V3D_PCTR_S3_SHIFT 24
> +# define V3D_PCTR_CYCLE_COUNT 32
> +
> +/* Output values of the counters. */
> +#define V3D_PCTR_0_PCTR0 0x00680
> +#define V3D_PCTR_0_PCTR31 0x006fc
> +#define V3D_PCTR_0_PCTRX(x)(V3D_PCTR_0_PCTR0 + \
> + 4 * (x))
> #define V3D_GMP_STATUS 0x00800
> # define V3D_GMP_STATUS_GMPRST BIT(31)
> # define V3D_GMP_STATUS_WR_COUNT_MASK V3D_MASK(30, 24)
Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw function
On Tue, 9 Oct 2018 09:52:23 + Chuanhua Han wrote: > 1. In the dspi driver (spi controller), bits_per_word > (dspi->bits_per_word = transfer->bits_per_word) passed from the upper > layer (spi-mem.c) is used. In this way, I can only assign the > appropriate value of transfer->bits_per_word before passing to the > controller, that is, the controller driver does not know the value of > bits_per_word, and it will use this value when the upper level sets > what value is passed. I think you're missing my point: ->bits_per_word is not what you're looking for if what you're trying to do is use 32-bits accesses when things are properly aligned. > 2. As I understand, bits_per_word does not > exist for non-byte alignment, but for the need to reserve non-byte > transmission mode that meets the controller. Exactly. It's an optimization you have to take care of inside your driver. The core cannot help you with that. > 3. In addition, now the > XSPI of dspi cannot transfer data normally, so this problem needs to > be solved. I still don't understand what the problem is. > As for the DMA transfer mode, some colleagues will study > it.
Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw function
On Tue, 9 Oct 2018 09:52:23 + Chuanhua Han wrote: > 1. In the dspi driver (spi controller), bits_per_word > (dspi->bits_per_word = transfer->bits_per_word) passed from the upper > layer (spi-mem.c) is used. In this way, I can only assign the > appropriate value of transfer->bits_per_word before passing to the > controller, that is, the controller driver does not know the value of > bits_per_word, and it will use this value when the upper level sets > what value is passed. I think you're missing my point: ->bits_per_word is not what you're looking for if what you're trying to do is use 32-bits accesses when things are properly aligned. > 2. As I understand, bits_per_word does not > exist for non-byte alignment, but for the need to reserve non-byte > transmission mode that meets the controller. Exactly. It's an optimization you have to take care of inside your driver. The core cannot help you with that. > 3. In addition, now the > XSPI of dspi cannot transfer data normally, so this problem needs to > be solved. I still don't understand what the problem is. > As for the DMA transfer mode, some colleagues will study > it.
Re: [PATCH v4 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
On Mon, 8 Oct 2018 16:41:39 +0530 Yogesh Gaur wrote: > +/* Registers used by the driver */ > +#define FSPI_MCR00x00 > +#define FSPI_MCR0_AHB_TIMEOUT_MASK GENMASK(31, 24) > +#define FSPI_MCR0_IP_TIMEOUT_MASKGENMASK(23, 16) You never mask the IP_TIMEOUT val, so you don't need a _MASK macro here. Just define #define FSPI_MCR0_IP_TIMEOUT(x) ((x) < 16) The same goes for any field that you don't need to mask. The only case you might need a mask def is when you have the following pattern: val = readl(reg); val &= ~_MASK; val |= (new_field_val); writel(val, reg); > +#define FSPI_MCR0_LEARN_EN_MASK BIT(15) > +#define FSPI_MCR0_SCRFRUN_EN_MASKBIT(14) > +#define FSPI_MCR0_OCTCOMB_EN_MASKBIT(13) Drop the _MASK suffix for any single-bit field: #define FSPI_MCR0_OCTCOMB_ENBIT(13)
Re: [PATCH v4 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
On Mon, 8 Oct 2018 16:41:39 +0530 Yogesh Gaur wrote: > +/* Registers used by the driver */ > +#define FSPI_MCR00x00 > +#define FSPI_MCR0_AHB_TIMEOUT_MASK GENMASK(31, 24) > +#define FSPI_MCR0_IP_TIMEOUT_MASKGENMASK(23, 16) You never mask the IP_TIMEOUT val, so you don't need a _MASK macro here. Just define #define FSPI_MCR0_IP_TIMEOUT(x) ((x) < 16) The same goes for any field that you don't need to mask. The only case you might need a mask def is when you have the following pattern: val = readl(reg); val &= ~_MASK; val |= (new_field_val); writel(val, reg); > +#define FSPI_MCR0_LEARN_EN_MASK BIT(15) > +#define FSPI_MCR0_SCRFRUN_EN_MASKBIT(14) > +#define FSPI_MCR0_OCTCOMB_EN_MASKBIT(13) Drop the _MASK suffix for any single-bit field: #define FSPI_MCR0_OCTCOMB_ENBIT(13)
Re: [PATCH v3 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
On Mon, 8 Oct 2018 11:21:13 +
Yogesh Narayan Gaur wrote:
> > > +static void nxp_fspi_read_ahb(struct nxp_fspi *f, const struct
> > > +spi_mem_op *op) {
> > > + u32 len = op->data.nbytes;
> > > +
> > > + /* Read out the data directly from the AHB buffer. */
> > > + memcpy_fromio(op->data.buf.in, (f->ahb_addr + op->addr.val), len);
> >
> > Don't know if it's supported, but if it is, I recommend using DMA to do
> > this copy,
> > because otherwise you might stall the CPU for quite a long time if the
> > flash is
> > operating in a low-speed mode, and RT maintainers will complain about that
> > at
> > some point ;-).
> >
> Read using DMA is not supported by the controller in AHB mode, only supported
> in IP mode.
> Have to use memcpy_fromio() calls. Maximum data size can be read in single
> call is 0x800 using AHB read.
>
Still, blocking the CPU until the SPI controller has read 0x800 bytes
is enough to make you miss a real-time deadline. Don't you have a
controller that supports mem2mem transfers (I'm pretty sure a mem2mem
DMA transfer would do the trick here)?
Regards,
Boris
Re: [PATCH v3 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
On Mon, 8 Oct 2018 11:21:13 +
Yogesh Narayan Gaur wrote:
> > > +static void nxp_fspi_read_ahb(struct nxp_fspi *f, const struct
> > > +spi_mem_op *op) {
> > > + u32 len = op->data.nbytes;
> > > +
> > > + /* Read out the data directly from the AHB buffer. */
> > > + memcpy_fromio(op->data.buf.in, (f->ahb_addr + op->addr.val), len);
> >
> > Don't know if it's supported, but if it is, I recommend using DMA to do
> > this copy,
> > because otherwise you might stall the CPU for quite a long time if the
> > flash is
> > operating in a low-speed mode, and RT maintainers will complain about that
> > at
> > some point ;-).
> >
> Read using DMA is not supported by the controller in AHB mode, only supported
> in IP mode.
> Have to use memcpy_fromio() calls. Maximum data size can be read in single
> call is 0x800 using AHB read.
>
Still, blocking the CPU until the SPI controller has read 0x800 bytes
is enough to make you miss a real-time deadline. Don't you have a
controller that supports mem2mem transfers (I'm pretty sure a mem2mem
DMA transfer would do the trick here)?
Regards,
Boris
Re: [PATCH v10 10/10] mtd: maps: gpio-addr-flash: Add support for device-tree devices
On Mon, 8 Oct 2018 09:40:09 +0200 Ricardo Ribalda Delgado wrote: > Hi Boris > On Fri, Oct 5, 2018 at 9:32 PM Boris Brezillon > wrote: > > > > On Fri, 5 Oct 2018 20:12:43 +0200 > > Ricardo Ribalda Delgado wrote: > > > > > > > > I think I know what might be the issue. on cfi_cmdset_002.c > > > cfi_amdstd_reset can be called in parrallel to cfi_amdstd_destroy. > > > > > > maybe we should call > > > unregister_reboot_notifier(>reboot_notifier); > > > before > > > cfi_amdstd_reset(mtd) > > > > > > need to try that on real hw with some strategical printfs :P. But that > > > will ahve to wait til Monday > > > > No problem, nothing urgent here. Have a nice weekend. > > Just updated my kernel version (4.14.53 -> 4.14.69) with you last > github and I do not see the crash anymore. So I guess we are good to > go. Okay, I'll try to send the patch series. Don't hesitate to ping me if I forget. Thanks, Boris
Re: [PATCH v10 10/10] mtd: maps: gpio-addr-flash: Add support for device-tree devices
On Mon, 8 Oct 2018 09:40:09 +0200 Ricardo Ribalda Delgado wrote: > Hi Boris > On Fri, Oct 5, 2018 at 9:32 PM Boris Brezillon > wrote: > > > > On Fri, 5 Oct 2018 20:12:43 +0200 > > Ricardo Ribalda Delgado wrote: > > > > > > > > I think I know what might be the issue. on cfi_cmdset_002.c > > > cfi_amdstd_reset can be called in parrallel to cfi_amdstd_destroy. > > > > > > maybe we should call > > > unregister_reboot_notifier(>reboot_notifier); > > > before > > > cfi_amdstd_reset(mtd) > > > > > > need to try that on real hw with some strategical printfs :P. But that > > > will ahve to wait til Monday > > > > No problem, nothing urgent here. Have a nice weekend. > > Just updated my kernel version (4.14.53 -> 4.14.69) with you last > github and I do not see the crash anymore. So I guess we are good to > go. Okay, I'll try to send the patch series. Don't hesitate to ping me if I forget. Thanks, Boris
Re: [PATCH v4 1/2] spi: Add MXIC controller driver
Hi Mason,
On Mon, 8 Oct 2018 10:25:31 +0800
masonccy...@mxic.com.tw wrote:
> +static int mxic_spi_clk_enable(struct mxic_spi *mxic)
> +{
> + int ret;
> +
> + ret = clk_prepare_enable(mxic->send_clk);
> + if (ret)
> + goto out;
Please don't use gotos when it's not necessary, just do
return ret;
> +
> + ret = clk_prepare_enable(mxic->send_dly_clk);
> + if (ret)
> + goto err_send_dly_clk;
> +
> + return ret;
> +
> +err_send_dly_clk:
> + clk_disable_unprepare(mxic->send_clk);
> +out:
and you can get rid of the out label.
> + return ret;
> +}
> +
> +static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> + const struct spi_mem_op *op)
> +{
> + struct spi_master *master = spi_master_get(mem->spi->master);
> + struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
> + int nio = 1, i, ret;
> + u32 ss_ctrl;
> + u8 addr[8];
> +
> + if (master->prepare_transfer_hardware)
> + master->prepare_transfer_hardware(master);
Move the mxic_prepare_transfer_hardware() at the top of the file and
call it directly from there.
> +
> + if (mem->spi->mode & (SPI_TX_QUAD | SPI_RX_QUAD))
> + nio = 4;
> + else if (mem->spi->mode & (SPI_TX_DUAL | SPI_RX_DUAL))
> + nio = 2;
> +
> + writel(HC_CFG_NIO(nio) |
> +HC_CFG_TYPE(mem->spi->chip_select, HC_CFG_TYPE_SPI_NOR) |
> +HC_CFG_SLV_ACT(mem->spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1) |
> +HC_CFG_MAN_CS_EN,
> +mxic->regs + HC_CFG);
> + writel(HC_EN_BIT, mxic->regs + HC_EN);
> +
> + ss_ctrl = OP_CMD_BYTES(1) | OP_CMD_BUSW(fls(op->cmd.buswidth) - 1);
> +
> + if (op->addr.nbytes)
> + ss_ctrl |= OP_ADDR_BYTES(op->addr.nbytes) |
> +OP_ADDR_BUSW(fls(op->addr.buswidth) - 1);
> +
> + if (op->dummy.nbytes)
> + ss_ctrl |= OP_DUMMY_CYC(op->dummy.nbytes);
> +
> + if (op->data.nbytes) {
> + ss_ctrl |= OP_DATA_BUSW(fls(op->data.buswidth) - 1);
> + if (op->data.dir == SPI_MEM_DATA_IN)
> + ss_ctrl |= OP_READ;
> + }
> +
> + writel(ss_ctrl, mxic->regs + SS_CTRL(mem->spi->chip_select));
> +
> + writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
> +mxic->regs + HC_CFG);
> +
> + ret = mxic_spi_data_xfer(mxic, >cmd.opcode, NULL, 1);
> + if (ret)
> + goto out;
> +
> + for (i = 0; i < op->addr.nbytes; i++)
> + addr[i] = op->addr.val >> (8 * (op->addr.nbytes - i - 1));
> +
> + ret = mxic_spi_data_xfer(mxic, addr, NULL, op->addr.nbytes);
> + if (ret)
> + goto out;
> +
> + ret = mxic_spi_data_xfer(mxic, NULL, NULL, op->dummy.nbytes);
> + if (ret)
> + goto out;
> +
> + ret = mxic_spi_data_xfer(mxic,
> + op->data.dir == SPI_MEM_DATA_OUT ?
> + op->data.buf.out : NULL,
> + op->data.dir == SPI_MEM_DATA_IN ?
> + op->data.buf.in : NULL,
> + op->data.nbytes);
> +
> +out:
> + writel(readl(mxic->regs + HC_CFG) & ~HC_CFG_MAN_CS_ASSERT,
> +mxic->regs + HC_CFG);
> + writel(0, mxic->regs + HC_EN);
> +
> + return ret;
> +}
[...]
> +
> +static int mxic_spi_setup(struct spi_device *spi)
> +{
> + struct mxic_spi *mxic = spi_master_get_devdata(spi->master);
> +
> + mxic->cur_speed_hz = spi->max_speed_hz;
This is wrong, ->cur_speed_hz should be updated in
mxic_prepare_transfer_hardware() or mxic_spi_clk_check(), not when
->setup() is called. Also, you seem to ignore the xfer->speed_hz value,
which might be different from spi->max_speed_hz. Maybe the
->prepare_transfer() hook is not the right place to do this
->cur_speed_hz selection in the end.
Can you instead create the following function:
static int mxic_spi_set_freq(struct mxic_spi *mxic, unsigned long freq)
{
if (mxic->cur_speed_hz == freq)
return 0;
mxic_spi_clk_disable(mxic);
ret = mxic_spi_clk_setup(mxic, master->max_speed_hz);
if (ret)
return ret;
ret = mxic_spi_clk_enable(mxic);
if (ret)
return ret;
mxic->cur_speed_hz = freq;
return 0;
}
and then call it from mxic_spi_transfer_one() and
mxic_spi_mem_exec_op():
static int mxic_spi_mem_exec_op(struct spi_mem *mem,
const struct spi_mem_op *op)
{
...
ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
...
}
static int mxic_spi_transfer_one(struct spi_master *master,
struct spi_device *spi,
struct spi_transfer *t)
{
...
ret = mxic_spi_set_freq(mxic, t->speed_hz);
...
}
> +
> + return 0;
> +}
> +
[...]
> +
> +static int
Re: [PATCH v4 1/2] spi: Add MXIC controller driver
Hi Mason,
On Mon, 8 Oct 2018 10:25:31 +0800
masonccy...@mxic.com.tw wrote:
> +static int mxic_spi_clk_enable(struct mxic_spi *mxic)
> +{
> + int ret;
> +
> + ret = clk_prepare_enable(mxic->send_clk);
> + if (ret)
> + goto out;
Please don't use gotos when it's not necessary, just do
return ret;
> +
> + ret = clk_prepare_enable(mxic->send_dly_clk);
> + if (ret)
> + goto err_send_dly_clk;
> +
> + return ret;
> +
> +err_send_dly_clk:
> + clk_disable_unprepare(mxic->send_clk);
> +out:
and you can get rid of the out label.
> + return ret;
> +}
> +
> +static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> + const struct spi_mem_op *op)
> +{
> + struct spi_master *master = spi_master_get(mem->spi->master);
> + struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
> + int nio = 1, i, ret;
> + u32 ss_ctrl;
> + u8 addr[8];
> +
> + if (master->prepare_transfer_hardware)
> + master->prepare_transfer_hardware(master);
Move the mxic_prepare_transfer_hardware() at the top of the file and
call it directly from there.
> +
> + if (mem->spi->mode & (SPI_TX_QUAD | SPI_RX_QUAD))
> + nio = 4;
> + else if (mem->spi->mode & (SPI_TX_DUAL | SPI_RX_DUAL))
> + nio = 2;
> +
> + writel(HC_CFG_NIO(nio) |
> +HC_CFG_TYPE(mem->spi->chip_select, HC_CFG_TYPE_SPI_NOR) |
> +HC_CFG_SLV_ACT(mem->spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1) |
> +HC_CFG_MAN_CS_EN,
> +mxic->regs + HC_CFG);
> + writel(HC_EN_BIT, mxic->regs + HC_EN);
> +
> + ss_ctrl = OP_CMD_BYTES(1) | OP_CMD_BUSW(fls(op->cmd.buswidth) - 1);
> +
> + if (op->addr.nbytes)
> + ss_ctrl |= OP_ADDR_BYTES(op->addr.nbytes) |
> +OP_ADDR_BUSW(fls(op->addr.buswidth) - 1);
> +
> + if (op->dummy.nbytes)
> + ss_ctrl |= OP_DUMMY_CYC(op->dummy.nbytes);
> +
> + if (op->data.nbytes) {
> + ss_ctrl |= OP_DATA_BUSW(fls(op->data.buswidth) - 1);
> + if (op->data.dir == SPI_MEM_DATA_IN)
> + ss_ctrl |= OP_READ;
> + }
> +
> + writel(ss_ctrl, mxic->regs + SS_CTRL(mem->spi->chip_select));
> +
> + writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
> +mxic->regs + HC_CFG);
> +
> + ret = mxic_spi_data_xfer(mxic, >cmd.opcode, NULL, 1);
> + if (ret)
> + goto out;
> +
> + for (i = 0; i < op->addr.nbytes; i++)
> + addr[i] = op->addr.val >> (8 * (op->addr.nbytes - i - 1));
> +
> + ret = mxic_spi_data_xfer(mxic, addr, NULL, op->addr.nbytes);
> + if (ret)
> + goto out;
> +
> + ret = mxic_spi_data_xfer(mxic, NULL, NULL, op->dummy.nbytes);
> + if (ret)
> + goto out;
> +
> + ret = mxic_spi_data_xfer(mxic,
> + op->data.dir == SPI_MEM_DATA_OUT ?
> + op->data.buf.out : NULL,
> + op->data.dir == SPI_MEM_DATA_IN ?
> + op->data.buf.in : NULL,
> + op->data.nbytes);
> +
> +out:
> + writel(readl(mxic->regs + HC_CFG) & ~HC_CFG_MAN_CS_ASSERT,
> +mxic->regs + HC_CFG);
> + writel(0, mxic->regs + HC_EN);
> +
> + return ret;
> +}
[...]
> +
> +static int mxic_spi_setup(struct spi_device *spi)
> +{
> + struct mxic_spi *mxic = spi_master_get_devdata(spi->master);
> +
> + mxic->cur_speed_hz = spi->max_speed_hz;
This is wrong, ->cur_speed_hz should be updated in
mxic_prepare_transfer_hardware() or mxic_spi_clk_check(), not when
->setup() is called. Also, you seem to ignore the xfer->speed_hz value,
which might be different from spi->max_speed_hz. Maybe the
->prepare_transfer() hook is not the right place to do this
->cur_speed_hz selection in the end.
Can you instead create the following function:
static int mxic_spi_set_freq(struct mxic_spi *mxic, unsigned long freq)
{
if (mxic->cur_speed_hz == freq)
return 0;
mxic_spi_clk_disable(mxic);
ret = mxic_spi_clk_setup(mxic, master->max_speed_hz);
if (ret)
return ret;
ret = mxic_spi_clk_enable(mxic);
if (ret)
return ret;
mxic->cur_speed_hz = freq;
return 0;
}
and then call it from mxic_spi_transfer_one() and
mxic_spi_mem_exec_op():
static int mxic_spi_mem_exec_op(struct spi_mem *mem,
const struct spi_mem_op *op)
{
...
ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
...
}
static int mxic_spi_transfer_one(struct spi_master *master,
struct spi_device *spi,
struct spi_transfer *t)
{
...
ret = mxic_spi_set_freq(mxic, t->speed_hz);
...
}
> +
> + return 0;
> +}
> +
[...]
> +
> +static int
Re: [PATCH v10 10/10] mtd: maps: gpio-addr-flash: Add support for device-tree devices
On Fri, 5 Oct 2018 20:12:43 +0200 Ricardo Ribalda Delgado wrote: > > I think I know what might be the issue. on cfi_cmdset_002.c > cfi_amdstd_reset can be called in parrallel to cfi_amdstd_destroy. > > maybe we should call > unregister_reboot_notifier(>reboot_notifier); > before > cfi_amdstd_reset(mtd) > > need to try that on real hw with some strategical printfs :P. But that > will ahve to wait til Monday No problem, nothing urgent here. Have a nice weekend.
Re: [PATCH v10 10/10] mtd: maps: gpio-addr-flash: Add support for device-tree devices
On Fri, 5 Oct 2018 20:12:43 +0200 Ricardo Ribalda Delgado wrote: > > I think I know what might be the issue. on cfi_cmdset_002.c > cfi_amdstd_reset can be called in parrallel to cfi_amdstd_destroy. > > maybe we should call > unregister_reboot_notifier(>reboot_notifier); > before > cfi_amdstd_reset(mtd) > > need to try that on real hw with some strategical printfs :P. But that > will ahve to wait til Monday No problem, nothing urgent here. Have a nice weekend.
Re: [PATCH] lib/bch: fix possible stack overrun
On Fri, 5 Oct 2018 17:56:51 +0200
Arnd Bergmann wrote:
> The previous patch introduced very large kernel stack usage and a Makefile
> change to hide the warning about it.
>
> From what I can tell, a number of things went wrong here:
>
> - The BCH_MAX_T constant was set to the maximum value for 'n',
> not the maximum for 't', which is much smaller.
>
> - The stack usage is actually larger than the entire kernel stack
> on some architectures that can use 4KB stacks (m68k, sh, c6x), which
> leads to an immediate overrun.
>
> - The justification in the patch description claimed that nothing
> changed, however that is not the case even without the two points above:
> the configuration is machine specific, and most boards never use the
> maximum BCH_ECC_WORDS() length but instead have something much smaller.
> That maximum would only apply to machines that use both the maximum
> block size and the maximum ECC strength.
>
> The largest value for 't' that I could find is '32', which in turn leads
> to a 60 byte array instead of 2048 bytes. With that changed, the warning
> can be enabled again.
>
> Fixes: 02361bc77888 ("lib/bch: Remove VLA usage")
> Reported-by: Ard Biesheuvel
> Cc: sta...@vger.kernel.org
> Signed-off-by: Arnd Bergmann
> ---
> Please review carefully to ensure my logic is correct. I spent a
> long time trying to understand what is going on here, but I'm not
> too familiar with this algorithm, and it's possible I still got it
> wrong as well.
> In particular, I'm not 100% sure if '32' is the maximum ECC strength
> we can support, or if a larger one (which?) might be possible.
Well, the ECC strength (T) is dynamically configurable through the
nand-ecc-strength param, so it's theoretically not limited to 32. This
being said, I doubt people are using soft BCH with more strength higher
than 32.
> ---
> lib/Makefile | 1 -
> lib/bch.c| 10 ++
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/lib/Makefile b/lib/Makefile
> index 8c9647fa271a..12c479dd46e0 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -122,7 +122,6 @@ obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/
> obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/
> obj-$(CONFIG_REED_SOLOMON) += reed_solomon/
> obj-$(CONFIG_BCH) += bch.o
> -CFLAGS_bch.o := $(call cc-option,-Wframe-larger-than=4500)
> obj-$(CONFIG_LZO_COMPRESS) += lzo/
> obj-$(CONFIG_LZO_DECOMPRESS) += lzo/
> obj-$(CONFIG_LZ4_COMPRESS) += lz4/
> diff --git a/lib/bch.c b/lib/bch.c
> index 7b0f2006698b..3ef1a3467e7b 100644
> --- a/lib/bch.c
> +++ b/lib/bch.c
> @@ -79,20 +79,19 @@
> #define GF_T(_p) (CONFIG_BCH_CONST_T)
> #define GF_N(_p) ((1 << (CONFIG_BCH_CONST_M))-1)
> #define BCH_MAX_M (CONFIG_BCH_CONST_M)
> +#define BCH_MAX_T (CONFIG_BCH_CONST_T)
> #else
> #define GF_M(_p) ((_p)->m)
> #define GF_T(_p) ((_p)->t)
> #define GF_N(_p) ((_p)->n)
> -#define BCH_MAX_M 15
> +#define BCH_MAX_M 15 /* 2KB */
> +#define BCH_MAX_T 32 /* 32 bit correction */
I'd recommend adding a test on t here [1] (t > BCH_MAX_T), so that you
fail at init time if t is too big.
[1]https://elixir.bootlin.com/linux/v4.19-rc6/source/lib/bch.c#L1280
> #endif
>
> -#define BCH_MAX_T (((1 << BCH_MAX_M) - 1) / BCH_MAX_M)
> -
> #define BCH_ECC_WORDS(_p) DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 32)
> #define BCH_ECC_BYTES(_p) DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 8)
>
> #define BCH_ECC_MAX_WORDS DIV_ROUND_UP(BCH_MAX_M * BCH_MAX_T, 32)
> -#define BCH_ECC_MAX_BYTES DIV_ROUND_UP(BCH_MAX_M * BCH_MAX_T, 8)
>
> #ifndef dbg
> #define dbg(_fmt, args...) do {} while (0)
> @@ -202,6 +201,9 @@ void encode_bch(struct bch_control *bch, const uint8_t
> *data,
> const uint32_t * const tab3 = tab2 + 256*(l+1);
> const uint32_t *pdata, *p0, *p1, *p2, *p3;
>
> + if (WARN_ON(r_bytes > sizeof(r)))
> + return;
> +
> if (ecc) {
> /* load ecc parity bytes into internal 32-bit buffer */
> load_ecc8(bch, bch->ecc_buf, ecc);
Re: [PATCH] lib/bch: fix possible stack overrun
On Fri, 5 Oct 2018 17:56:51 +0200
Arnd Bergmann wrote:
> The previous patch introduced very large kernel stack usage and a Makefile
> change to hide the warning about it.
>
> From what I can tell, a number of things went wrong here:
>
> - The BCH_MAX_T constant was set to the maximum value for 'n',
> not the maximum for 't', which is much smaller.
>
> - The stack usage is actually larger than the entire kernel stack
> on some architectures that can use 4KB stacks (m68k, sh, c6x), which
> leads to an immediate overrun.
>
> - The justification in the patch description claimed that nothing
> changed, however that is not the case even without the two points above:
> the configuration is machine specific, and most boards never use the
> maximum BCH_ECC_WORDS() length but instead have something much smaller.
> That maximum would only apply to machines that use both the maximum
> block size and the maximum ECC strength.
>
> The largest value for 't' that I could find is '32', which in turn leads
> to a 60 byte array instead of 2048 bytes. With that changed, the warning
> can be enabled again.
>
> Fixes: 02361bc77888 ("lib/bch: Remove VLA usage")
> Reported-by: Ard Biesheuvel
> Cc: sta...@vger.kernel.org
> Signed-off-by: Arnd Bergmann
> ---
> Please review carefully to ensure my logic is correct. I spent a
> long time trying to understand what is going on here, but I'm not
> too familiar with this algorithm, and it's possible I still got it
> wrong as well.
> In particular, I'm not 100% sure if '32' is the maximum ECC strength
> we can support, or if a larger one (which?) might be possible.
Well, the ECC strength (T) is dynamically configurable through the
nand-ecc-strength param, so it's theoretically not limited to 32. This
being said, I doubt people are using soft BCH with more strength higher
than 32.
> ---
> lib/Makefile | 1 -
> lib/bch.c| 10 ++
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/lib/Makefile b/lib/Makefile
> index 8c9647fa271a..12c479dd46e0 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -122,7 +122,6 @@ obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/
> obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/
> obj-$(CONFIG_REED_SOLOMON) += reed_solomon/
> obj-$(CONFIG_BCH) += bch.o
> -CFLAGS_bch.o := $(call cc-option,-Wframe-larger-than=4500)
> obj-$(CONFIG_LZO_COMPRESS) += lzo/
> obj-$(CONFIG_LZO_DECOMPRESS) += lzo/
> obj-$(CONFIG_LZ4_COMPRESS) += lz4/
> diff --git a/lib/bch.c b/lib/bch.c
> index 7b0f2006698b..3ef1a3467e7b 100644
> --- a/lib/bch.c
> +++ b/lib/bch.c
> @@ -79,20 +79,19 @@
> #define GF_T(_p) (CONFIG_BCH_CONST_T)
> #define GF_N(_p) ((1 << (CONFIG_BCH_CONST_M))-1)
> #define BCH_MAX_M (CONFIG_BCH_CONST_M)
> +#define BCH_MAX_T (CONFIG_BCH_CONST_T)
> #else
> #define GF_M(_p) ((_p)->m)
> #define GF_T(_p) ((_p)->t)
> #define GF_N(_p) ((_p)->n)
> -#define BCH_MAX_M 15
> +#define BCH_MAX_M 15 /* 2KB */
> +#define BCH_MAX_T 32 /* 32 bit correction */
I'd recommend adding a test on t here [1] (t > BCH_MAX_T), so that you
fail at init time if t is too big.
[1]https://elixir.bootlin.com/linux/v4.19-rc6/source/lib/bch.c#L1280
> #endif
>
> -#define BCH_MAX_T (((1 << BCH_MAX_M) - 1) / BCH_MAX_M)
> -
> #define BCH_ECC_WORDS(_p) DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 32)
> #define BCH_ECC_BYTES(_p) DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 8)
>
> #define BCH_ECC_MAX_WORDS DIV_ROUND_UP(BCH_MAX_M * BCH_MAX_T, 32)
> -#define BCH_ECC_MAX_BYTES DIV_ROUND_UP(BCH_MAX_M * BCH_MAX_T, 8)
>
> #ifndef dbg
> #define dbg(_fmt, args...) do {} while (0)
> @@ -202,6 +201,9 @@ void encode_bch(struct bch_control *bch, const uint8_t
> *data,
> const uint32_t * const tab3 = tab2 + 256*(l+1);
> const uint32_t *pdata, *p0, *p1, *p2, *p3;
>
> + if (WARN_ON(r_bytes > sizeof(r)))
> + return;
> +
> if (ecc) {
> /* load ecc parity bytes into internal 32-bit buffer */
> load_ecc8(bch, bch->ecc_buf, ecc);
