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.
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.
To address an edge case, if the power button was being pressed before
the driver loads, look for if it's ever released. Only after then start
working as usual.
Looking forward to hearing your thoughts.
Arınç
Hi Arınç,
On lun., janv. 30, 2023 at 16:36, Arınç ÜNAL <[email protected]> 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?
>
> 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?
Hope that helps,
Mattijs
>
> To address an edge case, if the power button was being pressed before
> the driver loads, look for if it's ever released. Only after then start
> working as usual.
>
> Looking forward to hearing your thoughts.
> Arınç
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 <[email protected]> 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ç