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

Rafał Miłecki zajec5 at gmail.com
Sun Mar 6 12:53:49 PST 2016


On 5 March 2016 at 04:19, Brian Norris <computersforpeace at 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 at 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ł



More information about the linux-mtd mailing list