On 11/12/21 11:50 PM, Michael Walle wrote:

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

Am 2021-10-29 19:26, schrieb Tudor Ambarus:

quoted

Clarify for what the flash_info flags are used for. Split them in
three categories:
1/ NON_SFDP_FLAGS: flags that indicate support that is not defined
   by the JESD216 standard in its SFDP tables.
2/ SFDP_FLAGS: flags that indicate support that can be discovered
   via SFDP. These flags are used when the flash does not define the
   SFDP tables. Used together with SPI_NOR_SKIP_SFDP flag.
3/ FIXUP_FLAGS: flags that indicate support that can be discovered
   via SFDP ideally, but can not be discovered for this particular
flash
   because the SFDP table that indicates this support is not defined by
   the flash. In case the table for this support is defined but has
wrong
   values, one should instead use a post_sfdp() hook to set the SNOR_F
   equivalent flag.

Manufacturer specific flags like USE_CLSR, USE_FSR, SPI_NOR_XSR_RDY,
will be removed in a future series.

While i like the partitioning of the flags, I don't really like
that masks etc. Why don't you just use different members, like
non_sfdp_flags sfdp_flags and fixup_flags?

because of memory concerns. But I think I can substitute the u32 flags
with u16 and u8 equivalents, so will end with the same memory footprint.
Will implement this, thanks.

ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel