[v4,0/7] mtd: improve block2mtd + airoha parser

This small series handle 2 problems.

It does try to ""standardize"" the usage of block2mtd module with
MTD OF nodes.

It is very easy to add support for MTD parser by just adding an
OF node to the mtd created for block2mtd.

This apply only if the root block is used for block2mtd to allow
scenario where the full eMMC or an NVME is used for MTD and it doesn't
have any partition table.

To also support NVME, similar to how it's done with eMMC, we introduce
a subnode to the NVME controller that needs to have the "nvme-card"
compatible where a dev can define fixed-paritions for MTD parser usage.

This series also add support for the Airoha partition table where
the last partition is always ART and is placed at the end of the flash.

This require dynamic calculation of the offset as some dedicated
driver for bad block management might be used that reserve some space
at the end of the flash for block accounting.

New aarch64 Airoha SoC make use of this partition table and use block2mtd
for eMMC to treat them as MTD with custom bad block management and block
tracking.

Changes v4:
- Add additional patch for ofpart kmod with of_update_property
  not exported
Changes v3:
- Fix compilation error for missing slab.h header
- Add compatible to partitions.yaml
Changes v2:
- Fix typo in DT patch
- Fix compilation error for non-OF platform
- Fix compilation error due to recent changes in block2mtd module

Christian Marangi (7):
  dt-bindings: nvme: Document nvme-card compatible
  nvme: assign of_node to nvme device
  dt-bindings: mmc: add property for partitions node in mmc-card node
  block2mtd: attach device OF node to MTD device
  of: also export of_update_property
  dt-bindings: mtd: Add Documentation for Airoha fixed-partitions
  mtd: parser: add support for Airoha parser

 .../devicetree/bindings/mmc/mmc-card.yaml     | 40 ++++++++++
 .../partitions/airoha,fixed-partitions.yaml   | 80 +++++++++++++++++++
 .../bindings/mtd/partitions/partitions.yaml   |  1 +
 .../devicetree/bindings/nvme/nvme-card.yaml   | 78 ++++++++++++++++++
 drivers/mtd/devices/block2mtd.c               | 12 +++
 drivers/mtd/parsers/Kconfig                   | 10 +++
 drivers/mtd/parsers/Makefile                  |  1 +
 drivers/mtd/parsers/ofpart_airoha.c           | 57 +++++++++++++
 drivers/mtd/parsers/ofpart_airoha.h           | 18 +++++
 drivers/mtd/parsers/ofpart_core.c             |  6 ++
 drivers/nvme/host/core.c                      |  4 +
 drivers/of/base.c                             |  1 +
 12 files changed, 308 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/partitions/airoha,fixed-partitions.yaml
 create mode 100644 Documentation/devicetree/bindings/nvme/nvme-card.yaml
 create mode 100644 drivers/mtd/parsers/ofpart_airoha.c
 create mode 100644 drivers/mtd/parsers/ofpart_airoha.h

Hi Christian,

ansuelsmth@gmail.com wrote on Fri,  9 Aug 2024 19:20:58 +0200:

> This small series handle 2 problems.
> 
> It does try to ""standardize"" the usage of block2mtd module with
> MTD OF nodes.
> 
> It is very easy to add support for MTD parser by just adding an
> OF node to the mtd created for block2mtd.
> 
> This apply only if the root block is used for block2mtd to allow
> scenario where the full eMMC or an NVME is used for MTD and it doesn't
> have any partition table.
> 
> To also support NVME, similar to how it's done with eMMC, we introduce
> a subnode to the NVME controller that needs to have the "nvme-card"
> compatible where a dev can define fixed-paritions for MTD parser usage.
> 
> This series also add support for the Airoha partition table where
> the last partition is always ART and is placed at the end of the flash.
> 
> This require dynamic calculation of the offset as some dedicated
> driver for bad block management might be used that reserve some space
> at the end of the flash for block accounting.

Who is reserving this space? And this is not reflected anywhere in the
partition table?

> New aarch64 Airoha SoC make use of this partition table and use block2mtd
> for eMMC to treat them as MTD with custom bad block management and block
> tracking.

I am sorry, I am not used to such use cases, and I really fail getting
why you would like to use mtd with an eMMC. Can you explain a little
bit more what is not available in the block world that you really need
from mtd?

Also, did you consider nvmem layouts instead to detect and define the
ART area? (just asking).

Thanks,
Miquèl

On Mon, Aug 12, 2024 at 10:49:54AM +0200, Miquel Raynal wrote:
> Hi Christian,
> 
> ansuelsmth@gmail.com wrote on Fri,  9 Aug 2024 19:20:58 +0200:
> 
> > This small series handle 2 problems.
> > 
> > It does try to ""standardize"" the usage of block2mtd module with
> > MTD OF nodes.
> > 
> > It is very easy to add support for MTD parser by just adding an
> > OF node to the mtd created for block2mtd.
> > 
> > This apply only if the root block is used for block2mtd to allow
> > scenario where the full eMMC or an NVME is used for MTD and it doesn't
> > have any partition table.
> > 
> > To also support NVME, similar to how it's done with eMMC, we introduce
> > a subnode to the NVME controller that needs to have the "nvme-card"
> > compatible where a dev can define fixed-paritions for MTD parser usage.
> > 
> > This series also add support for the Airoha partition table where
> > the last partition is always ART and is placed at the end of the flash.
> > 
> > This require dynamic calculation of the offset as some dedicated
> > driver for bad block management might be used that reserve some space
> > at the end of the flash for block accounting.
> 
> Who is reserving this space? And this is not reflected anywhere in the
> partition table?
>

