linux-stable.git/drivers/soc, branch v6.11.2

soc: versatile: realview: fix soc_dev leak during device remove

2024-10-04T14:38:52+00:00

[ Upstream commit c774f2564c0086c23f5269fd4691f233756bf075 ]

If device is unbound, the soc_dev should be unregistered to prevent
memory leak.

Fixes: a2974c9c1f83 ("soc: add driver for the ARM RealView")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/20240825-soc-dev-fixes-v1-3-ff4b35abed83@linaro.org
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

soc: versatile: realview: fix memory leak during device remove

2024-10-04T14:38:52+00:00

[ Upstream commit 1c4f26a41f9d052f334f6ae629e01f598ed93508 ]

If device is unbound, the memory allocated for soc_dev_attr should be
freed to prevent leaks.

Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/20240825-soc-dev-fixes-v1-2-ff4b35abed83@linaro.org
Signed-off-by: Linus Walleij 
Stable-dep-of: c774f2564c00 ("soc: versatile: realview: fix soc_dev leak during device remove")
Signed-off-by: Sasha Levin

soc: versatile: integrator: fix OF node leak in probe() error path

2024-10-04T14:38:32+00:00

commit 874c5b601856adbfda10846b9770a6c66c41e229 upstream.

Driver is leaking OF node reference obtained from
of_find_matching_node().

Fixes: f956a785a282 ("soc: move SoC driver for the ARM Integrator")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/20240825-soc-dev-fixes-v1-1-ff4b35abed83@linaro.org
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

soc: fsl: cpm1: tsa: Fix tsa_write8()

2024-10-04T14:38:31+00:00

commit 47a347bae9a491b467ab3543e4725a3e4fbe30f5 upstream.

The tsa_write8() parameter is an u32 value. This is not consistent with
the function itself. Indeed, tsa_write8() writes an 8bits value.

Be consistent and use an u8 parameter value.

Fixes: 1d4ba0b81c1c ("soc: fsl: cpm1: Add support for TSA")
Cc: stable@vger.kernel.org
Signed-off-by: Herve Codina 
Reviewed-by: Christophe Leroy 
Link: https://lore.kernel.org/r/20240808071132.149251-4-herve.codina@bootlin.com
Signed-off-by: Christophe Leroy 
Signed-off-by: Greg Kroah-Hartman

soc: fsl: cpm1: qmc: Update TRNSYNC only in transparent mode

2024-10-04T14:38:31+00:00

commit c3cc3e69b33fee3d276895e0e2d1a8fb37ea5d0e upstream.

The TRNSYNC feature is available (and enabled) only in transparent mode.

