[PATCH] mtd: spi-nor: update flags for n25q128a

[PATCH] mtd: spi-nor: update flags for n25q128a

[Ezequiel Garcia]

Micron n25q128a support subsector (4K) erase, and the hardware
protection TB (Top/Bottom) bit. Let's update its flags.

Tested on n25q128a13.

Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
---
 drivers/mtd/spi-nor/spi-nor.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 1348a3247472..37f661bd14f3 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -864,8 +864,12 @@ static const struct flash_info spi_nor_ids[] = {
 	{ "n25q032a",	 INFO(0x20bb16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) },
 	{ "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
 	{ "n25q064a",    INFO(0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
-	{ "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
-	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
+	{ "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256,
+		 SECT_4K | SPI_NOR_QUAD_READ |
+		 SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
+	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256,
+		 SECT_4K | SPI_NOR_QUAD_READ |
+		 SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
 	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ) },
 	{ "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
 	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
-- 
2.7.0

Re: [PATCH] mtd: spi-nor: update flags for n25q128a

[Rafał Miłecki]

On 27 February 2016 at 03:07, Ezequiel Garcia
<ezequiel@vanguardiasur.com.ar> wrote:
> @@ -864,8 +864,12 @@ static const struct flash_info spi_nor_ids[] = {
>         { "n25q032a",    INFO(0x20bb16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) },
>         { "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>         { "n25q064a",    INFO(0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
> -       { "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
> -       { "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
> +       { "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256,
> +                SECT_4K | SPI_NOR_QUAD_READ |
> +                SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> +       { "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256,
> +                SECT_4K | SPI_NOR_QUAD_READ |
> +                SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },

We use one line per chip, so please keep stick to this formatting. I
can guess you wanted to follow kernel's coding style, but this adds
inconsistency. Also kernel's coding style allows lines over 80 chars
for better readibility. If we are ever going to change it, it should
be a separated patch affecting all entries.

-- 
Rafał

Re: [PATCH] mtd: spi-nor: update flags for n25q128a

[Ezequiel Garcia]

On 27 February 2016 at 08:25, Rafał Miłecki <zajec5@gmail.com> wrote:
> On 27 February 2016 at 03:07, Ezequiel Garcia
> <ezequiel@vanguardiasur.com.ar> wrote:
>> @@ -864,8 +864,12 @@ static const struct flash_info spi_nor_ids[] = {
>>         { "n25q032a",    INFO(0x20bb16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) },
>>         { "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>>         { "n25q064a",    INFO(0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>> -       { "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
>> -       { "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
>> +       { "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256,
>> +                SECT_4K | SPI_NOR_QUAD_READ |
>> +                SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
>> +       { "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256,
>> +                SECT_4K | SPI_NOR_QUAD_READ |
>> +                SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
>
> We use one line per chip, so please keep stick to this formatting. I
> can guess you wanted to follow kernel's coding style, but this adds
> inconsistency. Also kernel's coding style allows lines over 80 chars
> for better readibility. If we are ever going to change it, it should
> be a separated patch affecting all entries.
>

Sure, I can do that.

Also, I'll drop the HAS_LOCK and HAS_TB flags for now. These devices
need more work
for protection to work properly.

The protection is handled with TB, BP3-BP0 and currently we only
support TB,BP2-BP0.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCH] mtd: spi-nor: update flags for n25q128a

[Brian Norris]

On Sat, Feb 27, 2016 at 12:25:21PM +0100, Rafał Miłecki wrote:
> On 27 February 2016 at 03:07, Ezequiel Garcia
> <ezequiel@vanguardiasur.com.ar> wrote:
> > @@ -864,8 +864,12 @@ static const struct flash_info spi_nor_ids[] = {
> >         { "n25q032a",    INFO(0x20bb16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) },
> >         { "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
> >         { "n25q064a",    INFO(0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
> > -       { "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
> > -       { "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
> > +       { "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256,
> > +                SECT_4K | SPI_NOR_QUAD_READ |
> > +                SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> > +       { "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256,
> > +                SECT_4K | SPI_NOR_QUAD_READ |
> > +                SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> 
> We use one line per chip, so please keep stick to this formatting. I
> can guess you wanted to follow kernel's coding style, but this adds
> inconsistency. Also kernel's coding style allows lines over 80 chars
> for better readibility. If we are ever going to change it, it should
> be a separated patch affecting all entries.

He may have been taking the hint from my patch:

http://lists.infradead.org/pipermail/linux-mtd/2016-January/065252.html

I didn't feel like we needed to change all entries, personally, but I
think if we're going to start having 5+ flags, we have to have *some*
cutoff point. The lines in my patch were going to be 144 characters
long. That's more than half my (too) large monitor, so IMO that's not
really "better readability."

If you have a good suggestion that doesn't make my above patch too wide,
then I can try to go with that.

Brian

Re: [PATCH] mtd: spi-nor: update flags for n25q128a

[Rafał Miłecki]

On 5 March 2016 at 04:19, Brian Norris <computersforpeace@gmail.com> wrote:
> On Sat, Feb 27, 2016 at 12:25:21PM +0100, Rafał Miłecki wrote:
>> On 27 February 2016 at 03:07, Ezequiel Garcia
>> <ezequiel@vanguardiasur.com.ar> wrote:
>> > @@ -864,8 +864,12 @@ static const struct flash_info spi_nor_ids[] = {
>> >         { "n25q032a",    INFO(0x20bb16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) },
>> >         { "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>> >         { "n25q064a",    INFO(0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>> > -       { "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
>> > -       { "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
>> > +       { "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256,
>> > +                SECT_4K | SPI_NOR_QUAD_READ |
>> > +                SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
>> > +       { "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256,
>> > +                SECT_4K | SPI_NOR_QUAD_READ |
>> > +                SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
>>
>> We use one line per chip, so please keep stick to this formatting. I
>> can guess you wanted to follow kernel's coding style, but this adds
>> inconsistency. Also kernel's coding style allows lines over 80 chars
>> for better readibility. If we are ever going to change it, it should
>> be a separated patch affecting all entries.
>
> He may have been taking the hint from my patch:
>
> http://lists.infradead.org/pipermail/linux-mtd/2016-January/065252.html
>
> I didn't feel like we needed to change all entries, personally, but I
> think if we're going to start having 5+ flags, we have to have *some*
> cutoff point. The lines in my patch were going to be 144 characters
> long. That's more than half my (too) large monitor, so IMO that's not
> really "better readability."
>
> If you have a good suggestion that doesn't make my above patch too wide,
> then I can try to go with that.

OK, use your maintainer hat and keep this code the way you prefer :)

-- 
Rafał