[PATCH v2] arm64: dts: qcom: milos-fairphone-fp6: Add Hall Effect sensor

[PATCH v2] arm64: dts: qcom: milos-fairphone-fp6: Add Hall Effect sensor

[Luca Weiss]

Add a node for the Hall Effect sensor, used to detect whether the Flip
Cover is closed or not.

The sensor is powered through vreg_l10b, so let's put a
regulator-always-on on that to make sure the sensor gets power.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
As pointed out in v1, this would preferably go via some vdd-supply to
gpio-keys, but this support does not exist yet.
---
Changes in v2:
- Add pinctrl for gpio70
- Link to v1: https://lore.kernel.org/r/20260116-fp6-hall-sensor-v1-1-69275c6bd809@fairphone.com
---
 arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
index 7629ceddde2a..bba327cc7a38 100644
--- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
+++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
@@ -29,9 +29,19 @@ aliases {
 	gpio-keys {
 		compatible = "gpio-keys";
 
-		pinctrl-0 = <&volume_up_default>;
+		pinctrl-0 = <&volume_up_default>, <&hall_sensor_default>;
 		pinctrl-names = "default";
 
+		/* Powered by the always-on vreg_l10b */
+		event-hall-sensor {
+			label = "Hall Effect Sensor";
+			gpios = <&tlmm 70 GPIO_ACTIVE_LOW>;
+			linux,input-type = <EV_SW>;
+			linux,code = <SW_LID>;
+			linux,can-disable;
+			wakeup-source;
+		};
+
 		key-volume-up {
 			label = "Volume Up";
 			gpios = <&pm7550_gpios 6 GPIO_ACTIVE_LOW>;
@@ -316,6 +326,8 @@ vreg_l10b: ldo10 {
 			regulator-min-microvolt = <1800000>;
 			regulator-max-microvolt = <1800000>;
 			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			/* Hall sensor VDD */
+			regulator-always-on;
 		};
 
 		vreg_l11b: ldo11 {
@@ -807,6 +819,13 @@ sdc2_card_det_n: sdc2-card-det-state {
 		bias-pull-up;
 	};
 
+	hall_sensor_default: hall-sensor-default-state {
+		pins = "gpio70";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
 	pm8008_int_default: pm8008-int-default-state {
 		pins = "gpio125";
 		function = "gpio";

---
base-commit: 3daf23347bb5f4a375d0101ed29c97ce1a99721b
change-id: 20260116-fp6-hall-sensor-1049f2f872ac

Best regards,
-- 
Luca Weiss <luca.weiss@fairphone.com>

Re: [PATCH v2] arm64: dts: qcom: milos-fairphone-fp6: Add Hall Effect sensor

[Dmitry Baryshkov]

On Fri, Feb 13, 2026 at 03:21:06PM +0100, Luca Weiss wrote:
> Add a node for the Hall Effect sensor, used to detect whether the Flip
> Cover is closed or not.
> 
> The sensor is powered through vreg_l10b, so let's put a
> regulator-always-on on that to make sure the sensor gets power.
> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> As pointed out in v1, this would preferably go via some vdd-supply to
> gpio-keys, but this support does not exist yet.

This usually means that it can be implemented by the submitter, sorry...

> ---
> Changes in v2:
> - Add pinctrl for gpio70
> - Link to v1: https://lore.kernel.org/r/20260116-fp6-hall-sensor-v1-1-69275c6bd809@fairphone.com
> ---
>  arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 21 ++++++++++++++++++++-
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 

-- 
With best wishes
Dmitry

Re: [PATCH v2] arm64: dts: qcom: milos-fairphone-fp6: Add Hall Effect sensor

[Luca Weiss]

On Fri Feb 13, 2026 at 3:33 PM CET, Dmitry Baryshkov wrote:
> On Fri, Feb 13, 2026 at 03:21:06PM +0100, Luca Weiss wrote:
>> Add a node for the Hall Effect sensor, used to detect whether the Flip
>> Cover is closed or not.
>> 
>> The sensor is powered through vreg_l10b, so let's put a
>> regulator-always-on on that to make sure the sensor gets power.
>> 
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> As pointed out in v1, this would preferably go via some vdd-supply to
>> gpio-keys, but this support does not exist yet.
>
> This usually means that it can be implemented by the submitter, sorry...

Honestly right now my motivation to (re-)submit Milos patches is
dropping. Every patch series I send (cci, ufs, wifi, bluetooth, hall
effect) is opening a new hole for yak shaving and the ones that don't
are taking forever to land, leading to me not wanting to send more due
to merge conflicts between the patches.

For trivial things like this, shall I hide/ignore that there's a VDD for
the hall sensor? In practice the vdd will be on 99% of the time anyways
due to it being used for other purposes.

I do get the desire to have proper hardware description, but requiring
submitters to yak shave their way through various subsystems of the
kernel is a bit much.

I've just recently yak-shaved my way through a limitation of the gdsc
driver[0] leading to some issues I could've ignored (because CCI worked
when the display was on), but even that thread is currently stuck on
someone explaining some intricacies of how Qualcomm SoCs work
internally. Even though I have access to quite some Qualcomm docs about
this SoC, I'm fairly sure there's zero docs explaining any of that what
was asked there because it's $secret_sauce.

[0] https://lore.kernel.org/linux-arm-msm/20260116-milos-camcc-icc-v1-0-400b7fcd156a@fairphone.com/

Regards
Luca

>
>> ---
>> Changes in v2:
>> - Add pinctrl for gpio70
>> - Link to v1: https://lore.kernel.org/r/20260116-fp6-hall-sensor-v1-1-69275c6bd809@fairphone.com
>> ---
>>  arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 21 ++++++++++++++++++++-
>>  1 file changed, 20 insertions(+), 1 deletion(-)
>> 

Re: [PATCH v2] arm64: dts: qcom: milos-fairphone-fp6: Add Hall Effect sensor

[Bjorn Andersson]

On Fri, Feb 13, 2026 at 03:40:44PM +0100, Luca Weiss wrote:
> On Fri Feb 13, 2026 at 3:33 PM CET, Dmitry Baryshkov wrote:
> > On Fri, Feb 13, 2026 at 03:21:06PM +0100, Luca Weiss wrote:
> >> Add a node for the Hall Effect sensor, used to detect whether the Flip
> >> Cover is closed or not.
> >> 
> >> The sensor is powered through vreg_l10b, so let's put a
> >> regulator-always-on on that to make sure the sensor gets power.
> >> 
> >> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> >> ---
> >> As pointed out in v1, this would preferably go via some vdd-supply to
> >> gpio-keys, but this support does not exist yet.
> >
> > This usually means that it can be implemented by the submitter, sorry...
> 
> Honestly right now my motivation to (re-)submit Milos patches is
> dropping. Every patch series I send (cci, ufs, wifi, bluetooth, hall
> effect) is opening a new hole for yak shaving and the ones that don't
> are taking forever to land, leading to me not wanting to send more due
> to merge conflicts between the patches.
> 

Understandably so.

> For trivial things like this, shall I hide/ignore that there's a VDD for
> the hall sensor? In practice the vdd will be on 99% of the time anyways
> due to it being used for other purposes.
> 

You have marked the pin as a wakeup-source, so what is the 1% case?
Seems to me that it might be always-on.

> I do get the desire to have proper hardware description, but requiring
> submitters to yak shave their way through various subsystems of the
> kernel is a bit much.
> 

There's some things where we can not approximate the system and postpone
the proper description, because we know that we will paint ourselves
into a corner.

This is not one of them.

There's nothing preventing us from merging this, realize next week that
the 1% is worth investing in, implement the necessary support and update
the dts accordingly.

> I've just recently yak-shaved my way through a limitation of the gdsc
> driver[0] leading to some issues I could've ignored (because CCI worked
> when the display was on), but even that thread is currently stuck on
> someone explaining some intricacies of how Qualcomm SoCs work
> internally. Even though I have access to quite some Qualcomm docs about
> this SoC, I'm fairly sure there's zero docs explaining any of that what
> was asked there because it's $secret_sauce.
> 

This looks like a case where the yak herder needs to step in. Do we have
any reason to believe that Milos is the only target with this issue?

Regards,
Bjorn

> [0] https://lore.kernel.org/linux-arm-msm/20260116-milos-camcc-icc-v1-0-400b7fcd156a@fairphone.com/
> 
> Regards
> Luca
> 
> >
> >> ---
> >> Changes in v2:
> >> - Add pinctrl for gpio70
> >> - Link to v1: https://lore.kernel.org/r/20260116-fp6-hall-sensor-v1-1-69275c6bd809@fairphone.com
> >> ---
> >>  arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 21 ++++++++++++++++++++-
> >>  1 file changed, 20 insertions(+), 1 deletion(-)
> >> 
> 

Re: [PATCH v2] arm64: dts: qcom: milos-fairphone-fp6: Add Hall Effect sensor

[Dmitry Baryshkov]

On Fri, Feb 13, 2026 at 03:40:44PM +0100, Luca Weiss wrote:
> On Fri Feb 13, 2026 at 3:33 PM CET, Dmitry Baryshkov wrote:
> > On Fri, Feb 13, 2026 at 03:21:06PM +0100, Luca Weiss wrote:
> >> Add a node for the Hall Effect sensor, used to detect whether the Flip
> >> Cover is closed or not.
> >> 
> >> The sensor is powered through vreg_l10b, so let's put a
> >> regulator-always-on on that to make sure the sensor gets power.
> >> 
> >> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> >> ---
> >> As pointed out in v1, this would preferably go via some vdd-supply to
> >> gpio-keys, but this support does not exist yet.
> >
> > This usually means that it can be implemented by the submitter, sorry...
> 
> Honestly right now my motivation to (re-)submit Milos patches is
> dropping. Every patch series I send (cci, ufs, wifi, bluetooth, hall
> effect) is opening a new hole for yak shaving and the ones that don't
> are taking forever to land, leading to me not wanting to send more due
> to merge conflicts between the patches.

It's really sad to read it (although shaved yaks might look funny). I
would not comment CCI side, I haven't looked into those patches in
details.

For the other items:

- UFS:
  * PHY patches are accepted
  * UFSHC bindings seem to be stalled, (although they are reviewed). My
    sugestion would be to resend after the rc1 and if doesn't get picked
    up, ping RobH, he picked up enough patches there.
  * DTB bits depend on UFSHC bindings

- WiFi:
  It's really an interesting question. We should probably merge it,
  because we need to support the ABI for the Kodiak anyway. I hope Jeff
  or one of his colleagues can comment.

- BT:
  I see a correct question regarding WCN6755 -> WCN6750 fallback.

- Hall effect
  Bjorn wrote a nice email about it.

> 
> For trivial things like this, shall I hide/ignore that there's a VDD for
> the hall sensor? In practice the vdd will be on 99% of the time anyways
> due to it being used for other purposes.

It's a very interesting question. On one hand you are correct for a
particular device. On the other hand, one of my colleagues is currently
trying to fight a bug which also might be caused by "let's assume it's
99% of time true". And he hit the 1% where it is not.

> I do get the desire to have proper hardware description, but requiring
> submitters to yak shave their way through various subsystems of the
> kernel is a bit much.

I know this feeling. My APQ8064 cpufreq series died because I could not
fight my way through the L2 cache devices (which is only necessary to
describe a bit of the table). Other series die because of the lack of
reviews. Or because of other in-kernel (and out-of-kernel) obstacles,
reviews, bikeshedding and similar issues.

> I've just recently yak-shaved my way through a limitation of the gdsc
> driver[0] leading to some issues I could've ignored (because CCI worked
> when the display was on), but even that thread is currently stuck on
> someone explaining some intricacies of how Qualcomm SoCs work
> internally. Even though I have access to quite some Qualcomm docs about
> this SoC, I'm fairly sure there's zero docs explaining any of that what
> was asked there because it's $secret_sauce.
> 
> [0] https://lore.kernel.org/linux-arm-msm/20260116-milos-camcc-icc-v1-0-400b7fcd156a@fairphone.com/
> 
> Regards
> Luca
> 
> >
> >> ---
> >> Changes in v2:
> >> - Add pinctrl for gpio70
> >> - Link to v1: https://lore.kernel.org/r/20260116-fp6-hall-sensor-v1-1-69275c6bd809@fairphone.com
> >> ---
> >>  arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 21 ++++++++++++++++++++-
> >>  1 file changed, 20 insertions(+), 1 deletion(-)
> >> 
> 

-- 
With best wishes
Dmitry

Re: [PATCH v2] arm64: dts: qcom: milos-fairphone-fp6: Add Hall Effect sensor

[Konrad Dybcio]

On 2/13/26 3:21 PM, Luca Weiss wrote:
> Add a node for the Hall Effect sensor, used to detect whether the Flip
> Cover is closed or not.
> 
> The sensor is powered through vreg_l10b, so let's put a
> regulator-always-on on that to make sure the sensor gets power.
> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH v2] arm64: dts: qcom: milos-fairphone-fp6: Add Hall Effect sensor

[Bjorn Andersson]

On Fri, 13 Feb 2026 15:21:06 +0100, Luca Weiss wrote:
> Add a node for the Hall Effect sensor, used to detect whether the Flip
> Cover is closed or not.
> 
> The sensor is powered through vreg_l10b, so let's put a
> regulator-always-on on that to make sure the sensor gets power.
> 
> 
> [...]

Applied, thanks!

[1/1] arm64: dts: qcom: milos-fairphone-fp6: Add Hall Effect sensor
      commit: e46755582c062bbda37ec81a68511e7a539b7b29

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>