On Tue, Jul 04, 2023 at 05:23:03PM +0200, Francesco Dolcini wrote: > On Tue, Jul 04, 2023 at 11:14:57AM -0400, Tom Rini wrote: > > On Tue, Jul 04, 2023 at 05:12:42PM +0200, Francesco Dolcini wrote: > > > On Tue, Jul 04, 2023 at 11:39:59AM -0300, Fabio Estevam wrote: > > > > Then for the next cycle, we should plan on adding this > > > > fdt_increase_size() into the common fdt_status_disabled(). > > > > > > > > Does it work? > > > > > > Now that the situation is pretty much clear I am not overly concerned for > > > colibri-imx7s. > > > > > > Do we consider this something to be worried about for other boards? > > > > The cases calling fdt_status_disabled itself are small enough that I > > think a quick audit isn't unreasonable (and PowerPC should probably > > mirror the kernel and pass -p 0x1000 in DTC_FLAGS so it becomes a > > non-issue). > > Do we expect this to not affect fdt_setprop() or other fdt_*() APIs? > fdt_increase_size() seems not to be used most of the time, unless I am > missing something here.
It depends on the case. For example, fdt_node_set_part_info is big/complex enough that it does call fdt_increase_size (which is not cheap) when there's no space. Other cases already do check for no space and grow+retry. And then the general answer is that if you're expecting needing to make "big" changes to the dtb you should pad it to start with as that's a free operation at run time. -- Tom
signature.asc
Description: PGP signature