Hi Rafał, zajec5@xxxxxxxxx wrote on Fri, 10 Mar 2023 11:53:30 +0100: > From: Rafał Miłecki <rafal@xxxxxxxxxx> > > There are a lot of devices with NVMEM content stored in MTD devices in > relevant partitions. Add a DT binding for marking such partitions. > > Note: Linux already treats every MTD partition as NVMEM provider so in > general it doesn't need to care about this binding. It's meant just to > make DT clearer in describing hardware. > > Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx> > --- > As explained in commit body this isn't really needed for Linux. I > thought it'd be a small nice addition for writing clear DTS files. > --- > .../devicetree/bindings/nvmem/mtd.yaml | 52 +++++++++++++++++++ > 1 file changed, 52 insertions(+) > create mode 100644 Documentation/devicetree/bindings/nvmem/mtd.yaml > > diff --git a/Documentation/devicetree/bindings/nvmem/mtd.yaml b/Documentation/devicetree/bindings/nvmem/mtd.yaml > new file mode 100644 > index 000000000000..7435b2803cf9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/nvmem/mtd.yaml > @@ -0,0 +1,52 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/nvmem/mtd.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MTD access based NVMEM > + > +description: | > + MTD partitions can be NVMEM providers. This binding allows explicitly marking > + such partitions. We already have that, it's nvmem-cell? I understand what you want to do, but I think it suffers from a common problem, see below. > + The exact way of handling MTD partition content (NVMEM cells) should be > + described using a proper NVMEM layout. Ok so I believe this is another solution for the layout offset proposed by Michael. Except that it only fixes it for mtd. I think I would prefer the former solution which handles all nvmem cases. > + > +maintainers: > + - Rafał Miłecki <rafal@xxxxxxxxxx> > + > +allOf: > + - $ref: nvmem.yaml# > + - $ref: /schemas/mtd/partitions/partition.yaml# > + > +properties: > + compatible: > + const: mtd-nvmem > + > + reg: > + maxItems: 1 > + > +required: > + - reg > + > +unevaluatedProperties: false > + > +examples: > + - | > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + compatible = "mtd-nvmem"; Actually there has been valid push-back from devlink gurus against stale compatibles (on a device-driver point of view) like that. Maybe something like this instead: partition@x{ <mtd-nvmem-property> ? > + reg = <0x0 0x40000>; > + label = "device-data"; > + > + nvmem-layout { > + /* Just a dummy example: Kontron can be found on OTP actually */ > + compatible = "kontron,sl28-vpd"; The Onie tlv compatible would perfectly apply here. > + }; > + }; > + }; Thanks, Miquèl
