Messages in this thread | | | Date | Sun, 12 Feb 2023 14:29:10 +0300 | Subject | Re: mtk-pmic-keys: Ignore power button if pressed before driver loads | From | Arınç ÜNAL <> |
| |
Hey Mattijs,
Sorry for the late response.
On 30.01.2023 20:21, Mattijs Korpershoek wrote: > Hi Arınç, > > On lun., janv. 30, 2023 at 16:36, Arınç ÜNAL <arinc.unal@arinc9.com> wrote: > >> Hi all, >> >> The power button on my Bananapi BPI-R2 (MT7623NI SoC, mt6323-keys) is >> shorted, so the device automatically boots when there's power. This >> causes the device to reboot when KEYBOARD_MTK_PMIC is loaded because the >> driver sees the power button being pressed. > > What evidence do you have that there is actually a "press" event being > received by userspace? Did you tested this with evtest or something > similar? > > If a "power button press" is generated, than I imagine that a userspace > process must receive it and halt the system, right? > > The PMIC also has a feature to shutdown in case detect a long key-press, > which is controlled by the mediatek,long-press-mode device-tree > property. > So is it the pmic that shutdown your board (probably no evidence in > logs, just a "power cut" behaviour) or is it userspace?
Nothing appears on the kernel log and evtest doesn't detect anything. The input device appears only after loading mtk-pmic-keys.ko so I have to run evtest after the driver is loaded. After that, I see nothing noticeable running evtest:
# evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: mtk_cir /dev/input/event1: mtk-pmic-keys Select the device event number [0-1]: 1 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x1 Input device name: "mtk-pmic-keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 114 (KEY_VOLUMEDOWN) Event code 116 (KEY_POWER) Properties: Testing ... (interrupt to exit) (Device reboots)
I've set this on the devicetree of Bananapi BPI-R2:
&mt6323keys { mediatek,long-press-mode = <0>; };
This prevents the device from rebooting after the driver is loaded so I believe this proves that it's the driver that tries to shutdown the board.
> >> >> I was wondering if it's possible to change the driver in a way that >> doesn't break in this situation. Maybe don't do anything if the first >> state of the the power button the driver sees is being pressed, and if >> the state doesn't change. > > If the driver is an issue, can't we blacklist it from being probed > instead? or do you want to use the home key feature that that same > driver provides?
Since it's a special case, specific to my own board, I just disabled the key.
&mt6323keys { power { status = "disabled"; }; };
I also see there's no home key on this board so I may submit a patch to disable the home button for this device.
Thanks for your help!
Cheers. Arınç
| |