arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
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>
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>
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
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
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(-) >>
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
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(-) > >> >
© 2016 - 2026 Red Hat, Inc.