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
