linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>
> 


  reply	other threads:[~2020-03-13  9:30 UTC|newest]

Thread overview: 39+ 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 ` [PATCH 01/23] mtd: spi-nor: Stop prefixing generic functions with a manufacturer name Tudor.Ambarus
2020-03-13  6:04   ` Vignesh Raghavendra
2020-03-13  9:30     ` Boris Brezillon [this message]
2020-03-13 14:30       ` 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-13  6:08   ` Vignesh Raghavendra
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-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-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 ` [PATCH 07/23] mtd: spi-nor: Move Eon bits out of core.c Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 06/23] mtd: spi-nor: Move Atmel " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 08/23] mtd: spi-nor: Move ESMT " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 09/23] mtd: spi-nor: Move Everspin " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 10/23] mtd: spi-nor: Move Fujitsu " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 12/23] mtd: spi-nor: Move Intel " Tudor.Ambarus
2020-03-03 10:22   ` Mika Westerberg
2020-03-02 18:07 ` [PATCH 11/23] mtd: spi-nor: Move GigaDevice " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 13/23] mtd: spi-nor: Move ISSI " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 14/23] mtd: spi-nor: Move Macronix " Tudor.Ambarus
2020-03-04  7:20   ` chenxiang (M)
2020-03-02 18:07 ` [PATCH 16/23] mtd: spi-nor: Move Spansion " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 15/23] mtd: spi-nor: Move Micron/ST " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 18/23] mtd: spi-nor: Move Winbond " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 17/23] mtd: spi-nor: Move SST " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 19/23] mtd: spi-nor: Move Catalyst " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 21/23] mtd: spi-nor: Move XMC " Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 20/23] mtd: spi-nor: Move Xilinx " 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 ` [PATCH 23/23] mtd: spi-nor: Trim what is exposed in spi-nor.h Tudor.Ambarus
2020-03-07 14:49   ` Boris Brezillon
2020-03-13  8:13   ` Vignesh Raghavendra
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: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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).