| Message ID | 20250207151706.45031-1-caleb.connolly@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | arm64: dts: qcom: sdm845-oneplus: use guard pages | expand |
(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 >
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
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
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