[PATCH] drivers: firmware: ti_sci: Add DM_FLAG_PRE_RELOC to driver

[Tom Rini]

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-sjg@chromium.org/
> [1]: https://lore.kernel.org/all/20240709084857.nf7c57mi6miajeau@uda0497581/#t
> [2]: https://lore.kernel.org/u-boot/CAFLszTjr7bJFPnyVx7rTdFB3AFBM_2DVAZU8FZnLBE7ep5ejXw@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241218/6fc17567/attachment.sig>