Flash API: road forward and the no_explicit_erase capability

[de-nordic]

Introduction

Following discussions here:
Original issue: #62228
Original PR #67687
https://discord.com/channels/720317445772017664/883445484923011172/threads/1220424912829681846

I have decided that slowly extending Flash API into general code/storage access API is the way to go.

Therefore I will be adding the capability flag which will be informing code at run-time on what kind device it is working, and additional Kconfig options, in a HAS form, to inform software stack, and build system, on capabilities provided by compiled in drivers.

Problem description

We are in need of support for devices that do not require device, in a way that allows software stack to work efficiently but also not take in code that would never be used. As I have already explained in mentioned discussions software does work better when it does not have to erase, so it is happy to know that; I also do understand that our current solutions have been mainly focused around Flash - and that is where new storage come.
This means that there is no quick and easy way to transition to new kind of API and the path is to slowly move Flash API from Flash oriented API into general raw storage access type API, by breaking device into the features they represent, and adapting software to work on these features, rather than on types of devices - as every storage device can be described by various properties, often common with other technologies.

Adding more layers do not fix the issue, it will just add additional layers on top of what is already becoming obsolete. Adding more layers will just add opportunity to further diverge software stack to rely on co-existing APIs doing similar task, making it even harder to transition in the future. And the layers will have to break devices to features or recognize them by technology anyway.

Proposed change

Slowly adapt Flash API into generic storage API based on device capabilities rather than device types.

Proposed change (Detailed)

The change will happen in stages.

Stage 0

• Addition of no_explicit_erase capability to, currently, limited number of devices that have no erase requirement prior to write (MRAM,FRAM,RRAM, and so on, and yes I have agreed that adding explicit_erase flag to all flash drivers may be unneeded change);
• Addition of definition FLASH_HAS_NO_EXPLICIT_ERASE and FLASH_HAS_EXPLICIT_ERASE Kconfig options for drivers to advertise support or lack thereof to software stack and subsystems;
• Addition of FLASH_CAPS_EXPLICIT_ERASE and FLASH_CAPS_NO_EXPLICIT_ERASE macros to be used on flash_parameters to check for the capability; these macros are provided in an attempt to blackbox the flash_parameters;
• flash_erase can now return -ENOSYS as drivers do not have to implement erase (they actually never had to, by the API Design Guidelines anyway)
• Addition of flash_flatten and flash_fill, where the former is used as replacement for flash_erase where erase has been used for cleaning storage, rather than enforced by used device; the later is just addition to allow users quickly fill devices with value with no need to repeat code between units;
• Changes in samples and test scenarios and samples to correctly work with devices that do not require erase;
• Change in Flash Simulator that now allows it to pretend device without erase
• Drivers have been updated with selection of proper Kconfig option, listed above, according to capability they have;
• Subsystems have been altered to use the new capability.

And no, adding new layer would not save us from doing all the subsystem, test and sample changes, it could just allow us to postpone them for some time.

Stage 1

Once we merge PR for stage 0 we go into advertisement phase, where Developers, via mailing list, will be informed and reminded that the flash_erase and flash_area_erase are able now to return -ENOSYS and there is intention to remove the code from drivers, including support for pages layout and so on, as this is needles code. This will limit dead code for, or needlessly existing code, in software solutions that are build around device that are not providing them anyway.

Stage 2

Modules adaptation: all (three of them, and all based on MCUboot), will have to adapt. I take responsibility for adapting MCUboot.
They will have to work with devices that do not provide erase and do not have paged layout, require erase and have paged layout, or work with both types of devices at once.

Stage 3

This is rather distant stage from Stage 2.
This will be making erase callback and pages support optional for devices and will follow with removal of the code, depending on vendor approach to that.

Stage N

After years of adapting Flash API to common storage API it will be renamed. Or not. We write to EEPROMs and they are still ROM, so I guess we will just get used to Flash API being the storage raw access API.

Dependencies

Users will slowly adapt to new reality. Dividing the change into stages should not end up in shocking the community.
Projects that have been, to this point, sure that they work with Flash type (progra-erase, erase required, explicit-erase) devices will have to slowly adapt to reality that this is no longer the case. We will give them a chance and opportunity.

Concerns and Unresolved Questions

I had to modify some subsystems, often with by best knowledge and assistance from samples and tests that have been provided for them. I have run a lot of these configurations on nrf54l15 RRAM base device in my possession and on Flash Simulator altered to support no-explicit-erase devices.

Alternatives

