linux-stable.git/drivers/firmware/qcom, branch linux-6.11.y Linux kernel stable tree firmware: qcom: scm: suppress download mode error 2024-11-14T12:21:14+00:00 Johan Hovold johan+linaro@kernel.org 2024-10-02T10:01:21+00:00 a70638760015accb1494fe69ea16a9cfbf2413dd [ Upstream commit d67907154808745b0fae5874edc7b0f78d33991c ] Stop spamming the logs with errors about missing mechanism for setting the so called download (or dump) mode for users that have not requested that feature to be enabled in the first place. This avoids the follow error being logged on boot as well as on shutdown when the feature it not available and download mode has not been enabled on the kernel command line: qcom_scm firmware:scm: No available mechanism for setting download mode Fixes: 79cb2cb8d89b ("firmware: qcom: scm: Disable SDI and write no dump to dump mode") Fixes: 781d32d1c970 ("firmware: qcom_scm: Clear download bit during reboot") Cc: Mukesh Ojha <quic_mojha@quicinc.com> Cc: stable@vger.kernel.org # 6.4 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20241002100122.18809-2-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d67907154808745b0fae5874edc7b0f78d33991c ]

Stop spamming the logs with errors about missing mechanism for setting
the so called download (or dump) mode for users that have not requested
that feature to be enabled in the first place.

This avoids the follow error being logged on boot as well as on
shutdown when the feature it not available and download mode has not
been enabled on the kernel command line:

	qcom_scm firmware:scm: No available mechanism for setting download mode

Fixes: 79cb2cb8d89b ("firmware: qcom: scm: Disable SDI and write no dump to dump mode")
Fixes: 781d32d1c970 ("firmware: qcom_scm: Clear download bit during reboot")
Cc: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: stable@vger.kernel.org	# 6.4
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/r/20241002100122.18809-2-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: qcom: scm: Refactor code to support multiple dload mode 2024-11-14T12:21:14+00:00 Mukesh Ojha quic_mojha@quicinc.com 2024-07-15T15:56:54+00:00 f82ed58b14e9d2c16877379efb76457bae9d52b4 [ Upstream commit c802b0a2ed0f67fcec8cc0cac685c8fd0dd0aa6f ] Currently on Qualcomm SoC, download_mode is enabled if CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is selected or passed a boolean value from command line. Refactor the code such that it supports multiple download modes and drop CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT config instead, give interface to set the download mode from module parameter while being backword compatible at the same time. Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20240715155655.1811178-1-quic_mojha@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Stable-dep-of: d67907154808 ("firmware: qcom: scm: suppress download mode error") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c802b0a2ed0f67fcec8cc0cac685c8fd0dd0aa6f ]

Currently on Qualcomm SoC, download_mode is enabled if
CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is selected or
passed a boolean value from command line.

Refactor the code such that it supports multiple download
modes and drop CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT config
instead, give interface to set the download mode from
module parameter while being backword compatible at the
same time.

Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/r/20240715155655.1811178-1-quic_mojha@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stable-dep-of: d67907154808 ("firmware: qcom: scm: suppress download mode error")
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling 2024-11-14T12:20:56+00:00 Qingqing Zhou quic_qqzhou@quicinc.com 2024-10-22T19:21:48+00:00 239fc66b7a0fb1ad0bbf09dc430539ddf49d5138 [ Upstream commit f489f6c6eb26482010470d77bad3901a3de1b166 ] When enabling SHM bridge, QTEE returns 0 and sets error 4 in result to qcom_scm for unsupported platforms. Currently, tzmem interprets this as an unknown error rather than recognizing it as an unsupported platform. Error log: [ 0.177224] qcom_scm firmware:scm: error (____ptrval____): Failed to enable the TrustZone memory allocator [ 0.177244] qcom_scm firmware:scm: probe with driver qcom_scm failed with error 4 To address this, modify the function call qcom_scm_shm_bridge_enable() to remap result to indicate an unsupported error. This way, tzmem will correctly identify it as an unsupported platform case instead of reporting it as an error. Fixes: 178e19c0df1b ("firmware: qcom: scm: add support for SHM bridge operations") Signed-off-by: Qingqing Zhou <quic_qqzhou@quicinc.com> Co-developed-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Signed-off-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20241022192148.1626633-1-quic_kuldsing@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f489f6c6eb26482010470d77bad3901a3de1b166 ]

