[PATCH] arm64: dts: qcom: sdm845-oneplus: use guard pages

[PATCH] arm64: dts: qcom: sdm845-oneplus: use guard pages

[Caleb Connolly]

From: "Dr. Git" <drgitx@gmail.com>

Rather than manually define the guard pages, use the
"qcom,use-guard-pages" property for rmtfs.

Signed-off-by: "Dr. Git" <drgitx@gmail.com>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
---
 .../boot/dts/qcom/sdm845-oneplus-common.dtsi   | 18 +++---------------
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
index 46e25c53829a..6a2acbec68ba 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
@@ -70,33 +70,21 @@ key-vol-up {
 		};
 	};
 
 	reserved-memory {
-		/*
-		 * The rmtfs_mem needs to be guarded due to "XPU limitations"
-		 * it is otherwise possible for an allocation adjacent to the
-		 * rmtfs_mem region to trigger an XPU violation, causing a crash.
-		 */
-		rmtfs_lower_guard: rmtfs-lower-guard@f5b00000 {
-			no-map;
-			reg = <0 0xf5b00000 0 0x1000>;
-		};
 		/*
 		 * The rmtfs memory region in downstream is 'dynamically allocated'
 		 * but given the same address every time. Hard code it as this address is
 		 * where the modem firmware expects it to be.
 		 */
-		rmtfs_mem: rmtfs-mem@f5b01000 {
+		rmtfs_mem: rmtfs-mem@f5b00000 {
 			compatible = "qcom,rmtfs-mem";
-			reg = <0 0xf5b01000 0 0x200000>;
+			reg = <0 0xf5b00000 0 0x202000>;
 			no-map;
 
 			qcom,client-id = <1>;
 			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
-		};
-		rmtfs_upper_guard: rmtfs-upper-guard@f5d01000 {
-			no-map;
-			reg = <0 0xf5d01000 0 0x1000>;
+			qcom,use-guard-pages;
 		};
 
 		/*
 		 * It seems like reserving the old rmtfs_mem region is also needed to prevent
-- 
2.48.1

Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: use guard pages

[Konrad Dybcio]

On 7.02.2025 4:17 PM, Caleb Connolly wrote:
> From: "Dr. Git" <drgitx@gmail.com>
> 
> Rather than manually define the guard pages, use the
> "qcom,use-guard-pages" property for rmtfs.
> 
> Signed-off-by: "Dr. Git" <drgitx@gmail.com>

I'm not sure this ID is acceptable

> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
> ---

The patch looks good otherwise

Konrad

Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: use guard pages

[Caleb Connolly]

(resending from not a mobile client, oops)

On 2/7/25 21:20, Konrad Dybcio wrote:
> On 7.02.2025 4:17 PM, Caleb Connolly wrote:
>> From: "Dr. Git" <drgitx@gmail.com>
>>
>> Rather than manually define the guard pages, use the
>> "qcom,use-guard-pages" property for rmtfs.
>>
>> Signed-off-by: "Dr. Git" <drgitx@gmail.com>
> 
> I'm not sure this ID is acceptable


Linus & Greg explicitly allowed for aliases previously. Patches by 
"Asahi Lina" and others have been merged.

Ive spoken with the author several time about this in the previous years 
and they aren't interested in publicising their legal name. So the only 
alternative here is that plagiarise these patches which I didn't write, 
or i have to carry them forever downstream...

Kind regards,
> 
>> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
>> ---
> 
> The patch looks good otherwise
> 
> Konrad
> 

-- 
Caleb (they/them)

Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: use guard pages

[Konrad Dybcio]

On 8.02.2025 12:49 AM, Caleb Connolly wrote:
> (resending from not a mobile client, oops)
> 
> On 2/7/25 21:20, Konrad Dybcio wrote:
>> On 7.02.2025 4:17 PM, Caleb Connolly wrote:
>>> From: "Dr. Git" <drgitx@gmail.com>
>>>
>>> Rather than manually define the guard pages, use the
>>> "qcom,use-guard-pages" property for rmtfs.
>>>
>>> Signed-off-by: "Dr. Git" <drgitx@gmail.com>
>>
>> I'm not sure this ID is acceptable
> 
> 
> Linus & Greg explicitly allowed for aliases previously. Patches by "Asahi Lina" and others have been merged.

Correct, however the trust is put into the maintainer. Marcan et al. accepted
patches by ""Asahi Lina"", as they had enough confidence to put their name
behind said contributor not being e.g. on the sanctioned lists.

Konrad

> Ive spoken with the author several time about this in the previous years and they aren't interested in publicising their legal name. So the only alternative here is that plagiarise these patches which I didn't write, or i have to carry them forever downstream...

Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: use guard pages

[Caleb Connolly]

On 2/10/25 18:14, Konrad Dybcio wrote:
> On 8.02.2025 12:49 AM, Caleb Connolly wrote:
>> (resending from not a mobile client, oops)
>>
>> On 2/7/25 21:20, Konrad Dybcio wrote:
>>> On 7.02.2025 4:17 PM, Caleb Connolly wrote:
>>>> From: "Dr. Git" <drgitx@gmail.com>
>>>>
>>>> Rather than manually define the guard pages, use the
>>>> "qcom,use-guard-pages" property for rmtfs.
>>>>
>>>> Signed-off-by: "Dr. Git" <drgitx@gmail.com>
>>>
>>> I'm not sure this ID is acceptable
>>
>>
>> Linus & Greg explicitly allowed for aliases previously. Patches by "Asahi Lina" and others have been merged.
> 
> Correct, however the trust is put into the maintainer. Marcan et al. accepted
> patches by ""Asahi Lina"", as they had enough confidence to put their name
> behind said contributor not being e.g. on the sanctioned lists.

Right, well please let me know your decision and how you'd like to 
proceed if this patch is unacceptable.

Kind regards,
> 
> Konrad
> 
>> Ive spoken with the author several time about this in the previous years and they aren't interested in publicising their legal name. So the only alternative here is that plagiarise these patches which I didn't write, or i have to carry them forever downstream...
> 
> 

-- 
Caleb (they/them)

Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: use guard pages

[Krzysztof Kozlowski]

On 07/02/2025 21:20, Konrad Dybcio wrote:
> On 7.02.2025 4:17 PM, Caleb Connolly wrote:
>> From: "Dr. Git" <drgitx@gmail.com>
>>
>> Rather than manually define the guard pages, use the
>> "qcom,use-guard-pages" property for rmtfs.
>>
>> Signed-off-by: "Dr. Git" <drgitx@gmail.com>
> 
> I'm not sure this ID is acceptable

It is not. We do not take anonymous contributions.

This has to be known identity, you can achieve this by having your key
signed and present in kernel keyring.


Best regards,
Krzysztof

Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: use guard pages

[Krzysztof Kozlowski]

On 07/02/2025 21:24, Caleb Connolly wrote:
> Linus & Greg explicitly allowed for aliases previously. Patches by "Asahi
> Lina" and others have been merged.

That's not alias but anonymous contribution. This was never accepted.

> 
> Ive spoken with the author several time about this in the previous years
> and they aren't interested in publicising their legal name. So the only
> alternative here is that plagiarise these patches which I didn't write, or
> i have to carry them forever downstream...

Or get known identity verified.

Best regards,
Krzysztof

Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: use guard pages

[Arnd Bergmann]

On Mon, Feb 10, 2025, at 21:05, Caleb Connolly wrote:
> On 2/10/25 18:14, Konrad Dybcio wrote:
>> On 8.02.2025 12:49 AM, Caleb Connolly wrote:
>>> (resending from not a mobile client, oops)
>>>
>>> On 2/7/25 21:20, Konrad Dybcio wrote:
>>>> On 7.02.2025 4:17 PM, Caleb Connolly wrote:
>>>>> From: "Dr. Git" <drgitx@gmail.com>
>>>>>
>>>>> Rather than manually define the guard pages, use the
>>>>> "qcom,use-guard-pages" property for rmtfs.
>>>>>
>>>>> Signed-off-by: "Dr. Git" <drgitx@gmail.com>
>>>>
>>>> I'm not sure this ID is acceptable
>>>
>>>
>>> Linus & Greg explicitly allowed for aliases previously. Patches by "Asahi Lina" and others have been merged.
>> 
>> Correct, however the trust is put into the maintainer. Marcan et al. accepted
>> patches by ""Asahi Lina"", as they had enough confidence to put their name
>> behind said contributor not being e.g. on the sanctioned lists.
>
> Right, well please let me know your decision and how you'd like to 
> proceed if this patch is unacceptable.

This is clearly a grey area, but since you are familiar with the
patch author, and are have added your S-o-B, I don't mind taking
the patch through the SoC tree with that S-o-B chain, even if I
would not personally apply a patch from the same author without
additional information.

I would suggest that Konrad should follows the same rules
here, but of course they are free to make their own decisions.

     Arnd