arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
GPIOs 44-47 were previously reserved, preventing Linux from accessing
SPI11 (qupv1_se3). Since there is no TZ use case for these pins on Linux,
they can be safely unreserved. Removing them from the reserved list
resolves the SPI11 access issue for Linux.
Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
index 1aead50b8920..107ea8045f55 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
@@ -451,8 +451,7 @@ &remoteproc_cdsp {
};
&tlmm {
- gpio-reserved-ranges = <34 2>, /* TPM LP & INT */
- <44 4>; /* SPI (TPM) */
+ gpio-reserved-ranges = <34 2>; /* TPM LP & INT */
pcie4_default: pcie4-default-state {
clkreq-n-pins {
--
2.43.0
On 11/6/25 11:24 AM, Xueyao An wrote: > GPIOs 44-47 were previously reserved, preventing Linux from accessing > SPI11 (qupv1_se3). Since there is no TZ use case for these pins on Linux, > they can be safely unreserved. Removing them from the reserved list > resolves the SPI11 access issue for Linux. > > Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com> > --- Note: you sent a v2 of the patch, it's expected that you provide a short changelog and a link to the previous revisions. Please switch to using the b4 tool, which help you meeting that and other expectations - check out the internal upstreaming guide Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Konrad
On 06/11/2025 11:24, Xueyao An wrote: > GPIOs 44-47 were previously reserved, preventing Linux from accessing > SPI11 (qupv1_se3). Since there is no TZ use case for these pins on Linux, > they can be safely unreserved. Removing them from the reserved list > resolves the SPI11 access issue for Linux. > > Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com> Please read carefully internal guideline about changelogs and tags. <form letter> This is a friendly reminder during the review process. It looks like you received a tag and forgot to add it. If you do not know the process, here is a short explanation: Please add Acked-by/Reviewed-by/Tested-by tags when posting new versions of patchset, under or above your Signed-off-by tag, unless patch changed significantly (e.g. new properties added to the DT bindings). Tag is "received", when provided in a message replied to you on the mailing list. Tools like b4 can help here. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for tags received on the version they apply. Please read: https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577 If a tag was not added on purpose, please state why and what changed. </form letter> Best regards, Krzysztof
© 2016 - 2025 Red Hat, Inc.