On Thu, 4 May 2023 at 11:31, Ilias Apalodimas <ilias.apalodi...@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 <tr...@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...@kernel.org> wrote: > > > > On Thu, May 4, 2023 at 9:01 AM Jassi Brar <jaswinder.si...@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.
