From: <Tudor.Ambarus@microchip.com>
To: <boris.brezillon@collabora.com>
Cc: kstewart@linuxfoundation.org, alexandre.belloni@bootlin.com,
vigneshr@ti.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, 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 14:30:48 +0000 [thread overview]
Message-ID: <2838624.3XVpXx8FI0@192.168.1.3> (raw)
In-Reply-To: <20200313103007.7d7ea6af@collabora.com>
On Friday, March 13, 2020 11:30:07 AM EET Boris Brezillon wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> 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.
A single big function will be ugly to handle because of the
spansion_set_4byte() -> it uses a different opcode.
I like the nor->params>set_4byte hook.
I think that spi_nor_en4_ex4_set_4byte() can be renamed to spi_nor_set_4byte()
and be the only set_4byte() method exposed to manufacturers.
spansion_set_4byte() will be static in core.c and the rest will be private in
the manufacturer drivers.
Here's how the manufacturers enter and exit the 4 byte mode:
-> eon, gidadevice, issi, macronix, xmc use EN4B/EX4B
-> micron-st needs WEN -> private method as they are the only ones that
require this
-> newer spansion have a 4BAM opcode (new, public command), older spansion
flashes use BRWR (legacy in core.c, spansion_set_4byte())
-> winbond set_4byte method is hackish and may be reason for just a flash
fixup hook -> private method
Let me know if you agree with this, so I can respin later today or tomorrow.
cut
>
> > I expect sending WREN should be harmless even for cmds that don't expect
> > one.
The commands may be ok, but the flash can be corrupted. The WEL bit is NOT
reset after the completion of the EN4B command on macronix flashes, so the
gates are opened for some inadvertent commands that may corrupt the memory.
Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-03-13 14:31 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
2020-03-13 14:30 ` Tudor.Ambarus [this message]
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 06/23] mtd: spi-nor: Move Atmel bits out of core.c Tudor.Ambarus
2020-03-02 18:07 ` [PATCH 07/23] mtd: spi-nor: Move Eon " 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=2838624.3XVpXx8FI0@192.168.1.3 \
--to=tudor.ambarus@microchip.com \
--cc=Ludovic.Desroches@microchip.com \
--cc=Nicolas.Ferre@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=boris.brezillon@collabora.com \
--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).