Re: [PATCH v11 4/7] media: qcom: camss: Add support to populate sub-devices

[Loic Poulain]

On Fri, Mar 27, 2026 at 11:37 PM Bryan O'Donoghue
<bryan.odonoghue@xxxxxxxxxx> wrote:
>
> On 27/03/2026 21:33, Dmitry Baryshkov wrote:
> >> Other drivers typically call the populate function at the end of the
> >> probe function. In this case, however, it is invoked before the main
> >> resources are enabled. I assume this is because the CSIPHY device
> >> needs to be available early. Aside from that, it looks good to me.
> > This becomes fragile. The CSI PHY might be built as a module, which
> > might be loaded later.
>
> Is it any more or less fragile than "simple-mfd" in a DT though ?
> Krzysztof isn't very much in favour of simple-mfd so this method of
> population is the alternative to hand.
>
> The CSIPHY driver uses devm_of_phy_get which handles deferred probe. If
> the PHY module isn't loaded yet when CAMSS tries to get it, CAMSS gets
> -EPROBE_DEFER and retries.

What about relying on v4l2_async_nf_register() in the same way as for
the sensors? That would allow both the sensors and the CSIPHY to be
bound asynchronously when they are ready, assuming the CSIPHY driver
registers a V4L2 subdevice...

>
> >
> >> Reviewed-by: Loic Poulain<loic.poulain@xxxxxxxxxxxxxxxx>
> >>
> >>> @@ -4964,6 +4965,8 @@ static int camss_probe(struct platform_device *pdev)
> >>>          if (!camss)
> >>>                  return -ENOMEM;
> >>>
> >>> +       devm_of_platform_populate(dev);
> >>> +
> >>>          camss->res = of_device_get_match_data(dev);
> >>>
> >>>          atomic_set(&camss->ref_count, 0);
> > And this looks suspicious. What if drivers for submodules are already
> > there and start probing once populated? Do they have a chance to access
> > this ref_count?
>
> Nope, we don't share the camss pointer or any of the data-structures in
> the existing upstream driver with sub-modules.
>
> ---
> bod