Replying to both Jassi and Tom here since it makes more sense,
On Thu, 4 May 2023 at 19:19, Tom Rini trini@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@kernel.org wrote:
On Thu, May 4, 2023 at 9:01 AM Jassi Brar jaswinder.singh@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. - Alternatively, if we want to submit it upstream, we need to change where that data lives and ideally have them under existing partition bindings.
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. I'll repeat myself though, it would be useful to have the format standardized in case other bootloaders have similar needs. In any case I am happy with the discussion so far. We (as in u-boot) need to decide which of the above directions suits as best and either send the bindings upstream, or clean then up before we boot.
Cheers /Ilias
-- Tom