Adding new layer that is based on device type: FLASH, FRAM, RRAM, MRAM, EEPROM, etc:

• such a layer would still require code to check what kind of device it is working with, just in clumsy way because first we multiplex all device into one layer, marking them with tech they represent, to then demultiplex them using the tech they represent;
• additional layer code will affect: app size, icache (more paths not taken but read), SPI (more code to pull in XIP and so on),
• additional will make it harder to relocate code into external flash: now you have additional things to relocate with dependencies
• more time is passed going through layers

Additional layer based on capabilities:

• now the tech is broken into capabilities at a new layer; so layer that does not really know what device offers, and what drivers actually knows, attempts to represent device as capabilities;
• all the other issues above

Additional layer that takes capabilities from drivers and represents them in higher layer:

• yeah so just another layer

DTS property that will state what kind of device there is (I have tried that actually at the beginning):

• the property allows you only to set a difference from base set of properties; this means that you can only tell that some of devices you have have extra property, but you can not tell whether there are any that do not have it at all; this means that you can not optimize your code, at compile time, for your system that consists only of devices that have the property (capability).
• the DTS property would not change behavior of device, and probably should not alter driver which should represent device perfectly for a system, it would affect subsystems - this means that such property is attached to incorrect object, because it is attached to device definition yet it control software above it.
• the additional problem with DTS property is that it is hard to figure all devices that have it without introducing some compatibility string to first introduce devices that may have it, in entire system; this leads to one of below:
  • just introduce compatibility for each new capability: no need for property but a lot of compatibilities;
  • special compatibility with properties for capabilities: we end up adding the compatibility to every device of storage type;
  • find devices by DTS property (for example the no_explicit_erase): this introduces common namespace for all DTS properties, which means that once property is defined for on type of device no other can use it.
• DTS entry is not required at all for devices to be created as we have https://docs.zephyrproject.org/latest/kernel/drivers/index.html#c.DEVICE_DEFINE that allows to create devices without DT entries.

[Laczen]

The proposed solution in stage0 does not scale well. The first "capability" that is added is forcing drivers to be split up in drivers with and without the capability. When applying this methodology to each capability that will be added will force drivers to be split up in multiple parts.

[de-nordic]

The proposed solution in stage0 does not scale well. The first "capability" that is added is forcing drivers to be split up in drivers with and without the capability. When applying this methodology to each capability that will be added will force drivers to be split up in multiple parts.

There is possibility of a single split now, and it not even sure whether it happens.
This capability is change in base. If flash would be, as it should, derivative of eeprom, then eeprom would be the base, CONFIG_EEPROM_HAS_EXPLICIT_ERASE would be the only Kconfig, because it would be capability added over the base.
There is a small risk of having to teardown the base even furthe.

This has been explained many times, and you perfectly understand that, because you have followed the pattern in your alternate PRs.

For these interested the link to discussion is on top of this issue.

[Laczen]

The proposed solution in stage0 does not scale well. The first "capability" that is added is forcing drivers to be split up in drivers with and without the capability. When applying this methodology to each capability that will be added will force drivers to be split up in multiple parts.

There is possibility of a single split now, and it not even sure whether it happens. This capability is change in base. If flash would be, as it should, derivative of eeprom, then eeprom would be the base, CONFIG_EEPROM_HAS_EXPLICIT_ERASE would be the only Kconfig, because it would be capability added over the base. There is a small risk of having to teardown the base even furthe.

This has been explained many times, and you perfectly understand that, because you have followed the pattern in your alternate PRs.

For these interested the link to discussion is on top of this issue.

You seem to be missing the point. The solution in stage0 is setting the Kconfig on the driver level for the explicit_erase capability, for any other capability the same approach should be taken as the same reasons for selecting the chosen approach apply for this new capability. Any possible compile optimizations also apply to this new capability. This will lead to each driver needing to disable the new capability at the driver level. As an example think about adding nand flash capabilities, only a nand flash will have the ability to access oob data and/or ecc data, when this is added at the driver level all other drivers will need to disable the oob access and/or the ecc data access to be able to find out if only drivers with oob access and/or ecc access are selected. As said, this doesn't scale well.

[de-nordic]

You seem to be missing the point. The solution in stage0 is setting the Kconfig on the driver level for the explicit_erase capability, for any other capability the same approach should be taken as the same reasons for selecting the chosen approach apply for this new capability. Any possible compile optimizations also apply to this new capability. This will lead to each driver needing to disable the new capability at the driver level. As an example think about adding nand flash capabilities, only a nand flash will have the ability to access oob data and/or ecc data, when this is added at the driver level all other drivers will need to disable the oob access and/or the ecc data access to be able to find out if only drivers with oob access and/or ecc access are selected. As said, this doesn't scale well.