When enabling SHM bridge, QTEE returns 0 and sets error 4 in result to
qcom_scm for unsupported platforms. Currently, tzmem interprets this as
an unknown error rather than recognizing it as an unsupported platform.

Error log:
[    0.177224] qcom_scm firmware:scm: error (____ptrval____): Failed to enable the TrustZone memory allocator
[    0.177244] qcom_scm firmware:scm: probe with driver qcom_scm failed with error 4

To address this, modify the function call qcom_scm_shm_bridge_enable()
to remap result to indicate an unsupported error. This way, tzmem will
correctly identify it as an unsupported platform case instead of
reporting it as an error.

Fixes: 178e19c0df1b ("firmware: qcom: scm: add support for SHM bridge operations")
Signed-off-by: Qingqing Zhou <quic_qqzhou@quicinc.com>
Co-developed-by: Kuldeep Singh <quic_kuldsing@quicinc.com>
Signed-off-by: Kuldeep Singh <quic_kuldsing@quicinc.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/r/20241022192148.1626633-1-quic_kuldsing@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: qcom: scm: fix a NULL-pointer dereference 2024-11-14T12:20:54+00:00 Bartosz Golaszewski bartosz.golaszewski@linaro.org 2024-09-30T08:33:28+00:00 3d36e2b1d803f0d1cc674115d295a8f20ddb9268 [ Upstream commit ca61d6836e6f4442a77762e1074d2706a2a6e578 ] Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer. Fixes: 449d0d84bcd8 ("firmware: qcom: scm: smc: switch to using the SCM allocator") Reported-by: Rudraksha Gupta <guptarud@gmail.com> Closes: https://lore.kernel.org/lkml/692cfe9a-8c05-4ce4-813e-82b3f310019a@gmail.com/ Reviewed-by: Konrad Dybcio <konradybcio@kernel.org> Tested-by: Rudraksha Gupta <guptarud@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Link: https://lore.kernel.org/r/20240930083328.17904-1-brgl@bgdev.pl Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ca61d6836e6f4442a77762e1074d2706a2a6e578 ]

Some SCM calls can be invoked with __scm being NULL (the driver may not
have been and will not be probed as there's no SCM entry in device-tree).
Make sure we don't dereference a NULL pointer.

Fixes: 449d0d84bcd8 ("firmware: qcom: scm: smc: switch to using the SCM allocator")
Reported-by: Rudraksha Gupta <guptarud@gmail.com>
Closes: https://lore.kernel.org/lkml/692cfe9a-8c05-4ce4-813e-82b3f310019a@gmail.com/
Reviewed-by: Konrad Dybcio <konradybcio@kernel.org>
Tested-by: Rudraksha Gupta <guptarud@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Kuldeep Singh <quic_kuldsing@quicinc.com>
Link: https://lore.kernel.org/r/20240930083328.17904-1-brgl@bgdev.pl
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: qcom: scm: Disable SDI and write no dump to dump mode 2024-10-04T14:37:34+00:00 Mukesh Ojha quic_mojha@quicinc.com 2024-07-08T15:53:32+00:00 ce6277d123735d083dbc70ab20e8134248be9457 [ Upstream commit 79cb2cb8d89b7eca87e8dac031dadea4aeafeaa7 ] SDI is enabled for most of the Qualcomm SoCs and as per commit ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required") it was recommended to disable SDI by mentioning it in device tree to avoid hang during watchdog or during reboot. However, for some cases if download mode tcsr register already configured from boot firmware to collect dumps and if SDI is disabled via means of mentioning it in device tree we could still end up with dump collection. Disabling SDI alone is not completely enough to disable dump mode and we also need to zero out the bits download bits from tcsr register. Current commit now, unconditionally call qcom_scm_set_download_mode() based on download_mode flag, at max if TCSR register is not mentioned or available for a SoC it will fallback to legacy way of setting download mode through command which may be no-ops or return error in case current firmware does not implements QCOM_SCM_INFO_IS_CALL_AVAIL so, at worst it does nothing if it fails. It also does to call SDI disable call if dload mode is disabled, which looks fine to do as intention is to disable dump collection even if system crashes. Fixes: ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required") Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20240708155332.4056479-1-quic_mojha@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 79cb2cb8d89b7eca87e8dac031dadea4aeafeaa7 ]

