* [PATCH 0/2] Input: tests - miscellaneous fixes
From: Geert Uytterhoeven @ 2023-05-02 10:17 UTC (permalink / raw)
To: Dmitry Torokhov, Javier Martinez Canillas, Brendan Higgins,
David Gow
Cc: linux-input, linux-kselftest, kunit-dev, linux-kernel,
Geert Uytterhoeven
Hi all,
This patch series fixes a crash in the new input selftest, and makes the
test available when the KUnit framework is modular.
Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W)
and ARAnyM):
KTAP version 1
# Subtest: input_core
1..3
input: Test input device as /devices/virtual/input/input1
ok 1 input_test_polling
input: Test input device as /devices/virtual/input/input2
ok 2 input_test_timestamp
input: Test input device as /devices/virtual/input/input3
# input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99
Expected input_match_device_id(input_dev, &id) to be true, but is false
not ok 3 input_test_match_device_id
# input_core: pass:2 fail:1 skip:0 total:3
# Totals: pass:2 fail:1 skip:0 total:3
not ok 1 input_core
Thanks!
Geert Uytterhoeven (2):
Input: tests - fix use-after-free and refcount underflow in
input_test_exit()
Input: tests - modular KUnit tests should not depend on KUNIT=y
drivers/input/Kconfig | 2 +-
drivers/input/tests/input_test.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.34.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 2/2] Input: tests - modular KUnit tests should not depend on KUNIT=y
From: Geert Uytterhoeven @ 2023-05-02 10:17 UTC (permalink / raw)
To: Dmitry Torokhov, Javier Martinez Canillas, Brendan Higgins,
David Gow
Cc: linux-input, linux-kselftest, kunit-dev, linux-kernel,
Geert Uytterhoeven
In-Reply-To: <cover.1683022164.git.geert+renesas@glider.be>
While KUnit tests that cannot be built as a loadable module must depend
on "KUNIT=y", this is not true for modular tests, where it adds an
unnecessary limitation.
Fix this by relaxing the dependency to "KUNIT".
Fixes: fdefcbdd6f361841 ("Input: Add KUnit tests for some of the input core helper functions")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/input/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index 735f90b74ee5ad44..3bdbd34314b3495a 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -168,7 +168,7 @@ config INPUT_EVBUG
config INPUT_KUNIT_TEST
tristate "KUnit tests for Input" if !KUNIT_ALL_TESTS
- depends on INPUT && KUNIT=y
+ depends on INPUT && KUNIT
default KUNIT_ALL_TESTS
help
Say Y here if you want to build the KUnit tests for the input
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] Input: tests - fix use-after-free and refcount underflow in input_test_exit()
From: Geert Uytterhoeven @ 2023-05-02 10:17 UTC (permalink / raw)
To: Dmitry Torokhov, Javier Martinez Canillas, Brendan Higgins,
David Gow
Cc: linux-input, linux-kselftest, kunit-dev, linux-kernel,
Geert Uytterhoeven
In-Reply-To: <cover.1683022164.git.geert+renesas@glider.be>
With CONFIG_DEBUG_SLAB=y:
# Subtest: input_core
1..3
input: Test input device as /devices/virtual/input/input1
8<--- cut here ---
Unable to handle kernel paging request at virtual address 6b6b6dd7 when read
...
__lock_acquire from lock_acquire+0x26c/0x300
lock_acquire from _raw_spin_lock_irqsave+0x50/0x64
_raw_spin_lock_irqsave from devres_remove+0x20/0x7c
devres_remove from devres_destroy+0x8/0x24
devres_destroy from input_free_device+0x2c/0x60
input_free_device from kunit_try_run_case+0x70/0x94 [kunit]
Without CONFIG_DEBUG_SLAB=y:
KTAP version 1
# Subtest: input_core
1..3
input: Test input device as /devices/virtual/input/input1
------------[ cut here ]------------
WARNING: CPU: 0 PID: 694 at lib/refcount.c:28 refcount_warn_saturate+0x54/0x100
refcount_t: underflow; use-after-free.
...
Call Trace: [<0037cad4>] dump_stack+0xc/0x10
[<00377614>] __warn+0x7e/0xb4
[<0037768c>] warn_slowpath_fmt+0x42/0x62
[<001eee1c>] refcount_warn_saturate+0x54/0x100
[<000b1d34>] kfree_const+0x0/0x20
[<0036290a>] __kobject_del+0x0/0x6e
[<001eee1c>] refcount_warn_saturate+0x54/0x100
[<00362a1a>] kobject_put+0xa2/0xb6
[<11965770>] kunit_generic_run_threadfn_adapter+0x0/0x1c [kunit]
As per the comments for input_allocate_device() and
input_register_device(), input_free_device() must be called only to free
devices that have not been registered. input_unregister_device()
already calls input_put_device(), thus leading to a use-after-free.
Moreover, the kunit_suite.exit() method is called after every test case,
even on failures. As the test itself already does cleanups in its
failure paths, this may lead to a second use-after-free.
Fix the first issue by dropping the call to input_allocate_device() from
input_test_exit().
Fix the second issue by making the cleanup code conditional on a
successful test.
Fixes: fdefcbdd6f361841 ("Input: Add KUnit tests for some of the input core helper functions")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/input/tests/input_test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/tests/input_test.c b/drivers/input/tests/input_test.c
index e5a6c1ad2167c103..8b8ac3412a70d3b4 100644
--- a/drivers/input/tests/input_test.c
+++ b/drivers/input/tests/input_test.c
@@ -43,8 +43,8 @@ static void input_test_exit(struct kunit *test)
{
struct input_dev *input_dev = test->priv;
- input_unregister_device(input_dev);
- input_free_device(input_dev);
+ if (input_dev)
+ input_unregister_device(input_dev);
}
static void input_test_poll(struct input_dev *input) { }
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 5/5] ARM: dts: qcom: apq8026-huawei-sturgeon: Add vibrator
From: Konrad Dybcio @ 2023-05-02 10:21 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel,
Dmitry Torokhov, Dan Murphy, Andy Gross, Bjorn Andersson,
Rob Herring, Krzysztof Kozlowski, Raffaele Tranquillini,
Yassine Oudjana
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20230430-drv260x-improvements-v1-5-1fb28b4cc698@z3ntu.xyz>
On 30.04.2023 20:20, Luca Weiss wrote:
> The watch has a DRV2605 for haptics. Add a node for it based on the
> values found in the downstream board file.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
> arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts | 28 ++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts b/arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts
> index d64096028ab1..eb73b992a696 100644
> --- a/arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts
> +++ b/arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts
> @@ -7,6 +7,7 @@
>
> #include "qcom-msm8226.dtsi"
> #include "qcom-pm8226.dtsi"
> +#include <dt-bindings/input/ti-drv260x.h>
>
> /delete-node/ &adsp_region;
>
> @@ -68,6 +69,26 @@ &adsp {
> status = "okay";
> };
>
> +&blsp1_i2c2 {
> + clock-frequency = <384000>;
> +
> + status = "okay";
> +
> + vibrator@5a {
> + compatible = "ti,drv2605";
> + reg = <0x5a>;
> + enable-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> +
> + mode = <DRV260X_ERM_MODE>;
> + library-sel = <DRV260X_ERM_LIB_D>;
> + vib-rated-mv = <2765>;
> + vib-overdrive-mv = <3525>;
> +
> + pinctrl-0 = <&vibrator_default_state>;
> + pinctrl-names = "default";
> + };
> +};
> +
> &blsp1_i2c5 {
> clock-frequency = <384000>;
>
> @@ -347,6 +368,13 @@ reset-pins {
> };
> };
>
> + vibrator_default_state: vibrator-default-state {
> + pins = "gpio59", "gpio60";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> wlan_hostwake_default_state: wlan-hostwake-default-state {
> pins = "gpio66";
> function = "gpio";
>
^ permalink raw reply
* Re: [PATCH] Input: xpad - fix GPF in xpad_probe
From: Dan Carpenter @ 2023-05-02 10:34 UTC (permalink / raw)
To: Dongliang Mu, smatch
Cc: Dan Carpenter, Vicki Pfau, kernel-janitors, Dmitry Torokhov,
Pavel Rojtberg, Nate Yocom, Mattijs Korpershoek, John Butler,
Matthias Benkmann, Christopher Crockett, Santosh De Massari,
hust-os-kernel-patches, syzbot+a3f758b8d8cb7e49afec,
Pierre-Loup A. Griffais, linux-input, linux-kernel
In-Reply-To: <f71f3012-916c-5271-b908-feeee5a85a46@hust.edu.cn>
On Sun, Apr 23, 2023 at 10:33:29AM +0800, Dongliang Mu wrote:
> BTW, do you have any plans to improve the code readability, directory
> orgranization, documentation etc. of Smatch? It's hard even for senior
> students to start with.
I have created some documentation. Read the following blogs in order:
https://staticthinking.wordpress.com/2023/04/24/smatch-data-types/
https://staticthinking.wordpress.com/2023/04/25/first-smatch-check/
https://staticthinking.wordpress.com/2023/04/25/merging-states/
https://staticthinking.wordpress.com/2023/05/02/the-cross-function-db/
https://staticthinking.wordpress.com/2023/05/02/the-param-key-api/
https://staticthinking.wordpress.com/2023/05/02/smatch-hooks-and-modules/
https://staticthinking.wordpress.com/2023/05/02/debugging-smatch-checks/
Email the smatch@vger.kernel.org mailing list with any questions.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 3/4] Input: pwm-vibra - add support for enable GPIO
From: Konrad Dybcio @ 2023-05-02 10:39 UTC (permalink / raw)
To: Luca Weiss, Brian Masney
Cc: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Sebastian Reichel, Andy Gross,
Bjorn Andersson, Brian Masney, linux-input, devicetree,
linux-kernel, linux-arm-msm
In-Reply-To: <8250064.NyiUUSuA9g@z3ntu.xyz>
On 28.04.2023 18:06, Luca Weiss wrote:
> On Freitag, 28. April 2023 01:29:27 CEST Brian Masney wrote:
>> On Thu, Apr 27, 2023 at 10:34:28PM +0200, Luca Weiss wrote:
>>> Some pwm vibrators have a dedicated enable GPIO that needs to be set
>>> high so that the vibrator works. Add support for that optionally.
>>>
>>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
>>
>> Hi Luca,
>>
>> Thank you for picking up this work!
>>
>>> + vibrator->enable_gpio = devm_gpiod_get_optional(&pdev->dev,
> "enable",
>>> +
> GPIOD_OUT_LOW);
>>> + err = PTR_ERR_OR_ZERO(vibrator->enable_gpio);
>>> + if (err) {
>>> + if (err != -EPROBE_DEFER)
>>> + dev_err(&pdev->dev, "Failed to request enable
> gpio: %d\n",
>>> + err);
>>> + return err;
>>> + }
>>> +
>>
Looks like your email client messes with the replies.. perhaps it tries
to round them to n characters forcefully?
Konrad
>> Take a look at dev_err_probe() to remove the -EPROBE_DEFER check.
>
> The input subsystem doesn't like dev_err_probe for some reason, you should
> quickly find examples of that being rejected on the mailing list (or see
> "git grep dev_err_probe drivers/input/")
>
>>
>> With that fixed:
>>
>> Reviewed-by: Brian Masney <bmasney@redhat.com>
>
> Thanks for the reviews!
>
>
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: qcom: msm8974-hammerhead: Add vibrator
From: Konrad Dybcio @ 2023-05-02 10:40 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Sebastian Reichel, Andy Gross, Bjorn Andersson, Brian Masney
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20230427-hammerhead-vibra-v1-4-e87eeb94da51@z3ntu.xyz>
On 27.04.2023 22:34, Luca Weiss wrote:
> The Nexus 5 has a vibrator connected to the clock output of GP1_CLK
> which we can use with the clk-pwm driver, then we can use that pwm with
> pwm-vibrator to get haptics functionality.
>
> This patch is based on Brian Masney's previous patch with clk-vibrator.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
> .../dts/qcom-msm8974-lge-nexus5-hammerhead.dts | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> index ab35f2d644c0..fea8a6be9021 100644
> --- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> +++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> @@ -41,6 +41,25 @@ key-volume-down {
> };
> };
>
> + clk_pwm: pwm {
> + compatible = "clk-pwm";
> + clocks = <&mmcc CAMSS_GP1_CLK>;
Are you sure it's <&mmcc CAMSS_GP1_CLK> and not <&gcc GCC_GP1_CLK>?
Konrad
> +
> + pinctrl-0 = <&vibrator_pin>;
> + pinctrl-names = "default";
> +
> + #pwm-cells = <2>;
> + };
> +
> + vibrator {
> + compatible = "pwm-vibrator";
> + pwms = <&clk_pwm 0 100000>;
> + pwm-names = "enable";
> +
> + vcc-supply = <&pm8941_l19>;
> + enable-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> + };
> +
> vreg_wlan: wlan-regulator {
> compatible = "regulator-fixed";
>
> @@ -637,6 +656,22 @@ shutdown-pins {
> function = "gpio";
> };
> };
> +
> + vibrator_pin: vibrator-state {
> + core-pins {
> + pins = "gpio27";
> + function = "gp1_clk";
> + drive-strength = <6>;
> + bias-disable;
> + };
> +
> + enable-pins {
> + pins = "gpio60";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> + };
> };
>
> &usb {
>
^ permalink raw reply
* Re: [PATCH 2/2] Input: tests - modular KUnit tests should not depend on KUNIT=y
From: Javier Martinez Canillas @ 2023-05-02 11:19 UTC (permalink / raw)
To: Geert Uytterhoeven, Dmitry Torokhov, Brendan Higgins, David Gow
Cc: linux-input, linux-kselftest, kunit-dev, linux-kernel,
Geert Uytterhoeven
In-Reply-To: <483c4f520e4acc6357ebba3e605977b4c56374df.1683022164.git.geert+renesas@glider.be>
Hello Geert,
I've only been Cc'ed in patch #2.
Geert Uytterhoeven <geert+renesas@glider.be> writes:
> While KUnit tests that cannot be built as a loadable module must depend
> on "KUNIT=y", this is not true for modular tests, where it adds an
> unnecessary limitation.
>
> Fix this by relaxing the dependency to "KUNIT".
>
> Fixes: fdefcbdd6f361841 ("Input: Add KUnit tests for some of the input core helper functions")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH 2/2] Input: tests - modular KUnit tests should not depend on KUNIT=y
From: Geert Uytterhoeven @ 2023-05-02 11:22 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Dmitry Torokhov, Brendan Higgins, David Gow, linux-input,
linux-kselftest, kunit-dev, linux-kernel
In-Reply-To: <87ildbx9or.fsf@minerva.mail-host-address-is-not-set>
Hi Javier,
On Tue, May 2, 2023 at 1:19 PM Javier Martinez Canillas
<javierm@redhat.com> wrote:
> I've only been Cc'ed in patch #2.
Not really, you're in the To-header on the full series?
https://lore.kernel.org/all/cover.1683022164.git.geert+renesas@glider.be
> Geert Uytterhoeven <geert+renesas@glider.be> writes:
> > While KUnit tests that cannot be built as a loadable module must depend
> > on "KUNIT=y", this is not true for modular tests, where it adds an
> > unnecessary limitation.
> >
> > Fix this by relaxing the dependency to "KUNIT".
> >
> > Fixes: fdefcbdd6f361841 ("Input: Add KUnit tests for some of the input core helper functions")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/2] Input: tests - modular KUnit tests should not depend on KUNIT=y
From: Javier Martinez Canillas @ 2023-05-02 11:34 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Dmitry Torokhov, Brendan Higgins, David Gow, linux-input,
linux-kselftest, kunit-dev, linux-kernel
In-Reply-To: <CAMuHMdWA7R7NrS-T8x4qA3tn59zmZS8w20f1UyTw-R53iryeTw@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> Hi Javier,
>
> On Tue, May 2, 2023 at 1:19 PM Javier Martinez Canillas
> <javierm@redhat.com> wrote:
>> I've only been Cc'ed in patch #2.
>
> Not really, you're in the To-header on the full series?
> https://lore.kernel.org/all/cover.1683022164.git.geert+renesas@glider.be
>
Strange... I only got patch #2, neither patch #1 nor the cover letter.
For patch #1 as well:
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Sorry for missing that bug and thanks a lot for fixing it!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS 529de2f1ca3f0898c0d905b7d355a43dce1de7dc
From: kernel test robot @ 2023-05-02 13:50 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 529de2f1ca3f0898c0d905b7d355a43dce1de7dc Input: cyttsp5 - fix array length
elapsed time: 724m
configs tested: 138
configs skipped: 9
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha defconfig gcc
alpha randconfig-r022-20230501 gcc
alpha randconfig-r036-20230501 gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-r004-20230501 gcc
arc randconfig-r012-20230430 gcc
arc randconfig-r016-20230502 gcc
arc randconfig-r025-20230430 gcc
arc randconfig-r043-20230430 gcc
arc randconfig-r043-20230501 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm randconfig-r022-20230430 gcc
arm randconfig-r046-20230430 gcc
arm randconfig-r046-20230501 gcc
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r005-20230430 gcc
arm64 randconfig-r013-20230502 gcc
csky defconfig gcc
csky randconfig-r003-20230501 gcc
csky randconfig-r012-20230502 gcc
csky randconfig-r021-20230430 gcc
hexagon randconfig-r031-20230501 clang
hexagon randconfig-r041-20230430 clang
hexagon randconfig-r041-20230501 clang
hexagon randconfig-r045-20230430 clang
hexagon randconfig-r045-20230501 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230501 gcc
i386 randconfig-a002-20230501 gcc
i386 randconfig-a003-20230501 gcc
i386 randconfig-a004-20230501 gcc
i386 randconfig-a005-20230501 gcc
i386 randconfig-a006-20230501 gcc
i386 randconfig-a011-20230501 clang
i386 randconfig-a012-20230501 clang
i386 randconfig-a013-20230501 clang
i386 randconfig-a014-20230501 clang
i386 randconfig-a015-20230501 clang
i386 randconfig-a016-20230501 clang
i386 randconfig-r025-20230501 clang
i386 randconfig-r026-20230501 clang
ia64 allmodconfig gcc
ia64 defconfig gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch buildonly-randconfig-r004-20230501 gcc
loongarch defconfig gcc
loongarch randconfig-r023-20230501 gcc
loongarch randconfig-r026-20230430 gcc
loongarch randconfig-r031-20230430 gcc
m68k allmodconfig gcc
m68k defconfig gcc
m68k randconfig-r001-20230501 gcc
m68k randconfig-r034-20230430 gcc
microblaze buildonly-randconfig-r005-20230430 gcc
microblaze randconfig-r013-20230430 gcc
microblaze randconfig-r016-20230430 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips buildonly-randconfig-r005-20230501 clang
mips randconfig-r006-20230501 clang
mips randconfig-r014-20230502 clang
nios2 buildonly-randconfig-r002-20230501 gcc
nios2 buildonly-randconfig-r004-20230430 gcc
nios2 defconfig gcc
nios2 randconfig-r015-20230501 gcc
nios2 randconfig-r032-20230501 gcc
openrisc buildonly-randconfig-r006-20230430 gcc
openrisc randconfig-r015-20230502 gcc
openrisc randconfig-r035-20230430 gcc
openrisc randconfig-r036-20230430 gcc
parisc defconfig gcc
parisc randconfig-r003-20230430 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc randconfig-r033-20230501 gcc
powerpc randconfig-r035-20230501 gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv defconfig gcc
riscv randconfig-r002-20230430 gcc
riscv randconfig-r004-20230430 gcc
riscv randconfig-r042-20230430 clang
riscv randconfig-r042-20230501 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 buildonly-randconfig-r003-20230501 clang
s390 defconfig gcc
s390 randconfig-r032-20230430 gcc
s390 randconfig-r044-20230430 clang
s390 randconfig-r044-20230501 clang
sh allmodconfig gcc
sh randconfig-r011-20230502 gcc
sh randconfig-r021-20230501 gcc
sh randconfig-r024-20230430 gcc
sparc defconfig gcc
sparc64 randconfig-r001-20230430 gcc
sparc64 randconfig-r002-20230501 gcc
sparc64 randconfig-r013-20230501 gcc
sparc64 randconfig-r023-20230430 gcc
sparc64 randconfig-r033-20230430 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230501 gcc
x86_64 randconfig-a002-20230501 gcc
x86_64 randconfig-a003-20230501 gcc
x86_64 randconfig-a004-20230501 gcc
x86_64 randconfig-a005-20230501 gcc
x86_64 randconfig-a006-20230501 gcc
x86_64 randconfig-a011-20230501 clang
x86_64 randconfig-a012-20230501 clang
x86_64 randconfig-a013-20230501 clang
x86_64 randconfig-a014-20230501 clang
x86_64 randconfig-a015-20230501 clang
x86_64 randconfig-a016-20230501 clang
x86_64 randconfig-k001 clang
x86_64 randconfig-r005-20230501 gcc
x86_64 randconfig-r012-20230501 clang
x86_64 rhel-8.3-bpf gcc
x86_64 rhel-8.3-kunit gcc
x86_64 rhel-8.3-kvm gcc
x86_64 rhel-8.3-syz gcc
x86_64 rhel-8.3 gcc
xtensa buildonly-randconfig-r003-20230430 gcc
xtensa buildonly-randconfig-r006-20230501 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* Re: [PATCH v2 6/6] Input: cyttsp5 - implement proper sleep and wakeup procedures
From: Maximilian Weigand @ 2023-05-02 14:21 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, linux-input,
linux-kernel, devicetree, Alistair Francis
In-Reply-To: <ZFBXvz17jDhEPI6c@google.com>
Hi,
On 02.05.23 02:22, Dmitry Torokhov wrote:
> On Mon, May 01, 2023 at 01:30:10PM +0200, Maximilian Weigand wrote:
>> struct cyttsp5 {
>> struct device *dev;
>> struct completion cmd_done;
>> + struct completion cmd_command_done;
>
> Why do we need separate comletion? Do you observe some additional
> traffic from the controller when powering it off and on?
I checked and indeed there is no overlap in the different command types,
so one completion will work. I will reformat correspondingly.
>> +static int __maybe_unused cyttsp5_suspend(struct device *dev)
>> +{
>> + struct cyttsp5 *ts = dev_get_drvdata(dev);
>> +
>> + if (!ts->is_wakeup_source)
>
> I believe the idiomatic way to check this is to call
> device_may_wakeup().
Thanks for pointing that out. I will fix that, too.
Thanks for the feedback and best regards
Maximilian
^ permalink raw reply
* Re: [PATCH v2 3/6] dt-bindings: input: cypress,tt21000 - fix interrupt type in dts example
From: Maximilian Weigand @ 2023-05-02 14:23 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, linux-input,
linux-kernel, devicetree, Alistair Francis
In-Reply-To: <ZFBYIZc5zKs6dpHF@google.com>
Hi,
On 02.05.23 02:24, Dmitry Torokhov wrote:
> On Mon, May 01, 2023 at 01:30:07PM +0200, Maximilian Weigand wrote:
>> Triggering the interrupt of the IRQ_TYPE_LEVEL_LOW type can lead to
>> probing issues with the device for the current driver (encountered on
>> the Pine64 PineNote). Basically the interrupt would be triggered before
>> certain commands were sent to the device, leading to a race between the
>> device responding fast enough and the irq handler fetching a data frame
>> from it. Actually all devices currently using the driver already use a
>> falling edge trigger.
>
> I'd prefer we adjusted the driver to handle level interrupts properly.
Ok, I will have a look at that. Just to be clear: The driver should work
only with level interrupts, or should it optimally support both level
and falling edge triggers?
Thanks and best regards
Maximilian
^ permalink raw reply
* Re: [PATCH 3/4] ARM/mmc: Convert old mmci-omap to GPIO descriptors
From: Ulf Hansson @ 2023-05-02 14:25 UTC (permalink / raw)
To: Linus Walleij
Cc: Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Thomas Bogendoerfer,
Dmitry Torokhov, Mark Brown, Bartosz Golaszewski, Andreas Kemnade,
Helge Deller, linux-omap, linux-arm-kernel, linux-kernel,
linux-mips, linux-input, linux-spi, linux-fbdev, dri-devel,
linux-mmc
In-Reply-To: <20230430-nokia770-regression-v1-3-97704e36b094@linaro.org>
On Sun, 30 Apr 2023 at 11:22, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> A recent change to the OMAP driver making it use a dynamic GPIO
> base created problems with some old OMAP1 board files, among
> them Nokia 770, SX1 and also the OMAP2 Nokia n8x0.
>
> Fix up all instances of GPIOs being used for the MMC driver
> by pushing the handling of power, slot selection and MMC
> "cover" into the driver as optional GPIOs.
>
> This is maybe not the most perfect solution as the MMC
> framework have some central handlers for some of the
> stuff, but it at least makes the situtation better and
> solves the immediate issue.
>
> Fixes: 92bf78b33b0b ("gpio: omap: use dynamic allocation of base")
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This looks like it's best funneled through the soc maintainer's tree(s), right?
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> arch/arm/mach-omap1/board-nokia770.c | 43 ++++++-----------
> arch/arm/mach-omap1/board-sx1-mmc.c | 1 -
> arch/arm/mach-omap2/board-n8x0.c | 85 +++++++++++-----------------------
> drivers/mmc/host/omap.c | 46 +++++++++++++++++-
> include/linux/platform_data/mmc-omap.h | 2 -
> 5 files changed, 83 insertions(+), 94 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
> index 509afcd42823..53a4a44d5f4a 100644
> --- a/arch/arm/mach-omap1/board-nokia770.c
> +++ b/arch/arm/mach-omap1/board-nokia770.c
> @@ -162,27 +162,23 @@ static struct omap_usb_config nokia770_usb_config __initdata = {
>
> #if IS_ENABLED(CONFIG_MMC_OMAP)
>
> -#define NOKIA770_GPIO_MMC_POWER 41
> -#define NOKIA770_GPIO_MMC_SWITCH 23
> -
> -static int nokia770_mmc_set_power(struct device *dev, int slot, int power_on,
> - int vdd)
> -{
> - gpio_set_value(NOKIA770_GPIO_MMC_POWER, power_on);
> - return 0;
> -}
> -
> -static int nokia770_mmc_get_cover_state(struct device *dev, int slot)
> -{
> - return gpio_get_value(NOKIA770_GPIO_MMC_SWITCH);
> -}
> +static struct gpiod_lookup_table nokia770_mmc_gpio_table = {
> + .dev_id = "mmci-omap",
> + .table = {
> + /* Slot index 0, VSD power, GPIO 41 */
> + GPIO_LOOKUP_IDX("gpio-32-47", 9,
> + "vsd", 0, GPIO_ACTIVE_HIGH),
> + /* Slot index 0, switch, GPIO 23 */
> + GPIO_LOOKUP_IDX("gpio-16-31", 7,
> + "cover", 0, GPIO_ACTIVE_HIGH),
> + { }
> + },
> +};
>
> static struct omap_mmc_platform_data nokia770_mmc2_data = {
> .nr_slots = 1,
> .max_freq = 12000000,
> .slots[0] = {
> - .set_power = nokia770_mmc_set_power,
> - .get_cover_state = nokia770_mmc_get_cover_state,
> .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
> .name = "mmcblk",
> },
> @@ -192,20 +188,7 @@ static struct omap_mmc_platform_data *nokia770_mmc_data[OMAP16XX_NR_MMC];
>
> static void __init nokia770_mmc_init(void)
> {
> - int ret;
> -
> - ret = gpio_request(NOKIA770_GPIO_MMC_POWER, "MMC power");
> - if (ret < 0)
> - return;
> - gpio_direction_output(NOKIA770_GPIO_MMC_POWER, 0);
> -
> - ret = gpio_request(NOKIA770_GPIO_MMC_SWITCH, "MMC cover");
> - if (ret < 0) {
> - gpio_free(NOKIA770_GPIO_MMC_POWER);
> - return;
> - }
> - gpio_direction_input(NOKIA770_GPIO_MMC_SWITCH);
> -
> + gpiod_add_lookup_table(&nokia770_mmc_gpio_table);
> /* Only the second MMC controller is used */
> nokia770_mmc_data[1] = &nokia770_mmc2_data;
> omap1_init_mmc(nokia770_mmc_data, OMAP16XX_NR_MMC);
> diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c b/arch/arm/mach-omap1/board-sx1-mmc.c
> index f1c160924dfe..f183a8448a7b 100644
> --- a/arch/arm/mach-omap1/board-sx1-mmc.c
> +++ b/arch/arm/mach-omap1/board-sx1-mmc.c
> @@ -9,7 +9,6 @@
> * Copyright (C) 2007 Instituto Nokia de Tecnologia - INdT
> */
>
> -#include <linux/gpio.h>
> #include <linux/platform_device.h>
>
> #include "hardware.h"
> diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
> index 3353b0a923d9..baa2f0341aed 100644
> --- a/arch/arm/mach-omap2/board-n8x0.c
> +++ b/arch/arm/mach-omap2/board-n8x0.c
> @@ -11,6 +11,7 @@
> #include <linux/clk.h>
> #include <linux/delay.h>
> #include <linux/gpio.h>
> +#include <linux/gpio/machine.h>
> #include <linux/init.h>
> #include <linux/io.h>
> #include <linux/irq.h>
> @@ -170,22 +171,32 @@ static struct spi_board_info n800_spi_board_info[] __initdata = {
> * GPIO23 and GPIO9 slot 2 EMMC on N810
> *
> */
> -#define N8X0_SLOT_SWITCH_GPIO 96
> -#define N810_EMMC_VSD_GPIO 23
> -#define N810_EMMC_VIO_GPIO 9
> -
> static int slot1_cover_open;
> static int slot2_cover_open;
> static struct device *mmc_device;
>
> -static int n8x0_mmc_switch_slot(struct device *dev, int slot)
> -{
> -#ifdef CONFIG_MMC_DEBUG
> - dev_dbg(dev, "Choose slot %d\n", slot + 1);
> -#endif
> - gpio_set_value(N8X0_SLOT_SWITCH_GPIO, slot);
> - return 0;
> -}
> +static struct gpiod_lookup_table nokia8xx_mmc_gpio_table = {
> + .dev_id = "mmci-omap",
> + .table = {
> + /* Slot switch, GPIO 96 */
> + GPIO_LOOKUP("gpio-80-111", 16,
> + "switch", GPIO_ACTIVE_HIGH),
> + { }
> + },
> +};
> +
> +static struct gpiod_lookup_table nokia810_mmc_gpio_table = {
> + .dev_id = "mmci-omap",
> + .table = {
> + /* Slot index 1, VSD power, GPIO 23 */
> + GPIO_LOOKUP_IDX("gpio-16-31", 7,
> + "vsd", 1, GPIO_ACTIVE_HIGH),
> + /* Slot index 1, VIO power, GPIO 9 */
> + GPIO_LOOKUP_IDX("gpio-0-15", 9,
> + "vsd", 1, GPIO_ACTIVE_HIGH),
> + { }
> + },
> +};
>
> static int n8x0_mmc_set_power_menelaus(struct device *dev, int slot,
> int power_on, int vdd)
> @@ -256,31 +267,13 @@ static int n8x0_mmc_set_power_menelaus(struct device *dev, int slot,
> return 0;
> }
>
> -static void n810_set_power_emmc(struct device *dev,
> - int power_on)
> -{
> - dev_dbg(dev, "Set EMMC power %s\n", power_on ? "on" : "off");
> -
> - if (power_on) {
> - gpio_set_value(N810_EMMC_VSD_GPIO, 1);
> - msleep(1);
> - gpio_set_value(N810_EMMC_VIO_GPIO, 1);
> - msleep(1);
> - } else {
> - gpio_set_value(N810_EMMC_VIO_GPIO, 0);
> - msleep(50);
> - gpio_set_value(N810_EMMC_VSD_GPIO, 0);
> - msleep(50);
> - }
> -}
> -
> static int n8x0_mmc_set_power(struct device *dev, int slot, int power_on,
> int vdd)
> {
> if (board_is_n800() || slot == 0)
> return n8x0_mmc_set_power_menelaus(dev, slot, power_on, vdd);
>
> - n810_set_power_emmc(dev, power_on);
> + /* The n810 power will be handled by GPIO code in the driver */
>
> return 0;
> }
> @@ -418,13 +411,6 @@ static void n8x0_mmc_shutdown(struct device *dev)
> static void n8x0_mmc_cleanup(struct device *dev)
> {
> menelaus_unregister_mmc_callback();
> -
> - gpio_free(N8X0_SLOT_SWITCH_GPIO);
> -
> - if (board_is_n810()) {
> - gpio_free(N810_EMMC_VSD_GPIO);
> - gpio_free(N810_EMMC_VIO_GPIO);
> - }
> }
>
> /*
> @@ -433,7 +419,6 @@ static void n8x0_mmc_cleanup(struct device *dev)
> */
> static struct omap_mmc_platform_data mmc1_data = {
> .nr_slots = 0,
> - .switch_slot = n8x0_mmc_switch_slot,
> .init = n8x0_mmc_late_init,
> .cleanup = n8x0_mmc_cleanup,
> .shutdown = n8x0_mmc_shutdown,
> @@ -463,14 +448,9 @@ static struct omap_mmc_platform_data mmc1_data = {
>
> static struct omap_mmc_platform_data *mmc_data[OMAP24XX_NR_MMC];
>
> -static struct gpio n810_emmc_gpios[] __initdata = {
> - { N810_EMMC_VSD_GPIO, GPIOF_OUT_INIT_LOW, "MMC slot 2 Vddf" },
> - { N810_EMMC_VIO_GPIO, GPIOF_OUT_INIT_LOW, "MMC slot 2 Vdd" },
> -};
> -
> static void __init n8x0_mmc_init(void)
> {
> - int err;
> + gpiod_add_lookup_table(&nokia8xx_mmc_gpio_table);
>
> if (board_is_n810()) {
> mmc1_data.slots[0].name = "external";
> @@ -483,20 +463,7 @@ static void __init n8x0_mmc_init(void)
> */
> mmc1_data.slots[1].name = "internal";
> mmc1_data.slots[1].ban_openended = 1;
> - }
> -
> - err = gpio_request_one(N8X0_SLOT_SWITCH_GPIO, GPIOF_OUT_INIT_LOW,
> - "MMC slot switch");
> - if (err)
> - return;
> -
> - if (board_is_n810()) {
> - err = gpio_request_array(n810_emmc_gpios,
> - ARRAY_SIZE(n810_emmc_gpios));
> - if (err) {
> - gpio_free(N8X0_SLOT_SWITCH_GPIO);
> - return;
> - }
> + gpiod_add_lookup_table(&nokia810_mmc_gpio_table);
> }
>
> mmc1_data.nr_slots = 2;
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index ce78edfb402b..a14af21f12da 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -26,6 +26,7 @@
> #include <linux/clk.h>
> #include <linux/scatterlist.h>
> #include <linux/slab.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/platform_data/mmc-omap.h>
>
>
> @@ -111,6 +112,9 @@ struct mmc_omap_slot {
> struct mmc_request *mrq;
> struct mmc_omap_host *host;
> struct mmc_host *mmc;
> + struct gpio_desc *vsd;
> + struct gpio_desc *vio;
> + struct gpio_desc *cover;
> struct omap_mmc_slot_data *pdata;
> };
>
> @@ -133,6 +137,7 @@ struct mmc_omap_host {
> int irq;
> unsigned char bus_mode;
> unsigned int reg_shift;
> + struct gpio_desc *slot_switch;
>
> struct work_struct cmd_abort_work;
> unsigned abort:1;
> @@ -216,8 +221,13 @@ static void mmc_omap_select_slot(struct mmc_omap_slot *slot, int claimed)
>
> if (host->current_slot != slot) {
> OMAP_MMC_WRITE(host, CON, slot->saved_con & 0xFC00);
> - if (host->pdata->switch_slot != NULL)
> - host->pdata->switch_slot(mmc_dev(slot->mmc), slot->id);
> + if (host->slot_switch)
> + /*
> + * With two slots and a simple GPIO switch, setting
> + * the GPIO to 0 selects slot ID 0, setting it to 1
> + * selects slot ID 1.
> + */
> + gpiod_set_value(host->slot_switch, slot->id);
> host->current_slot = slot;
> }
>
> @@ -297,6 +307,9 @@ static void mmc_omap_release_slot(struct mmc_omap_slot *slot, int clk_enabled)
> static inline
> int mmc_omap_cover_is_open(struct mmc_omap_slot *slot)
> {
> + /* If we have a GPIO then use that */
> + if (slot->cover)
> + return gpiod_get_value(slot->cover);
> if (slot->pdata->get_cover_state)
> return slot->pdata->get_cover_state(mmc_dev(slot->mmc),
> slot->id);
> @@ -1106,6 +1119,11 @@ static void mmc_omap_set_power(struct mmc_omap_slot *slot, int power_on,
>
> host = slot->host;
>
> + if (slot->vsd)
> + gpiod_set_value(slot->vsd, power_on);
> + if (slot->vio)
> + gpiod_set_value(slot->vio, power_on);
> +
> if (slot->pdata->set_power != NULL)
> slot->pdata->set_power(mmc_dev(slot->mmc), slot->id, power_on,
> vdd);
> @@ -1240,6 +1258,23 @@ static int mmc_omap_new_slot(struct mmc_omap_host *host, int id)
> slot->power_mode = MMC_POWER_UNDEFINED;
> slot->pdata = &host->pdata->slots[id];
>
> + /* Check for some optional GPIO controls */
> + slot->vsd = gpiod_get_index_optional(host->dev, "vsd",
> + id, GPIOD_OUT_LOW);
> + if (IS_ERR(slot->vsd))
> + return dev_err_probe(host->dev, PTR_ERR(slot->vsd),
> + "error looking up VSD GPIO\n");
> + slot->vio = gpiod_get_index_optional(host->dev, "vio",
> + id, GPIOD_OUT_LOW);
> + if (IS_ERR(slot->vio))
> + return dev_err_probe(host->dev, PTR_ERR(slot->vio),
> + "error looking up VIO GPIO\n");
> + slot->cover = gpiod_get_index_optional(host->dev, "cover",
> + id, GPIOD_IN);
> + if (IS_ERR(slot->cover))
> + return dev_err_probe(host->dev, PTR_ERR(slot->cover),
> + "error looking up cover switch GPIO\n");
> +
> host->slots[id] = slot;
>
> mmc->caps = 0;
> @@ -1349,6 +1384,13 @@ static int mmc_omap_probe(struct platform_device *pdev)
> if (IS_ERR(host->virt_base))
> return PTR_ERR(host->virt_base);
>
> + host->slot_switch = gpiod_get_optional(host->dev, "switch",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(host->slot_switch))
> + return dev_err_probe(host->dev, PTR_ERR(host->slot_switch),
> + "error looking up slot switch GPIO\n");
> +
> +
> INIT_WORK(&host->slot_release_work, mmc_omap_slot_release_work);
> INIT_WORK(&host->send_stop_work, mmc_omap_send_stop_work);
>
> diff --git a/include/linux/platform_data/mmc-omap.h b/include/linux/platform_data/mmc-omap.h
> index 91051e9907f3..054d0c3c5ec5 100644
> --- a/include/linux/platform_data/mmc-omap.h
> +++ b/include/linux/platform_data/mmc-omap.h
> @@ -20,8 +20,6 @@ struct omap_mmc_platform_data {
> * maximum frequency on the MMC bus */
> unsigned int max_freq;
>
> - /* switch the bus to a new slot */
> - int (*switch_slot)(struct device *dev, int slot);
> /* initialize board-specific MMC functionality, can be NULL if
> * not supported */
> int (*init)(struct device *dev);
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 2/2] input: imx_sc_key: add wakeup support
From: Ulf Hansson @ 2023-05-02 14:53 UTC (permalink / raw)
To: Dmitry Torokhov, Peng Fan
Cc: Peng Fan, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
shawnguo@kernel.org, Aisheng Dong, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx
In-Reply-To: <fcfd3b04-ce51-af95-5d94-cc244d75727f@oss.nxp.com>
On Thu, 20 Apr 2023 at 09:54, Peng Fan <peng.fan@oss.nxp.com> wrote:
>
> Dmitry,Ulf
>
> On 4/18/2023 4:32 PM, Ulf Hansson wrote:
> > On Wed, 12 Apr 2023 at 17:58, Peng Fan <peng.fan@nxp.com> wrote:
> >>
> >> +Ulf
> >>
> >>> Subject: RE: [PATCH 2/2] input: imx_sc_key: add wakeup support
> >>>
> >>>> Subject: Re: [PATCH 2/2] input: imx_sc_key: add wakeup support
> >>>>
> >>>> On Thu, Mar 23, 2023 at 05:31:41PM +0800, Peng Fan (OSS) wrote:
> >>>>> From: Peng Fan <peng.fan@nxp.com>
> >>>>>
> >>>>> Add support for waking up from system wide suspend.
> >>>>>
> >>>>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> >>>>> ---
> >>>>> drivers/input/keyboard/imx_sc_key.c | 2 ++
> >>>>> 1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/input/keyboard/imx_sc_key.c
> >>>> b/drivers/input/keyboard/imx_sc_key.c
> >>>>> index d18839f1f4f6..234f23cf9990 100644
> >>>>> --- a/drivers/input/keyboard/imx_sc_key.c
> >>>>> +++ b/drivers/input/keyboard/imx_sc_key.c
> >>>>> @@ -151,6 +151,8 @@ static int imx_sc_key_probe(struct
> >>>> platform_device *pdev)
> >>>>> priv->input = input;
> >>>>> platform_set_drvdata(pdev, priv);
> >>>>>
> >>>>> + device_init_wakeup(&pdev->dev,
> >>>> device_property_read_bool(&pdev->dev, "wakeup-source"));
> >>>>> +
> >>>>
> >>>> I wonder - could we move this to the device core?
> >>>
> >>> I see lots device drivers parse wakeup-source, so I also follow That. Not sure
> >>> whether could move this feature to device core, but anyway I could give a
> >>> try.
> >>
> >> Do you think it is feasible to move device_init_wakeup into device core
> >> part?
> >
> > Not sure it would really improve things that much. Subsystems/drivers
> > need to make additional configurations based upon whether this DT
> > property is set anyway.
> >
> > Perhaps an option is to make this a part of the common input subsystem
> > helper functions instead? Other subsystems do this, but I am not sure
> > how feasible that would be in the input case.
>
> How do you think of below patch?
Seems reasonable to me, but I can't really tell if this makes sense
for all input drivers.
Dmitry?
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 37e876d45eb9..a98a9f37e1f5 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -2402,6 +2402,10 @@ int input_register_device(struct input_dev *dev)
> __func__, dev_name(&dev->dev));
> devres_add(dev->dev.parent, devres);
> }
> +
> + if (device_property_read_bool(input->dev.parent, "wakeup-source"))
> + device_init_wakeup(&pdev->dev, true);
> +
> return 0;
>
> err_device_del:
>
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 3/4] Input: pwm-vibra - add support for enable GPIO
From: Luca Weiss @ 2023-05-02 15:24 UTC (permalink / raw)
To: Brian Masney, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Sebastian Reichel, Andy Gross,
Bjorn Andersson, Brian Masney, linux-input, devicetree,
linux-kernel, linux-arm-msm
In-Reply-To: <8a54d0ec-8a22-9ffd-43a4-55da988fbeb1@linaro.org>
On Dienstag, 2. Mai 2023 12:39:10 CEST Konrad Dybcio wrote:
> On 28.04.2023 18:06, Luca Weiss wrote:
> > On Freitag, 28. April 2023 01:29:27 CEST Brian Masney wrote:
> >> On Thu, Apr 27, 2023 at 10:34:28PM +0200, Luca Weiss wrote:
> >>> Some pwm vibrators have a dedicated enable GPIO that needs to be set
> >>> high so that the vibrator works. Add support for that optionally.
> >>>
> >>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> >>
> >> Hi Luca,
> >>
> >> Thank you for picking up this work!
> >>
> >>> + vibrator->enable_gpio = devm_gpiod_get_optional(&pdev->dev,
> >
> > "enable",
> >
> >>> +
> >
> > GPIOD_OUT_LOW);
> >
> >>> + err = PTR_ERR_OR_ZERO(vibrator->enable_gpio);
> >>> + if (err) {
> >>> + if (err != -EPROBE_DEFER)
> >>> + dev_err(&pdev->dev, "Failed to request enable
> >
> > gpio: %d\n",
> >
> >>> + err);
> >>> + return err;
> >>> + }
> >>> +
>
> Looks like your email client messes with the replies.. perhaps it tries
> to round them to n characters forcefully?
Quite possible, I'm using KMail with Options -> Wordwrap turned on, otherwise
I have to manually wrap everything but with this on there doesn't seem to be a
way to get over that limit, even when posting links etc - or when quoting
existing text.
Regards
Luca
>
> Konrad
>
> >> Take a look at dev_err_probe() to remove the -EPROBE_DEFER check.
> >
> > The input subsystem doesn't like dev_err_probe for some reason, you should
> > quickly find examples of that being rejected on the mailing list (or see
> > "git grep dev_err_probe drivers/input/")
> >
> >> With that fixed:
> >>
> >> Reviewed-by: Brian Masney <bmasney@redhat.com>
> >
> > Thanks for the reviews!
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: qcom: msm8974-hammerhead: Add vibrator
From: Luca Weiss @ 2023-05-02 15:28 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Sebastian Reichel, Andy Gross,
Bjorn Andersson, Brian Masney, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <fc22fd34-6cce-c175-d845-cf4435b4b0be@linaro.org>
On Dienstag, 2. Mai 2023 12:40:40 CEST Konrad Dybcio wrote:
> On 27.04.2023 22:34, Luca Weiss wrote:
> > The Nexus 5 has a vibrator connected to the clock output of GP1_CLK
> > which we can use with the clk-pwm driver, then we can use that pwm with
> > pwm-vibrator to get haptics functionality.
> >
> > This patch is based on Brian Masney's previous patch with clk-vibrator.
> >
> > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > ---
> >
> > .../dts/qcom-msm8974-lge-nexus5-hammerhead.dts | 35
> > ++++++++++++++++++++++ 1 file changed, 35 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> > b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts index
> > ab35f2d644c0..fea8a6be9021 100644
> > --- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> > +++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> > @@ -41,6 +41,25 @@ key-volume-down {
> >
> > };
> >
> > };
> >
> > + clk_pwm: pwm {
> > + compatible = "clk-pwm";
> > + clocks = <&mmcc CAMSS_GP1_CLK>;
>
> Are you sure it's <&mmcc CAMSS_GP1_CLK> and not <&gcc GCC_GP1_CLK>?
Quite sure.
The driver uses:
cam_gp1_clk = clk_get(&pdev->dev, "cam_gp1_clk");
and this comes from the clock-8974.c driver
CLK_LOOKUP("cam_gp1_clk", camss_gp1_clk.c, "vibrator"),
Regards
Luca
>
> Konrad
>
> > +
> > + pinctrl-0 = <&vibrator_pin>;
> > + pinctrl-names = "default";
> > +
> > + #pwm-cells = <2>;
> > + };
> > +
> > + vibrator {
> > + compatible = "pwm-vibrator";
> > + pwms = <&clk_pwm 0 100000>;
> > + pwm-names = "enable";
> > +
> > + vcc-supply = <&pm8941_l19>;
> > + enable-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> > + };
> > +
> >
> > vreg_wlan: wlan-regulator {
> >
> > compatible = "regulator-fixed";
> >
> > @@ -637,6 +656,22 @@ shutdown-pins {
> >
> > function = "gpio";
> >
> > };
> >
> > };
> >
> > +
> > + vibrator_pin: vibrator-state {
> > + core-pins {
> > + pins = "gpio27";
> > + function = "gp1_clk";
> > + drive-strength = <6>;
> > + bias-disable;
> > + };
> > +
> > + enable-pins {
> > + pins = "gpio60";
> > + function = "gpio";
> > + drive-strength = <2>;
> > + bias-disable;
> > + };
> > + };
> >
> > };
> >
> > &usb {
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: qcom: msm8974-hammerhead: Add vibrator
From: Konrad Dybcio @ 2023-05-02 15:31 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Sebastian Reichel, Andy Gross, Bjorn Andersson, Brian Masney
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <112204300.nniJfEyVGO@z3ntu.xyz>
On 2.05.2023 17:28, Luca Weiss wrote:
> On Dienstag, 2. Mai 2023 12:40:40 CEST Konrad Dybcio wrote:
>> On 27.04.2023 22:34, Luca Weiss wrote:
>>> The Nexus 5 has a vibrator connected to the clock output of GP1_CLK
>>> which we can use with the clk-pwm driver, then we can use that pwm with
>>> pwm-vibrator to get haptics functionality.
>>>
>>> This patch is based on Brian Masney's previous patch with clk-vibrator.
>>>
>>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
>>> ---
>>>
>>> .../dts/qcom-msm8974-lge-nexus5-hammerhead.dts | 35
>>> ++++++++++++++++++++++ 1 file changed, 35 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
>>> b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts index
>>> ab35f2d644c0..fea8a6be9021 100644
>>> --- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
>>> +++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
>>> @@ -41,6 +41,25 @@ key-volume-down {
>>>
>>> };
>>>
>>> };
>>>
>>> + clk_pwm: pwm {
>>> + compatible = "clk-pwm";
>>> + clocks = <&mmcc CAMSS_GP1_CLK>;
>>
>> Are you sure it's <&mmcc CAMSS_GP1_CLK> and not <&gcc GCC_GP1_CLK>?
>
> Quite sure.
>
> The driver uses:
>
> cam_gp1_clk = clk_get(&pdev->dev, "cam_gp1_clk");
>
> and this comes from the clock-8974.c driver
>
> CLK_LOOKUP("cam_gp1_clk", camss_gp1_clk.c, "vibrator"),
>
> Regards
> Luca
ugh that hurts my brain but fine, maybe the camss clock had a
pad closer to the vibrator pcb traces..
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
>
>>
>> Konrad
>>
>>> +
>>> + pinctrl-0 = <&vibrator_pin>;
>>> + pinctrl-names = "default";
>>> +
>>> + #pwm-cells = <2>;
>>> + };
>>> +
>>> + vibrator {
>>> + compatible = "pwm-vibrator";
>>> + pwms = <&clk_pwm 0 100000>;
>>> + pwm-names = "enable";
>>> +
>>> + vcc-supply = <&pm8941_l19>;
>>> + enable-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +
>>>
>>> vreg_wlan: wlan-regulator {
>>>
>>> compatible = "regulator-fixed";
>>>
>>> @@ -637,6 +656,22 @@ shutdown-pins {
>>>
>>> function = "gpio";
>>>
>>> };
>>>
>>> };
>>>
>>> +
>>> + vibrator_pin: vibrator-state {
>>> + core-pins {
>>> + pins = "gpio27";
>>> + function = "gp1_clk";
>>> + drive-strength = <6>;
>>> + bias-disable;
>>> + };
>>> +
>>> + enable-pins {
>>> + pins = "gpio60";
>>> + function = "gpio";
>>> + drive-strength = <2>;
>>> + bias-disable;
>>> + };
>>> + };
>>>
>>> };
>>>
>>> &usb {
>
>
>
>
^ permalink raw reply
* Re: [PATCH 3/4] Input: pwm-vibra - add support for enable GPIO
From: Luca Weiss @ 2023-05-02 15:35 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: ~postmarketos/upstreaming, phone-devel, Rob Herring,
Krzysztof Kozlowski, Sebastian Reichel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Brian Masney, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <ZFBdobY1yxMXYfFt@google.com>
On Dienstag, 2. Mai 2023 02:47:29 CEST Dmitry Torokhov wrote:
> On Thu, Apr 27, 2023 at 10:34:28PM +0200, Luca Weiss wrote:
> > Some pwm vibrators have a dedicated enable GPIO that needs to be set
> > high so that the vibrator works. Add support for that optionally.
>
> So this is not simply a power supply in your case controlled by a GPIO?
> We truly can have both GPIO and a separate regulator?
Yes it appears to be the EN pin on the ISA1000A, see
https://electronics.stackexchange.com/q/380475
On apq8026-lg-lenok there is a similar setup for the vibration motor although
there I don't know whether it's actually a fixed-regulator or not, but since
the two devices were built in a similar time (without checking further) I
could assume they both contain the same IC.
Regards
Luca
>
> Thanks.
^ permalink raw reply
* Re: [PATCH 0/2] Input: tests - miscellaneous fixes
From: Geert Uytterhoeven @ 2023-05-02 16:09 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Dmitry Torokhov, Brendan Higgins, David Gow, linux-input,
linux-kselftest, kunit-dev, linux-kernel
In-Reply-To: <cover.1683022164.git.geert+renesas@glider.be>
Hi Javier,
On Tue, May 2, 2023 at 12:17 PM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> This patch series fixes a crash in the new input selftest, and makes the
> test available when the KUnit framework is modular.
>
> Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W)
> and ARAnyM):
>
> KTAP version 1
> # Subtest: input_core
> 1..3
> input: Test input device as /devices/virtual/input/input1
> ok 1 input_test_polling
> input: Test input device as /devices/virtual/input/input2
> ok 2 input_test_timestamp
> input: Test input device as /devices/virtual/input/input3
> # input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99
> Expected input_match_device_id(input_dev, &id) to be true, but is false
> not ok 3 input_test_match_device_id
> # input_core: pass:2 fail:1 skip:0 total:3
> # Totals: pass:2 fail:1 skip:0 total:3
> not ok 1 input_core
Adding more debug code shows that it's the test on evbit [1] in
input_match_device_id() that fails.
Looking at your input_test_match_device_id(), I think you expect
the checks for the various bitmaps to be gated by
"if (id->flags & INPUT_DEVICE_ID_MATCH_EVBIT)", like is done for the
other checks?
[1] https://elixir.bootlin.com/linux/latest/source/drivers/input/input.c#L1021
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [dtor-input:master] BUILD SUCCESS 3a2df60200a03f78173f1fd831aa54c08464dcde
From: kernel test robot @ 2023-05-02 16:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git master
branch HEAD: 3a2df60200a03f78173f1fd831aa54c08464dcde Input: uinput - allow injecting event times
elapsed time: 721m
configs tested: 165
configs skipped: 18
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha defconfig gcc
alpha randconfig-r002-20230430 gcc
alpha randconfig-r013-20230430 gcc
alpha randconfig-r013-20230502 gcc
alpha randconfig-r021-20230430 gcc
alpha randconfig-r022-20230501 gcc
alpha randconfig-r031-20230430 gcc
arc allyesconfig gcc
arc buildonly-randconfig-r006-20230502 gcc
arc defconfig gcc
arc randconfig-r005-20230501 gcc
arc randconfig-r006-20230502 gcc
arc randconfig-r011-20230430 gcc
arc randconfig-r013-20230501 gcc
arc randconfig-r025-20230430 gcc
arc randconfig-r043-20230430 gcc
arc randconfig-r043-20230501 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm buildonly-randconfig-r001-20230501 gcc
arm buildonly-randconfig-r005-20230501 gcc
arm buildonly-randconfig-r006-20230430 gcc
arm buildonly-randconfig-r006-20230501 gcc
arm defconfig gcc
arm randconfig-r004-20230501 clang
arm randconfig-r022-20230430 gcc
arm randconfig-r035-20230502 gcc
arm randconfig-r046-20230430 gcc
arm randconfig-r046-20230501 gcc
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r006-20230430 gcc
arm64 randconfig-r036-20230502 clang
csky defconfig gcc
csky randconfig-r014-20230430 gcc
csky randconfig-r021-20230430 gcc
hexagon randconfig-r011-20230502 clang
hexagon randconfig-r012-20230501 clang
hexagon randconfig-r031-20230502 clang
hexagon randconfig-r041-20230430 clang
hexagon randconfig-r041-20230501 clang
hexagon randconfig-r045-20230430 clang
hexagon randconfig-r045-20230501 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230501 gcc
i386 randconfig-a002-20230501 gcc
i386 randconfig-a003-20230501 gcc
i386 randconfig-a004-20230501 gcc
i386 randconfig-a005-20230501 gcc
i386 randconfig-a006-20230501 gcc
i386 randconfig-a011-20230501 clang
i386 randconfig-a012-20230501 clang
i386 randconfig-a013-20230501 clang
i386 randconfig-a014-20230501 clang
i386 randconfig-a015-20230501 clang
i386 randconfig-a016-20230501 clang
i386 randconfig-r003-20230501 gcc
i386 randconfig-r025-20230501 clang
i386 randconfig-r026-20230501 clang
i386 randconfig-r035-20230501 gcc
ia64 allmodconfig gcc
ia64 defconfig gcc
ia64 randconfig-r004-20230430 gcc
ia64 randconfig-r015-20230430 gcc
ia64 randconfig-r024-20230430 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch buildonly-randconfig-r002-20230430 gcc
loongarch buildonly-randconfig-r004-20230430 gcc
loongarch defconfig gcc
loongarch randconfig-r001-20230430 gcc
loongarch randconfig-r003-20230430 gcc
loongarch randconfig-r023-20230501 gcc
loongarch randconfig-r026-20230430 gcc
m68k allmodconfig gcc
m68k buildonly-randconfig-r004-20230502 gcc
m68k defconfig gcc
m68k randconfig-r001-20230501 gcc
m68k randconfig-r001-20230502 gcc
m68k randconfig-r015-20230502 gcc
m68k randconfig-r035-20230430 gcc
microblaze randconfig-r005-20230502 gcc
microblaze randconfig-r012-20230502 gcc
microblaze randconfig-r021-20230501 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips randconfig-r011-20230502 clang
mips randconfig-r034-20230501 clang
mips randconfig-r036-20230430 clang
nios2 buildonly-randconfig-r001-20230502 gcc
nios2 defconfig gcc
nios2 randconfig-r022-20230501 gcc
nios2 randconfig-r032-20230430 gcc
openrisc randconfig-r002-20230501 gcc
openrisc randconfig-r033-20230502 gcc
parisc buildonly-randconfig-r002-20230501 gcc
parisc defconfig gcc
parisc randconfig-r025-20230501 gcc
parisc randconfig-r032-20230501 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc buildonly-randconfig-r004-20230501 clang
powerpc randconfig-r012-20230502 gcc
powerpc randconfig-r016-20230502 gcc
powerpc randconfig-r023-20230501 clang
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r005-20230502 gcc
riscv defconfig gcc
riscv randconfig-r014-20230502 gcc
riscv randconfig-r031-20230501 gcc
riscv randconfig-r033-20230430 gcc
riscv randconfig-r034-20230430 gcc
riscv randconfig-r042-20230430 clang
riscv randconfig-r042-20230501 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 buildonly-randconfig-r003-20230501 clang
s390 buildonly-randconfig-r005-20230430 clang
s390 defconfig gcc
s390 randconfig-r015-20230502 gcc
s390 randconfig-r044-20230430 clang
s390 randconfig-r044-20230501 clang
sh allmodconfig gcc
sh buildonly-randconfig-r002-20230502 gcc
sh randconfig-r005-20230430 gcc
sh randconfig-r021-20230501 gcc
sh randconfig-r024-20230430 gcc
sh randconfig-r032-20230502 gcc
sparc defconfig gcc
sparc randconfig-r025-20230430 gcc
sparc64 randconfig-r013-20230502 gcc
sparc64 randconfig-r014-20230501 gcc
sparc64 randconfig-r023-20230430 gcc
sparc64 randconfig-r034-20230502 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230501 gcc
x86_64 randconfig-a002-20230501 gcc
x86_64 randconfig-a003-20230501 gcc
x86_64 randconfig-a004-20230501 gcc
x86_64 randconfig-a005-20230501 gcc
x86_64 randconfig-a006-20230501 gcc
x86_64 randconfig-a011-20230501 clang
x86_64 randconfig-a012-20230501 clang
x86_64 randconfig-a013-20230501 clang
x86_64 randconfig-a014-20230501 clang
x86_64 randconfig-a015-20230501 clang
x86_64 randconfig-a016-20230501 clang
x86_64 randconfig-r011-20230501 clang
x86_64 randconfig-r016-20230501 clang
x86_64 rhel-8.3 gcc
xtensa randconfig-r006-20230501 gcc
xtensa randconfig-r016-20230430 gcc
xtensa randconfig-r016-20230502 gcc
xtensa randconfig-r036-20230501 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* Re: [PATCH 0/2] Input: tests - miscellaneous fixes
From: Javier Martinez Canillas @ 2023-05-02 16:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Dmitry Torokhov, Brendan Higgins, David Gow, linux-input,
linux-kselftest, kunit-dev, linux-kernel
In-Reply-To: <CAMuHMdVmfj8L24QbMGn54jW96rYkvX1gizmvgvEB7T3Jwevd+g@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
Hello Geert,
> Hi Javier,
>
> On Tue, May 2, 2023 at 12:17 PM Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>> This patch series fixes a crash in the new input selftest, and makes the
>> test available when the KUnit framework is modular.
>>
>> Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W)
>> and ARAnyM):
>>
>> KTAP version 1
>> # Subtest: input_core
>> 1..3
>> input: Test input device as /devices/virtual/input/input1
>> ok 1 input_test_polling
>> input: Test input device as /devices/virtual/input/input2
>> ok 2 input_test_timestamp
>> input: Test input device as /devices/virtual/input/input3
>> # input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99
>> Expected input_match_device_id(input_dev, &id) to be true, but is false
>> not ok 3 input_test_match_device_id
>> # input_core: pass:2 fail:1 skip:0 total:3
>> # Totals: pass:2 fail:1 skip:0 total:3
>> not ok 1 input_core
>
> Adding more debug code shows that it's the test on evbit [1] in
> input_match_device_id() that fails.
> Looking at your input_test_match_device_id(), I think you expect
> the checks for the various bitmaps to be gated by
> "if (id->flags & INPUT_DEVICE_ID_MATCH_EVBIT)", like is done for the
> other checks?
>
> [1] https://elixir.bootlin.com/linux/latest/source/drivers/input/input.c#L1021
>
That's correct. In input_test_init(), the input dev is marked as capable
of emitting EV_KEY BTN_LEFT and BTN_RIGHT. The goal of that test was to
check this.
That is, check if matches by the input dev capabilities in which case the
__set_bit(EV_KEY, ...) would make the match true and __set_bit(EV_ABS, ..)
would make the condition false.
But maybe I misunderstood how the input_set_capability() and __set_bit()
functions work ?
I'll take a look to this tomorrow, thanks a lot for your report!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH 0/2] Input: tests - miscellaneous fixes
From: Dmitry Torokhov @ 2023-05-02 17:05 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Geert Uytterhoeven, Brendan Higgins, David Gow, linux-input,
linux-kselftest, kunit-dev, linux-kernel
In-Reply-To: <878re6y9s8.fsf@minerva.mail-host-address-is-not-set>
On Tue, May 02, 2023 at 06:31:51PM +0200, Javier Martinez Canillas wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
> Hello Geert,
>
> > Hi Javier,
> >
> > On Tue, May 2, 2023 at 12:17 PM Geert Uytterhoeven
> > <geert+renesas@glider.be> wrote:
> >> This patch series fixes a crash in the new input selftest, and makes the
> >> test available when the KUnit framework is modular.
> >>
> >> Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W)
> >> and ARAnyM):
> >>
> >> KTAP version 1
> >> # Subtest: input_core
> >> 1..3
> >> input: Test input device as /devices/virtual/input/input1
> >> ok 1 input_test_polling
> >> input: Test input device as /devices/virtual/input/input2
> >> ok 2 input_test_timestamp
> >> input: Test input device as /devices/virtual/input/input3
> >> # input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99
> >> Expected input_match_device_id(input_dev, &id) to be true, but is false
> >> not ok 3 input_test_match_device_id
> >> # input_core: pass:2 fail:1 skip:0 total:3
> >> # Totals: pass:2 fail:1 skip:0 total:3
> >> not ok 1 input_core
> >
> > Adding more debug code shows that it's the test on evbit [1] in
> > input_match_device_id() that fails.
> > Looking at your input_test_match_device_id(), I think you expect
> > the checks for the various bitmaps to be gated by
> > "if (id->flags & INPUT_DEVICE_ID_MATCH_EVBIT)", like is done for the
> > other checks?
> >
> > [1] https://elixir.bootlin.com/linux/latest/source/drivers/input/input.c#L1021
> >
>
> That's correct. In input_test_init(), the input dev is marked as capable
> of emitting EV_KEY BTN_LEFT and BTN_RIGHT. The goal of that test was to
> check this.
>
> That is, check if matches by the input dev capabilities in which case the
> __set_bit(EV_KEY, ...) would make the match true and __set_bit(EV_ABS, ..)
> would make the condition false.
>
> But maybe I misunderstood how the input_set_capability() and __set_bit()
> functions work ?
>
> I'll take a look to this tomorrow, thanks a lot for your report!
Unfortunately (?) INPUT_DEVICE_ID_MATCH_*BIT have never had any effect,
the kernel always used bitmaps when matching (with the assumption that
if one does not care about given bitmap they can simply pass empty one),
so I think what we need to change is:
diff --git a/drivers/input/tests/input_test.c b/drivers/input/tests/input_test.c
index 8b8ac3412a70..0540225f0288 100644
--- a/drivers/input/tests/input_test.c
+++ b/drivers/input/tests/input_test.c
@@ -87,7 +87,7 @@ static void input_test_timestamp(struct kunit *test)
static void input_test_match_device_id(struct kunit *test)
{
struct input_dev *input_dev = test->priv;
- struct input_device_id id;
+ struct input_device_id id = { 0 };
/*
* Must match when the input device bus, vendor, product, version
to avoid having garbage in the match data.
I suppose we should remove INPUT_DEVICE_ID_MATCH_*BIT from
mod_devicetable.h to avoid this confusion.
Thanks.
--
Dmitry
^ permalink raw reply related
* Re: [PATCH] Input: avoid calling input_set_abs_val() in the event handling core
From: Dmitry Torokhov @ 2023-05-02 20:21 UTC (permalink / raw)
To: Peter Hutterer; +Cc: linux-input, Teng Qi, linux-kernel
In-Reply-To: <20230502060531.GA857155@quokka>
On Tue, May 02, 2023 at 04:05:31PM +1000, Peter Hutterer wrote:
> On Mon, May 01, 2023 at 06:01:19PM -0700, Dmitry Torokhov wrote:
> > input_abs_set_val() can nominally call input_alloc_absinfo() which may
> > allocate memory with GFP_KERNEL flag. This does not happen when
> > input_abs_set_val() is called by the input core to set current MT slot when
> > handling a new input event, but it trips certain static analyzers.
> >
> > Rearrange the code to access the relevant structures directly.
> >
> > Reported-by: Teng Qi <starmiku1207184332@gmail.com>
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Thanks for the review.
>
> If git grep is to be believed, this is the only use of
> input_abs_set_val. Maybe removing that function is an option?
We generate input_abs_[get|set]_<item>() accessors and setters, and
there is a couple of users of input_abs_get_val() in the code, so
dropping just input_abs_set_val() is kind of hard. It might be useful
elsewhere although I have no idea if anyone is actually using it
anywhere...
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: fix open count when closing inhibited device
From: Dmitry Torokhov @ 2023-05-02 20:34 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Peter Hutterer
Because the kernel increments device's open count in input_open_device()
even if device is inhibited, the counter should always be decremented in
input_close_device() to keep it balanced.
Fixes: a181616487db ("Input: Add "inhibited" property")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index f791d14ecf23..8c5fdb0f858a 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -705,7 +705,7 @@ void input_close_device(struct input_handle *handle)
__input_release_device(handle);
- if (!dev->inhibited && !--dev->users) {
+ if (!--dev->users && !dev->inhibited) {
if (dev->poller)
input_dev_poller_stop(dev->poller);
if (dev->close)
--
2.40.1.495.gc816e09b53d-goog
--
Dmitry
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox