[PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[Rudraksha Gupta via B4 Relay]

Throughout the years, many have contributed to the Pinephone Pro (ppp)
development. Unfortunately, these patches are scattered around various
repositories in different states.

I will be attempting to upstream these patches. I will start off with the
following small series:
- Add light/proximity sensor support
  - https://codeberg.org/megi/linux/commit/f171bc7013bc7ad3de9af817bfbcbfa548ebe01c
- Add accelerometer sensor support
  - https://codeberg.org/megi/linux/commit/b0bb7633e073a6760fa213b8c4a78ea2e73c7bf1
- Add magnetometer sensor support
  - https://codeberg.org/megi/linux/commit/2f7e67f451f16eaf15b81aa1dbdf126d54927d35
- Add mount-matrix for magnetometer
  - https://codeberg.org/megi/linux/commit/d7cd2eab931e32fa94408a96d73b4e6c0616107a
- Fix voltage threshold for volume down key
  - https://codeberg.org/megi/linux/commit/7c496a5cc27ed4e38b740f36c2d8b2c62f80ae54

Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
Changes in v3:
- change magnetometer mount matrix
- update volume button threshold
- Link to v2: https://lore.kernel.org/r/20250921-ppp_light_accel_mag_vol-down-v2-0-e6bcc6ca74ae@gmail.com

Changes in v2:
- remove usb-typec node in dts from light/proximity sensor patch
- Link to v1: https://lore.kernel.org/r/20250920-ppp_light_accel_mag_vol-down-v1-0-c8bbcd3e2e94@gmail.com

---
Leonardo G. Trombetta (1):
      arm64: dts: rk3399-pinephone-pro: Add mount-matrix for magnetometer

Ondrej Jirman (4):
      arm64: dts: rk3399-pinephone-pro: Add light/proximity sensor support
      arm64: dts: rk3399-pinephone-pro: Add accelerometer sensor support
      arm64: dts: rk3399-pinephone-pro: Add magnetometer sensor support
      arm64: dts: rk3399-pinephone-pro: Fix voltage threshold for volume keys

 .../boot/dts/rockchip/rk3399-pinephone-pro.dts     | 42 ++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)
---
base-commit: f83ec76bf285bea5727f478a68b894f5543ca76e
change-id: 20250920-ppp_light_accel_mag_vol-down-817c84fdae8d

Best regards,
-- 
Rudraksha Gupta <guptarud@gmail.com>

[PATCH v3 1/5] arm64: dts: rk3399-pinephone-pro: Add light/proximity sensor support

[Rudraksha Gupta via B4 Relay]

From: Ondrej Jirman <megi@xff.cz>

Pinephone Pro uses STK3311

Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
index 6f97e57f36f5599f4027a0f3db98bcbc69cef5e5..65ee0b805034a4357a766d4f1f9efa2d4a843d77 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
@@ -520,6 +520,17 @@ touchscreen@14 {
 		touchscreen-size-x = <720>;
 		touchscreen-size-y = <1440>;
 	};
+
+	light-sensor@48 {
+		compatible = "sensortek,stk3311";
+		reg = <0x48>;
+		interrupt-parent = <&gpio4>;
+		interrupts = <RK_PD3 IRQ_TYPE_EDGE_FALLING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&stk3311_int>;
+		vdd-supply = <&vcc_3v0>;
+		leda-supply = <&vcc_3v0>;
+	};
 };
 
 &i2c4 {
@@ -689,6 +700,12 @@ vcc1v8_codec_en: vcc1v8-codec-en {
 		};
 	};
 