Since commit 7cc9bda9c163 ("soc: fsl: cpm1: qmc: Handle timeslot entries
at channel start() and stop()") TRNSYNC register is updated in
transparent and hdlc mode. In hdlc mode, the address of the TRNSYNC
register is used by the QMC for other internal purpose. Even if no weird
results were observed in hdlc mode, touching this register in this mode
is wrong.

Update TRNSYNC only in transparent mode.

Fixes: 7cc9bda9c163 ("soc: fsl: cpm1: qmc: Handle timeslot entries at channel start() and stop()")
Cc: stable@vger.kernel.org
Signed-off-by: Herve Codina 
Reviewed-by: Christophe Leroy 
Link: https://lore.kernel.org/r/20240808071132.149251-2-herve.codina@bootlin.com
Signed-off-by: Christophe Leroy 
Signed-off-by: Greg Kroah-Hartman

Revert "soc: qcom: smd-rpm: Match rpmsg channel instead of compatible"

2024-10-04T14:38:31+00:00

commit b17155133391d7f6dd18d3fb94a7d492fdec18fa upstream.

The rpm_requests device nodes have the compatible node. As such the
rpmsg core uses OF modalias instead of a native rpmsg modalias. Thus if
smd-rpm is built as a module, it doesn't get autoloaded for the device.

Revert the commit bcabe1e09135 ("soc: qcom: smd-rpm: Match rpmsg channel
instead of compatible")

Fixes: bcabe1e09135 ("soc: qcom: smd-rpm: Match rpmsg channel instead of compatible")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20240729-fix-smd-rpm-v2-1-0776408a94c5@linaro.org
Signed-off-by: Bjorn Andersson 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'qcom-drivers-fixes-for-6.11' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes

2024-08-28T20:27:39+00:00

Qualcomm driver fixes for v6.11

This corrects the tzmem virt-to-phys conversion, which caused issues for
the uefisecapp implementation of EFI variable access. SDM670 is excluded
from tzmem usage due to reported issues.

The SCM get wait queue context call is corrected to be marked ATOMIC and
some dead code in qseecom, following the tzmem conversion, is removed.

The memory backing command DB is remapped writecombined, to avoid XPU
violations when Linux runs without the Qualcomm hypervisor.

Two compile fixes are added for pd-mapper, and the broken reference
count is corrected, to make pd-mapper deal with remoteprocs going away.

In pmic_glink a race condition where the client callbacks might be
called before we returned the client handle is corrected. The broken conditions
for when to signal that the firmware is going down is also corrected.

In the pmic_glink UCSI driver, the ucsi_unregister() is moved out of the
pdr callback, as this is being invoked in atomic context.

Konrad's email address is updated in MAINTAINERS, and related mailmap
entries are added.

* tag 'qcom-drivers-fixes-for-6.11' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
  soc: qcom: pd-mapper: Fix singleton refcount
  firmware: qcom: tzmem: disable sdm670 platform
  soc: qcom: pmic_glink: Actually communicate when remote goes down
  usb: typec: ucsi: Move unregister out of atomic section
  soc: qcom: pmic_glink: Fix race during initialization
  firmware: qcom: qseecom: remove unused functions
  firmware: qcom: tzmem: fix virtual-to-physical address conversion
  firmware: qcom: scm: Mark get_wq_ctx() as atomic call
  MAINTAINERS: Update Konrad Dybcio's email address
  mailmap: Add an entry for Konrad Dybcio
  soc: qcom: pd-mapper: mark qcom_pdm_domains as __maybe_unused
  soc: qcom: cmd-db: Map shared memory as WC, not WB
  soc: qcom: pd-mapper: Depend on ARCH_QCOM || COMPILE_TEST

Link: https://lore.kernel.org/r/20240826145209.1646159-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann

soc: qcom: pd-mapper: Fix singleton refcount

2024-08-21T14:50:48+00:00

The Qualcomm pd-mapper is a refcounted singleton, but the refcount is
never incremented, which means the as soon as any remoteproc instance
stops the count will hit 0.

At this point the pd-mapper QMI service is stopped, leaving firmware
without access to the PD information. Stopping any other remoteproc
instances will result in a use-after-free, which best case manifest
itself as a refcount underflow:

  refcount_t: underflow; use-after-free.
  WARNING: CPU: 1 PID: 354 at lib/refcount.c:87 refcount_dec_and_mutex_lock+0xc4/0x148
  ...
  Call trace:
   refcount_dec_and_mutex_lock+0xc4/0x148
   qcom_pdm_remove+0x40/0x118 [qcom_pd_mapper]
   ...

Fix this by incrementing the refcount, so that the pd-mapper is only
torn down when the last remoteproc stops, as intended.

Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")
Signed-off-by: Bjorn Andersson 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20240820-pd-mapper-refcount-fix-v1-1-03ea65c0309b@quicinc.com
Signed-off-by: Bjorn Andersson

soc: qcom: pmic_glink: Actually communicate when remote goes down

2024-08-21T13:37:37+00:00

When the pmic_glink state is UP and we either receive a protection-
domain (PD) notification indicating that the PD is going down, or that
the whole remoteproc is going down, it's expected that the pmic_glink
client instances are notified that their function has gone DOWN.

This is not what the code does, which results in the client state either
not updating, or being wrong in many cases. So let's fix the conditions.

Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
Cc: stable@vger.kernel.org
Reviewed-by: Heikki Krogerus 
Reviewed-by: Neil Armstrong 
Reviewed-by: Dmitry Baryshkov 
Tested-by: Amit Pundir 
Reviewed-by: Johan Hovold 
Tested-by: Johan Hovold 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-3-eec53c750a04@quicinc.com
Signed-off-by: Bjorn Andersson

usb: typec: ucsi: Move unregister out of atomic section

2024-08-21T13:37:37+00:00

Commit '9329933699b3 ("soc: qcom: pmic_glink: Make client-lock
non-sleeping")' moved the pmic_glink client list under a spinlock, as it
is accessed by the rpmsg/glink callback, which in turn is invoked from
IRQ context.

This means that ucsi_unregister() is now called from atomic context,
which isn't feasible as it's expecting a sleepable context. An effort is
under way to get GLINK to invoke its callbacks in a sleepable context,
but until then lets schedule the unregistration.

A side effect of this is that ucsi_unregister() can now happen
after the remote processor, and thereby the communication link with it, is
gone. pmic_glink_send() is amended with a check to avoid the resulting NULL
pointer dereference.
This does however result in the user being informed about this error by
the following entry in the kernel log:

  ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5

Fixes: 9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping")
Cc: stable@vger.kernel.org
Reviewed-by: Heikki Krogerus 
Reviewed-by: Neil Armstrong 
Reviewed-by: Dmitry Baryshkov 
Tested-by: Amit Pundir 
Reviewed-by: Johan Hovold 
Tested-by: Johan Hovold 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20240820-pmic-glink-v6-11-races-v3-2-eec53c750a04@quicinc.com
Signed-off-by: Bjorn Andersson