[PATCH] spi-nor: sfdp: Allow configuring unknown flashes using SFDP

[Petr Malat]

On Thu, May 27, 2021 at 07:22:19PM +0530, Vignesh Raghavendra wrote:
> >>> This change allows adding a support for flashes with correct SFDP
> >>> without recompilation of the kernel by setting sfdp-compatible property
> >>> in their node. Alternatively, sfdp_compatible module option can be used
> >>> to list JEDEC IDs of flashes, whose SFDP can be trusted. Star "*" can
> >>> be used to match all JEDEC IDs.
> >>
> >> I have skimmed through the patch. Before I look at it more closely, I 
> >> want to understand the use case for this patch. Why would you not want 
> >> to recompile the kernel when adding support for new hardware? Do you 
> >> want the ability to support flashes on devices that have already been 
> >> deployed in the field? Is it something that comes up frequently?
> > In my case the kernel is loaded from a USB mass storage device, which
> > can be preproduced and on stock (with the kernel already on it). With
> > my patch I can change the flash vendor without the need of updating
> > the image on already existing USB mass storage devices.
> > 
> > The patch is also useful for people who use distribution kernel as they
> > will not have to wait until (and if) the distribution updates it.
> 
> Don't need separate DT property or cmdline argument. There is no way to
> know if the SFDP tables are 100% valid when kernel is working with a
> "generic flash".
> Flashes are often replaced with newer revisions of the part that may/may
> not have valid SFDP tables.
> 
> So just rely on SFDP, when no valid entry is found in the manufacturer's
> flash_info[] while printing out a warning to user that this is just best
> effort support.

OK, I will rework it to fallback to SFDP by default. I put the safeguard
there to avoid a case when one has a flash requiring workarounds and then
does a kernel downgrade to a release where the flash is not known and uses
it. Should I make an opposite flag sfdp-incompatible or do we consider this
a theoretical scenario not worth of addressing in the code?
  Petr