From: Boris Brezillon <boris.brezillon@collabora.com>
To: Vignesh Raghavendra <vigneshr@ti.com>
Cc: kstewart@linuxfoundation.org, alexandre.belloni@bootlin.com,
linux-aspeed@lists.ozlabs.org, thor.thayer@linux.intel.com,
jethro@fortanix.com, rfontana@redhat.com,
linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com,
opensource@jilayne.com, richard@nod.at, allison@lohutok.net,
michal.simek@xilinx.com, Ludovic.Desroches@microchip.com,
joel@jms.id.au, nishkadg.linux@gmail.com,
Tudor.Ambarus@microchip.com, john.garry@huawei.com, vz@mleia.com,
alexander.sverdlin@nokia.com, matthias.bgg@gmail.com,
tglx@linutronix.de, swboyd@chromium.org,
mika.westerberg@linux.intel.com, ludovic.barre@st.com,
linux-arm-kernel@lists.infradead.org, bbrezillon@kernel.org,
andrew@aj.id.au, Nicolas.Ferre@microchip.com,
linux-kernel@vger.kernel.org, dinguyen@kernel.org,
michael@walle.cc, linux-mediatek@lists.infradead.org,
info@metux.net
Subject: Re: [PATCH 01/23] mtd: spi-nor: Stop prefixing generic functions with a manufacturer name
Date: Fri, 13 Mar 2020 10:30:07 +0100 [thread overview]
Message-ID: <20200313103007.7d7ea6af@collabora.com> (raw)
In-Reply-To: <91394111-cbd6-c24e-485d-88fcd6825dc7@ti.com>
On Fri, 13 Mar 2020 11:34:55 +0530
Vignesh Raghavendra <vigneshr@ti.com> wrote:
> On 02/03/20 11:37 pm, Tudor.Ambarus@microchip.com wrote:
> > From: Boris Brezillon <bbrezillon@kernel.org>
> >
> > Replace the manufacturer prefix by something describing more precisely
> > what those functions do.
> >
> > Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
> > [tudor.ambarus@microchip.com: prepend spi_nor_ to all modified methods.]
> > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 88 ++++++++++++++++++-----------------
> > 1 file changed, 45 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index caf0c109cca0..b15e262765e1 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -568,14 +568,15 @@ static int spi_nor_read_cr(struct spi_nor *nor, u8 *cr)
> > }
> >
> > /**
> > - * macronix_set_4byte() - Set 4-byte address mode for Macronix flashes.
> > + * spi_nor_en4_ex4_set_4byte() - Enter/Exit 4-byte mode for Macronix like
> > + * flashes.
> > * @nor: pointer to 'struct spi_nor'.
> > * @enable: true to enter the 4-byte address mode, false to exit the 4-byte
> > * address mode.
> > *
> > * Return: 0 on success, -errno otherwise.
> > */
> > -static int macronix_set_4byte(struct spi_nor *nor, bool enable)
> > +static int spi_nor_en4_ex4_set_4byte(struct spi_nor *nor, bool enable)
>
>
> Sounds a bit weird, how about simplifying this to:
>
> spi_nor_set_4byte_addr_mode()
>
> Or if you want to be specific:
>
> spi_nor_en_ex_4byte_addr_mode()
You're right. Maybe we can simplify things by having a single function
that does optional steps based on new flags
SPI_NOR_EN_EX_4B_NEEDS_WEN
SPI_NOR_CLEAR_EAR_ON_4B_EXIT
This should probably be done in a separate patch though, so ack on the
spi_nor_en_ex_4byte_addr_mode() rename, assuming we also change the
bool argument name to enter.
>
> > {
> > int ret;
> >
> > @@ -604,14 +605,15 @@ static int macronix_set_4byte(struct spi_nor *nor, bool enable)
> > }
> >
> > /**
> > - * st_micron_set_4byte() - Set 4-byte address mode for ST and Micron flashes.
> > + * spi_nor_en4_ex4_wen_set_4byte() - Set 4-byte address mode for ST and Micron
> > + * flashes.
> > * @nor: pointer to 'struct spi_nor'.
> > * @enable: true to enter the 4-byte address mode, false to exit the 4-byte
> > * address mode.
> > *
> > * Return: 0 on success, -errno otherwise.
> > */
> > -static int st_micron_set_4byte(struct spi_nor *nor, bool enable)
> > +static int spi_nor_en4_ex4_wen_set_4byte(struct spi_nor *nor, bool enable)
>
>
> Unrelated to this patch itself, but can we just have one set_4byte
> variant that uses WREN and drop the other one?
Hm, not sure that's a good idea to insert WEN instructions for
everyone, sounds like a recipe for regressions.
> I expect sending WREN should be harmless even for cmds that don't expect
> one.
In theory yes, but you know flash chips are capricious, so let's not
take the risk of breaking things :-).
>
> Rest looks good to me.
>
> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Vignesh Raghavendra <vigneshr@ti.com>
Cc: kstewart@linuxfoundation.org, alexandre.belloni@bootlin.com,
linux-aspeed@lists.ozlabs.org, thor.thayer@linux.intel.com,
jethro@fortanix.com, rfontana@redhat.com,
linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com,
opensource@jilayne.com, richard@nod.at, allison@lohutok.net,
michal.simek@xilinx.com, Ludovic.Desroches@microchip.com,
joel@jms.id.au, nishkadg.linux@gmail.com,
Tudor.Ambarus@microchip.com, john.garry@huawei.com, vz@mleia.com,
alexander.sverdlin@nokia.com, matthias.bgg@gmail.com,
tglx@linutronix.de, swboyd@chromium.org,
mika.westerberg@linux.intel.com, ludovic.barre@st.com,
linux-arm-kernel@lists.infradead.org, bbrezillon@kernel.org,
andrew@aj.id.au, Nicolas.Ferre@microchip.com,
linux-kernel@vger.kernel.org, dinguyen@kernel.org,
michael@walle.cc, linux-mediatek@lists.infradead.org,
info@metux.net
Subject: Re: [PATCH 01/23] mtd: spi-nor: Stop prefixing generic functions with a manufacturer name
Date: Fri, 13 Mar 2020 10:30:07 +0100 [thread overview]
Message-ID: <20200313103007.7d7ea6af@collabora.com> (raw)
In-Reply-To: <91394111-cbd6-c24e-485d-88fcd6825dc7@ti.com>
On Fri, 13 Mar 2020 11:34:55 +0530
Vignesh Raghavendra <vigneshr@ti.com> wrote:
> On 02/03/20 11:37 pm, Tudor.Ambarus@microchip.com wrote:
> > From: Boris Brezillon <bbrezillon@kernel.org>
> >
> > Replace the manufacturer prefix by something describing more precisely
> > what those functions do.
> >
> > Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
> > [tudor.ambarus@microchip.com: prepend spi_nor_ to all modified methods.]
> > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 88 ++++++++++++++++++-----------------
> > 1 file changed, 45 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index caf0c109cca0..b15e262765e1 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -568,14 +568,15 @@ static int spi_nor_read_cr(struct spi_nor *nor, u8 *cr)
> > }
> >
> > /**
> > - * macronix_set_4byte() - Set 4-byte address mode for Macronix flashes.
> > + * spi_nor_en4_ex4_set_4byte() - Enter/Exit 4-byte mode for Macronix like
> > + * flashes.
> > * @nor: pointer to 'struct spi_nor'.
> > * @enable: true to enter the 4-byte address mode, false to exit the 4-byte
> > * address mode.
> > *
> > * Return: 0 on success, -errno otherwise.
> > */
> > -static int macronix_set_4byte(struct spi_nor *nor, bool enable)
> > +static int spi_nor_en4_ex4_set_4byte(struct spi_nor *nor, bool enable)
>
>
> Sounds a bit weird, how about simplifying this to:
>
> spi_nor_set_4byte_addr_mode()
>
> Or if you want to be specific:
>
> spi_nor_en_ex_4byte_addr_mode()
You're right. Maybe we can simplify things by having a single function
that does optional steps based on new flags
SPI_NOR_EN_EX_4B_NEEDS_WEN
SPI_NOR_CLEAR_EAR_ON_4B_EXIT
This should probably be done in a separate patch though, so ack on the
spi_nor_en_ex_4byte_addr_mode() rename, assuming we also change the
bool argument name to enter.
>
> > {
> > int ret;
> >
> > @@ -604,14 +605,15 @@ static int macronix_set_4byte(struct spi_nor *nor, bool enable)
> > }
> >
> > /**
> > - * st_micron_set_4byte() - Set 4-byte address mode for ST and Micron flashes.
> > + * spi_nor_en4_ex4_wen_set_4byte() - Set 4-byte address mode for ST and Micron
> > + * flashes.
> > * @nor: pointer to 'struct spi_nor'.
> > * @enable: true to enter the 4-byte address mode, false to exit the 4-byte
> > * address mode.
> > *
> > * Return: 0 on success, -errno otherwise.
> > */
> > -static int st_micron_set_4byte(struct spi_nor *nor, bool enable)
> > +static int spi_nor_en4_ex4_wen_set_4byte(struct spi_nor *nor, bool enable)
>
>
> Unrelated to this patch itself, but can we just have one set_4byte
> variant that uses WREN and drop the other one?
Hm, not sure that's a good idea to insert WEN instructions for
everyone, sounds like a recipe for regressions.
> I expect sending WREN should be harmless even for cmds that don't expect
> one.
In theory yes, but you know flash chips are capricious, so let's not
take the risk of breaking things :-).
>
> Rest looks good to me.
>
> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Vignesh Raghavendra <vigneshr@ti.com>
Cc: kstewart@linuxfoundation.org, alexandre.belloni@bootlin.com,
linux-aspeed@lists.ozlabs.org, thor.thayer@linux.intel.com,
jethro@fortanix.com, rfontana@redhat.com,
linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com,
opensource@jilayne.com, richard@nod.at, allison@lohutok.net,
michal.simek@xilinx.com, Ludovic.Desroches@microchip.com,
joel@jms.id.au, nishkadg.linux@gmail.com,
Tudor.Ambarus@microchip.com, john.garry@huawei.com, vz@mleia.com,
alexander.sverdlin@nokia.com, matthias.bgg@gmail.com,
tglx@linutronix.de, swboyd@chromium.org,
mika.westerberg@linux.intel.com, ludovic.barre@st.com,
linux-arm-kernel@lists.infradead.org, bbrezillon@kernel.org,
andrew@aj.id.au, linux-kernel@vger.kernel.org,
dinguyen@kernel.org, michael@walle.cc,
linux-mediatek@lists.infradead.org, info@metux.net
Subject: Re: [PATCH 01/23] mtd: spi-nor: Stop prefixing generic functions with a manufacturer name
Date: Fri, 13 Mar 2020 10:30:07 +0100 [thread overview]
Message-ID: <20200313103007.7d7ea6af@collabora.com> (raw)
In-Reply-To: <91394111-cbd6-c24e-485d-88fcd6825dc7@ti.com>
On Fri, 13 Mar 2020 11:34:55 +0530
Vignesh Raghavendra <vigneshr@ti.com> wrote:
> On 02/03/20 11:37 pm, Tudor.Ambarus@microchip.com wrote:
> > From: Boris Brezillon <bbrezillon@kernel.org>
> >
> > Replace the manufacturer prefix by something describing more precisely
> > what those functions do.
> >
> > Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
> > [tudor.ambarus@microchip.com: prepend spi_nor_ to all modified methods.]
> > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 88 ++++++++++++++++++-----------------
> > 1 file changed, 45 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index caf0c109cca0..b15e262765e1 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -568,14 +568,15 @@ static int spi_nor_read_cr(struct spi_nor *nor, u8 *cr)
> > }
> >
> > /**
> > - * macronix_set_4byte() - Set 4-byte address mode for Macronix flashes.
> > + * spi_nor_en4_ex4_set_4byte() - Enter/Exit 4-byte mode for Macronix like
> > + * flashes.
> > * @nor: pointer to 'struct spi_nor'.
> > * @enable: true to enter the 4-byte address mode, false to exit the 4-byte
> > * address mode.
> > *
> > * Return: 0 on success, -errno otherwise.
> > */
> > -static int macronix_set_4byte(struct spi_nor *nor, bool enable)
> > +static int spi_nor_en4_ex4_set_4byte(struct spi_nor *nor, bool enable)
>
>
> Sounds a bit weird, how about simplifying this to:
>
> spi_nor_set_4byte_addr_mode()
>
> Or if you want to be specific:
>
> spi_nor_en_ex_4byte_addr_mode()
You're right. Maybe we can simplify things by having a single function
that does optional steps based on new flags
SPI_NOR_EN_EX_4B_NEEDS_WEN
SPI_NOR_CLEAR_EAR_ON_4B_EXIT
This should probably be done in a separate patch though, so ack on the
spi_nor_en_ex_4byte_addr_mode() rename, assuming we also change the
bool argument name to enter.
>
> > {
> > int ret;
> >
> > @@ -604,14 +605,15 @@ static int macronix_set_4byte(struct spi_nor *nor, bool enable)
> > }
> >
> > /**
> > - * st_micron_set_4byte() - Set 4-byte address mode for ST and Micron flashes.
> > + * spi_nor_en4_ex4_wen_set_4byte() - Set 4-byte address mode for ST and Micron
> > + * flashes.
> > * @nor: pointer to 'struct spi_nor'.
> > * @enable: true to enter the 4-byte address mode, false to exit the 4-byte
> > * address mode.
> > *
> > * Return: 0 on success, -errno otherwise.
> > */
> > -static int st_micron_set_4byte(struct spi_nor *nor, bool enable)
> > +static int spi_nor_en4_ex4_wen_set_4byte(struct spi_nor *nor, bool enable)
>
>
> Unrelated to this patch itself, but can we just have one set_4byte
> variant that uses WREN and drop the other one?
Hm, not sure that's a good idea to insert WEN instructions for
everyone, sounds like a recipe for regressions.
> I expect sending WREN should be harmless even for cmds that don't expect
> one.
In theory yes, but you know flash chips are capricious, so let's not
take the risk of breaking things :-).
>
> Rest looks good to me.
>
> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Vignesh Raghavendra <vigneshr@ti.com>
Cc: <Tudor.Ambarus@microchip.com>, <bbrezillon@kernel.org>,
<linux-mtd@lists.infradead.org>, <miquel.raynal@bootlin.com>,
<richard@nod.at>, <joel@jms.id.au>, <andrew@aj.id.au>,
<Nicolas.Ferre@microchip.com>, <alexandre.belloni@bootlin.com>,
<Ludovic.Desroches@microchip.com>, <matthias.bgg@gmail.com>,
<vz@mleia.com>, <michal.simek@xilinx.com>, <ludovic.barre@st.com>,
<john.garry@huawei.com>, <tglx@linutronix.de>,
<nishkadg.linux@gmail.com>, <michael@walle.cc>,
<dinguyen@kernel.org>, <thor.thayer@linux.intel.com>,
<swboyd@chromium.org>, <opensource@jilayne.com>,
<mika.westerberg@linux.intel.com>, <kstewart@linuxfoundation.org>,
<allison@lohutok.net>, <jethro@fortanix.com>, <info@metux.net>,
<alexander.sverdlin@nokia.com>, <rfontana@redhat.com>,
<linux-kernel@vger.kernel.org>,
<linux-mediatek@lists.infradead.org>,
<linux-aspeed@lists.ozlabs.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 01/23] mtd: spi-nor: Stop prefixing generic functions with a manufacturer name
Date: Fri, 13 Mar 2020 10:30:07 +0100 [thread overview]
Message-ID: <20200313103007.7d7ea6af@collabora.com> (raw)
In-Reply-To: <91394111-cbd6-c24e-485d-88fcd6825dc7@ti.com>
On Fri, 13 Mar 2020 11:34:55 +0530
Vignesh Raghavendra <vigneshr@ti.com> wrote:
> On 02/03/20 11:37 pm, Tudor.Ambarus@microchip.com wrote:
> > From: Boris Brezillon <bbrezillon@kernel.org>
> >
> > Replace the manufacturer prefix by something describing more precisely
> > what those functions do.
> >
> > Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
> > [tudor.ambarus@microchip.com: prepend spi_nor_ to all modified methods.]
> > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 88 ++++++++++++++++++-----------------
> > 1 file changed, 45 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index caf0c109cca0..b15e262765e1 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -568,14 +568,15 @@ static int spi_nor_read_cr(struct spi_nor *nor, u8 *cr)
> > }
> >
> > /**
> > - * macronix_set_4byte() - Set 4-byte address mode for Macronix flashes.
> > + * spi_nor_en4_ex4_set_4byte() - Enter/Exit 4-byte mode for Macronix like
> > + * flashes.
> > * @nor: pointer to 'struct spi_nor'.
> > * @enable: true to enter the 4-byte address mode, false to exit the 4-byte
> > * address mode.
> > *
> > * Return: 0 on success, -errno otherwise.
> > */
> > -static int macronix_set_4byte(struct spi_nor *nor, bool enable)
> > +static int spi_nor_en4_ex4_set_4byte(struct spi_nor *nor, bool enable)
>
>
> Sounds a bit weird, how about simplifying this to:
>
> spi_nor_set_4byte_addr_mode()
>
> Or if you want to be specific:
>
> spi_nor_en_ex_4byte_addr_mode()
You're right. Maybe we can simplify things by having a single function
that does optional steps based on new flags
SPI_NOR_EN_EX_4B_NEEDS_WEN
SPI_NOR_CLEAR_EAR_ON_4B_EXIT
This should probably be done in a separate patch though, so ack on the
spi_nor_en_ex_4byte_addr_mode() rename, assuming we also change the
bool argument name to enter.
>
> > {
> > int ret;
> >
> > @@ -604,14 +605,15 @@ static int macronix_set_4byte(struct spi_nor *nor, bool enable)
> > }
> >
> > /**
> > - * st_micron_set_4byte() - Set 4-byte address mode for ST and Micron flashes.
> > + * spi_nor_en4_ex4_wen_set_4byte() - Set 4-byte address mode for ST and Micron
> > + * flashes.
> > * @nor: pointer to 'struct spi_nor'.
> > * @enable: true to enter the 4-byte address mode, false to exit the 4-byte
> > * address mode.
> > *
> > * Return: 0 on success, -errno otherwise.
> > */
> > -static int st_micron_set_4byte(struct spi_nor *nor, bool enable)
> > +static int spi_nor_en4_ex4_wen_set_4byte(struct spi_nor *nor, bool enable)
>
>
> Unrelated to this patch itself, but can we just have one set_4byte
> variant that uses WREN and drop the other one?
Hm, not sure that's a good idea to insert WEN instructions for
everyone, sounds like a recipe for regressions.
> I expect sending WREN should be harmless even for cmds that don't expect
> one.
In theory yes, but you know flash chips are capricious, so let's not
take the risk of breaking things :-).
>
> Rest looks good to me.
>
> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
>
next prev parent reply other threads:[~2020-03-13 9:30 UTC|newest]
Thread overview: 183+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-02 18:07 [PATCH 00/23] mtd: spi-nor: Move manufacturer/SFDP code out of the core Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 01/23] mtd: spi-nor: Stop prefixing generic functions with a manufacturer name Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-13 6:04 ` Vignesh Raghavendra
2020-03-13 6:04 ` Vignesh Raghavendra
2020-03-13 6:04 ` Vignesh Raghavendra
2020-03-13 6:04 ` Vignesh Raghavendra
2020-03-13 9:30 ` Boris Brezillon [this message]
2020-03-13 9:30 ` Boris Brezillon
2020-03-13 9:30 ` Boris Brezillon
2020-03-13 9:30 ` Boris Brezillon
2020-03-13 14:30 ` Tudor.Ambarus
2020-03-13 14:30 ` Tudor.Ambarus
2020-03-13 14:30 ` Tudor.Ambarus
2020-03-13 14:30 ` Tudor.Ambarus
2020-03-13 15:50 ` Tudor.Ambarus
2020-03-13 15:50 ` Tudor.Ambarus
2020-03-13 15:50 ` Tudor.Ambarus
2020-03-13 15:50 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 02/23] mtd: spi-nor: Prepare core / manufacturer code split Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-13 6:08 ` Vignesh Raghavendra
2020-03-13 6:08 ` Vignesh Raghavendra
2020-03-13 6:08 ` Vignesh Raghavendra
2020-03-13 6:08 ` Vignesh Raghavendra
2020-03-13 14:41 ` Tudor.Ambarus
2020-03-13 14:41 ` Tudor.Ambarus
2020-03-13 14:41 ` Tudor.Ambarus
2020-03-13 14:41 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 03/23] mtd: spi-nor: Move SFDP logic out of the core Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-07 14:50 ` Boris Brezillon
2020-03-07 14:50 ` Boris Brezillon
2020-03-07 14:50 ` Boris Brezillon
2020-03-07 14:50 ` Boris Brezillon
2020-03-02 18:07 ` [PATCH 04/23] mtd: spi-nor: Expose stuctures and functions to manufacturer drivers Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-13 6:38 ` Vignesh Raghavendra
2020-03-13 6:38 ` Vignesh Raghavendra
2020-03-13 6:38 ` Vignesh Raghavendra
2020-03-13 6:38 ` Vignesh Raghavendra
2020-03-02 18:07 ` [PATCH 05/23] mtd: spi-nor: Add the concept of SPI NOR manufacturer driver Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 07/23] mtd: spi-nor: Move Eon bits out of core.c Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 06/23] mtd: spi-nor: Move Atmel " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 09/23] mtd: spi-nor: Move Everspin " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 08/23] mtd: spi-nor: Move ESMT " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 10/23] mtd: spi-nor: Move Fujitsu " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 11/23] mtd: spi-nor: Move GigaDevice " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 12/23] mtd: spi-nor: Move Intel " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-03 10:22 ` Mika Westerberg
2020-03-03 10:22 ` Mika Westerberg
2020-03-03 10:22 ` Mika Westerberg
2020-03-03 10:22 ` Mika Westerberg
2020-03-03 10:22 ` Mika Westerberg
2020-03-02 18:07 ` [PATCH 14/23] mtd: spi-nor: Move Macronix " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-04 7:20 ` chenxiang (M)
2020-03-04 7:20 ` chenxiang (M)
2020-03-04 7:20 ` chenxiang (M)
2020-03-04 7:20 ` chenxiang (M)
2020-03-02 18:07 ` [PATCH 13/23] mtd: spi-nor: Move ISSI " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 16/23] mtd: spi-nor: Move Spansion " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 15/23] mtd: spi-nor: Move Micron/ST " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 18/23] mtd: spi-nor: Move Winbond " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 17/23] mtd: spi-nor: Move SST " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 19/23] mtd: spi-nor: Move Catalyst " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 21/23] mtd: spi-nor: Move XMC " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 20/23] mtd: spi-nor: Move Xilinx " Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 22/23] mtd: spi-nor: Get rid of the now empty spi_nor_ids[] table Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 23/23] mtd: spi-nor: Trim what is exposed in spi-nor.h Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-02 18:07 ` Tudor.Ambarus
2020-03-07 14:49 ` Boris Brezillon
2020-03-07 14:49 ` Boris Brezillon
2020-03-07 14:49 ` Boris Brezillon
2020-03-07 14:49 ` Boris Brezillon
2020-03-13 8:13 ` Vignesh Raghavendra
2020-03-13 8:13 ` Vignesh Raghavendra
2020-03-13 8:13 ` Vignesh Raghavendra
2020-03-13 8:13 ` Vignesh Raghavendra
2020-03-13 8:27 ` Tudor.Ambarus
2020-03-13 8:27 ` Tudor.Ambarus
2020-03-13 8:27 ` Tudor.Ambarus
2020-03-13 8:27 ` Tudor.Ambarus
2020-03-03 7:15 ` [PATCH 00/23] mtd: spi-nor: Move manufacturer/SFDP code out of the core Joel Stanley
2020-03-03 7:15 ` Joel Stanley
2020-03-03 7:15 ` Joel Stanley
2020-03-03 7:15 ` Joel Stanley
2020-03-03 7:15 ` Joel Stanley
2020-03-03 7:28 ` Tudor.Ambarus
2020-03-03 7:28 ` Tudor.Ambarus
2020-03-03 7:28 ` Tudor.Ambarus
2020-03-03 7:28 ` Tudor.Ambarus
2020-03-03 7:28 ` Tudor.Ambarus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200313103007.7d7ea6af@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=Ludovic.Desroches@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=alexander.sverdlin@nokia.com \
--cc=alexandre.belloni@bootlin.com \
--cc=allison@lohutok.net \
--cc=andrew@aj.id.au \
--cc=bbrezillon@kernel.org \
--cc=dinguyen@kernel.org \
--cc=info@metux.net \
--cc=jethro@fortanix.com \
--cc=joel@jms.id.au \
--cc=john.garry@huawei.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=ludovic.barre@st.com \
--cc=matthias.bgg@gmail.com \
--cc=michael@walle.cc \
--cc=michal.simek@xilinx.com \
--cc=mika.westerberg@linux.intel.com \
--cc=miquel.raynal@bootlin.com \
--cc=nishkadg.linux@gmail.com \
--cc=opensource@jilayne.com \
--cc=rfontana@redhat.com \
--cc=richard@nod.at \
--cc=swboyd@chromium.org \
--cc=tglx@linutronix.de \
--cc=thor.thayer@linux.intel.com \
--cc=vigneshr@ti.com \
--cc=vz@mleia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.