[PATCH v4] mtd: spi-nor: Improve reporting for software reset failures

[Pratyush Yadav]

On Thu, Oct 26 2023, Michael Walle wrote:

> Am 26. Oktober 2023 16:39:54 OESZ schrieb Pratyush Yadav <pratyush at kernel.org>:
>>On Thu, Oct 26 2023, AceLan Kao wrote:
>>
>>> From: "Chia-Lin Kao (AceLan)" <acelan.kao at canonical.com>
>>>
>>> When the software reset command isn't supported, we now report it
>>> as an informational message(dev_info) instead of a warning(dev_warn).
>>> This adjustment helps avoid unnecessary alarm and confusion regarding
>>> software reset capabilities.
>>
>>I still think the soft reset command deserves a warn, and not an info.
>>Because it _is_ a bad thing if you need to soft reset and are unable to
>>do so. Your bootloader (or linux if you rmmod and modprobe again) might
>>not be able to detect the flash mode and operate it properly. 
>
> agreed.. but.. 
>
>>I think we should just not unconditionally run this and instead only
>>call it when the flash reset is not connected -- that is only call this
>>under a check for SNOR_F_BROKEN_RESET, like we do for 4-byte addressing
>>mode.
>
> .. keep in mind that this is a restriction of the flash controller. the Intel one seems to be the only affected one (for now) and it's doing a reset (according to mika) on its own. 
>
> snor_broken_reset is a property of the flash. 

The documentation for the property says:

  broken-flash-reset:
    type: boolean
    description:
      Some flash devices utilize stateful addressing modes (e.g., for 32-bit
      addressing) which need to be managed carefully by a system. Because these
      sorts of flash don't have a standardized software reset command, and
      because some systems don't toggle the flash RESET# pin upon system reset
      (if the pin even exists at all), there are systems which cannot reboot
      properly if the flash is left in the "wrong" state. This boolean flag can
      be used on such systems, to denote the absence of a reliable reset
      mechanism.

So it is more a property of the system as a whole perhaps.

>
>
>>I don't have a strong opposition to this patch but I do think it is
>>fixing the problem in the wrong place.
>
> if the flash controller doesn't let you issue a soft reset (or does so on its own), what's the fix?

I think in those cases we could inquire the controller if it can do a
soft reset (probably via spi_mem_supports_op()). If it can not do so
_and_ the flash reset is broken, refuse to enter stateful modes like
8D-8D-8D or 4-byte addressing.

We already do so for the broken reset thing in
spi_nor_spimem_adjust_hwcaps():

	/*
	 * If the reset line is broken, we do not want to enter a stateful
	 * mode.
	 */
	if (nor->flags & SNOR_F_BROKEN_RESET)
		*hwcaps &= ~(SNOR_HWCAPS_X_X_X | SNOR_HWCAPS_X_X_X_DTR);

We should probably also add a spi_nor_spimem_can_soft_reset() (function
doesn't exist as of now -- just using an example name) check here.

Note: This restriction is placed only for X-X-X modes, and not 4-byte
addressing mode, which is an inconsistency on SPI NOR's part. See below.

Alternatively, if we are more willing to let users shoot themselves in
the foot if they so wish, we can just throw a warning that you might not
be able to recover, like we do in spi_nor_init():

	/*
	 * If the RESET# pin isn't hooked up properly, or the system
	 * otherwise doesn't perform a reset command in the boot
	 * sequence, it's impossible to 100% protect against unexpected
	 * reboots (e.g., crashes). Warn the user (or hopefully, system
	 * designer) that this is bad.
	 */
	WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
		  "enabling reset hack; may not recover from unexpected reboots\n");
	err = spi_nor_set_4byte_addr_mode(nor, true);

In that case, we would only run spi_nor_soft_reset() if the reset is
broken and let the user deal with the consequences if it fails.

-- 
Regards,
Pratyush Yadav