[PATCH] mtd: spi-nor: Move n25q032 entry to Micron devices list

Rafał Miłecki zajec5 at gmail.com
Wed Oct 29 12:43:32 PDT 2014


On 29 October 2014 20:19, Marek Vasut <marex at denx.de> wrote:
> On Wednesday, October 29, 2014 at 06:40:46 PM, Rafał Miłecki wrote:
>> On 29 October 2014 15:05, Marek Vasut <marex at denx.de> wrote:
>> > On Wednesday, October 29, 2014 at 10:57:55 AM, Chunhe Lan wrote:
>> >
>> > [...]
>> >
>> > There are problems with this patch. Firstly, it misses any description
>> > explaining why the change took place at all. From an outside observer
>> > point of view, this change seems random at best.
>>
>> This looks like a normal cleaning for me.
>
> We can only guess, since the commit message is missing.

Maybe the topic says everything the patch does :)


>> > I can only speculate here, that your SPI NOR was
>> > recognised as some other part, right ? That's why moving the n25q032
>> > higher resolved the problem for you, right ?
>> >
>> > The problem is with the fragility of this code which matches the JEDEC
>> > ID and type of the SPI NOR. I recall Huang had some patches which tried
>> > to resolve this, not sure what the status of those patches is though.
>>
>> Wait, what? OK, this makes things tricky. Does this patch really
>> change any behavior? How does it happen? I don't see any duplicated
>> entry with the same JEDEC ID (0x20ba16).
>>
>> Could you give us some more details?
>
> Please see this thread:
> http://lists.infradead.org/pipermail/linux-mtd/2014-April/053308.html
>
> This is where the discussion about ordering in the table took place
> and where the patch for implementing the support for length of READID
> return value was proposed.

As I said, entry "n25q032" doesn't share JEDEC with anything else and
does not even have an ext_id. So I don't think it's related to the
s25fl128s vs. s25fl129p1 problem.

-- 
Rafał



More information about the linux-mtd mailing list