Re: [PATCH v3 06/10] dt-bindings: mtd: partitions: Drop partitions.yaml

[Daniel Golle <daniel@makrotopia.org>]

On Thu, Jan 22, 2026 at 11:31:54AM +0100, Miquel Raynal wrote:
> On 21/01/2026 at 21:18:58 GMT, Daniel Golle <daniel@makrotopia.org> wrote:
> 
> > On Wed, Jan 21, 2026 at 01:56:39PM -0600, Rob Herring (Arm) wrote:
> >> The partitions.yaml schema is an unusual structure in that it includes
> >> all possible partition types, and it disables the normal matching by
> >> compatible strings. As partitions.yaml has nothing to match on, it is
> >> only applied when explicitly referenced. The use of "oneOf" also results
> >> in misleading warnings which are difficult to understand. Drop
> >> partitions.yaml and rely on the standard compatible matching instead.
> >> 
> >> The "mmc-card" case previously allowed any partition type, but now only
> >> allows "fixed-partitions". There aren't any users and the original
> >> intent appeared to be only for "fixed-partitions".
> >
> > It would actually be great to also allow 'gpt-partitions' as compatible
> > type with #address-cells = <0> and #size-cells = <0> and allow matching
> > on partition UUID, name or index. This has previously been discussed and
> > would avoid having to extract MAC addresses and WiFi EEPROM data in
> > userspace on many devices which rely on such conventions.
> 
> Out of curiosity, why not exposing this data through an NVMEM cell
> instead? Anyway, this (re?)addition can probably be part of a follow-up
> series and is almost orthogonal to this cleanup IMO.

Exposing this data via NVMEM cell is exactly what I'd like to see.
However, for that the location of the data to be exposed as NVMEM cell
needs to be identified in the same way as done by the stock firmware,
which uses a GPT partition name in case of Adtran, for example.