Re: [PATCH] soc: qcom: pmic_glink: Avoid losing early rpmsg probe

[Bjorn Andersson <andersson@kernel.org>]

On Sun, Jul 26, 2026 at 12:11:48AM -0300, Val Packett wrote:
> 
> On 7/20/26 11:39 AM, Konrad Dybcio wrote:
> > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > 
> > The PMIC GLINK rpmsg device can appear before the platform device has
> > finished probing. In that case pmic_glink_rpmsg_probe() sees
> > __pmic_glink as NULL and returns -ENODEV, which is treated as a fatal
> > probe failure for the rpmsg endpoint.
> > 
> > If this race is hit, pg->ept is never installed and PMIC GLINK clients
> > never receive the service-up notification. This may leave the system
> > with no Type-C functionality and without battery/power supply
> > management.
> > 
> > Return -EPROBE_DEFER when the rpmsg endpoint arrives before the platform
> > device is ready. [..]
> 
> Hm, in the Linaro tree there was this hack patch to accomplish the same
> thing differently:
> 
> https://gitlab.com/Linaro/arm64-laptops/linux/-/commit/8c309c7e852a49118ddc2ee54c3d8b7c74466f6a
> 
> that claimed that "Returning -EPROBE_DEFER from the rpmsg driver does not
> seem to work because the rpmsg core doesn't handle EPROBE_DEFER(?)"
> 
> Was that resolved or was that always wrong?
> 

Returning an error from probe of an rpmsg driver will destroy the
"endpoint", which results in the GLINK channel being closed again. (See
rpmsg_dev_probe())

This is still on the todo list to figure out how to gracefully handle.

Regards,
Bjorn

> 
> Thanks,
> ~val
>