On Wed, Dec 18, 2024 at 10:38:37AM +0530, Manorit Chawdhry wrote: > Hi Tom, > > On 08:53-20241217, Tom Rini wrote: > > On Tue, Dec 17, 2024 at 02:24:37PM +0530, Manorit Chawdhry wrote: > > > > > Currently the driver relies on bootph flag to probe it during PRE_RELOC > > > stage but with the upcoming cleanup of v6.13, we don't have the bootph > > > property in the parent nodes anymore and ti_sci driver being one of the > > > parent nodes required during SPL stage would end up hampering the probe > > > model [0]. > > > > > > Add DM_FLAG_PRE_RELOC to ti_sci driver for mitigating this issue. > > > > > > Can you please expand on why with v6.13 we don't have the flag anymore? > > Thanks. > > So the idea was that following series [0] would help us cleanup all the > parent node bootph-* tags as putting a bootph-* in child node implies > that it applies to parent nodes as well, though even if the parent node > gets packed after the following series, the parent node still don't get > probed as from my understanding, we need bootph-* tag to probe the > driver as well but the phase tag doesn't get propagated as such. > > So while working in Linux, some comments related to this was raised [1] > and after confirming the behaviour with Simon [2], the cleanup was done > in Linux and meanwhile this way was found to probe the driver so that > even after cleaning up the parent bootph-* tags we can continue. > > I don't think it's a hack also as this driver is required pre-relocation > and this is another way to probe it pre-relocation but the only thing is > that since the cleanup is done right now, we would kind of need it to be > booting in some platforms ( that were fully reliant on Linux DT and > don't have -u-boot override for this particular node with bootph-* ) > before 6.13 DT gets synced up. > > [0]: https://lore.kernel.org/u-boot/20231217163627.2339802-1-...@chromium.org/ > [1]: https://lore.kernel.org/all/20240709084857.nf7c57mi6miajeau@uda0497581/#t > [2]: > https://lore.kernel.org/u-boot/caflsztjr7bjfpnyvx7rtdfb3afbm_2dvazu8fznlbe7ep5e...@mail.gmail.com/
Thanks. Did you end up filing an issue about this? And can you now perhaps push to make doing the fdtgrep work a priority? There's going to be a lot of other cases like this to resolve I suspect. -- Tom
signature.asc
Description: PGP signature
