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

[Rob Herring]

On Thu, May 4, 2023 at 11:42 AM Jassi Brar <jaswinder.singh at linaro.org> wrote:
>
> On Thu, 4 May 2023 at 11:31, Ilias Apalodimas
> <ilias.apalodimas at linaro.org> wrote:
> >
> > Replying to both Jassi and Tom here since it makes more sense,
> >
> > On Thu, 4 May 2023 at 19:19, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, May 04, 2023 at 10:39:06AM -0500, Jassi Brar wrote:
> > > > On Thu, 4 May 2023 at 10:19, Rob Herring <robh+dt at kernel.org> wrote:
> > > > > On Thu, May 4, 2023 at 9:01 AM Jassi Brar <jaswinder.singh at linaro.org> wrote:
> > > > >
> > > > > >  I may be wrong, but I see having fwu properties contained within the
> > > > > > fwu node is cleaner than having them embedded into existing bindings
> > > > > > (potentially different classes in future). So I moved to the current
> > > > > > design.
> > > > >
> > > > > Having all the information related to a device/node in one place is cleaner IMO.
> > > > >
> > > > > As I said, if u-boot wants private interfaces between the DT and
> > > > > itself, then fine, but that should remain private and be stripped by
> > > > > u-boot. A separate node would certainly be easier for doing that.
> > > > >
> > > > Seems we are on the same page(?). Current implementation does exactly
> > > > that -- we have a separate fwu node containing all the properties it
> > > > needs.
> >
> > I think Rob is saying the exact opposite.  The way I see it we either
> > - Keep the bindings as an internal u-boot ABI, in which case the
> > current format is fine, but we need to strip it from the DT before
> > handing it over to the OS.
> >
> I interpreted "Having all the information related to a device/node in
> one place is cleaner IMO." to suggest this approach.

The one place being where there is already partition information in
the partition nodes. This binding adds a 2nd location with pointers to
the 1st location.

> Though the stripping part remains tbd. Where should that be done in u-boot?

Yes.

> > - Alternatively, if we want to submit it upstream, we need to change
> > where that data lives and ideally have them under existing partition
> > bindings.
> >
> Here we may have to add to bindings of various subsystems (as support
> widens) and still have to strip the property before handover to the
> kernel. right?
>
> > Both would work, with the latter offering a bit more standardization
> > if another bootloader tries to implement something similar.
> >
> > >
> > > Well, isn't part of why we're here is that this isn't strictly a U-Boot
> > > only thing? My question is can, and then is, this also being used in
> > > other projects yet?
> >
> > I am not aware of any other projects currently using it.
> >
> Maybe I am overlooking something, but the kernel should not have
> anything to do with it.

Um, LinuxBoot, kexec?

> EDK2 may use the node as such and BL1/2 would
> have the meta-data location info hardcoded into them (?)

Certainly not hard to imagine others needing this.

Rob