Re: [PATCH v4 2/2] soc: qcom: ubwc: Get HBB from SMEM

On Tue, Jul 21, 2026 at 12:40:05PM +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] A race condition between SMEM probing and `qcom_ubwc_config_get_data()` can cause the driver to bypass probe deferral, incorrectly fall back to default UBWC data, and return mismatched configurations to concurrent callers.
> - [Low] Missing Kconfig dependency on QCOM_SMEM causes linker errors when QCOM_UBWC_CONFIG is selected but QCOM_SMEM is disabled or built as a module.
> --
> 
> --- Patch [2]: [PATCH v4 2/2] soc: qcom: ubwc: Get HBB from SMEM ---
> commit e0bf0c57e180329e2b45423901bc2dc1b3492f77
> Author: Konrad Dybcio <[email protected]>
> 
> soc: qcom: ubwc: Get HBB from SMEM
> 
> This commit updates the UBWC configuration driver to dynamically retrieve
> the Highest Bank Bit (HBB) from SMEM. If SMEM is not yet available, it
> returns -EPROBE_DEFER. Once available, it allocates and updates a copy of
> the UBWC configuration data with the retrieved HBB value.
> 
> > diff --git a/drivers/soc/qcom/ubwc_config.c b/drivers/soc/qcom/ubwc_config.c
> > index 0209a02c390f0..23901a4c51f73 100644
> > --- a/drivers/soc/qcom/ubwc_config.c
> > +++ b/drivers/soc/qcom/ubwc_config.c
> [ ... ]
> > @@ -168,9 +169,25 @@ static const struct of_device_id qcom_ubwc_configs[] __maybe_unused = {
> >  	{ }
> >  };
> >  
> > +static struct qcom_ubwc_cfg_data *cfg;
> > +static DEFINE_MUTEX(cfg_mutex);
> > +/**
> > + * qcom_ubwc_config_get_data() - Retrieve UBWC data for the platform.
> > + *
> > + * Return: Pointer to valid struct qcom_ubwc_cfg_data on success, negative
> > + * errno on failure. Note that this may return EPROBE_DEFER.
> > + */
> >  const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void)
> >  {
> >  	const struct qcom_ubwc_cfg_data *data;
> > +	int hbb;
> > +
> > +	guard(mutex)(&cfg_mutex);
> > +	if (cfg)
> > +		return cfg;
> > +
> > +	if (!qcom_smem_is_available())
> > +		return ERR_PTR(-EPROBE_DEFER);
> 
> [Severity: Low]
> Will this cause linker errors if the kernel is configured with
> CONFIG_QCOM_UBWC_CONFIG=y but CONFIG_QCOM_SMEM=m or CONFIG_QCOM_SMEM=n?
> 
> Since these SMEM functions are called unconditionally without stub
> implementations provided for when SMEM is disabled, it seems dependent drivers
> selecting QCOM_UBWC_CONFIG might trigger undefined reference errors during
> the build.

I've been seeing exactly these linker errors now since next-20270731.
This is the DRM MSM driver selecting QCOM_UBWC_CONFIG without anything
else selecting QCOM_SMEM. This should be addressed somehow. Locally I
did select QCOM_SMEM from QCOM_UBWC_CONFIG but that's a bit risky since
QCOM_SMEM is user-visible and shouldn't be selected. A depends doesn't
work here because it gives an unmet direct dependency (nothing selects
QCOM_SMEM while QCOM_UBWC_CONFIG is selected by DRM_MSM).

Thierry

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmpzH7QACgkQ3SOs138+
s6HL3g/8DsCDJKW3az6Y1zCrYg3PF6b5QtbMxLu9cgGmRPa5nAD1Y3Mu9Mr4uH6D
22PVKRatHh6eVYatcdwO04HfYXuWK8tOdPkbpdpuJZN5gxIklVRaNyZ0g1xl4tp+
GloMZ/mfrtNVr2Mrt8GWCHci0wCimeriluEzus2RGm8MFXd0m39O8Xj4OAUF7GuQ
unPgYmfUk/W043t2Zz/JkuwUO3tHSJ8gtXmj+SmVGb1OqPwuw9G0bvNtfBHYltQB
aztfsVFsYtub9fKULKz+R/um31jdpAdd1zNRRjfbtcckKBmLxX7O78SYUo0h37W5
F+A2Navk1a0S23VftfXWvoIoyJcPC9Uix9yORaAN18yveezxcVGMuk0znDA4DHoM
XPD9E9oDLgrOAdGEQu7kHAUK7STd0y7XiPXdxaJxs+Kf15V1p7uccaqEXVuhnv/0
gOcw/VaS5nSdaqLdrveuoZsh9/BF68smBIKRgvxtQFzjQ827vXM29S/s+WVj9eHz
hX2L14FAzpRLUkgN2VWexLJPfpBT9BuLWaU1LP79QNIL5GkbkVnGuGvLZ0EPvn4j
ZPnv0ZjcS/ewQp+FBjUGc0A2NoQ5EisLF0zl0kSpC6lhfoxXXBjrI6CqUSzFCZuy
tzmbQjLlrzuMusaNLWsY5Gk0enbKSMlbn83tHdHODYG/wWGssLc=
=U87s
-----END PGP SIGNATURE-----