ECC is not a good example for that as in most cases everybody just implements proven ECC algorithm or recommended by manufacturer directly in a driver, and misses the main reason why the ECC in the hardware is in the first place; if somebody would like to implement ECC in software stack, that rather would be an addition on top of what storage offers in hardware, but lets go.

So somebody implements the additional ECC in software stack to amend lack of it in hardware (so if (!fparams->caos.wbs_ecc) path; for such a single case we are not probably going to add the opposite Kconfig in flash, and they can have own Kconfig to turn on/off the flag for the subsystem.
Lets assume years pass and now we have five, or N, subsystems that have that, then one of two things may happen:

• users/customers want a single Kconfig to turn of the software ECC path in all subsystems because they have no hardware without ECC in their setup (they may even provide the change for us!), then yeah we will consider adding the negative flag; users want this, what are going to do, say no?
• there is no longer any equipment that lacks ECC and customers want removal of wbs_ecc and FLASH_HAS_WBS_ECC because they are pointless to; yeah, we will consider doing that too (and the software scales down!)

Scalability is multi-dimensional issue. Ability to remove code that makes no sense when system lack something, is scalability because it gives back resources that other systems demand. Does that require extra work by maintainers (affects scalability of organization): probably, but I think users would like system to scale itself as much as possible without having to do extra steps in Kconfigs/dts, the occasional spike in maintainer involvement will happen, but we grow too.

I also like this scalability: customer pays $ for N size storage and does not ask me why there is 0.1N used does nothing for their configuration. I like when time I spend cutting, by hand, things that are not needed scales down.

[Laczen]

Regarding the ECC, this is about hardware ecc like used on some nxp and st devices. These generate a nmi when a uncorrectable error occurs and allow retrieving the data as is. When used for xip the nmi is ok, when used for storage this nmi should be converted in a different error. The ECC is as such a hardware feature (capability).

Next to the fact that the proposed solution does not scale well, there is another limitation of the solution: on boards where both "explicit-erase" and "no-explicit-erase" devices are used the solution does not allow subsystem to reduce the code size. This is a result of not reflecting the capabilities in dts.

I really don't understand why I need to repeat myself. If you as a maintainer decide that this is the way to go you should make clear to all your users what the implications of this decision are. Be open about the limitations and the work they will create. Don't complain about someone else doing this.

[de-nordic]

Regarding the ECC, this is about hardware ecc like used on some nxp and st devices. These generate a nmi when a uncorrectable error occurs and allow retrieving the data as is. When used for xip the nmi is ok, when used for storage this nmi should be converted in a different error. The ECC is as such a hardware feature (capability).

Have you looked through our drivers? The any XIP stuff that is done is either initialization or marking that device is working with XIP. XIP does not do flash_read, that is done by SoC peripheral, it (mostly) works without drivers. flash_read has to live along XIP.

If you want different NMI behavior depending whether XIP causes it or flash_read, you basically have to switch NMI on callback entry. Of course now XIP can not interrupt the read callback, if that is allowed by device, because you end up with wrong NMI.
Lets assume though that you have a single NMI, and flash driver uses the RAM-XIP mapping and returns different errors when XIP and flash_read happens. Now you have a problem because flash_read behaves differently when you read XIP region and vs other regions: you can have XIP errors reported on flash_read, by XIP path of NMI.

Next to the fact that the proposed solution does not scale well, there is another limitation of the solution: on boards where both "explicit-erase" and "no-explicit-erase" devices are used the solution does not allow subsystem to reduce the code size. This is a result of not reflecting the capabilities in dts.

The Kconfigs expose what drivers offer. Subsystems have to present what they offer according to what they work with. User has to choose what they finally want.
Yes it is possible to have path that will not be used, because subsystem is ready to serve a device it will not be called to serve, but that needs to be tuned in subsystem options. There is no automatic solution to every problem.

DTS capability works here even worse, because it does not control how device behaves (device is as it is), but rather how multiple independent subsystems see it: the device will not change. This means that there is property introduced into device that controls something other than the device itself - that is bad modular design.

Lets assume that the property is attached to partition: so this is property exposed to subsystems, lets say you have two subsystems using, interchangeably, that partition at-run time; now you have a property that tunes two independent subsystems, that is not defined for these subsystems.
That creates conundrum for an user: how to make both systems work if efficiently if the property tunes one at the cost of the other. What you do? Add an instance flag that can overwrite that?
That is bad design to overwrite misplaced subsystem property.

I have started my "already explained" stuff here https://github.com/zephyrproject-rtos/zephyr/files/14795769/QA.no-erase-flash.pdf, slides 8, 9 and 12 (will be updating it, with more, didn't have time).

I really don't understand why I need to repeat myself. If you as a maintainer decide that this is the way to go you should make clear to all your users what the implications of this decision are. Be open about the limitations and the work they will create.

Same complain on my side. DTS limitations explained above. It is easy to advertise a solution without going into details. I did go into details, and I have started the work with DTS flag and have abandoned the idea.

Don't complain about someone else doing this.

OK. Show reviewers where I complain about deficiencies in my proposal being pointed out rather then being forced to repeat myself.

[Laczen]

Regarding the ECC, these devices should have a ecc_error_handler defined in the flash driver that allows doing the appropiate action. In some cases this might be stop execution, in other cases this might continue with bad data, and possibly other action,...

Regarding the dts capability: why add information to a partition, this clearly belongs to the flash node. When a compatible is added to the flash node that describes the capability the driver can pick this up, verify it (error out if needed) and use it (if the driver can support multiple capabilities). This is the way dts is used for all of our driver parameters, the capability could be just the same.
Is there a possibility to create errors by defining a wrong capability to a device, yes there is. As these compatibles would be set in dtsi files the risk is small that an error will appear. And if a user does this in a overlay file without understanding the consequences his system will just generate errors.
Does this allow checking if all device have or miss the capability ? No it has not, but is this needed if all subsystems can figure it out themselves.

[Laczen]

Sorry about the closing, pushed the wrong button....

[de-nordic]

Regarding the ECC, these devices should have a ecc_error_handler defined in the flash driver that allows doing the appropiate action. In some cases this might be stop execution, in other cases this might continue with bad data, and possibly other action,...

Nothing stops driver from doing so.

Regarding the dts capability: why add information to a partition,

That was your idea at some point, just bringing it up why it does not solve a problem with below:

this clearly belongs to the flash node. When a compatible is added to the flash node that describes the capability the driver can pick this up, verify it (error out if needed) and use it (if the driver can support multiple capabilities). This is the way dts is used for all of our driver parameters, the capability could be just the same.

https://github.com/zephyrproject-rtos/zephyr/files/14795769/QA.no-erase-flash.pdf, 12 explaining write_block_size.

Is there a possibility to create errors by defining a wrong capability to a device, yes there is. As these compatibles would be set in dtsi files the risk is small that an error will appear. And if a user does this in a overlay file without understanding the consequences his system will just generate errors.

Explained here: #71270 (comment), and it is not about "wrong capability" but how it affects sub-systems above it (multiple at once).

Does this allow checking if all device have or miss the capability ? No it has not, but is this needed if all subsystems can figure it out themselves.

Then subsystems are figuring out their own property from parameter that does not belong to them.

Explained here: #71270 (comment),

[Laczen]

Regarding the ECC, these devices should have a ecc_error_handler defined in the flash driver that allows doing the appropiate action. In some cases this might be stop execution, in other cases this might continue with bad data, and possibly other action,...

Nothing stops driver from doing so.

This is exactly why the proposal does not scale well:

Add a capability FLASH_HAS_ECC all drivers that do not have it need to select FLASH_HAS_NO_ECC,
Add a capability FLASH_HAS_OOB all drivers that do not have it need to select FLASH_HAS_NO_OBB,
Add a capability FLASH_HAS_OTP all drivers that do not have it need to select FLASH_HAS_NO_OTP,
...
Every capability that is added requires change to all driver Kconfigs.

Regarding the dts capability: why add information to a partition,

That was your idea at some point, just bringing it up why it does not solve a problem with below:

It was never proposed this way, what was proposed was to add information about the backend (by using a compatible) to a partitions (the parent of a partition) definition. This is a way to allow defining partitions over a range of device types and allowing devices to be a true representation of what they are. nvmp as proposed in #70979 just takes the information from devicetree to create a unified way to access storage devices.

In #71158 an alternative was proposed that would be limited to flash devices, the disadvantage of #71158 over #70979 is that it forces all storage devices to use the flash interface.

this clearly belongs to the flash node. When a compatible is added to the flash node that describes the capability the driver can pick this up, verify it (error out if needed) and use it (if the driver can support multiple capabilities). This is the way dts is used for all of our driver parameters, the capability could be just the same.

https://github.com/zephyrproject-rtos/zephyr/files/14795769/QA.no-erase-flash.pdf, 12 explaining write_block_size.

There is nothing wrong or broken about write-block-size, it is defined as an optional property and as such does not allow to be retrieved as a global property. When it is defined drivers (and subsystems on top of drivers) can utilize it. Should drivers check the specified value and adapt their behavior accordingly, probably yes. Is the definition to limited to cover all use cases: maybe, some drivers might not be able to respect the specified write-block-size depending on the operating voltage. Is it broken, no.

Is there a possibility to create errors by defining a wrong capability to a device, yes there is. As these compatibles would be set in dtsi files the risk is small that an error will appear. And if a user does this in a overlay file without understanding the consequences his system will just generate errors.

Explained here: #71270 (comment), and it is not about "wrong capability" but how it affects sub-systems above it (multiple at once).

Does this allow checking if all device have or miss the capability ? No it has not, but is this needed if all subsystems can figure it out themselves.

Then subsystems are figuring out their own property from parameter that does not belong to them.

Explained here: #71270 (comment),

As drivers and subsystems are getting their information from the same source, the dts file, there should not be any difference between getting the information from the driver or utilizing the information from devicetree. Allowing subsystems to retrieve this information at compile time instead of runtime reduces codesize. If the driver does not honor the specifications from devicetree this would be driver error.

In general the power of the compatible construct in devicetree is highly underused. Defining and utilizing compatible allows drivers to be combined and share code. It also allows creating device-types and grouping devices as a means to e.g. walk over all devices of a specified type (ad converter, sensor, ...): just create a compatible "zephyr,ad-converter", "zephyr,sensor" add this to the nodes and done. All macros to work with the compatible are already in place.

[de-nordic]

Nothing stops driver from doing so.

This is exactly why the proposal does not scale well:

The response is not relevant to my response.

Add a capability FLASH_HAS_ECC all drivers that do not have it need to select FLASH_HAS_NO_ECC, Add a capability FLASH_HAS_OOB all drivers that do not have it need to select FLASH_HAS_NO_OBB, Add a capability FLASH_HAS_OTP all drivers that do not have it need to select FLASH_HAS_NO_OTP, ... Every capability that is added requires change to all driver Kconfigs.

In the beginning everything is addition over the base. If at some point users find that they want to have a way to figure out whether there are no devices without a feature supported in their build, then we will probably add the negative Kconfig (I have answered this here already #71270 (comment))

It was never proposed this way, what was proposed was to add information about the backend (by using a compatible) to a partitions (the parent of a partition) definition. This is a way to allow defining partitions over a range of device types and allowing devices to be a true representation of what they are. nvmp as proposed in #70979 just takes the information from devicetree to create a unified way to access storage devices.

Making Flash API generic storage device access API does the same.

In #71158 an alternative was proposed that would be limited to flash devices, the disadvantage of #71158 over #70979 is that it forces all storage devices to use the flash interface.

We are slowly turning Flash API into generic storage API, yes.

So pointless addition of code to verify something that driver provides or not, and can easily advertise without checking DTS.
And write_block_size is example here, where drivers verify it alignment to what the hardware can do and that is it.

https://github.com/zephyrproject-rtos/zephyr/files/14795769/QA.no-erase-flash.pdf, 12 explaining write_block_size.

There is nothing wrong or broken about write-block-size, it is defined as an optional property and as such does not allow to be retrieved as a global property. When it is defined drivers (and subsystems on top of drivers) can utilize it. Should drivers check the specified value and adapt their behavior accordingly, probably yes. Is the definition to limited to cover all use cases: maybe, some drivers might not be able to respect the specified write-block-size depending on the operating voltage. Is it broken, no.

If it is not a global property and if it is optional then subsystem can not use it reliably, and again they keep on picking their own property from the wrong node.

As drivers and subsystems are getting their information from the same source, the dts file, there should not be any difference between getting the information from the driver or utilizing the information from devicetree. Allowing subsystems to retrieve this information at compile time instead of runtime reduces codesize. If the driver does not honor the specifications from devicetree this would be driver error.

Subsystems should not poke around nodes that do not directly belong to them.
Drivers should not query properties that do not affect them.
Adding code that verifies property of a device that can not be altered makes no sense.

In general the power of the compatible construct in devicetree is highly underused. Defining and utilizing compatible allows drivers to be combined and share code. It also allows creating device-types and grouping devices as a means to e.g. walk over all devices of a specified type (ad converter, sensor, ...): just create a compatible "zephyr,ad-converter", "zephyr,sensor" add this to the nodes and done. All macros to work with the compatible are already in place.

"For a device driver selection"

https://github.com/devicetree-org/devicetree-specification/releases/download/v0.4/devicetree-specification-v0.4.pdf

And, it is possible to create device driver without even touching DTS, at run time, and attach it to a bus, for example SPI. Yes, you would probably have to add Kconfigs to add the _HAS_ but you have to do that anyway (to get FLASH_HAS_DRIVER for example, to make it work with other subsystems).
(https://docs.zephyrproject.org/latest/kernel/drivers/index.html#c.DEVICE_DEFINE)

[Laczen]

@de-nordic, the recently proposed RFC #71773 when applied to storage devices would make it unnecessary to extend the flash api to other storage devices. Whatever storage device could be defined with a minimal (fit to purpose) api and it is possible to retrieve what the device type is. This makes it possible to create a solution similar to nvmp without any addition to the dts.

A layer for working with partitions (that is still needed on top of the currect proposal) could then be used to provide a unified way of working with these devices, and their capabilities could be reflected in the existence of certain routines by this unified layer (e.g. a erase function being NULL if there is no erase). This layer could provide support for partitioning also on disks. The interface for working with partitions could be (with a block_size or write_block_size being the base parameter):
a. blockread: bread(const struct part_info *info, uint32_t bstart, void *data, size_t bcount),
b. blockwrite: bwrite(const struct part_info *info, uint32_t bstart, const void *data, size_t bcount) or -ENOSYS if not supported,
c. blockerase: berase(const struct part_info *info, uint32_t bstart, size_t bcount) or -ENOSYS if not supported,
The part_info struct would contain a pointer to the device and this could be used to find out what kind of device is used and to retrieve/use more detailed info on the device type.

This method would also allow support for nand-flash with their own peculiarities to be a separate type of devices with dedicated is_bad, set_bad, ecc_error routines to allow full support for these devices (without affecting the interface of nor-flash devices).

There would be no Kconfig options (other than the selection of a type of device) to describe device properties and also there would be no addition to the dts.

Devices like fram, mram, ... could be defined as flash-devices as is done today but they could also be added under a separate device-type without any erase functionality or properties.

The fixed-partition compatible could be used on flash, eeprom, disks, ... and for disks the partitions could be registered as a separate disk in the disk access method.

[de-nordic]

@de-nordic, the recently proposed RFC #71773 when applied to storage devices would make it unnecessary to extend the flash api to other storage devices. Whatever storage device could be defined with a minimal (fit to purpose) api and it is possible to retrieve what the device type is. This makes it possible to create a solution similar to nvmp without any addition to the dts.

This does not change anything. This would only land flash class devices in specific class section and check whether devices passed to that class API syscalls have api objects defined within that section.

A layer for working with partitions (that is still needed on top of the currect proposal) could then be used to provide a unified way of working with these devices, and their capabilities could be reflected in the existence of certain routines by this unified (...)

I am not hiding my intention, for more than three years now, that I am willing to make fixed-partition devices of Flash API kind and remove the flash map, leaving the FIXED_PARTITION macros only.
One API for all.

There is no need for blockwhatever, we already have that is flash_*functions are capable of doing the job, we even have block restrictions imposed by write-block-size (on subsystems), we only, not really but that is for other discussion, missing read-block-size.

This method would also allow support for nand-flash with their own peculiarities to be a separate type of devices with dedicated is_bad, set_bad, ecc_error routines to allow full support for these devices (without affecting the interface of nor-flash devices).

NOR and other also can have those, in the end we will end up with multiple API having *_{read|write|erase|is_bla , from From #64732:

There would be no Kconfig options (other than the selection of a type of device) to describe device properties and also there would be no addition to the dts.

Both PRs are addressing different issues.

Devices like fram, mram, ... could be defined as flash-devices as is done today but they could also be added under a separate device-type without any erase functionality or properties.

One API for raw devices of storage type is the goal.

The fixed-partition compatible could be used on flash, eeprom, disks, ... and for disks the partitions could be registered as a separate disk in the disk access method.

Disk access is for, kinda, FTL layer, not raw access. fixed-partitions are for cutting devices into areas, disk has been provided for supporting file systems that are block oriented, currently, by the notion the FAT FS sees storage devices.

[de-nordic]

This should not be closed, till the other stages are followed.