SDI is enabled for most of the Qualcomm SoCs and as per commit
ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required")
it was recommended to disable SDI by mentioning it in device tree
to avoid hang during watchdog or during reboot.

However, for some cases if download mode tcsr register already
configured from boot firmware to collect dumps and if SDI is
disabled via means of mentioning it in device tree we could
still end up with dump collection. Disabling SDI alone is
not completely enough to disable dump mode and we also need to
zero out the bits download bits from tcsr register.

Current commit now, unconditionally call qcom_scm_set_download_mode()
based on download_mode flag, at max if TCSR register is not mentioned
or available for a SoC it will fallback to legacy way of setting
download mode through command which may be no-ops or return error
in case current firmware does not implements QCOM_SCM_INFO_IS_CALL_AVAIL
so, at worst it does nothing if it fails.

It also does to call SDI disable call if dload mode is disabled, which
looks fine to do as intention is to disable dump collection even if
system crashes.

Fixes: ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required")
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/r/20240708155332.4056479-1-quic_mojha@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire() 2024-08-31T03:17:50+00:00 Dan Carpenter dan.carpenter@linaro.org 2024-08-29T19:23:04+00:00 db213b0cfe3268d8b1d382b3bcc999c687a2567f If the __qcuefi pointer is not set, then in the original code, we would hold onto the lock. That means that if we tried to set it later, then it would cause a deadlock. Drop the lock on the error path. That's what all the callers are expecting. Fixes: 759e7a2b62eb ("firmware: Add support for Qualcomm UEFI Secure Application") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/19829bc4-1b6f-47f7-847a-e90c25749e40@stanley.mountain Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
If the __qcuefi pointer is not set, then in the original code, we would
hold onto the lock.  That means that if we tried to set it later, then
it would cause a deadlock.  Drop the lock on the error path.  That's
what all the callers are expecting.

Fixes: 759e7a2b62eb ("firmware: Add support for Qualcomm UEFI Secure Application")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/19829bc4-1b6f-47f7-847a-e90c25749e40@stanley.mountain
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
firmware: qcom: tzmem: disable sdm670 platform 2024-08-21T13:37:37+00:00 Richard Acayan mailingradian@gmail.com 2024-07-30T01:38:35+00:00 8342009efa2a5e75dce56173d7de026bcc6666d8 The Pixel 3a returns 4291821499 (-3145797 or 0xFFCFFFBB) when attempting to load the GPU firmware if tzmem is allowed. Disable it on SDM670 so the GPU can successfully probe. Signed-off-by: Richard Acayan <mailingradian@gmail.com> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20240730013834.41840-2-mailingradian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
The Pixel 3a returns 4291821499 (-3145797 or 0xFFCFFFBB) when attempting
to load the GPU firmware if tzmem is allowed. Disable it on SDM670 so
the GPU can successfully probe.

Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20240730013834.41840-2-mailingradian@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
firmware: qcom: tzmem: fix virtual-to-physical address conversion 2024-08-15T03:08:32+00:00 Bartosz Golaszewski bartosz.golaszewski@linaro.org 2024-07-31T07:44:56+00:00 1c753d001a259d0278fe318a1ed3c8aa5f3ea09e We currently only correctly convert the virtual address passed by the caller to qcom_tzmem_to_phys() if it corresponds to the base address of the chunk. If the user wants to convert some pointer at an offset relative to that base address, we'll return 0. Let's change the implementation of qcom_tzmem_to_phys(): iterate over the chunks and try to call gen_pool_virt_to_phys() just-in-time instead of trying to call it only once when creating the chunk. Fixes: 84f5a7b67b61 ("firmware: qcom: add a dedicated TrustZone buffer allocator") Reported-by: Johan Hovold <johan+linaro@kernel.org> Closes: https://lore.kernel.org/lkml/20240729095542.21097-1-johan+linaro@kernel.org/ Acked-by: Andrew Halaney <ahalaney@redhat.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20240731-tzmem-efivars-fix-v2-1-f0e84071ec07@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
We currently only correctly convert the virtual address passed by the
caller to qcom_tzmem_to_phys() if it corresponds to the base address of
the chunk. If the user wants to convert some pointer at an offset
relative to that base address, we'll return 0. Let's change the
implementation of qcom_tzmem_to_phys(): iterate over the chunks and try
to call gen_pool_virt_to_phys() just-in-time instead of trying to call
it only once when creating the chunk.

