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

[Simon Glass]

Hi Tom,

On Wed, 18 Dec 2024 at 10:38, Tom Rini <trini at 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-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.

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