+	stk3311 {
+		stk3311_int: stk3311-int {
+			rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_input_pull_up>;
+		};
+	};
+
 	wireless-bluetooth {
 		bt_wake_pin: bt-wake-pin {
 			rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;

-- 
2.51.0

[PATCH v3 2/5] arm64: dts: rk3399-pinephone-pro: Add accelerometer sensor support

[Rudraksha Gupta via B4 Relay]

From: Ondrej Jirman <megi@xff.cz>

Pinephone Pro uses mpu6500.

Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
index 65ee0b805034a4357a766d4f1f9efa2d4a843d77..21ff12ac5f6e52041f485c9f2702f5a15ee831f9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
@@ -544,7 +544,13 @@ mpu6500@68 {
 		reg = <0x68>;
 		interrupt-parent = <&gpio1>;
 		interrupts = <RK_PC6 IRQ_TYPE_LEVEL_LOW>;
+		vdd-supply = <&vcc_1v8>;
 		vddio-supply = <&vcc_1v8>;
+
+		mount-matrix =
+			"1", "0", "0",
+			"0", "-1", "0",
+			"0", "0", "1";
 	};
 };
 

-- 
2.51.0

[PATCH v3 3/5] arm64: dts: rk3399-pinephone-pro: Add magnetometer sensor support

[Rudraksha Gupta via B4 Relay]

From: Ondrej Jirman <megi@xff.cz>

Pinephone Pro uses AF8133J.

Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
index 21ff12ac5f6e52041f485c9f2702f5a15ee831f9..266a08540dd0fe099319ec703bb0828c8c5c2c25 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
@@ -554,6 +554,16 @@ mpu6500@68 {
 	};
 };
 
+&i2c4 {
+	af8133j: compass@1c {
+		compatible = "voltafield,af8133j";
+		reg = <0x1c>;
+		reset-gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_LOW>;
+		avdd-supply = <&vcc_3v0>;
+		dvdd-supply = <&vcc_1v8>;
+	};
+};
+
 &io_domains {
 	bt656-supply = <&vcc1v8_dvp>;
 	audio-supply = <&vcca1v8_codec>;

-- 
2.51.0

[PATCH v3 4/5] arm64: dts: rk3399-pinephone-pro: Add mount-matrix for magnetometer

[Rudraksha Gupta via B4 Relay]

From: "Leonardo G. Trombetta" <lgtrombetta@gmx.com>

After experimenting with the magnetometer on the Pinephone Pro I found
out the mount-matrix currently reported by the AF8133J driver is just
the identity matrix (no rotation), which is wrong. It would seem to me
that there is currently no `mount-matrix` info and that's why the driver
reports a trivial answer. As far as I can tell from my tests, a 90
degree clockwise rotation in the XY plane would align it properly.

Signed-off-by: Leonardo G. Trombetta <lgtrombetta@gmx.com>
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
index 266a08540dd0fe099319ec703bb0828c8c5c2c25..a744f207dd1acebcdf566eef1c2a471b1e8f3f56 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
@@ -561,6 +561,11 @@ af8133j: compass@1c {
 		reset-gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_LOW>;
 		avdd-supply = <&vcc_3v0>;
 		dvdd-supply = <&vcc_1v8>;
+
+		mount-matrix =
+			"0", "1", "0",
+			"1", "0", "0",
+			"0", "0", "-1";
 	};
 };
 

-- 
2.51.0

[PATCH v3 5/5] arm64: dts: rk3399-pinephone-pro: Fix voltage threshold for volume keys

[Rudraksha Gupta via B4 Relay]

From: Ondrej Jirman <megi@xff.cz>

Match the thresholds as shown in the Pinephone Pro schematic.

Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
index a744f207dd1acebcdf566eef1c2a471b1e8f3f56..80c0acb506062b379a307a3125c322929724a7e8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
@@ -40,13 +40,13 @@ adc-keys {
 		button-up {
 			label = "Volume Up";
 			linux,code = <KEY_VOLUMEUP>;
-			press-threshold-microvolt = <100000>;
+			press-threshold-microvolt = <2000>;
 		};
 
 		button-down {
 			label = "Volume Down";
 			linux,code = <KEY_VOLUMEDOWN>;
-			press-threshold-microvolt = <600000>;
+			press-threshold-microvolt = <300000>;
 		};
 	};
 

-- 
2.51.0