Fixes: 84f5a7b67b61 ("firmware: qcom: add a dedicated TrustZone buffer allocator")
Reported-by: Johan Hovold <johan+linaro@kernel.org>
Closes: https://lore.kernel.org/lkml/20240729095542.21097-1-johan+linaro@kernel.org/
Acked-by: Andrew Halaney <ahalaney@redhat.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20240731-tzmem-efivars-fix-v2-1-f0e84071ec07@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
firmware: qcom: scm: Mark get_wq_ctx() as atomic call 2024-08-15T03:08:28+00:00 Murali Nalajala quic_mnalajal@quicinc.com 2024-08-14T22:32:44+00:00 9960085a3a82c58d3323c1c20b991db6045063b0 Currently get_wq_ctx() is wrongly configured as a standard call. When two SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to resume the corresponding sleeping thread. But if get_wq_ctx() is interrupted, goes to sleep and another SMC call is waiting to be allocated a waitq context, it leads to a deadlock. To avoid this get_wq_ctx() must be an atomic call and can't be a standard SMC call. Hence mark get_wq_ctx() as a fast call. Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic") Cc: stable@vger.kernel.org Signed-off-by: Murali Nalajala <quic_mnalajal@quicinc.com> Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240814223244.40081-1-quic_uchalich@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
Currently get_wq_ctx() is wrongly configured as a standard call. When two
SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to
resume the corresponding sleeping thread. But if get_wq_ctx() is
interrupted, goes to sleep and another SMC call is waiting to be allocated
a waitq context, it leads to a deadlock.

To avoid this get_wq_ctx() must be an atomic call and can't be a standard
SMC call. Hence mark get_wq_ctx() as a fast call.

Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic")
Cc: stable@vger.kernel.org
Signed-off-by: Murali Nalajala <quic_mnalajal@quicinc.com>
Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com>
Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
Link: https://lore.kernel.org/r/20240814223244.40081-1-quic_uchalich@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
firmware: qcom: tzmem: don't ask about allocator mode when not enabled 2024-07-17T00:35:45+00:00 Linus Torvalds torvalds@linux-foundation.org 2024-07-17T00:35:45+00:00 9de4ad3bde144b55b8451fc280c18107c139481c The Qualcomm firmware code shouldn't ask about what memory allocator mode should be used when the code isn't even enabled. Get rid of pointless config-time question. Link: https://lore.kernel.org/all/CAHk-=wg+38EHPKGou1MqXwAAXC30cM8sMgZAGnZ7TcFO4L9J2w@mail.gmail.com/ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
The Qualcomm firmware code shouldn't ask about what memory allocator
mode should be used when the code isn't even enabled.

Get rid of pointless config-time question.

Link: https://lore.kernel.org/all/CAHk-=wg+38EHPKGou1MqXwAAXC30cM8sMgZAGnZ7TcFO4L9J2w@mail.gmail.com/
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>