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 <[email protected]> > >> --- > >> 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/[email protected]/ > > Regards > Luca > > > > >> --- > >> Changes in v2: > >> - Add pinctrl for gpio70 > >> - Link to v1: > >> https://lore.kernel.org/r/[email protected] > >> --- > >> arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 21 > >> ++++++++++++++++++++- > >> 1 file changed, 20 insertions(+), 1 deletion(-) > >> >
