linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Yicong Yang <yangyicong@hisilicon.com>
To: "Vignesh Raghavendra" <vigneshr@ti.com>,
	"Matthias Weißer" <m.weisser.m@gmail.com>,
	p.yadav@ti.com
Cc: sergei.shtylyov@cogentembedded.com, tudor.ambarus@microchip.com,
	richard@nod.at, me@yadavpratyush.com, john.garry@huawei.com,
	linuxarm@huawei.com, linux-mtd@lists.infradead.org,
	miquel.raynal@bootlin.com, alexander.sverdlin@nokia.com
Subject: Re: [PATCH 2/2] mtd: spi-nor: Disable the flash quad mode in spi_nor_restore()
Date: Fri, 4 Sep 2020 15:54:51 +0800	[thread overview]
Message-ID: <0c3dcb65-3a6d-d742-da83-3b71f5417115@hisilicon.com> (raw)
In-Reply-To: <10ab34bf-653a-ae72-286e-43b08dc7f909@ti.com>


On 2020/9/3 13:59, Vignesh Raghavendra wrote:
>
> On 9/2/20 3:42 PM, Yicong Yang wrote:
>> Hi Vignesh,
>>
>>
>> On 2020/9/2 15:50, Vignesh Raghavendra wrote:
>>> Hi Yicong,
>>>
>>> On 9/1/20 7:50 PM, Yicong Yang wrote:
>>>> Hi Mathhias and Pratyush,
>>>>
> [...]
>>> This will break backward compatibility... Imagine a new board being 
>>> flashed from Kernel. Before this series, QE bit would be set at the end of flashing
>>> and  ROM/bootloader (such as the one reported by Matthias) would work fine. 
>>> After this series, QE bit would no longer be set and would most likely
>>> break boot..
>>>
>>> I still am unable to understand what is the underlying problem that is 
>>> being addressed here?
>>>
>>> You mention addressing issue loading the driver in Quad mode first and reload it in
>>> Standard SPI/Dual mode. But per s25fs128s data sheet:
>>> "
>>> Quad Data Width (QUAD) CR1V[1]: When set to 1, this bit switches the data width of the device to 4-bit Quad Mode. That is, WP#
>>> becomes IO2 and IO3 / RESET# becomes an active I/O signal when CS# is low or the RESET# input when CS# is high. The WP#
>>> input is not monitored for its normal function and is internally set to high (inactive). The commands for Serial, and Dual I/O Read still
>>> function normally but, there is no need to drive the WP# input for those commands when switching between commands using
>>> different data path widths. Similarly, there is no requirement to drive the IO3 / RESET# during those commands (while CS# is low)."
>>>
>>> So setting QE bit should have no impact for serial/dual IO modes?
>> yes. and I reword the commit like below,  as suggested by Tudor and send a v2 patch. This thread is the v1 one.
>> "If the flash's quad mode is enabled, it'll remain in the quad mode when
>> it's removed. If we drive the flash next time in Standard/Dual SPI mode,
>> the QE bit is not cleared and the function of flash's WP# and RESET#/HOLD#
>> have been switched to IO2 and IO3 and are not restored."
>>
>> I believe we should restore the state of the flash when it's unloaded from the kernel. In previous code, if we load the flash
>> in Quad mode (originally in Standard SPI mode) and shutdown, its WP# and RESET# won't be restored correctly. Seems
>> the patch doesn't consider the condition that the flash has already in Quad mode before loaded and restore the flash
>> in a wrong state.
>>
> How do you load driver in Quad mode first and then reload in Single/Dual  
> mode later on? What is the use case?

we use module paramters to indicate the bus width in a private version of our driver,
yet this hasn't been upstreamed.

>
> I don't think relying on WP# and RESET#/HOLD# functionality for a QSPI 
> flash is right thing to do as these lines would act as data lines in 
> Quad mode and thus WP# wont really protect contents of the flash 
> when in Quad mode.
>
> Also, below patch is not fool proof even for hypothetical case that you are
> trying to solve: 
> Consider a scenario of kernel crash or hard reset, then there will be no 
> chance to call spi_nor_restore() and you would end up with QE bit set.. 
> Upon reboot, kernel will find that QE bit and will simply restore the same
> back on shutdown.

well this make sense to me.

>
> Given the fact that setting and unsetting NV bit causes wearing of this 
> rather important bit and also breaks backward compatibility of tools 
> that expect Kernel to set QE bit on flashing, I suggest reverting these patches:
>
> cc59e6bb6cd6 mtd: spi-nor: Disable the flash quad mode in spi_nor_restore()
> be192209d5a3 mtd: spi-nor: Add capability to disable flash quad mode

I've send the revert patches. You may found at :
https://lore.kernel.org/linux-mtd/1599205640-26690-1-git-send-email-yangyicong@hisilicon.com/

but I still have something uncertain, I think we should avoid setting the non-volatile bits
in spi-nor driver, should we?

Regards
Yicong

>
>
> Regards
> Vignesh
> .
>


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

  reply	other threads:[~2020-09-04  7:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16 13:02 [PATCH 0/2] Add support to Disable the flash quad mode Yicong Yang
2020-06-16 13:02 ` [PATCH 1/2] mtd: spi-nor: Add capability to disable " Yicong Yang
2020-07-02 11:07   ` Tudor.Ambarus
2020-06-16 13:02 ` [PATCH 2/2] mtd: spi-nor: Disable the flash quad mode in spi_nor_restore() Yicong Yang
2020-07-02 11:02   ` Tudor.Ambarus
2020-07-03 11:19     ` Pratyush Yadav
2020-07-03 11:52       ` Tudor.Ambarus
2020-07-06  6:47         ` Yicong Yang
2020-09-01  6:16   ` Matthias Weißer
2020-09-01  9:48     ` Pratyush Yadav
2020-09-01 10:08       ` Matthias Weißer
2020-09-01 11:11         ` Pratyush Yadav
2020-09-01 11:41     ` Yicong Yang
2020-09-01 14:20     ` Yicong Yang
2020-09-02  7:50       ` Vignesh Raghavendra
2020-09-02 10:12         ` Yicong Yang
2020-09-03  5:59           ` Vignesh Raghavendra
2020-09-04  7:54             ` Yicong Yang [this message]
2020-09-04  9:35               ` Matthias Weißer
2020-09-02 12:15       ` Matthias Weißer
2020-09-03  3:03         ` Yicong Yang
2020-09-03  5:33           ` Matthias Weißer
2020-09-04  7:56             ` Yicong Yang

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=0c3dcb65-3a6d-d742-da83-3b71f5417115@hisilicon.com \
    --to=yangyicong@hisilicon.com \
    --cc=alexander.sverdlin@nokia.com \
    --cc=john.garry@huawei.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=m.weisser.m@gmail.com \
    --cc=me@yadavpratyush.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=tudor.ambarus@microchip.com \
    --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;
as well as URLs for NNTP newsgroup(s).