To be more precise Mediatek use a custom way to handle bad blocks called
BMT where they reserve and store data at the end of the nand. This is
loaded before the flash driver controller so when MTD is init, the size
is already reduced. The reserved space can change and it really depends
on the tuned values hence it may change.

> > New aarch64 Airoha SoC make use of this partition table and use block2mtd
> > for eMMC to treat them as MTD with custom bad block management and block
> > tracking.
> 
> I am sorry, I am not used to such use cases, and I really fail getting
> why you would like to use mtd with an eMMC. Can you explain a little
> bit more what is not available in the block world that you really need
> from mtd?

Since vendor needs more space and doesn't want to adapt to block world,
they are starting to use eMMC or block devices in general unpartitioned
and raw and using block2mtd to simulate it. They don't care about the
performance penalities as it's something read at boot time and only new
firmware or some config files are written.

Is it more clear now?

> 
> Also, did you consider nvmem layouts instead to detect and define the
> ART area? (just asking).
> 

They still need a MTD partition and most of the time userspace tool are
used on the ART partition. Using block2mtd and DT support will permit
the use of nvmem cell as a side effect (and that is a missive bonus
point of this honestly)

Hi Christian,

ansuelsmth@gmail.com wrote on Mon, 12 Aug 2024 12:10:03 +0200:

> On Mon, Aug 12, 2024 at 10:49:54AM +0200, Miquel Raynal wrote:
> > Hi Christian,
> > 
> > ansuelsmth@gmail.com wrote on Fri,  9 Aug 2024 19:20:58 +0200:
> >   
> > > This small series handle 2 problems.
> > > 
> > > It does try to ""standardize"" the usage of block2mtd module with
> > > MTD OF nodes.
> > > 
> > > It is very easy to add support for MTD parser by just adding an
> > > OF node to the mtd created for block2mtd.
> > > 
> > > This apply only if the root block is used for block2mtd to allow
> > > scenario where the full eMMC or an NVME is used for MTD and it doesn't
> > > have any partition table.
> > > 
> > > To also support NVME, similar to how it's done with eMMC, we introduce
> > > a subnode to the NVME controller that needs to have the "nvme-card"
> > > compatible where a dev can define fixed-paritions for MTD parser usage.
> > > 
> > > This series also add support for the Airoha partition table where
> > > the last partition is always ART and is placed at the end of the flash.
> > > 
> > > This require dynamic calculation of the offset as some dedicated
> > > driver for bad block management might be used that reserve some space
> > > at the end of the flash for block accounting.  
> > 
> > Who is reserving this space? And this is not reflected anywhere in the
> > partition table?
> >  
> 
> To be more precise Mediatek use a custom way to handle bad blocks called
> BMT where they reserve and store data at the end of the nand. This is
> loaded before the flash driver controller so when MTD is init, the size
> is already reduced. The reserved space can change and it really depends
> on the tuned values hence it may change.

Is this supported in mainline Linux? MTD handles the bad blocks and the
bad block tables, so I don't understand how this hardware feature can
live together with MTD.

Anyway, you are talking about MMCs, I don't understand why there are
bad blocks, nor what is checking them and when. This is all still very
fuzzy to me, I'm sorry.

> > > New aarch64 Airoha SoC make use of this partition table and use block2mtd
> > > for eMMC to treat them as MTD with custom bad block management and block
> > > tracking.  
> > 
> > I am sorry, I am not used to such use cases, and I really fail getting
> > why you would like to use mtd with an eMMC. Can you explain a little
> > bit more what is not available in the block world that you really need
> > from mtd?  
> 
> Since vendor needs more space and doesn't want to adapt to block world,
> they are starting to use eMMC or block devices in general unpartitioned
> and raw 

Okay, why not, it's easier for ROMs to access it I guess.

> and using block2mtd to simulate it.

This is what I don't understand. You can very well access your block
device by offset, why do you need the mtd interface at all?

> They don't care about the
> performance penalities as it's something read at boot time and only new
> firmware or some config files are written.
> 
> Is it more clear now?

I still don't understand the need for going through MTD tbh.

> > Also, did you consider nvmem layouts instead to detect and define the
> > ART area? (just asking).
> >   
> 
> They still need a MTD partition

Why?

> and most of the time userspace tool are
> used on the ART partition. Using block2mtd and DT support will permit
> the use of nvmem cell as a side effect (and that is a missive bonus
> point of this honestly)

MTD also registers into NVMEM, so this is nice if you need both, but if
what you need is some NVMEM area derived dynamically and you register
into MTD for that, then no, I'm sorry, that's not the correct approach.

Thanks,
Miquèl

On Mon, Aug 12, 2024 at 03:17:55PM +0200, Miquel Raynal wrote:
> Is this supported in mainline Linux? MTD handles the bad blocks and the
> bad block tables, so I don't understand how this hardware feature can
> live together with MTD.
> 
> Anyway, you are talking about MMCs, I don't understand why there are
> bad blocks, nor what is checking them and when. This is all still very
> fuzzy to me, I'm sorry.

Yes.  The idea of using block2mtd for anything but development seems
a bit odd to say it politely.  Using it to reinvent bad block management
on top of a block device that needs to do that as one of it's fundamental
functions seems extremely odd.