From: Mattijs Korpershoek <mkorpershoek@baylibre.com>
To: "Arınç ÜNAL" <arinc.unal@arinc9.com>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>
Cc: linux-input@vger.kernel.org,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Frank Wunderlich <frank-w@public-files.de>,
erkin.bozoglu@xeront.com
Subject: Re: mtk-pmic-keys: Ignore power button if pressed before driver loads
Date: Mon, 30 Jan 2023 18:21:04 +0100 [thread overview]
Message-ID: <87r0vcc51b.fsf@baylibre.com> (raw)
In-Reply-To: <883798d8-f7d9-eadc-1343-7d241741ff67@arinc9.com>
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?
>
> 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ç
WARNING: multiple messages have this Message-ID (diff)
From: Mattijs Korpershoek <mkorpershoek@baylibre.com>
To: "Arınç ÜNAL" <arinc.unal@arinc9.com>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
linux-input@vger.kernel.org, erkin.bozoglu@xeront.com,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: mtk-pmic-keys: Ignore power button if pressed before driver loads
Date: Mon, 30 Jan 2023 18:21:04 +0100 [thread overview]
Message-ID: <87r0vcc51b.fsf@baylibre.com> (raw)
In-Reply-To: <883798d8-f7d9-eadc-1343-7d241741ff67@arinc9.com>
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?
>
> 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ç
WARNING: multiple messages have this Message-ID (diff)
From: Mattijs Korpershoek <mkorpershoek@baylibre.com>
To: "Arınç ÜNAL" <arinc.unal@arinc9.com>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>
Cc: linux-input@vger.kernel.org,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Frank Wunderlich <frank-w@public-files.de>,
erkin.bozoglu@xeront.com
Subject: Re: mtk-pmic-keys: Ignore power button if pressed before driver loads
Date: Mon, 30 Jan 2023 18:21:04 +0100 [thread overview]
Message-ID: <87r0vcc51b.fsf@baylibre.com> (raw)
In-Reply-To: <883798d8-f7d9-eadc-1343-7d241741ff67@arinc9.com>
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?
>
> 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ç
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-01-30 17:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-30 13:36 mtk-pmic-keys: Ignore power button if pressed before driver loads Arınç ÜNAL
2023-01-30 13:36 ` Arınç ÜNAL
2023-01-30 13:36 ` Arınç ÜNAL
2023-01-30 17:21 ` Mattijs Korpershoek [this message]
2023-01-30 17:21 ` Mattijs Korpershoek
2023-01-30 17:21 ` Mattijs Korpershoek
2023-02-12 11:29 ` Arınç ÜNAL
2023-02-12 11:29 ` Arınç ÜNAL
2023-02-12 11:29 ` Arınç ÜNAL
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r0vcc51b.fsf@baylibre.com \
--to=mkorpershoek@baylibre.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=arinc.unal@arinc9.com \
--cc=dmitry.torokhov@gmail.com \
--cc=erkin.bozoglu@xeront.com \
--cc=frank-w@public-files.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.