mbox series

[v3,0/6] mtd: improve block2mtd + airoha parser

Message ID 20240806114118.17198-1-ansuelsmth@gmail.com
Headers show
Series mtd: improve block2mtd + airoha parser | expand

Message

Christian Marangi Aug. 6, 2024, 11:41 a.m. UTC 
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 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 (6):
  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
  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 +
 11 files changed, 307 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

Comments

Christoph Hellwig Aug. 6, 2024, 12:42 p.m. UTC | #1 
On Tue, Aug 06, 2024 at 01:41:11PM +0200, Christian Marangi wrote:
> Document new nvme-card compatible to permit defining fixed-partition in
> DT by the use of the block2mtd module to use block devices as MTD.
 
What does nvme card mean?  Is this about nvmem or nvme?  If this is nvme,
are you talking about nvme-pci?  Why would that needs a device binding
when it is a PCI device?
Christian Marangi Aug. 6, 2024, 12:55 p.m. UTC | #2 
On Tue, Aug 06, 2024 at 02:42:24PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 06, 2024 at 01:41:11PM +0200, Christian Marangi wrote:
> > Document new nvme-card compatible to permit defining fixed-partition in
> > DT by the use of the block2mtd module to use block devices as MTD.
>  
> What does nvme card mean?  Is this about nvmem or nvme?  If this is nvme,
> are you talking about nvme-pci?  Why would that needs a device binding
> when it is a PCI device?
>

It's similar to how it's done with mmc and it's to keep the property
consistent with block devices.

emmc have something like

mmc {
	mmc-card {
		specific-property;

		partitions...
	};
};

The same will be with nvme with

nvme {
	compatible = "pci_id"

	nvme-card {
		quirks maybe in the future?
		partitions...
	};
};

The following implementation permits in block2mtd to not complicate the
implementation with all the add_disk functions works with parenting
struct and how they are initialized.

(alternative is to have in block2mtd all kind of extra logic with switch
case to check for major block ID that deviates from a common schema)
Christian Marangi Aug. 6, 2024, 1:17 p.m. UTC | #3 
On Tue, Aug 06, 2024 at 03:00:03PM +0200, Christoph Hellwig wrote:
> I don't see how this works.  There is absolutely nothing nvme specific
> in there, and we really should not bring OF into NVMe.
>

Thing is that OF for PCIe devices is already a thing so NVMe already
have OF support. And that is totally OK if the PCIe is not removable.

So it's really a simple subnode to keep things organized in DT and
permit common code. Why this would be problematic, the implications of
adding support for this are really none, only additional support for the
new devices that are taking this path. (you would be surprised by the
amount of hacks they use downstream so about times to stabilize this the
correct way)

> > (alternative is to have in block2mtd all kind of extra logic with switch
> > case to check for major block ID that deviates from a common schema)
> 
> What common scheme?
> 

The emmc one and also nand attached to spi. They all follow this.

controller {
	card {
	};
};