mtk-pmic-keys: Ignore power button if pressed before driver loads

Arınç ÜNAL arinc.unal at arinc9.com
Sun Feb 12 03:29:10 PST 2023


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 at 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ç



More information about the linux-arm-kernel mailing list