linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Tudor.Ambarus@microchip.com, marek.vasut@gmail.com,
	dwmw2@infradead.org, computersforpeace@gmail.com,
	bbrezillon@kernel.org, richard@nod.at,
	linux-mtd@lists.infradead.org, Cyrille.Pitchen@microchip.com
Subject: Re: [PATCH 0/2] Untangle Spansion S25F{L|S}512S chip IDs
Date: Mon, 21 Jan 2019 20:40:23 +0300	[thread overview]
Message-ID: <fb92b27c-ed36-4b3b-9d0d-c568c8a9ce09@cogentembedded.com> (raw)
In-Reply-To: <0f8ec847-9e36-32c4-ecaa-8e8fcc1e3337@microchip.com>

Hello!

On 01/21/2019 11:28 AM, Tudor.Ambarus@microchip.com wrote:

>> Here's the set of 2 patches against the 'spi-nor/next' branch of 'linux-mtd.git'
>> repo. We're untangling the S25FS512S being taken for S25FL512S by the SPI NOR code
>> due to omitting the family ID byte in the latter chip's ID. I'm proposing to use
>> the full 6-byte JEDEC ID for both these chips.
> 
> The patch set is looking good. If these patches are based on Cyrille's
> suggestion from [1], we can give him credit by adding:

   No, I even had trouble finding where Cyrille was suggesting that. :-)
BTW, looking at his message, I feel somewhat perplexed:

"Maybe you can do the magic by placing a new INFO6() entry for the S25FL512S,
just before the legacy INFO() entry for S25FL512S. Indeed entries are tested
in the order they appear inside the spi_nor_ids[] array from spi_nor_read_id(),
so the INFO6() entry would be tested 1st, trying to match 6 bytes, then the
INFO() entry only trying to match 3 bytes."

   Did he actually mean adding a new INFO6() entry for S25FS512S? Else that
sentence doesn't make a lot of sense to me. :-) Also INFO() entry matches 5 bytes,
not 3. 
   Anyway, I'm suggesting to get rid of the INFO() entry for S25FL512S altogether --
and that's not a part of his suggestion... perhaps it's too risky; I'm not sure
why 5-byte matching was used for S25FL512S in the 1st place.

> Suggested-by: Cyrille Pitchen <cyrille.pitchen@microchip.com>
> We'll need his approval if that's the case.

[...]

> Of course, if this is not the case, and you came with this proposal without
> knowing about Cyrille's suggestion,

   Well, I remember you (or somebody else) pointing to that patchwork entry...
however, the idea I got was from the Renesas BSP patch.

> I'm not going to ask you to resubmit just
> for this little cosmetic change, just say.

   Thank you. :-)   

> Thanks,
> ta
> 
> [1] https://patchwork.kernel.org/patch/10595835/

MBR, Sergei

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2019-01-21 17:40 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 17:49 [PATCH 0/2] Untangle Spansion S25F{L|S}512S chip IDs Sergei Shtylyov
2019-01-16 17:51 ` [PATCH 1/2] mtd: spi-nor: add Spansion S25FS512S ID Sergei Shtylyov
2019-01-22 10:18   ` Tudor.Ambarus
2019-01-24 11:55   ` [1/2] " Boris Brezillon
2019-01-16 17:53 ` [PATCH 2/2] mtd: spi-nor: refine Spansion S25FL512S ID Sergei Shtylyov
2019-01-22 10:18   ` Tudor.Ambarus
2019-01-24 11:55   ` [2/2] " Boris Brezillon
2019-03-05 14:05   ` [PATCH 2/2] " Geert Uytterhoeven
2019-03-06 10:59     ` Tudor.Ambarus
2019-03-06 11:28     ` Tudor.Ambarus
2019-03-12 11:02     ` Geert Uytterhoeven
2019-01-21  8:28 ` [PATCH 0/2] Untangle Spansion S25F{L|S}512S chip IDs Tudor.Ambarus
2019-01-21 17:40   ` Sergei Shtylyov [this message]
2019-05-31 18:31 ` [PATCH v4] mtd: devices: m25p80: Use the spi-mem dirmap API Sergei Shtylyov
2019-06-18  4:30   ` Vignesh Raghavendra
2019-07-03 20:26 ` [PATCH] mtd: chips: gen_probe: kill useless initializer in mtd_do_chip_probe() Sergei Shtylyov
2019-09-17  4:24   ` Vignesh Raghavendra
2019-09-17 19:28 ` [PATCH] mtd: cfi_util: use DIV_ROUND_UP() in cfi_udelay() Sergei Shtylyov
2019-09-17 19:43   ` Geert Uytterhoeven
2019-09-17 19:53     ` Sergei Shtylyov
2019-09-17 21:23       ` Geert Uytterhoeven
2019-09-18  5:45         ` Vignesh Raghavendra
2019-09-27 20:15           ` Sergei Shtylyov
2019-10-25 20:26 ` [PATCH] mtd: spi-nor: use spi-mem dirmap API Sergei Shtylyov
2019-10-26  7:36   ` Boris Brezillon
2019-11-07 18:51     ` Sergei Shtylyov
2019-11-07 20:49 ` [PATCH v2] " Sergei Shtylyov
2019-11-07 20:56   ` Sergei Shtylyov
2019-11-07 20:56   ` Sergei Shtylyov
2019-11-09 19:35   ` Boris Brezillon
2019-11-10 19:49     ` Sergei Shtylyov
2020-02-01 20:55 ` [PATCH] mtd: spi-nor: use le32_to_cpu_array() Sergei Shtylyov
2020-02-17  0:03   ` 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=fb92b27c-ed36-4b3b-9d0d-c568c8a9ce09@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=Cyrille.Pitchen@microchip.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=bbrezillon@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=richard@nod.at \
    /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).