linux-kernel - Re: [PATCH 1/3] Input: add `SW_BOOT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YzJYZrw09dXEihnn@nixie71>
Date:   Mon, 26 Sep 2022 20:56:54 -0500
From:   Jeff LaBundy <jeff@...undy.com>
To:     Quentin Schulz <quentin.schulz@...obroma-systems.com>
Cc:     Quentin Schulz <foss+kernel@...il.net>, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, heiko@...ech.de,
        dmitry.torokhov@...il.com, klaus.goger@...obroma-systems.com,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-input@...r.kernel.org
Subject: Re: [PATCH 1/3] Input: add `SW_BOOT_ALT`

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