On Sun, 30 Sep 2018 10:10:14 +
Chuanhua Han wrote:
> > -Original Message-
> > From: Boris Brezillon
> > Sent: 2018年9月30日 18:07
> > To: Chuanhua Han
> > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; e...@dei
On Sun, 30 Sep 2018 10:10:14 +
Chuanhua Han wrote:
> > -Original Message-
> > From: Boris Brezillon
> > Sent: 2018年9月30日 18:07
> > To: Chuanhua Han
> > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; e...@dei
On Sun, 30 Sep 2018 17:25:33 +0800
Chuanhua Han wrote:
> This patch fixes the problem of rxdata being equal to 0 during the XSPI
> mode transfer of the dspi controller.
> In XSPI mode, If it is not deleted, the value of rxdata will be equal
> to 0, and the data received will not be received
On Sun, 30 Sep 2018 17:25:33 +0800
Chuanhua Han wrote:
> This patch fixes the problem of rxdata being equal to 0 during the XSPI
> mode transfer of the dspi controller.
> In XSPI mode, If it is not deleted, the value of rxdata will be equal
> to 0, and the data received will not be received
Hi Chuanhua,
On Sun, 30 Sep 2018 17:25:32 +0800
Chuanhua Han wrote:
> Before we add this spi_transfer to the spi_message chain table, we need
> bits_per_word_mask based on spi_control to set the bits_per_word of
> this spi_transfer.
Let's make it clearer: this is wrong. The spi-mem protocol is
Hi Chuanhua,
On Sun, 30 Sep 2018 17:25:32 +0800
Chuanhua Han wrote:
> Before we add this spi_transfer to the spi_message chain table, we need
> bits_per_word_mask based on spi_control to set the bits_per_word of
> this spi_transfer.
Let's make it clearer: this is wrong. The spi-mem protocol is
Hi Lukasz,
On Sat, 29 Sep 2018 23:02:40 +0200
Lukasz Majewski wrote:
> > Talking about that, can you try to port your fixes on top of Frieder's
> > patchset? I'm pretty sure some bug fixes are irrelevant after the
> > migration to spi-mem (patch 1, 3, 4, 5, 6, 7 and 9 should be dropped I
> >
Hi Lukasz,
On Sat, 29 Sep 2018 23:02:40 +0200
Lukasz Majewski wrote:
> > Talking about that, can you try to port your fixes on top of Frieder's
> > patchset? I'm pretty sure some bug fixes are irrelevant after the
> > migration to spi-mem (patch 1, 3, 4, 5, 6, 7 and 9 should be dropped I
> >
Hi Esben,
On Sat, 29 Sep 2018 16:56:17 +0200
Esben Haabendal wrote:
> Chuanhua Han writes:
>
> > This patch fixes the problem that the XSPI mode of the dspi controller
> > cannot transfer data properly.
> > In XSPI mode, cmd_fifo is written before tx_fifo, which transforms the
> > byte order
Hi Esben,
On Sat, 29 Sep 2018 16:56:17 +0200
Esben Haabendal wrote:
> Chuanhua Han writes:
>
> > This patch fixes the problem that the XSPI mode of the dspi controller
> > cannot transfer data properly.
> > In XSPI mode, cmd_fifo is written before tx_fifo, which transforms the
> > byte order
Hi Yogesh,
On Fri, 21 Sep 2018 15:51:59 +0530
Yogesh Gaur wrote:
> +/* Registers used by the driver */
> +#define FSPI_MCR00x00
> +#define FSPI_MCR0_AHB_TIMEOUT_SHIFT 24
> +#define FSPI_MCR0_AHB_TIMEOUT_MASK (0xFF << FSPI_MCR0_AHB_TIMEOUT_SHIFT)
> +#define
Hi Yogesh,
On Fri, 21 Sep 2018 15:51:59 +0530
Yogesh Gaur wrote:
> +/* Registers used by the driver */
> +#define FSPI_MCR00x00
> +#define FSPI_MCR0_AHB_TIMEOUT_SHIFT 24
> +#define FSPI_MCR0_AHB_TIMEOUT_MASK (0xFF << FSPI_MCR0_AHB_TIMEOUT_SHIFT)
> +#define
Hi Lukasz,
On Thu, 27 Sep 2018 00:07:30 +0200
Lukasz Majewski wrote:
> Please find following set of patches, which provide improved behaviour
> of the fsl-quadspi.c driver on Vybrid vf610 HW.
>
> Below code is based on previous work done by Albert ARIBAUD:
>
Hi Lukasz,
On Thu, 27 Sep 2018 00:07:30 +0200
Lukasz Majewski wrote:
> Please find following set of patches, which provide improved behaviour
> of the fsl-quadspi.c driver on Vybrid vf610 HW.
>
> Below code is based on previous work done by Albert ARIBAUD:
>
Hi Mason,
On Fri, 28 Sep 2018 16:21:27 +0800
masonccy...@mxic.com.tw wrote:
> > > +static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> > > +const struct spi_mem_op *op)
> > > +{
> > > + struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
> > > + int nio = 1, i,
Hi Mason,
On Fri, 28 Sep 2018 16:21:27 +0800
masonccy...@mxic.com.tw wrote:
> > > +static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> > > +const struct spi_mem_op *op)
> > > +{
> > > + struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
> > > + int nio = 1, i,
On Fri, 28 Sep 2018 06:59:58 +
Chuanhua Han wrote:
> >
> > It's still unclear why you need to specify a bits_per_word value,
> > but if this is needed, it's probably something you want to add to
> > spi.c, when a message is queued.
> To specify a specific bits_per_word to be able to use
On Fri, 28 Sep 2018 06:59:58 +
Chuanhua Han wrote:
> >
> > It's still unclear why you need to specify a bits_per_word value,
> > but if this is needed, it's probably something you want to add to
> > spi.c, when a message is queued.
> To specify a specific bits_per_word to be able to use
Hi Chuanhua,
On Fri, 21 Sep 2018 15:06:27 +0800
Chuanhua Han wrote:
> This patch fixes the problem that the XSPI mode of the dspi controller
> cannot transfer data properly.
> In XSPI mode, cmd_fifo is written before tx_fifo, which transforms the
> byte order of sending and receiving data.
Hi Chuanhua,
On Fri, 21 Sep 2018 15:06:27 +0800
Chuanhua Han wrote:
> This patch fixes the problem that the XSPI mode of the dspi controller
> cannot transfer data properly.
> In XSPI mode, cmd_fifo is written before tx_fifo, which transforms the
> byte order of sending and receiving data.
Hi Chuanhua,
On Fri, 21 Sep 2018 15:06:26 +0800
Chuanhua Han wrote:
> Before we add this spi_transfer to the spi_message chain table, we need
> bits_per_word_mask based on spi_control to set the bits_per_word of
> this spi_transfer.
It's not clear to me what you're trying to fix/improve. Can
Hi Chuanhua,
On Fri, 21 Sep 2018 15:06:26 +0800
Chuanhua Han wrote:
> Before we add this spi_transfer to the spi_message chain table, we need
> bits_per_word_mask based on spi_control to set the bits_per_word of
> this spi_transfer.
It's not clear to me what you're trying to fix/improve. Can
> Changelog v2:
>
> From Boris Brezillon:
> -Add Fixes and cc:stable
>
> From kbuild:
> - Fix warnings
>
> - Rebase
>
> Ricardo Ribalda Delgado (8):
> mtd: maps: gpio-addr-flash: Replace custom printk
> mtd: maps: gpio-addr-flash: Fix ioremapped size
> Changelog v2:
>
> From Boris Brezillon:
> -Add Fixes and cc:stable
>
> From kbuild:
> - Fix warnings
>
> - Rebase
>
> Ricardo Ribalda Delgado (8):
> mtd: maps: gpio-addr-flash: Replace custom printk
> mtd: maps: gpio-addr-flash: Fix ioremapped size
On Wed, 5 Sep 2018 16:36:40 +0200
Ricardo Ribalda Delgado wrote:
> By replacing the array with an integer we can avoid completely
> the bit comparison loop if the value has not changed (by far
> the most common case).
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
>
On Wed, 5 Sep 2018 16:36:40 +0200
Ricardo Ribalda Delgado wrote:
> By replacing the array with an integer we can avoid completely
> the bit comparison loop if the value has not changed (by far
> the most common case).
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
>
On Wed, 5 Sep 2018 16:36:42 +0200
Ricardo Ribalda Delgado wrote:
> +static int gpio_flash_probe_gpios(struct platform_device *pdev,
> + struct async_state *state)
> +{
> + struct physmap_flash_data *pdata;
> + struct device_node *dn;
> + struct resource
On Wed, 5 Sep 2018 16:36:42 +0200
Ricardo Ribalda Delgado wrote:
> +static int gpio_flash_probe_gpios(struct platform_device *pdev,
> + struct async_state *state)
> +{
> + struct physmap_flash_data *pdata;
> + struct device_node *dn;
> + struct resource
On Wed, 5 Sep 2018 16:36:38 +0200
Ricardo Ribalda Delgado wrote:
> @@ -234,9 +234,11 @@ static int gpio_flash_probe(struct platform_device *pdev)
> state->map.copy_to= gf_copy_to;
> state->map.bankwidth = pdata->width;
> state->map.size = state->win_size * (1 <<
On Wed, 5 Sep 2018 16:36:38 +0200
Ricardo Ribalda Delgado wrote:
> @@ -234,9 +234,11 @@ static int gpio_flash_probe(struct platform_device *pdev)
> state->map.copy_to= gf_copy_to;
> state->map.bankwidth = pdata->width;
> state->map.size = state->win_size * (1 <<
Hi Mason,
On Mon, 17 Sep 2018 15:16:17 +0800
masonccy...@mxic.com.tw wrote:
> From: Mason Yang
>
> Hi Mark and Trent,
>
> I patched spi-mxic.c and add the run time PM function.
BTW, you forgot to add v2 in the subject prefix (can be done by passing
-vX to git format-patch, where X is the
Hi Mason,
On Mon, 17 Sep 2018 15:16:17 +0800
masonccy...@mxic.com.tw wrote:
> From: Mason Yang
>
> Hi Mark and Trent,
>
> I patched spi-mxic.c and add the run time PM function.
BTW, you forgot to add v2 in the subject prefix (can be done by passing
-vX to git format-patch, where X is the
On Mon, 24 Sep 2018 18:36:36 +0200
Christophe Kerello wrote:
> >> +static int stm32_fmc2_resume(struct device *dev)
> >> +{
> >> + struct stm32_fmc2 *fmc2 = dev_get_drvdata(dev);
> >> + int i, ret;
> >> +
> >> + pinctrl_pm_select_default_state(dev);
> >> +
> >> + ret =
On Mon, 24 Sep 2018 18:36:36 +0200
Christophe Kerello wrote:
> >> +static int stm32_fmc2_resume(struct device *dev)
> >> +{
> >> + struct stm32_fmc2 *fmc2 = dev_get_drvdata(dev);
> >> + int i, ret;
> >> +
> >> + pinctrl_pm_select_default_state(dev);
> >> +
> >> + ret =
Hi Christophe,
On Mon, 17 Sep 2018 17:47:39 +0200
wrote:
> +struct stm32_fmc2 {
> + struct nand_chip chip;
> + struct device *dev;
> + void __iomem *io_base;
> + void __iomem *data_base[FMC2_MAX_CE];
> + void __iomem *cmd_base[FMC2_MAX_CE];
> + void __iomem
Hi Christophe,
On Mon, 17 Sep 2018 17:47:39 +0200
wrote:
> +struct stm32_fmc2 {
> + struct nand_chip chip;
> + struct device *dev;
> + void __iomem *io_base;
> + void __iomem *data_base[FMC2_MAX_CE];
> + void __iomem *cmd_base[FMC2_MAX_CE];
> + void __iomem
Hi Christophe,
On Mon, 24 Sep 2018 18:36:27 +0200
Christophe Kerello wrote:
> >> +- st,fmc2_timings: array of 8 bytes for NAND timings. The meanings of
> >> + these bytes are:
> >> + byte 0 TCLR : CLE to RE delay in number of AHB clock cycles, only
> >> 4 bits
> >> +
Hi Christophe,
On Mon, 24 Sep 2018 18:36:27 +0200
Christophe Kerello wrote:
> >> +- st,fmc2_timings: array of 8 bytes for NAND timings. The meanings of
> >> + these bytes are:
> >> + byte 0 TCLR : CLE to RE delay in number of AHB clock cycles, only
> >> 4 bits
> >> +
On Sat, 22 Sep 2018 09:53:40 +0200
Miquel Raynal wrote:
> Hi Naga,
>
> Naga Sureshkumar Relli wrote on Tue, 11 Sep 2018
> 05:23:09 +:
>
> > Hi Boris,
> >
> > > -----Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil.
On Sat, 22 Sep 2018 09:53:40 +0200
Miquel Raynal wrote:
> Hi Naga,
>
> Naga Sureshkumar Relli wrote on Tue, 11 Sep 2018
> 05:23:09 +:
>
> > Hi Boris,
> >
> > > -----Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil.
On Sat, 22 Sep 2018 09:41:11 +0200
Miquel Raynal wrote:
> Hi Masahiro,
>
> Masahiro Yamada wrote on Sat, 8 Sep
> 2018 01:10:25 +0900:
>
> > Hi Boris,
> >
> > 2018-09-07 23:53 GMT+09:00 Boris Brezillon :
> > > On Fri, 7 Sep 2018 2
On Sat, 22 Sep 2018 09:41:11 +0200
Miquel Raynal wrote:
> Hi Masahiro,
>
> Masahiro Yamada wrote on Sat, 8 Sep
> 2018 01:10:25 +0900:
>
> > Hi Boris,
> >
> > 2018-09-07 23:53 GMT+09:00 Boris Brezillon :
> > > On Fri, 7 Sep 2018 2
On Tue, 18 Sep 2018 12:51:51 +0200
Frieder Schrempf wrote:
> I want to revive the discussion about this patch. Meanwhile we have
> received confirmation from NXP, that the hardware can't handle writing
> data chunks bigger than the TX buffer size, even when we use DMA to
> refill the buffer
On Tue, 18 Sep 2018 12:51:51 +0200
Frieder Schrempf wrote:
> I want to revive the discussion about this patch. Meanwhile we have
> received confirmation from NXP, that the hardware can't handle writing
> data chunks bigger than the TX buffer size, even when we use DMA to
> refill the buffer
river")
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Boris Brezillon
> ---
> Changes in v2:
> - Add Fixes tag to the commit log.
> - Remove blank line before null checking nfc_np.
>
> drivers/mtd/nand/raw/atmel/nand-controller.c | 4
> 1 file changed,
river")
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Boris Brezillon
> ---
> Changes in v2:
> - Add Fixes tag to the commit log.
> - Remove blank line before null checking nfc_np.
>
> drivers/mtd/nand/raw/atmel/nand-controller.c | 4
> 1 file changed,
Hi Gustavo,
On Tue, 18 Sep 2018 08:33:17 -0500
"Gustavo A. R. Silva" wrote:
> There is a potential execution path in which function
> of_find_compatible_node() returns NULL. In such a case,
> we end up having a NULL pointer dereference when accessing
> pointer *nfc_np* in function of_clk_get().
Hi Gustavo,
On Tue, 18 Sep 2018 08:33:17 -0500
"Gustavo A. R. Silva" wrote:
> There is a potential execution path in which function
> of_find_compatible_node() returns NULL. In such a case,
> we end up having a NULL pointer dereference when accessing
> pointer *nfc_np* in function of_clk_get().
On Tue, 11 Sep 2018 18:40:05 +0300
Tudor Ambarus wrote:
> Backward compatibility test done on mx25l3273fm2i-08g with
> CONFIG_MTD_SPI_NOR_USE_4K_SECTORS set and unset.
> Non-uniform erase test done on sst26vf064b-104i/sn with
> CONFIG_MTD_SPI_NOR_USE_4K_SECTORS set and unset.
>
> Note that in
On Tue, 11 Sep 2018 18:40:05 +0300
Tudor Ambarus wrote:
> Backward compatibility test done on mx25l3273fm2i-08g with
> CONFIG_MTD_SPI_NOR_USE_4K_SECTORS set and unset.
> Non-uniform erase test done on sst26vf064b-104i/sn with
> CONFIG_MTD_SPI_NOR_USE_4K_SECTORS set and unset.
>
> Note that in
Hi Yogesh,
On Tue, 18 Sep 2018 11:34:18 +
Yogesh Narayan Gaur wrote:
> >
> > Do we really need all those macros for registers and modes, that
> > aren't even used in the driver? I don't know what the common
> > practice is, but to me it seems like removing all the unused macros
> > would
Hi Yogesh,
On Tue, 18 Sep 2018 11:34:18 +
Yogesh Narayan Gaur wrote:
> >
> > Do we really need all those macros for registers and modes, that
> > aren't even used in the driver? I don't know what the common
> > practice is, but to me it seems like removing all the unused macros
> > would
On Thu, 13 Sep 2018 14:58:49 +0900
Masahiro Yamada wrote:
> I thought the read-back of the DMA_ENABLE register was unnecessary
> (at least it is working on my boards), then deleted it in commit
> 586a2c52909d ("mtd: nand: denali: squash denali_enable_dma() helper
> into caller"). Sorry, I was
On Thu, 13 Sep 2018 14:58:49 +0900
Masahiro Yamada wrote:
> I thought the read-back of the DMA_ENABLE register was unnecessary
> (at least it is working on my boards), then deleted it in commit
> 586a2c52909d ("mtd: nand: denali: squash denali_enable_dma() helper
> into caller"). Sorry, I was
Hi Mason,
On Mon, 17 Sep 2018 15:16:18 +0800
masonccy...@mxic.com.tw wrote:
> +
> +static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> + const struct spi_mem_op *op)
> +{
> + struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
> + int nio = 1,
Hi Mason,
On Mon, 17 Sep 2018 15:16:18 +0800
masonccy...@mxic.com.tw wrote:
> +
> +static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> + const struct spi_mem_op *op)
> +{
> + struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
> + int nio = 1,
Hi Yogesh,
On Mon, 17 Sep 2018 15:18:26 +0530
Yogesh Gaur wrote:
> +
> + /*
> + * R/W functions for big- or little-endian registers:
> + * The FSPI controller's endianness is independent of
> + * the CPU core's endianness. So far, although the CPU
> + * core is
Hi Yogesh,
On Mon, 17 Sep 2018 15:18:26 +0530
Yogesh Gaur wrote:
> +
> + /*
> + * R/W functions for big- or little-endian registers:
> + * The FSPI controller's endianness is independent of
> + * the CPU core's endianness. So far, although the CPU
> + * core is
On Fri, 7 Sep 2018 23:42:53 +0900
Masahiro Yamada wrote:
> Hi Boris,
>
> 2018-09-07 23:08 GMT+09:00 Boris Brezillon :
> > Hi Masahiro,
> >
> > On Fri, 7 Sep 2018 19:56:23 +0900
> > Masahiro Yamada wrote:
> >
> >> NAND devices need
On Fri, 7 Sep 2018 23:42:53 +0900
Masahiro Yamada wrote:
> Hi Boris,
>
> 2018-09-07 23:08 GMT+09:00 Boris Brezillon :
> > Hi Masahiro,
> >
> > On Fri, 7 Sep 2018 19:56:23 +0900
> > Masahiro Yamada wrote:
> >
> >> NAND devices need
Hi Masahiro,
On Fri, 7 Sep 2018 19:56:23 +0900
Masahiro Yamada wrote:
> NAND devices need additional data area (OOB) for error correction,
> but it is also used for Bad Block Marker (BBM). In many cases, the
> first byte in OOB is used for BBM, but the location actually depends
> on chip
Hi Masahiro,
On Fri, 7 Sep 2018 19:56:23 +0900
Masahiro Yamada wrote:
> NAND devices need additional data area (OOB) for error correction,
> but it is also used for Bad Block Marker (BBM). In many cases, the
> first byte in OOB is used for BBM, but the location actually depends
> on chip
On Fri, 7 Sep 2018 18:57:10 +0800
Jianxin Pan wrote:
> From: Liang Yang
>
> Add Amlogic NAND controller dt-bindings for Meson SoC,
> Current this driver support GXBB/GXL/AXG platform.
>
> Signed-off-by: Liang Yang
> Signed-off-by: Yixun Lan
> ---
>
On Fri, 7 Sep 2018 18:57:10 +0800
Jianxin Pan wrote:
> From: Liang Yang
>
> Add Amlogic NAND controller dt-bindings for Meson SoC,
> Current this driver support GXBB/GXL/AXG platform.
>
> Signed-off-by: Liang Yang
> Signed-off-by: Yixun Lan
> ---
>
On Thu, 6 Sep 2018 10:49:22 +0200
Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> This patch enables support to read the ECC level from the NAND flash
> using ESMT SLC NAND ID byte 5 information as documented e.g. in the
> following data sheet:
>
>
On Thu, 6 Sep 2018 10:49:22 +0200
Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> This patch enables support to read the ECC level from the NAND flash
> using ESMT SLC NAND ID byte 5 information as documented e.g. in the
> following data sheet:
>
>
On Thu, 6 Sep 2018 10:49:21 +0200
Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Reorder NAND manufacturer ids for clarity.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> drivers/mtd/nand/raw/nand_ids.c | 20 ++--
> include/linux/mtd/rawnand.h | 8
> 2
On Thu, 6 Sep 2018 10:49:21 +0200
Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Reorder NAND manufacturer ids for clarity.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> drivers/mtd/nand/raw/nand_ids.c | 20 ++--
> include/linux/mtd/rawnand.h | 8
> 2
On Thu, 6 Sep 2018 11:35:13 +
Yogesh Narayan Gaur wrote:
> Hi Frieder,
>
> > -Original Message-
> > From: Frieder Schrempf [mailto:frieder.schre...@exceet.de]
> > Sent: Thursday, September 6, 2018 1:56 PM
> > To: Yogesh Narayan Gaur ; Bori
On Thu, 6 Sep 2018 11:35:13 +
Yogesh Narayan Gaur wrote:
> Hi Frieder,
>
> > -Original Message-
> > From: Frieder Schrempf [mailto:frieder.schre...@exceet.de]
> > Sent: Thursday, September 6, 2018 1:56 PM
> > To: Yogesh Narayan Gaur ; Bori
Hi Yogesh,
On Fri, 31 Aug 2018 16:00:00 +0530
Yogesh Gaur wrote:
> - Add a driver for NXP FlexSPI host controller
>
> (0) What is the FlexSPI controller?
> FlexSPI is a flexsible SPI host controller which supports two SPI
> channels and up to 4 external devices.
> Each channel supports
Hi Yogesh,
On Fri, 31 Aug 2018 16:00:00 +0530
Yogesh Gaur wrote:
> - Add a driver for NXP FlexSPI host controller
>
> (0) What is the FlexSPI controller?
> FlexSPI is a flexsible SPI host controller which supports two SPI
> channels and up to 4 external devices.
> Each channel supports
On Mon, 3 Sep 2018 09:54:08 +
Prabhakar Kushwaha wrote:
> Dear Yogesh,
>
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Yogesh Gaur
> > Sent: Friday, August 31, 2018 4:00 PM
> > To: linux-...@lists.infradead.org;
On Mon, 3 Sep 2018 09:54:08 +
Prabhakar Kushwaha wrote:
> Dear Yogesh,
>
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Yogesh Gaur
> > Sent: Friday, August 31, 2018 4:00 PM
> > To: linux-...@lists.infradead.org;
Hi Yogesh,
On Fri, 31 Aug 2018 15:59:57 +0530
Yogesh Gaur wrote:
> - Add a 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
Hi Yogesh,
On Fri, 31 Aug 2018 15:59:57 +0530
Yogesh Gaur wrote:
> - Add a 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
Hi Yogesh,
On Mon, 3 Sep 2018 04:47:25 +
Yogesh Narayan Gaur wrote:
> Hi Lothar,
>
> > -Original Message-
> > From: Lothar Waßmann [mailto:l...@karo-electronics.de]
> > Sent: Friday, August 31, 2018 5:28 PM
> > To: Yogesh Narayan Gaur
> > Cc: linux-...@lists.infradead.org;
Hi Yogesh,
On Mon, 3 Sep 2018 04:47:25 +
Yogesh Narayan Gaur wrote:
> Hi Lothar,
>
> > -Original Message-
> > From: Lothar Waßmann [mailto:l...@karo-electronics.de]
> > Sent: Friday, August 31, 2018 5:28 PM
> > To: Yogesh Narayan Gaur
> > Cc: linux-...@lists.infradead.org;
On Thu, 30 Aug 2018 09:13:03 +
Chuanhua Han wrote:
> > -Original Message-
> > From: Boris Brezillon
> > Sent: 2018年8月30日 16:47
> > To: Chuanhua Han
> > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; st
On Thu, 30 Aug 2018 09:13:03 +
Chuanhua Han wrote:
> > -Original Message-
> > From: Boris Brezillon
> > Sent: 2018年8月30日 16:47
> > To: Chuanhua Han
> > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; st
again. And when you do so and nothing changed in the patch
please use the [PATCH RESEND vX] prefix and explain why you resend it.
Thanks,
Boris
>
> Fixes: c36ff266dc82 ("spi: Extend the core to ease integration of SPI memory
> controllers")
> Cc:
> Signed-off-by: Chu
again. And when you do so and nothing changed in the patch
please use the [PATCH RESEND vX] prefix and explain why you resend it.
Thanks,
Boris
>
> Fixes: c36ff266dc82 ("spi: Extend the core to ease integration of SPI memory
> controllers")
> Cc:
> Signed-off-by: Chu
On Wed, 29 Aug 2018 18:29:05 +0800
Liang Yang wrote:
> On 8/29/2018 6:08 PM, Liang Yang wrote:
> >
> > On 8/28/2018 9:26 PM, Boris Brezillon wrote:
> >> On Tue, 28 Aug 2018 21:21:48 +0800
> >> Liang Yang wrote:
> >>
> >>> Hi Boris,
&
On Wed, 29 Aug 2018 18:29:05 +0800
Liang Yang wrote:
> On 8/29/2018 6:08 PM, Liang Yang wrote:
> >
> > On 8/28/2018 9:26 PM, Boris Brezillon wrote:
> >> On Tue, 28 Aug 2018 21:21:48 +0800
> >> Liang Yang wrote:
> >>
> >>> Hi Boris,
&
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:
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:
On Tue, 21 Aug 2018 16:31:46 +0200
Ricardo Ribalda Delgado wrote:
> We should only iomap the area of the chip that is memory mapped.
> Otherwise we could be mapping devices beyond the memory space or that
> belong to other devices.
>
Can you add
Fixes: ebd71e3a4861 ("mtd: maps:
On Tue, 21 Aug 2018 16:31:46 +0200
Ricardo Ribalda Delgado wrote:
> We should only iomap the area of the chip that is memory mapped.
> Otherwise we could be mapping devices beyond the memory space or that
> belong to other devices.
>
Can you add
Fixes: ebd71e3a4861 ("mtd: maps:
On Tue, 28 Aug 2018 22:16:08 +0800 (CST)
"Liu Xiang" wrote:
> Thanks for your suggestion. Should I send another patch?
Yes please.
On Tue, 28 Aug 2018 22:16:08 +0800 (CST)
"Liu Xiang" wrote:
> Thanks for your suggestion. Should I send another patch?
Yes please.
On Tue, 28 Aug 2018 21:21:48 +0800
Liang Yang wrote:
> Hi Boris,
>
> On 8/24/2018 8:48 PM, Boris Brezillon wrote:
> > On Wed, 22 Aug 2018 22:08:42 +0800
> > Liang Yang wrote:
> >
> >>> You have to wait tWB, that's for sure.
> >>>
&g
On Tue, 28 Aug 2018 21:21:48 +0800
Liang Yang wrote:
> Hi Boris,
>
> On 8/24/2018 8:48 PM, Boris Brezillon wrote:
> > On Wed, 22 Aug 2018 22:08:42 +0800
> > Liang Yang wrote:
> >
> >>> You have to wait tWB, that's for sure.
> >>>
&g
On Tue, 28 Aug 2018 21:21:16 +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.
>
> ---
> v2:
>
On Tue, 28 Aug 2018 21:21:16 +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.
>
> ---
> v2:
>
On Mon, 27 Aug 2018 20:52:34 -0500
Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Boris Brezillon
> Cc: Miquel Raynal
> Cc: Richard Weinberger
> Cc: David W
On Mon, 27 Aug 2018 20:52:34 -0500
Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Boris Brezillon
> Cc: Miquel Raynal
> Cc: Richard Weinberger
> Cc: David W
On Mon, 27 Aug 2018 16:01:41 +0900
Masahiro Yamada wrote:
> Commit 49aa76b16676 ("mtd: rawnand: do not execute nand_scan_ident()
> if maxchips is zero") gave a new meaning for calling nand_scan_ident()
> with maxchips=0.
>
> It is a special usage for some drivers such as docg4, but actually
>
On Mon, 27 Aug 2018 16:01:41 +0900
Masahiro Yamada wrote:
> Commit 49aa76b16676 ("mtd: rawnand: do not execute nand_scan_ident()
> if maxchips is zero") gave a new meaning for calling nand_scan_ident()
> with maxchips=0.
>
> It is a special usage for some drivers such as docg4, but actually
>
On Thu, 23 Aug 2018 23:43:45 +0200
Geert Uytterhoeven wrote:
> If gcc (e.g. 4.1.2) decides not to inline init_mtd_structs() and
> read_id_reg(), this will cause section mismatches, and crashes:
>
> WARNING: drivers/mtd/nand/raw/docg4.o(.text+0xc10): Section mismatch in
> reference from the
On Thu, 23 Aug 2018 23:43:45 +0200
Geert Uytterhoeven wrote:
> If gcc (e.g. 4.1.2) decides not to inline init_mtd_structs() and
> read_id_reg(), this will cause section mismatches, and crashes:
>
> WARNING: drivers/mtd/nand/raw/docg4.o(.text+0xc10): Section mismatch in
> reference from the
1001 - 1100 of 10969 matches
Mail list logo
