public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: David Bauer <mail@david-bauer.net>
Cc: Nick <vincent@systemli.org>,
	Tudor.Ambarus@microchip.com, linux-mtd@lists.infradead.org
Subject: Re: [PATCH 2/2] mtd: spi-nor: disable 16-bit-sr for macronix
Date: Thu, 20 Jan 2022 09:08:09 +0100	[thread overview]
Message-ID: <3d2837220261f2ba51569bb54ef334c7@walle.cc> (raw)
In-Reply-To: <8d578f8e-9cfd-58a0-940f-b085074c5d30@david-bauer.net>

Hi David,

Am 2022-01-19 21:36, schrieb David Bauer:
> On 1/19/22 16:49, Michael Walle wrote:

>> That being said. I'd prefer to have a sane default for that
>> flag - which is to _not_ set it by default. For now, we can
>> just remove the flag from spi_nor_init_default_params() and
>> move it into the manufacturer default init. Then we can
>> go through the flashes and remove the flag there.
> 
> I was working on a similar series in parallel - and i just want to
> confirm this before i submit it. [0]
> 
> Your take would be to remove the flag from spi_nor_init_default_params
> and place it in all vendor init-calls, right?

correct.

> My current take would be to add a new flag which denotes flashes that
> only have a single 8-bit SR, no second SR / CR.

but that new flag has the same meaning as the current one, no? In fact
I see you are just clearing the 16bit flag if the 8bit one is set.

Therefore, you have to bits for just two states. We want to
use less flags and IMHO this isn't good for readability.

Also it doesn't fix the bad default. I doubt anyone adding
a new vendor/flash is aware that the default is a WRSR with
16bit SR. Eg. I just had a quick look at gigadevice and it
doesn't seem to support this neither. Now depending on the
SFDP content the flag is overwritten anyways. But still.
I'd really like to get rid of this and just identify the
flashes that doesn't have an opcode to write the second
status register/configuration register.

-michael

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

      reply	other threads:[~2022-01-20  8:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-27  9:16 [PATCH 1/2] mtd: spi-nor: locking support for MX25L6405D vincent
2021-12-27  9:16 ` [PATCH 2/2] mtd: spi-nor: disable 16-bit-sr for macronix vincent
2021-12-29 14:08   ` Tudor.Ambarus
2021-12-31  9:10     ` Nick
2021-12-31  9:50       ` Nick
2022-01-19 15:49       ` Michael Walle
2022-01-19 20:36         ` David Bauer
2022-01-20  8:08           ` Michael Walle [this message]

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=3d2837220261f2ba51569bb54ef334c7@walle.cc \
    --to=michael@walle.cc \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mail@david-bauer.net \
    --cc=vincent@systemli.org \
    /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