Hi Tom, On Wed, 18 Dec 2024 at 10:38, Tom Rini <tr...@konsulko.com> wrote: > > 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.
fdtgrep is done, the confusion is that there are two [0] references in this chain. The one you want is: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/21 For SPL and U-Boot proper, all is well. But for pre-relocation, U-Boot doesn't actually bind parents even if their children have a bootph property, as I understand it. I believe that is what needs to be fixed? Regards, SImon
