[PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU

[Rob Herring]

On Wed, May 3, 2023 at 9:37 AM Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> Hi Krzysztof,
>
> On Tue, Apr 11, 2023 at 07:38:11AM +0200, Krzysztof Kozlowski wrote:
> > On 11/04/2023 01:21, jaswinder.singh at linaro.org wrote:
> > > From: Jassi Brar <jaswinder.singh at linaro.org>
> > >
> > > Any requirement of FWU should not require changes to bindings
> > > of other subsystems. For example, for mtd-backed storage we
> > > can do without requiring 'fixed-partitions' children to also
> > > carry 'uuid', a property which is non-standard and not in the
> > > bindings.
> > >
> > >  There exists no code yet, so we can change the fwu-mtd bindings
> > > to contain all properties within the fwu-mdata node.
> > >
> > > Signed-off-by: Jassi Brar <jaswinder.singh at linaro.org>
> > > ---
> > >
> > > Hi Rob, Hi Krzysztof,
> > >
> > >   I was suggested, and I agree, it would be a good idea to get your blessings
> > > for the location and meta-data (fwu-mdata) bindings for the FWU.
> > >
> > >   The FWU images can be located in GPT partitions or MTD backed storage.
> > > The basic bindings for fwu-mdata has already been merged in uboot (ideally they
> > > too should have had your review). Now I am trying to fully support MTD backed
> > > storage and hence looking for your review. The proposed bindings are totally
> > > self-contained and don't require changes to any other subsystem.
> > >
> > > Thanks.
> >
> > I think we do not review U-Boot bindings usually, except these put in
> > the Linux kernel. There were few targeting U-Boot specifically (e.g.
> > Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml and
> > Documentation/devicetree/bindings/nvmem/u-boot,env.yaml) so if you want
> > our blessing, the bindings should be done in Linux kernel repo.
> >
> > I am pretty sure that reviewing other project bindings would be too much
> > of work for me.
>
> Sure that makes sense.  But an answer here of whether the bindings make
> sense to the DT maintainers or not would help to move forward.

I have lots of comments on the bindings, but I'm missing what is the
problem to solve. Yes, it's 'A/B firmware updates', but what
configuration data do you need, why and when do you need it. IOW, give
me enough information to understand why a binding is designed the way
it is and be able to propose alternatives.

That's easy enough to deduce for the GPT case. It's just needing to
know which device has the f/w update GPT? That's easily solved with an
alias, a boolean property in the device, or property with the disk
GUID. All of those options are much more simple than a whole node and
compatible.


> These bindings are trying to define a standardized interface for A/B *firmware*
> updates [0] which is not what traditionally goes into a device tree.  OTOH we
> already have some U-Boot specific bindings as you already mentioned.  As we
> move forward we need to be very precise on what is allowed or not on the DT
> since it's now tested and verified on SystemReady certifications.  IOW if
> we add those binding in U-Boot only, we would need to strip them before
> handing the DT to linux, otherwise certification would fail.  If you do
> think that having them in the kernel repo makes sense,  it would help
> standardizing other boot loaders (at least it would standardize where that
> metadata lives) if they want to implement something similar.

I think it is fine if u-boot has things in DT which aren't an ABI, so
private and bundled, but I agree those should be stripped before
passing. To put it another way, if it's not an ABI nor shared amongst
projects, I don't think we need a schema nor to care outside of
u-boot.

However, it doesn't seem to me that needs for A/B updates would be
unique to u-boot.

> Just keep in mind we would need a schema per storage medium.  IOW this tries to
> standardize devices which keep the firmware binary in an mtd.  There's also
> another biding which describes firmware files on a GPT [1].

I'm assuming it's per partition type rather than storage medium (e.g.
SATA, USB, SD, NAND, SPI-NOR)? GPT, 'fixed-partitions', other DT
partition bindings, etc. If so, then I'm really wondering why it's a
standalone tree rather than integrated into those existing partition
bindings.

Rob