Re: [PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[Dragan Simic]

Hello Rudraksha,

On 2025-09-21 23:05, Rudraksha Gupta via B4 Relay wrote:
> Throughout the years, many have contributed to the Pinephone Pro (ppp)
> development. Unfortunately, these patches are scattered around various
> repositories in different states.

Thanks for submitting these patches.  However, please expand the patch
descriptions, because their current forms are too terse and, as such,
simply not acceptable.  This applies to all patches in this series.

I'm also under impression that you're submitting these patches upstream
blindly and without researching the rules that apply well enough, which
may not be the best possible approach.

Finally, please refrain yourself from sending multiple versions of the
same patch series in the same day.  Doing so makes reviewing the patches
unnecessarily hard.

> I will be attempting to upstream these patches. I will start off with 
> the
> following small series:
> - Add light/proximity sensor support
>   - 
> https://codeberg.org/megi/linux/commit/f171bc7013bc7ad3de9af817bfbcbfa548ebe01c
> - Add accelerometer sensor support
>   - 
> https://codeberg.org/megi/linux/commit/b0bb7633e073a6760fa213b8c4a78ea2e73c7bf1
> - Add magnetometer sensor support
>   - 
> https://codeberg.org/megi/linux/commit/2f7e67f451f16eaf15b81aa1dbdf126d54927d35
> - Add mount-matrix for magnetometer
>   - 
> https://codeberg.org/megi/linux/commit/d7cd2eab931e32fa94408a96d73b4e6c0616107a
> - Fix voltage threshold for volume down key
>   - 
> https://codeberg.org/megi/linux/commit/7c496a5cc27ed4e38b740f36c2d8b2c62f80ae54
> 
> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
> ---
> Changes in v3:
> - change magnetometer mount matrix
> - update volume button threshold
> - Link to v2:
> https://lore.kernel.org/r/20250921-ppp_light_accel_mag_vol-down-v2-0-e6bcc6ca74ae@gmail.com
> 
> Changes in v2:
> - remove usb-typec node in dts from light/proximity sensor patch
> - Link to v1:
> https://lore.kernel.org/r/20250920-ppp_light_accel_mag_vol-down-v1-0-c8bbcd3e2e94@gmail.com
> 
> ---
> Leonardo G. Trombetta (1):
>       arm64: dts: rk3399-pinephone-pro: Add mount-matrix for 
> magnetometer
> 
> Ondrej Jirman (4):
>       arm64: dts: rk3399-pinephone-pro: Add light/proximity sensor 
> support
>       arm64: dts: rk3399-pinephone-pro: Add accelerometer sensor 
> support
>       arm64: dts: rk3399-pinephone-pro: Add magnetometer sensor support
>       arm64: dts: rk3399-pinephone-pro: Fix voltage threshold for 
> volume keys
> 
>  .../boot/dts/rockchip/rk3399-pinephone-pro.dts     | 42 
> ++++++++++++++++++++--
>  1 file changed, 40 insertions(+), 2 deletions(-)

Re: [PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[Rob Herring (Arm)]

On Sun, 21 Sep 2025 14:05:53 -0700, Rudraksha Gupta wrote:
> Throughout the years, many have contributed to the Pinephone Pro (ppp)
> development. Unfortunately, these patches are scattered around various
> repositories in different states.
> 
> I will be attempting to upstream these patches. I will start off with the
> following small series:
> - Add light/proximity sensor support
>   - https://codeberg.org/megi/linux/commit/f171bc7013bc7ad3de9af817bfbcbfa548ebe01c
> - Add accelerometer sensor support
>   - https://codeberg.org/megi/linux/commit/b0bb7633e073a6760fa213b8c4a78ea2e73c7bf1
> - Add magnetometer sensor support
>   - https://codeberg.org/megi/linux/commit/2f7e67f451f16eaf15b81aa1dbdf126d54927d35
> - Add mount-matrix for magnetometer
>   - https://codeberg.org/megi/linux/commit/d7cd2eab931e32fa94408a96d73b4e6c0616107a
> - Fix voltage threshold for volume down key
>   - https://codeberg.org/megi/linux/commit/7c496a5cc27ed4e38b740f36c2d8b2c62f80ae54
> 
> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
> ---
> Changes in v3:
> - change magnetometer mount matrix
> - update volume button threshold
> - Link to v2: https://lore.kernel.org/r/20250921-ppp_light_accel_mag_vol-down-v2-0-e6bcc6ca74ae@gmail.com
> 
> Changes in v2:
> - remove usb-typec node in dts from light/proximity sensor patch
> - Link to v1: https://lore.kernel.org/r/20250920-ppp_light_accel_mag_vol-down-v1-0-c8bbcd3e2e94@gmail.com
> 
> ---
> Leonardo G. Trombetta (1):
>       arm64: dts: rk3399-pinephone-pro: Add mount-matrix for magnetometer
> 
> Ondrej Jirman (4):
>       arm64: dts: rk3399-pinephone-pro: Add light/proximity sensor support
>       arm64: dts: rk3399-pinephone-pro: Add accelerometer sensor support
>       arm64: dts: rk3399-pinephone-pro: Add magnetometer sensor support
>       arm64: dts: rk3399-pinephone-pro: Fix voltage threshold for volume keys
> 
>  .../boot/dts/rockchip/rk3399-pinephone-pro.dts     | 42 ++++++++++++++++++++--
>  1 file changed, 40 insertions(+), 2 deletions(-)
> ---
> base-commit: f83ec76bf285bea5727f478a68b894f5543ca76e
> change-id: 20250920-ppp_light_accel_mag_vol-down-817c84fdae8d
> 
> Best regards,
> --
> Rudraksha Gupta <guptarud@gmail.com>
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: using specified base-commit f83ec76bf285bea5727f478a68b894f5543ca76e

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/rockchip/' for 20250921-ppp_light_accel_mag_vol-down-v3-0-7af6651f77e4@gmail.com:

arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dtb: light-sensor@48 (sensortek,stk3311): 'leda-supply', 'vdd-supply' do not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/iio/light/stk33xx.yaml#

Re: [PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[Rudraksha Gupta]

Hi,


> My bot found new DTB warnings on the .dts files added or changed in this
> series.
>
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
>
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
>
>    pip3 install dtschema --upgrade
>
>
> This patch series was applied (using b4) to base:
>   Base: using specified base-commit f83ec76bf285bea5727f478a68b894f5543ca76e
>
> If this is not the correct base, please add 'base-commit' tag
> (or use b4 which does this automatically)
>
> New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/rockchip/' for 20250921-ppp_light_accel_mag_vol-down-v3-0-7af6651f77e4@gmail.com:
>
> arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dtb: light-sensor@48 (sensortek,stk3311): 'leda-supply', 'vdd-supply' do not match any of the regexes: '^pinctrl-[0-9]+$'
> 	from schema $id: http://devicetree.org/schemas/iio/light/stk33xx.yaml#

Thanks, addressed in v4!


Rudraksha

Re: [PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[Rudraksha Gupta]

Hi,


> Thanks for submitting these patches.  However, please expand the patch
> descriptions, because their current forms are too terse and, as such,
> simply not acceptable.  This applies to all patches in this series.

Gotcha, will do! I've added the testing that I did. From 
https://docs.kernel.org/process/submitting-patches.html

 > The text should be written in such detail so that when read weeks, 
months or even years later, it can give the reader the needed details to 
grasp the reasoning for why the patch was created.

It felt like saying more than "adding x sensor" seemed like adding fluff 
to me, so that is why I kept it short. Let me know if there is something 
else I should add beside the tests I have done.


> I'm also under impression that you're submitting these patches upstream
> blindly and without researching the rules that apply well enough, which
> may not be the best possible approach.

Sorry! I've read https://docs.kernel.org/process/submitting-patches.html 
a bunch of times during the years I have contributed to the Linux kernel 
and inevitably forget something. Please feel free to tell me what I've 
done wrong! I've corrected my mistakes in v4 (and undoubtedly probably 
introduced more, but feel free to tell me that ;) )


>
> Finally, please refrain yourself from sending multiple versions of the
> same patch series in the same day.  Doing so makes reviewing the patches
> unnecessarily hard. 

Sorry about that once again! I'm mostly a hobbyist that loves working on 
Linux over the weekend. I wanted to get correct my mistakes so that I 
can get reviews over the week. I wish lkml used a forge, so I didn't 
have to spam you, but I digress. I will keep this in mind moving forward.


Rudraksha

Re: [PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[Dragan Simic]

Hello Rudraksha,

On 2025-09-29 09:44, Rudraksha Gupta wrote:
>> Thanks for submitting these patches.  However, please expand the patch
>> descriptions, because their current forms are too terse and, as such,
>> simply not acceptable.  This applies to all patches in this series.
> 
> Gotcha, will do! I've added the testing that I did. From
> https://docs.kernel.org/process/submitting-patches.html
> 
>> The text should be written in such detail so that when read weeks,
>> months or even years later, it can give the reader the needed details
>> to grasp the reasoning for why the patch was created.
> 
> It felt like saying more than "adding x sensor" seemed like adding
> fluff to me, so that is why I kept it short. Let me know if there is
> something else I should add beside the tests I have done.

Thanks for improving the patch descriptions in the v4 of this series.
I just went quickly through the v4 and it looks much better.

It could be said that the new patch descriptions are now a bit too
verbose, in the sense that the test procedures and their results could
be summed up a bit better in prose, instead of providing the "raw"
inputs and outputs.  However, it's still better to have those, than
not to have anything.  Writing good prose is a skill that usually
requires learning and practice.

>> I'm also under impression that you're submitting these patches 
>> upstream
>> blindly and without researching the rules that apply well enough, 
>> which
>> may not be the best possible approach.
> 
> Sorry! I've read
> https://docs.kernel.org/process/submitting-patches.html a bunch of
> times during the years I have contributed to the Linux kernel and
> inevitably forget something. Please feel free to tell me what I've
> done wrong! I've corrected my mistakes in v4 (and undoubtedly probably
> introduced more, but feel free to tell me that ;) )

You haven't done anything technically wrong, but the way you submitted
the v2 and v3 made them feel a bit like you picked those patches from
some random place and submitted them to the mailing list without really
understanding the subject matter.  In other words, it's the 
contributor's
job to convince everyone else that the submitted patches are fine to
become accepted, and the v2 and v3 simply lacked that.

>> Finally, please refrain yourself from sending multiple versions of the
>> same patch series in the same day.  Doing so makes reviewing the 
>> patches
>> unnecessarily hard.
> 
> Sorry about that once again! I'm mostly a hobbyist that loves working
> on Linux over the weekend. I wanted to get correct my mistakes so that
> I can get reviews over the week. I wish lkml used a forge, so I didn't
> have to spam you, but I digress. I will keep this in mind moving
> forward.

I wonder how would some forge prevent "spamming"?  It isn't about the
possible "spamming", but about the act of submitting different versions,
which would be present regardless of the way they'd be submitted, and
the reviewers would need to be aware (i.e. "spammed") of them anyway.

Re: [PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[Rudraksha Gupta]

Hello Dragan,


> Thanks for improving the patch descriptions in the v4 of this series.
> I just went quickly through the v4 and it looks much better.
>
> It could be said that the new patch descriptions are now a bit too
> verbose, in the sense that the test procedures and their results could
> be summed up a bit better in prose, instead of providing the "raw"
> inputs and outputs.  However, it's still better to have those, than
> not to have anything.  Writing good prose is a skill that usually
> requires learning and practice.

Awesome! I was hoping that others would comment on the testing I've done 
(especially for the accelerometer and magnetometer patches) as I can't 
tell if userspace is wrong or if my testing/conclusion is wrong. Mobile 
Linux is very early stages at the moment, and I suspect the Pinephone 
and Pinephone Pro were used as reference devices with Megi's downstream 
kernel. Wrong mount matrices in the downstream kernel might be affecting 
userspace. This means that with the corrected mount matrices in this 
patch series, userspace is slightly broken (eg. since I fixed the 
accelerometer, the screen in Phosh and KDE Plasma are upside down. I 
suspect KDE's Kompass and Leonardo's compass app might be the same if 
I'm changing the mount matrix for the magnetometer). This is why I 
decided to showcase the raw values in my testing. If my testing is 
incorrect, please feel free to let me know.

I think I will leave my testing in the commits itself this time. If the 
mount matrices are correct based on my testing, it will probably be 
helpful in the future in identifying why downstream is slightly broken.


> You haven't done anything technically wrong, but the way you submitted
> the v2 and v3 made them feel a bit like you picked those patches from
> some random place and submitted them to the mailing list without really
> understanding the subject matter.  In other words, it's the contributor's
> job to convince everyone else that the submitted patches are fine to
> become accepted, and the v2 and v3 simply lacked that.

That's fair. I was under the assumption I had to keep the patches mostly 
in its original form.


> I wonder how would some forge prevent "spamming"?  It isn't about the
> possible "spamming", but about the act of submitting different versions,
> which would be present regardless of the way they'd be submitted, and
> the reviewers would need to be aware (i.e. "spammed") of them anyway.

At least with Gitlab & Codeberg, a lot of the notifications can be muted 
(I believe updates to pull requests is one of them) and pipelines can be 
created to ensure that formatting is correct and that the proper sub 
maintainers are notified automagically. In my opinion, b4 just brings 
some of the forge's functionalities into an email based workflow, but 
will have to fight it's own problems such as: 
https://social.kernel.org/notice/AypvdTWyAs5km0Gc3k. I don't mean to 
detract from it; it is very commendable what Konstantin Ryabitsev is doing.

If there are concerns about centralization, there are alternatives like 
Radical. I heard that Codeberg is looking to also decentralize in the 
future as well (Maybe using Radical's protocol? Not sure). If there is a 
call to action from the Linux maintainers about looking into 
decentralized forges, I bet there would be many projects excited to be 
used by the Linux kernel. It will also help get new people excited to be 
involved in the Linux kernel and potentially become kernel maintainers 
in the future

I think I will leave it at that, as I don't want to further derail the 
conversation from the ppp series.


Rudraksha

Re: [PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[Dragan Simic]

Hello Rudraksha,

On Sunday, October 05, 2025 06:55 CEST, Rudraksha Gupta <guptarud@gmail.com> wrote:
> > Thanks for improving the patch descriptions in the v4 of this series.
> > I just went quickly through the v4 and it looks much better.
> >
> > It could be said that the new patch descriptions are now a bit too
> > verbose, in the sense that the test procedures and their results could
> > be summed up a bit better in prose, instead of providing the "raw"
> > inputs and outputs.  However, it's still better to have those, than
> > not to have anything.  Writing good prose is a skill that usually
> > requires learning and practice.
> 
> Awesome! I was hoping that others would comment on the testing I've done 
> (especially for the accelerometer and magnetometer patches) as I can't 
> tell if userspace is wrong or if my testing/conclusion is wrong. Mobile 
> Linux is very early stages at the moment, and I suspect the Pinephone 
> and Pinephone Pro were used as reference devices with Megi's downstream 
> kernel. Wrong mount matrices in the downstream kernel might be affecting 
> userspace. This means that with the corrected mount matrices in this 
> patch series, userspace is slightly broken (eg. since I fixed the 
> accelerometer, the screen in Phosh and KDE Plasma are upside down. I 
> suspect KDE's Kompass and Leonardo's compass app might be the same if 
> I'm changing the mount matrix for the magnetometer). This is why I 
> decided to showcase the raw values in my testing. If my testing is 
> incorrect, please feel free to let me know.
> 
> I think I will leave my testing in the commits itself this time. If the 
> mount matrices are correct based on my testing, it will probably be 
> helpful in the future in identifying why downstream is slightly broken.

I'll prepare and send to the mailing list a couple of patches that
will also adjust the mount-matrix values, so you might want to have
a look at those patch descriptions I'll prepare, as an inspiration
how could such information be presented in prose.

I'll also review your patches, to make sure that the mount-matrix
values are correct, hopefully around the end of this week, or next
week.  I'm having some issues with email, which I must resolve first.
(I'm actually hoping that this message won't come through as HTML,
as a result of those issues).

> > You haven't done anything technically wrong, but the way you submitted
> > the v2 and v3 made them feel a bit like you picked those patches from
> > some random place and submitted them to the mailing list without really
> > understanding the subject matter.  In other words, it's the contributor's
> > job to convince everyone else that the submitted patches are fine to
> > become accepted, and the v2 and v3 simply lacked that.
> 
> That's fair. I was under the assumption I had to keep the patches mostly 
> in its original form.
> 
> > I wonder how would some forge prevent "spamming"?  It isn't about the
> > possible "spamming", but about the act of submitting different versions,
> > which would be present regardless of the way they'd be submitted, and
> > the reviewers would need to be aware (i.e. "spammed") of them anyway.
> 
> At least with Gitlab & Codeberg, a lot of the notifications can be muted 
> (I believe updates to pull requests is one of them) and pipelines can be 
> created to ensure that formatting is correct and that the proper sub 
> maintainers are notified automagically. In my opinion, b4 just brings 
> some of the forge's functionalities into an email based workflow, but 
> will have to fight it's own problems such as: 
> https://social.kernel.org/notice/AypvdTWyAs5km0Gc3k. I don't mean to 
> detract from it; it is very commendable what Konstantin Ryabitsev is doing.

When it comes to submitting patches and their different versions,
reviewers have to be notified about each and every version, which
means that muting the notifications or ignoring some patch versions
simply isn't an option.  Even fully ignoring the patches that one
isn't interested in isn't a great option, despite sounding good,
because leaving out such parts makes one less insightful about
the subsystem they're contributing to.

Of course, the associated level of interest depends on one being
a "drive-by" contributor or being in for the long term, but for
the former different options exist to help with their periodic
contributions, such as the b4 or GitGitGadget.

You're right that the automagic features of forges may help with
setting up the lists of recipients and whatnot, but that's just
offloading of the complexity elsewhere, in hope that the automagic
part will work flawlessly, which is hardly the case with highly
complex projects, such as the Linux kernel. In other words, the
mailing-list based workflow does have its deficiencies, but it
leaves the contributors in full control, without relying on some
automagic things to do everything perfectly instead.

When it comes to formatting and whatnot, I'm sure you know that
there's already scripts/checkpatch.pl.

Re: [PATCH v3 0/5] Upstreaming Pinephone Pro Patches

[Ondřej Jirman]

On Sat, Oct 04, 2025 at 09:55:19PM -0700, Rudraksha Gupta wrote:

> Awesome! I was hoping that others would comment on the testing I've done
> (especially for the accelerometer and magnetometer patches) as I can't tell
> if userspace is wrong or if my testing/conclusion is wrong. Mobile Linux is
> very early stages at the moment, and I suspect the Pinephone and Pinephone
> Pro were used as reference devices with Megi's downstream kernel. Wrong
> mount matrices in the downstream kernel might be affecting userspace. This
> means that with the corrected mount matrices in this patch series, userspace
> is slightly broken (eg. since I fixed the accelerometer, the screen in Phosh
> and KDE Plasma are upside down. I suspect KDE's Kompass and Leonardo's
> compass app might be the same if I'm changing the mount matrix for the
> magnetometer). This is why I decided to showcase the raw values in my
> testing. If my testing is incorrect, please feel free to let me know.
> 

KDE Kompass uses this as an algorithm: 

 https://invent.kde.org/smigaud/kompass/-/blob/master/src/compass.cpp?ref_type=heads

which is largely inadequate and doesn't take mount matrix (in_mount_matrix) into
account at all. So that's not a good reference app. Also it doesn't even
claim to support "af8133j" sensor.

Leonardo's compass app has its own mount matrices, when kernel doesn't contain
one:

https://gitlab.com/lgtrombetta/compass/-/blob/main/src/compass.py?ref_type=heads

which we can also use for comaprison/confusion and is different from what your
patches are trying to upstream. :)

regards,
	o.