| Message ID | 20240806114118.17198-2-ansuelsmth@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mtd: improve block2mtd + airoha parser | expand |
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?
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)
I don't see how this works. There is absolutely nothing nvme specific in there, and we really should not bring OF into NVMe. > (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?
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 { }; };
diff --git a/Documentation/devicetree/bindings/nvme/nvme-card.yaml b/Documentation/devicetree/bindings/nvme/nvme-card.yaml new file mode 100644 index 000000000000..20e9a877fac4 --- /dev/null +++ b/Documentation/devicetree/bindings/nvme/nvme-card.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvme/nvme-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVME Card + +maintainers: + - Christian Marangi <ansuelsmth@gmail.com> + +description: | + This documents describes the devicetree bindings for a NVME controller + child node describing a nvme-card. + +properties: + compatible: + const: nvme-card + + partitions: + $ref: /schemas/mtd/partitions/partitions.yaml + +required: + - compatible + +additionalProperties: false + +examples: + - | + pcie { + #address-cells = <3>; + #size-cells = <2>; + + bridge@0,0 { + reg = <0x00000000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + ranges; + + nvme@1,0 { + compatible = "pci144d,a809"; + + reg = <0x00010000 0 0 0 0>; + #address-cells = <1>; + #size-cells = <1>; + + card { + compatible = "nvme-card"; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + bootloader@0 { + label = "bootloader"; + reg = <0x00000000 0x00080000>; + }; + + tclinux@80000 { + label = "tclinux"; + reg = <0x00080000 0x02800000>; + }; + + tclinux_slave@2880000 { + label = "tclinux_slave"; + reg = <0x02880000 0x02800000>; + }; + + rootfs_data@5080000 { + label = "rootfs_data"; + reg = <0x5080000 0x00800000>; + }; + }; + }; + }; + }; + };
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. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> --- .../devicetree/bindings/nvme/nvme-card.yaml | 78 +++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvme/nvme-card.yaml