Re: [PATCH 1/3] Input: add `SW_BOOT_ALT`

From: Jeff LaBundy <jeff@labundy.com>
To: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Cc: Quentin Schulz <foss+kernel@0leil.net>,
	robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	heiko@sntech.de, dmitry.torokhov@gmail.com,
	klaus.goger@theobroma-systems.com, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org
Subject: Re: [PATCH 1/3] Input: add `SW_BOOT_ALT`
Date: Mon, 26 Sep 2022 20:56:54 -0500	[thread overview]
Message-ID: <YzJYZrw09dXEihnn@nixie71> (raw)
In-Reply-To: <953e4d00-110e-b337-3c6c-af008c843046@theobroma-systems.com>

Hi Quentin,

On Mon, Sep 26, 2022 at 11:37:45AM +0200, Quentin Schulz wrote:
> Hi all,
> 
> On 9/23/22 19:19, Jeff LaBundy wrote:
> [...]
> > > 
> > > I have this switch on the board and I want to expose its state to the user,
> > > if this new event code is not possible/a good idea what would you suggest we
> > > could use?
> > > 
> > > Note that we already support the same switch but in a different way: https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_arch_arm64_boot_dts_rockchip_rk3399-2Dpuma-2Dhaikou.dts-23n167&d=DwIBAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=vObtDja6hUlL_kVvKRILCvaQfklw1gl7TAW7cm5_9H_Yi00zkzGV6-D3yzazR2gU&s=0Xo-7CDmMoriaTNn_hJdMwftLlcY-tgopPcgzXfQtJE&e=
> > > We are just configuring the GPIOs into the GPIO mode with a pull-up, and
> > > then it's up to the user to use gpiod or gpio-sysfs to check the state of
> > > the GPIO used for this switch. I don't like this, very not user-friendly and
> > > was looking for something better :)
> > 
> > Actually, that's exactly what I was going to suggest. What in particular
> > is not user-friendly about it?
> > 
> 
> The implementation we currently have in place for Puma Haikou is just muxing
> the pins in their GPIO function with a pull-up. Nothing else. This means the
> user still needs to know exactly which GPIO number is for which
> signal/event. Not that great. Also does not allow for a consistent user
> "experience" across modules on the same devkit (different GPIOs depending on
> the SoM).
> 
> I had hoped gpio-hog in input mode would expose it to userspace but it does
> not seem to?

No, I don't believe that is the case. That being said, you should be
able to grep /sys/kernel/debug/gpio for the hog node's label and get
the pin state (lo or hi).

> 
> Anything to recommend so that we can export a GPIO line for a specific
> function to usersapce without needing the user to know which GPIO number
> they should look at?

If debugfs won't work for your purposes, another option is to request
the GPIO from a general-purpose platform driver and return one of two
strings via sysfs.

> 
> While I have your attention, I was wondering about the BATTERY event. We
> have a BATLOW button, following the Q7 standard:
> """
> Battery low input. This signal may be driven active low by external
> circuitry to signal that the system battery is low or may be used to
> signal some other external battery management event.
> """
> 
> Oddly vague, but the EV_BATTERY event is not really more precise though (at
> least didn't find more precise information and the introducing commit is a
> bit vague too on the usage). Was just wondering if there was any specific
> usage for this event or if I'm using it correctly here?

Do you mean KEY_BATTERY?

> 
> Cheers,
> Quentin

Kind regards,
Jeff LaBundy

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel