mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Michael Walle <mwalle@kernel.org>,
	Brian Norris <computersforpeace@gmail.com>,
	linux-mtd@lists.infradead.org
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	Pratyush Yadav <pratyush@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: micron-st: Add n25q064a WP support
Date: Tue, 30 Jul 2024 12:33:00 +0100	[thread overview]
Message-ID: <454deacb-88cc-4ab0-80b4-006d863a56d2@linaro.org> (raw)
In-Reply-To: <D32OADQF733D.3CVS3ZRPEBL2O@kernel.org>

Hi, Brian,

On 7/30/24 7:51 AM, Michael Walle wrote:
> Hi,
> 
> On Fri Jul 26, 2024 at 8:58 PM CEST, Brian Norris wrote:
>> These flash chips are used on Google / TP-Link / ASUS OnHub devices, and
>> OnHub devices are write-protected by default (same as any other
>> ChromeOS/Chromebook system). I've referred to datasheets, and tested on
>> OnHub devices.
> 
> Out of curiosity, there is also a hardware write protect switch
> somehow, right? At least that's my understanding how verify boot
> works.
> 
>>
>> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> 
> This looks good:
> Reviewed-by: Michael Walle <mwalle@kernel.org>
> 
> But could you have a look whether this flash supports SFDP.
> According to the datasheet it looks like it does. In that case,
> could you please dump it according to:
> https://docs.kernel.org/driver-api/mtd/spi-nor.html

This would help getting rid of the no_sfdp_flags and size from the flash
definition. Another reason is that the SFDP dump can help us
differentiate between flavors of the same flash, if it'll ever be the
case, and help us keep backward compatibility.

Also, if you care, would be good to extend the SPI NOR documentation on
how one shall test the Block Protection.

Cheers,
ta

  parent reply	other threads:[~2024-07-30 11:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-26 18:58 Brian Norris
2024-07-30  6:51 ` Michael Walle
2024-07-30 11:24   ` Pratyush Yadav
2024-07-30 11:33   ` Tudor Ambarus [this message]
2024-07-30 17:28     ` Brian Norris
2024-07-31  8:51       ` Tudor Ambarus
2024-07-31  9:05         ` Michael Walle
2024-07-31 17:31           ` Brian Norris
2024-08-05  9:01             ` Michael Walle
2024-07-31 17:10         ` Brian Norris

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=454deacb-88cc-4ab0-80b4-006d863a56d2@linaro.org \
    --to=tudor.ambarus@linaro.org \
    --cc=computersforpeace@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=mwalle@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /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

all inboxes | Powered by JetHome®