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

[Jassi Brar]

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.
Though the stripping part remains tbd. Where should that be done in u-boot?

> - 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. EDK2 may use the node as such and BL1/2 would
have the meta-data location info hardcoded into them (?)

thanks.