* [PATCH] hid-wiimote-debug.c: Fix error checking for debugfs_create_file
From: Osama Muhammad @ 2023-05-23 17:12 UTC (permalink / raw)
To: david.rheinsberg, benjamin.tissoires
Cc: linux-input, linux-kernel, Osama Muhammad
This patch fixes the error checking in hid-wiimote-debug.c in
debugfs_create_file. The correct way to check if an error occurred
is 'IS_ERR' inline function.
Signed-off-by: Osama Muhammad <osmtendev@gmail.com>
---
drivers/hid/hid-wiimote-debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-wiimote-debug.c b/drivers/hid/hid-wiimote-debug.c
index a99dcca2e099..eddd981fee1a 100644
--- a/drivers/hid/hid-wiimote-debug.c
+++ b/drivers/hid/hid-wiimote-debug.c
@@ -183,12 +183,12 @@ int wiidebug_init(struct wiimote_data *wdata)
dbg->eeprom = debugfs_create_file("eeprom", S_IRUSR,
dbg->wdata->hdev->debug_dir, dbg, &wiidebug_eeprom_fops);
- if (!dbg->eeprom)
+ if (IS_ERR(dbg->eeprom))
goto err;
dbg->drm = debugfs_create_file("drm", S_IRUSR,
dbg->wdata->hdev->debug_dir, dbg, &wiidebug_drm_fops);
- if (!dbg->drm)
+ if (IS_ERR(dbg->drm))
goto err_drm;
spin_lock_irqsave(&wdata->state.lock, flags);
--
2.34.1
^ permalink raw reply related
* [dtor-input:next] BUILD SUCCESS 9284d3b9a3609db30a528947ec4e5178055cd268
From: kernel test robot @ 2023-05-23 16:33 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: INFO setup_repo_specs: /db/releases/20230524001904/lkp-src/repo/*/dtor-input
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 9284d3b9a3609db30a528947ec4e5178055cd268 Input: xpad - spelling fixes for "Xbox"
elapsed time: 918m
configs tested: 277
configs skipped: 35
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha buildonly-randconfig-r002-20230522 gcc
alpha buildonly-randconfig-r006-20230521 gcc
alpha defconfig gcc
alpha randconfig-r021-20230521 gcc
alpha randconfig-r022-20230521 gcc
alpha randconfig-r023-20230521 gcc
alpha randconfig-r023-20230523 gcc
alpha randconfig-r024-20230521 gcc
alpha randconfig-r025-20230521 gcc
alpha randconfig-r026-20230522 gcc
alpha randconfig-r026-20230523 gcc
alpha randconfig-r033-20230522 gcc
arc allyesconfig gcc
arc buildonly-randconfig-r001-20230522 gcc
arc buildonly-randconfig-r004-20230521 gcc
arc buildonly-randconfig-r004-20230522 gcc
arc defconfig gcc
arc randconfig-r006-20230523 gcc
arc randconfig-r013-20230521 gcc
arc randconfig-r015-20230523 gcc
arc randconfig-r016-20230522 gcc
arc randconfig-r023-20230521 gcc
arc randconfig-r023-20230522 gcc
arc randconfig-r024-20230523 gcc
arc randconfig-r034-20230522 gcc
arc randconfig-r035-20230521 gcc
arc randconfig-r036-20230521 gcc
arc randconfig-r043-20230521 gcc
arc randconfig-r043-20230522 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm randconfig-r015-20230521 clang
arm randconfig-r035-20230521 gcc
arm randconfig-r036-20230521 gcc
arm randconfig-r046-20230521 clang
arm randconfig-r046-20230522 gcc
arm64 allyesconfig gcc
arm64 buildonly-randconfig-r003-20230521 clang
arm64 defconfig gcc
arm64 randconfig-r005-20230522 gcc
arm64 randconfig-r006-20230522 gcc
arm64 randconfig-r034-20230522 gcc
csky buildonly-randconfig-r004-20230522 gcc
csky buildonly-randconfig-r006-20230522 gcc
csky defconfig gcc
csky randconfig-r001-20230521 gcc
csky randconfig-r011-20230522 gcc
csky randconfig-r015-20230521 gcc
csky randconfig-r022-20230522 gcc
csky randconfig-r024-20230522 gcc
csky randconfig-r026-20230521 gcc
hexagon randconfig-r001-20230522 clang
hexagon randconfig-r003-20230521 clang
hexagon randconfig-r011-20230523 clang
hexagon randconfig-r016-20230522 clang
hexagon randconfig-r041-20230521 clang
hexagon randconfig-r041-20230522 clang
hexagon randconfig-r045-20230521 clang
hexagon randconfig-r045-20230522 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230522 gcc
i386 randconfig-a002-20230522 gcc
i386 randconfig-a003-20230522 gcc
i386 randconfig-a004-20230522 gcc
i386 randconfig-a005-20230522 gcc
i386 randconfig-a006-20230522 gcc
i386 randconfig-a011-20230522 clang
i386 randconfig-a012-20230522 clang
i386 randconfig-a013-20230522 clang
i386 randconfig-a014-20230522 clang
i386 randconfig-a015-20230522 clang
i386 randconfig-a016-20230522 clang
i386 randconfig-i051-20230523 clang
i386 randconfig-i052-20230523 clang
i386 randconfig-i053-20230523 clang
i386 randconfig-i054-20230523 clang
i386 randconfig-i055-20230523 clang
i386 randconfig-i056-20230523 clang
i386 randconfig-i061-20230523 clang
i386 randconfig-i062-20230523 clang
i386 randconfig-i063-20230523 clang
i386 randconfig-i064-20230523 clang
i386 randconfig-i065-20230523 clang
i386 randconfig-i066-20230523 clang
i386 randconfig-r001-20230522 gcc
i386 randconfig-r011-20230522 clang
ia64 allmodconfig gcc
ia64 defconfig gcc
ia64 generic_defconfig gcc
ia64 randconfig-r003-20230522 gcc
ia64 randconfig-r006-20230521 gcc
ia64 randconfig-r015-20230522 gcc
ia64 randconfig-r022-20230523 gcc
ia64 randconfig-r023-20230521 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch buildonly-randconfig-r003-20230521 gcc
loongarch buildonly-randconfig-r005-20230522 gcc
loongarch defconfig gcc
loongarch randconfig-r002-20230521 gcc
loongarch randconfig-r003-20230521 gcc
loongarch randconfig-r004-20230521 gcc
loongarch randconfig-r014-20230522 gcc
loongarch randconfig-r022-20230521 gcc
loongarch randconfig-r032-20230521 gcc
loongarch randconfig-r033-20230522 gcc
m68k allmodconfig gcc
m68k buildonly-randconfig-r003-20230522 gcc
m68k bvme6000_defconfig gcc
m68k defconfig gcc
m68k m5407c3_defconfig gcc
m68k randconfig-r013-20230522 gcc
m68k randconfig-r024-20230522 gcc
m68k randconfig-r034-20230521 gcc
microblaze buildonly-randconfig-r001-20230521 gcc
microblaze buildonly-randconfig-r006-20230522 gcc
microblaze randconfig-r004-20230522 gcc
microblaze randconfig-r013-20230522 gcc
microblaze randconfig-r035-20230521 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips buildonly-randconfig-r006-20230521 gcc
mips decstation_64_defconfig gcc
mips randconfig-r001-20230521 gcc
mips randconfig-r006-20230521 gcc
mips randconfig-r012-20230521 clang
mips randconfig-r013-20230521 clang
mips randconfig-r016-20230521 clang
mips randconfig-r023-20230523 clang
nios2 buildonly-randconfig-r004-20230521 gcc
nios2 defconfig gcc
nios2 randconfig-r004-20230521 gcc
nios2 randconfig-r004-20230523 gcc
nios2 randconfig-r005-20230521 gcc
nios2 randconfig-r005-20230522 gcc
nios2 randconfig-r012-20230523 gcc
nios2 randconfig-r015-20230521 gcc
nios2 randconfig-r025-20230521 gcc
nios2 randconfig-r031-20230522 gcc
nios2 randconfig-r032-20230521 gcc
nios2 randconfig-r033-20230521 gcc
nios2 randconfig-r035-20230522 gcc
openrisc buildonly-randconfig-r001-20230522 gcc
openrisc or1ksim_defconfig gcc
openrisc randconfig-r021-20230523 gcc
openrisc randconfig-r031-20230522 gcc
openrisc randconfig-r034-20230521 gcc
parisc buildonly-randconfig-r001-20230522 gcc
parisc defconfig gcc
parisc randconfig-r014-20230522 gcc
parisc randconfig-r015-20230522 gcc
parisc randconfig-r016-20230523 gcc
parisc randconfig-r024-20230523 gcc
parisc randconfig-r026-20230521 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc buildonly-randconfig-r002-20230521 gcc
powerpc buildonly-randconfig-r002-20230522 clang
powerpc randconfig-r001-20230522 gcc
powerpc randconfig-r006-20230521 clang
powerpc randconfig-r011-20230521 gcc
powerpc randconfig-r013-20230522 clang
powerpc randconfig-r021-20230521 gcc
powerpc randconfig-r033-20230521 clang
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv defconfig gcc
riscv randconfig-r002-20230523 clang
riscv randconfig-r013-20230522 clang
riscv randconfig-r042-20230521 gcc
riscv randconfig-r042-20230522 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 buildonly-randconfig-r001-20230521 gcc
s390 buildonly-randconfig-r006-20230521 gcc
s390 defconfig gcc
s390 randconfig-r006-20230522 gcc
s390 randconfig-r014-20230522 clang
s390 randconfig-r016-20230521 gcc
s390 randconfig-r021-20230522 clang
s390 randconfig-r024-20230521 gcc
s390 randconfig-r025-20230523 gcc
s390 randconfig-r026-20230521 gcc
s390 randconfig-r034-20230522 gcc
s390 randconfig-r044-20230521 gcc
s390 randconfig-r044-20230522 clang
sh allmodconfig gcc
sh buildonly-randconfig-r002-20230521 gcc
sh ecovec24_defconfig gcc
sh edosk7705_defconfig gcc
sh hp6xx_defconfig gcc
sh randconfig-r002-20230521 gcc
sh randconfig-r002-20230522 gcc
sh randconfig-r025-20230522 gcc
sh secureedge5410_defconfig gcc
sparc buildonly-randconfig-r005-20230522 gcc
sparc defconfig gcc
sparc randconfig-r012-20230522 gcc
sparc randconfig-r014-20230521 gcc
sparc randconfig-r016-20230522 gcc
sparc randconfig-r022-20230521 gcc
sparc randconfig-r023-20230522 gcc
sparc randconfig-r026-20230522 gcc
sparc randconfig-r035-20230522 gcc
sparc randconfig-r036-20230522 gcc
sparc64 buildonly-randconfig-r003-20230522 gcc
sparc64 buildonly-randconfig-r005-20230521 gcc
sparc64 randconfig-r002-20230522 gcc
sparc64 randconfig-r005-20230521 gcc
sparc64 randconfig-r005-20230522 gcc
sparc64 randconfig-r011-20230521 gcc
sparc64 randconfig-r016-20230521 gcc
sparc64 randconfig-r031-20230521 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 buildonly-randconfig-r005-20230522 gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230522 gcc
x86_64 randconfig-a002-20230522 gcc
x86_64 randconfig-a003-20230522 gcc
x86_64 randconfig-a004-20230522 gcc
x86_64 randconfig-a005-20230522 gcc
x86_64 randconfig-a006-20230522 gcc
x86_64 randconfig-a011-20230522 clang
x86_64 randconfig-a012-20230522 clang
x86_64 randconfig-a013-20230522 clang
x86_64 randconfig-a014-20230522 clang
x86_64 randconfig-a015-20230522 clang
x86_64 randconfig-a016-20230522 clang
x86_64 randconfig-x051-20230522 clang
x86_64 randconfig-x052-20230522 clang
x86_64 randconfig-x053-20230522 clang
x86_64 randconfig-x054-20230522 clang
x86_64 randconfig-x055-20230522 clang
x86_64 randconfig-x056-20230522 clang
x86_64 randconfig-x061-20230522 clang
x86_64 randconfig-x062-20230522 clang
x86_64 randconfig-x063-20230522 clang
x86_64 randconfig-x064-20230522 clang
x86_64 randconfig-x065-20230522 clang
x86_64 randconfig-x066-20230522 clang
x86_64 randconfig-x071-20230522 gcc
x86_64 randconfig-x072-20230522 gcc
x86_64 randconfig-x073-20230522 gcc
x86_64 randconfig-x074-20230522 gcc
x86_64 randconfig-x075-20230522 gcc
x86_64 randconfig-x076-20230522 gcc
x86_64 randconfig-x081-20230522 gcc
x86_64 randconfig-x082-20230522 gcc
x86_64 randconfig-x083-20230522 gcc
x86_64 randconfig-x084-20230522 gcc
x86_64 randconfig-x085-20230522 gcc
x86_64 randconfig-x086-20230522 gcc
x86_64 randconfig-x091-20230523 gcc
x86_64 randconfig-x092-20230523 gcc
x86_64 randconfig-x093-20230523 gcc
x86_64 randconfig-x094-20230523 gcc
x86_64 randconfig-x095-20230523 gcc
x86_64 randconfig-x096-20230523 gcc
x86_64 rhel-8.3 gcc
xtensa randconfig-r002-20230522 gcc
xtensa randconfig-r003-20230522 gcc
xtensa randconfig-r004-20230521 gcc
xtensa randconfig-r004-20230522 gcc
xtensa randconfig-r012-20230522 gcc
xtensa randconfig-r014-20230521 gcc
xtensa randconfig-r025-20230523 gcc
xtensa randconfig-r026-20230523 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* Re: [PATCH v4 0/2] Fix Goodix touchscreen power leakage for MT8186 boards
From: Fei Shao @ 2023-05-23 15:29 UTC (permalink / raw)
To: Doug Anderson
Cc: Jiri Kosina, Jeff LaBundy, Benjamin Tissoires, Rob Herring,
linux-mediatek, Dmitry Torokhov, Krzysztof Kozlowski,
Matthias Kaehlcke, Stephen Kitt, devicetree, linux-input,
linux-kernel
In-Reply-To: <CAD=FV=UyEw5xViGreQb6+cLNLrMcT27ts5P87aR=FEYWNOBM_w@mail.gmail.com>
On Tue, May 23, 2023 at 9:32 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Tue, May 23, 2023 at 6:11 AM Jiri Kosina <jikos@kernel.org> wrote:
> >
> > On Fri, 19 May 2023, Doug Anderson wrote:
> >
> > > > These changes are based on the series in [1], which modified the
> > > > i2c-hid-of-goodix driver and removed the workaround for a power leakage
> > > > issue, so the issue revisits on Mediatek MT8186 boards (Steelix).
> > > >
> > > > The root cause is that the touchscreen can be powered in different ways
> > > > depending on the hardware designs, and it's not as easy to come up with
> > > > a solution that is both simple and elegant for all the known designs.
> > > >
> > > > To address the issue, I ended up adding a new boolean property for the
> > > > driver so that we can control the power up/down sequence depending on
> > > > that.
> > > >
> > > > Adding a new property might not be the cleanest approach for this, but
> > > > at least the intention would be easy enough to understand, and it
> > > > introduces relatively small change to the code and fully preserves the
> > > > original control flow.
> > > > I hope this is something acceptable, and I'm open to any better
> > > > approaches.
> > > >
> > > > [1] https://lore.kernel.org/all/20230207024816.525938-1-dianders@chromium.org/
> > > >
> > > > Changes in v4:
> > > > - Minor coding style improvement
> > > >
> > > > Changes in v3:
> > > > - In power-down, only skip the GPIO but not the regulator calls if the
> > > > flag is set
> > > >
> > > > Changes in v2:
> > > > - Use a more accurate property name and with "goodix," prefix.
> > > > - Do not change the regulator_enable logic during power-up.
> > > >
> > > > Fei Shao (2):
> > > > dt-bindings: input: goodix: Add "goodix,no-reset-during-suspend"
> > > > property
> > > > HID: i2c-hid: goodix: Add support for "goodix,no-reset-during-suspend"
> > > > property
> > > >
> > > > .../bindings/input/goodix,gt7375p.yaml | 9 +++++++++
> > > > drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 16 +++++++++++++++-
> > > > 2 files changed, 24 insertions(+), 1 deletion(-)
> > >
> > > Just double-checking if there is any work needed on this series. I
> > > think it's ready to land but I wanted to double-check.
> >
> > I don't think I've been CCed on the dt-binding part (patch 1/2 I guess).
> > Has it been Acked? If so, I will happily take it through hid.git, but
> > please send it my way.
>
> Yeah, Rob Acked it:
>
> https://lore.kernel.org/r/168261692866.3205353.5077242811275926416.robh@kernel.org/
>
> Fei: can you repost the series with collected tags and make sure to CC Jiri?
Sure, I'll do that tomorrow :)
Regards,
Fei
>
> Thanks!
>
> -Doug
^ permalink raw reply
* [PATCH] [resend] Input: gpio-keys - Use input_report_key()
From: Geert Uytterhoeven @ 2023-05-23 15:13 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Geert Uytterhoeven
Use the input_report_key() helper instead of open-coding the same
operation.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/input/keyboard/gpio_keys.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 5e18ef01b0340f1b..7e8342ef7a79b17f 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -456,7 +456,7 @@ static enum hrtimer_restart gpio_keys_irq_timer(struct hrtimer *t)
struct input_dev *input = bdata->input;
if (bdata->key_pressed) {
- input_event(input, EV_KEY, *bdata->code, 0);
+ input_report_key(input, *bdata->code, 0);
input_sync(input);
bdata->key_pressed = false;
}
@@ -478,11 +478,11 @@ static irqreturn_t gpio_keys_irq_isr(int irq, void *dev_id)
if (bdata->button->wakeup)
pm_wakeup_event(bdata->input->dev.parent, 0);
- input_event(input, EV_KEY, *bdata->code, 1);
+ input_report_key(input, *bdata->code, 1);
input_sync(input);
if (!bdata->release_delay) {
- input_event(input, EV_KEY, *bdata->code, 0);
+ input_report_key(input, *bdata->code, 0);
input_sync(input);
goto out;
}
--
2.34.1
^ permalink raw reply related
* [PATCH resend] Input: gpio-keys - convert to dev_err_probe()
From: Geert Uytterhoeven @ 2023-05-23 15:13 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Geert Uytterhoeven
Use the dev_err_probe() helper, instead of open-coding the same
operation.
While at it, invert the error checking logic to simplify code flow.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/input/keyboard/gpio_keys.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 93b75d78a9cb882f..5e18ef01b0340f1b 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -523,18 +523,15 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
NULL, GPIOD_IN, desc);
if (IS_ERR(bdata->gpiod)) {
error = PTR_ERR(bdata->gpiod);
- if (error == -ENOENT) {
- /*
- * GPIO is optional, we may be dealing with
- * purely interrupt-driven setup.
- */
- bdata->gpiod = NULL;
- } else {
- if (error != -EPROBE_DEFER)
- dev_err(dev, "failed to get gpio: %d\n",
- error);
- return error;
- }
+ if (error != -ENOENT)
+ return dev_err_probe(dev, error,
+ "failed to get gpio\n");
+
+ /*
+ * GPIO is optional, we may be dealing with
+ * purely interrupt-driven setup.
+ */
+ bdata->gpiod = NULL;
}
} else if (gpio_is_valid(button->gpio)) {
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v2] HID: uclogic: Modular KUnit tests should not depend on KUNIT=y
From: Geert Uytterhoeven @ 2023-05-23 15:10 UTC (permalink / raw)
To: Jiri Kosina, Dmitry Torokhov, Benjamin Tissoires,
José Expósito, Brendan Higgins, David Gow,
Daniel Latypov
Cc: linux-input, linux-kselftest, kunit-dev, Geert Uytterhoeven
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: 08809e482a1c44d9 ("HID: uclogic: KUnit best practices and naming conventions")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: David Gow <davidgow@google.com>
Reviewed-by: José Expósito <jose.exposito89@gmail.com>
---
v2:
- Add Reviewed-by.
---
drivers/hid/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 4ce012f83253ec9f..b977450cac75265d 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1285,7 +1285,7 @@ config HID_MCP2221
config HID_KUNIT_TEST
tristate "KUnit tests for HID" if !KUNIT_ALL_TESTS
- depends on KUNIT=y
+ depends on KUNIT
depends on HID_BATTERY_STRENGTH
depends on HID_UCLOGIC
default KUNIT_ALL_TESTS
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 0/5] cleanups to amd-sfh
From: Jiri Kosina @ 2023-05-23 13:59 UTC (permalink / raw)
To: Basavaraj Natikar; +Cc: benjamin.tissoires, linux-input
In-Reply-To: <20230509065857.4170013-1-Basavaraj.Natikar@amd.com>
On Tue, 9 May 2023, Basavaraj Natikar wrote:
> Changes of code cleanup includes duplicate log removal, cleanup
> sequence and spliting into multiple functional blocks.
>
> Basavaraj Natikar (5):
> HID: amd_sfh: Remove unnecessary log
> HID: amd_sfh: Remove duplicate cleanup
> HID: amd_sfh: Split sensor and HID initialization
> HID: amd_sfh: Remove duplicate cleanup for SFH1.1
> HID: amd_sfh: Split sensor and HID initialization for SFH1.1
>
> drivers/hid/amd-sfh-hid/amd_sfh_client.c | 47 ++++++-------------
> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 24 +++-------
> 2 files changed, 20 insertions(+), 51 deletions(-)
Now queued in hid.git#for-6.5/amd-sfh.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: ensure timely release of driver-allocated resources
From: Jiri Kosina @ 2023-05-23 13:57 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, Stephen Boyd, linux-input, linux-kernel
In-Reply-To: <ZFWarGkRAfPOmI6E@google.com>
On Fri, 5 May 2023, Dmitry Torokhov wrote:
> More and more drivers rely on devres to manage their resources, however
> if bus' probe() and release() methods are not trivial and control some
> of resources as well (for example enable or disable clocks, or attach
> device to a power domain), we need to make sure that driver-allocated
> resources are released immediately after driver's remove() method
> returns, and not postponed until driver core gets around to releasing
> resources.
>
> In case of HID we should not try to close the report and release
> associated memory until after all devres callbacks are executed. To fix
> that we open a new devres group before calling driver's probe() and
> explicitly release it when we return from driver's remove().
>
> This is similar to what we did for I2C bus in commit 5b5475826c52 ("i2c:
> ensure timely release of driver-allocated resources"). It is tempting to
> try and move this into driver core, but actually doing so is challenging,
> we need to split bus' remove() method into pre- and post-remove methods,
> which would make the logic even less clear.
>
> Reported-by: Stephen Boyd <swboyd@chromium.org>
> Link: https://lore.kernel.org/r/20230505232417.1377393-1-swboyd@chromium.org
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/hid/hid-core.c | 55 ++++++++++++++++++++++++++++--------------
> include/linux/hid.h | 1 +
> 2 files changed, 38 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index c4ac9081194c..02a43bba9091 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2602,35 +2602,29 @@ static bool hid_device_check_match(struct hid_device *hdev,
> return !hid_ignore_special_drivers;
> }
>
> -static int hid_device_probe(struct device *dev)
> +static int __hid_device_probe(struct hid_device *hdev)
> {
> - struct hid_driver *hdrv = to_hid_driver(dev->driver);
> - struct hid_device *hdev = to_hid_device(dev);
> + struct hid_driver *hdrv = to_hid_driver(hdev->dev.driver);
> const struct hid_device_id *id;
> int ret;
>
> - if (down_interruptible(&hdev->driver_input_lock)) {
> - ret = -EINTR;
> - goto end;
> - }
> hdev->io_started = false;
> -
> clear_bit(ffs(HID_STAT_REPROBED), &hdev->status);
>
> - if (hdev->driver) {
> - ret = 0;
> - goto unlock;
> - }
> + if (hdev->driver)
> + return 0;
>
> - if (!hid_device_check_match(hdev, hdrv, &id)) {
> - ret = -ENODEV;
> - goto unlock;
> - }
Dmitry, which tree is this patch against, please? The code above looks
different in current tree (and hasn't been touched for a while).
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 0/2] Fix Goodix touchscreen power leakage for MT8186 boards
From: Doug Anderson @ 2023-05-23 13:32 UTC (permalink / raw)
To: Jiri Kosina
Cc: Fei Shao, Jeff LaBundy, Benjamin Tissoires, Rob Herring,
linux-mediatek, Dmitry Torokhov, Krzysztof Kozlowski,
Matthias Kaehlcke, Stephen Kitt, devicetree, linux-input,
linux-kernel
In-Reply-To: <nycvar.YFH.7.76.2305231510270.29760@cbobk.fhfr.pm>
Hi,
On Tue, May 23, 2023 at 6:11 AM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Fri, 19 May 2023, Doug Anderson wrote:
>
> > > These changes are based on the series in [1], which modified the
> > > i2c-hid-of-goodix driver and removed the workaround for a power leakage
> > > issue, so the issue revisits on Mediatek MT8186 boards (Steelix).
> > >
> > > The root cause is that the touchscreen can be powered in different ways
> > > depending on the hardware designs, and it's not as easy to come up with
> > > a solution that is both simple and elegant for all the known designs.
> > >
> > > To address the issue, I ended up adding a new boolean property for the
> > > driver so that we can control the power up/down sequence depending on
> > > that.
> > >
> > > Adding a new property might not be the cleanest approach for this, but
> > > at least the intention would be easy enough to understand, and it
> > > introduces relatively small change to the code and fully preserves the
> > > original control flow.
> > > I hope this is something acceptable, and I'm open to any better
> > > approaches.
> > >
> > > [1] https://lore.kernel.org/all/20230207024816.525938-1-dianders@chromium.org/
> > >
> > > Changes in v4:
> > > - Minor coding style improvement
> > >
> > > Changes in v3:
> > > - In power-down, only skip the GPIO but not the regulator calls if the
> > > flag is set
> > >
> > > Changes in v2:
> > > - Use a more accurate property name and with "goodix," prefix.
> > > - Do not change the regulator_enable logic during power-up.
> > >
> > > Fei Shao (2):
> > > dt-bindings: input: goodix: Add "goodix,no-reset-during-suspend"
> > > property
> > > HID: i2c-hid: goodix: Add support for "goodix,no-reset-during-suspend"
> > > property
> > >
> > > .../bindings/input/goodix,gt7375p.yaml | 9 +++++++++
> > > drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 16 +++++++++++++++-
> > > 2 files changed, 24 insertions(+), 1 deletion(-)
> >
> > Just double-checking if there is any work needed on this series. I
> > think it's ready to land but I wanted to double-check.
>
> I don't think I've been CCed on the dt-binding part (patch 1/2 I guess).
> Has it been Acked? If so, I will happily take it through hid.git, but
> please send it my way.
Yeah, Rob Acked it:
https://lore.kernel.org/r/168261692866.3205353.5077242811275926416.robh@kernel.org/
Fei: can you repost the series with collected tags and make sure to CC Jiri?
Thanks!
-Doug
^ permalink raw reply
* Re: [PATCH 1/3] HID: asus: Add support for ASUS ROG Z13 keyboard
From: Jiri Kosina @ 2023-05-23 13:17 UTC (permalink / raw)
To: Luke D. Jones; +Cc: linux-input, benjamin.tissoires, rydberg, linux-kernel
In-Reply-To: <20230503034711.253439-1-luke@ljones.dev>
On Wed, 3 May 2023, Luke D. Jones wrote:
> Add support for the ROG Z13 keyboard. This is a variant of the last
> few ASUS ROG keyboards and has much of the same functionality.
>
> Signed-off-by: Luke D. Jones <luke@ljones.dev>
Applied, thanks Luke.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: wacom: Added error check
From: Jiri Kosina @ 2023-05-23 13:12 UTC (permalink / raw)
To: Denis Arefev
Cc: Ping Cheng, Jason Gerecke, Benjamin Tissoires, linux-input,
linux-kernel, lvc-project, trufanov, vfh
In-Reply-To: <20230427114745.53136-1-arefev@swemel.ru>
On Thu, 27 Apr 2023, Denis Arefev wrote:
> Added a variable check and
> transition in case of an error
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 0/2] Fix Goodix touchscreen power leakage for MT8186 boards
From: Jiri Kosina @ 2023-05-23 13:11 UTC (permalink / raw)
To: Doug Anderson
Cc: Fei Shao, Jeff LaBundy, Benjamin Tissoires, Rob Herring,
linux-mediatek, Dmitry Torokhov, Krzysztof Kozlowski,
Matthias Kaehlcke, Stephen Kitt, devicetree, linux-input,
linux-kernel
In-Reply-To: <CAD=FV=XVubT-ozs7JssBPz+9UcsZb+q0My8Aq6HNs-nFiJnogg@mail.gmail.com>
On Fri, 19 May 2023, Doug Anderson wrote:
> > These changes are based on the series in [1], which modified the
> > i2c-hid-of-goodix driver and removed the workaround for a power leakage
> > issue, so the issue revisits on Mediatek MT8186 boards (Steelix).
> >
> > The root cause is that the touchscreen can be powered in different ways
> > depending on the hardware designs, and it's not as easy to come up with
> > a solution that is both simple and elegant for all the known designs.
> >
> > To address the issue, I ended up adding a new boolean property for the
> > driver so that we can control the power up/down sequence depending on
> > that.
> >
> > Adding a new property might not be the cleanest approach for this, but
> > at least the intention would be easy enough to understand, and it
> > introduces relatively small change to the code and fully preserves the
> > original control flow.
> > I hope this is something acceptable, and I'm open to any better
> > approaches.
> >
> > [1] https://lore.kernel.org/all/20230207024816.525938-1-dianders@chromium.org/
> >
> > Changes in v4:
> > - Minor coding style improvement
> >
> > Changes in v3:
> > - In power-down, only skip the GPIO but not the regulator calls if the
> > flag is set
> >
> > Changes in v2:
> > - Use a more accurate property name and with "goodix," prefix.
> > - Do not change the regulator_enable logic during power-up.
> >
> > Fei Shao (2):
> > dt-bindings: input: goodix: Add "goodix,no-reset-during-suspend"
> > property
> > HID: i2c-hid: goodix: Add support for "goodix,no-reset-during-suspend"
> > property
> >
> > .../bindings/input/goodix,gt7375p.yaml | 9 +++++++++
> > drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 16 +++++++++++++++-
> > 2 files changed, 24 insertions(+), 1 deletion(-)
>
> Just double-checking if there is any work needed on this series. I
> think it's ready to land but I wanted to double-check.
I don't think I've been CCed on the dt-binding part (patch 1/2 I guess).
Has it been Acked? If so, I will happily take it through hid.git, but
please send it my way.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: google: add jewel USB id
From: Jiri Kosina @ 2023-05-23 13:09 UTC (permalink / raw)
To: Sung-Chi Li; +Cc: LKML, phoenixshen, chentsung, Benjamin Tissoires, linux-input
In-Reply-To: <20230424023736.338464-1-lschyi@chromium.org>
On Mon, 24 Apr 2023, Sung-Chi Li wrote:
> Add 1 additional hammer-like device.
>
> Signed-off-by: Sung-Chi Li <lschyi@chromium.org>
> ---
>
> drivers/hid/hid-google-hammer.c | 2 ++
> drivers/hid/hid-ids.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
> index 7ae5f27df54d..c6bdb9c4ef3e 100644
> --- a/drivers/hid/hid-google-hammer.c
> +++ b/drivers/hid/hid-google-hammer.c
> @@ -586,6 +586,8 @@ static const struct hid_device_id hammer_devices[] = {
> USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_EEL) },
> { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
> USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER) },
> + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
> + USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_JEWEL) },
> { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
> USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_MAGNEMITE) },
> { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index c2e9b6d1fd7d..c40cd6f1095f 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -528,6 +528,7 @@
> #define USB_DEVICE_ID_GOOGLE_MOONBALL 0x5044
> #define USB_DEVICE_ID_GOOGLE_DON 0x5050
> #define USB_DEVICE_ID_GOOGLE_EEL 0x5057
> +#define USB_DEVICE_ID_GOOGLE_JEWEL 0x5061
Applied. Apologies for the delay.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: wacom: avoid integer overflow in wacom_intuos_inout()
From: Jiri Kosina @ 2023-05-23 13:08 UTC (permalink / raw)
To: Nikita Zhandarovich
Cc: Ping Cheng, Jason Gerecke, Benjamin Tissoires, linux-input,
linux-kernel, lvc-project
In-Reply-To: <20230417160148.60011-1-n.zhandarovich@fintech.ru>
On Mon, 17 Apr 2023, Nikita Zhandarovich wrote:
> If high bit is set to 1 in ((data[3] & 0x0f << 28), after all arithmetic
> operations and integer promotions are done, high bits in
> wacom->serial[idx] will be filled with 1s as well.
> Avoid this, albeit unlikely, issue by specifying left operand's __u64
> type for the right operand.
>
> Found by Linux Verification Center (linuxtesting.org) with static
> analysis tool SVACE.
>
> Fixes: 3bea733ab212 ("USB: wacom tablet driver reorganization")
> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Applied. Thanks for the fix, and sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: wacom: Check for string overflow from strscpy calls
From: Jiri Kosina @ 2023-05-23 13:07 UTC (permalink / raw)
To: Jason Gerecke
Cc: linux-input, Benjamin Tissoires, Ping Cheng,
Aaron Armstrong Skomra, Joshua Dickens, Jason Gerecke, Ping Cheng
In-Reply-To: <20230414182210.383218-1-jason.gerecke@wacom.com>
On Fri, 14 Apr 2023, Jason Gerecke wrote:
> From: Jason Gerecke <killertofu@gmail.com>
>
> The strscpy function is able to return an error code when a copy would
> overflow the size of the destination. The copy is stopped and the buffer
> terminated before overflow actually occurs so it is safe to continue
> execution, but we should still produce a warning should this occur.
>
> Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
> Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Now applied, sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [regression] Since kernel 6.3.1 logitech unify receiver not working properly
From: Jiri Kosina @ 2023-05-23 12:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux regressions mailing list, Benjamin Tissoires, Bagas Sanjaya,
Filipe Laíns, Bastien Nocera, open list:HID CORE LAYER, LKML,
guy.b
In-Reply-To: <CAHk-=whvhkSk6m8_AidhofgR9nq0Md+HbNad5r1RE69tZgbv6Q@mail.gmail.com>
On Mon, 22 May 2023, Linus Torvalds wrote:
> > FWIW, in case anybody is interested in a status update: one reporter
> > bisected the problem down to 586e8fede79 ("HID: logitech-hidpp: Retry
> > commands when device is busy"); reverting that commit on-top of 6.3
> > fixes the problem for that reporter. For that reporter things also work
> > on 6.4-rc; but for someone else that is affected that's not the case.
FWIW, I was pretty much away for past few weeks as well, same as Benjamin
as Bastien. Which is unfortunate timing, but that's how things pan out
sometimes.
> Hmm. It's likely timing-dependent.
>
> But that code is clearly buggy.
>
> If the wait_event_timeout() returns early, the device hasn't replied,
> but the code does
>
> if (!wait_event_timeout(hidpp->wait, hidpp->answer_available,
> 5*HZ)) {
> dbg_hid("%s:timeout waiting for response\n", __func__);
> memset(response, 0, sizeof(struct hidpp_report));
> ret = -ETIMEDOUT;
> }
>
> and then continues to look at the response _anyway_.
Yeah; we are zeroing it out, but that doesn't really make things any
better in principle, given all the dereferences later.
The issue seems to be existing ever since 2f31c52529 ("HID: Introduce
hidpp, a module to handle Logitech hid++ devices") when this whole driver
was introduced, as far as I can tell.
> Now, depending on out hardening options, that response may have been
> initialized by the compiler, or may just be random stack contents.
Again, as in case of timeout the buffer is just zeroed out, I'd just much
more expect NULL pointer dereference in such case. Which is not what we
are seeing here.
> That bug is pre-existing (ie the problem was not introduced by that
> commit), but who knows if the retry makes things worse (ie if it then
> triggers on a retry, the response data will be the *previous* response).
>
> The whole "goto exit" games should be removed too, because we're in a
> for-loop, and instead of "goto exit" it should just do "break".
>
> IOW, something like this might be worth testing.
>
> That said, while I think the code is buggy, I doubt this is the actual
> cause of the problem people are reporting. But it would be lovely to
> hear if the attached patch makes any difference, and I think this is
> fixing a real - but unlikely - problem anyway.
>
> And obviously it might be helpful to actually enable those dbg_hid()
> messages, but I didn't look at what the magic config option to do so
> was.
dbg_hid() is just pr_debug(), which means that on kernels with
CONFIG_DYNAMIC_DEBUG, this makes use of the dynamic debug facility;
otherwsie it just becomes printk(KERN_DEBUG...).
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* We are looking for resellers to cooperate
From: Oliver Brown @ 2023-05-23 8:10 UTC (permalink / raw)
To: linux-input
Hello!
Have you been wondering what solution can help you effectively build new sales networks?
Knowing the market and your industry well, we know how difficult it is to stay ahead of the competition and generate higher profits at the same time.
That is why we would like to offer you the opportunity to cooperate as resellers of one of the best auditing applications, thanks to which you can expand your portfolio of clients and build new markets.
This cloud and mobile solution enjoys high market interest, which makes it an ideal tool for building an additional or basic business.
Let me know if you are open to talking about potential cooperation.
Regards
Oliver Brown
^ permalink raw reply
* Re: [PATCH v2] xpad: Spelling fixes for "Xbox", improve and proofread the listed xpad device names
From: Dmitry Torokhov @ 2023-05-23 0:29 UTC (permalink / raw)
To: Ismael Ferreras Morezuelas
Cc: Jonathan Corbet, linux-input, linux-doc, linux-kernel,
Cameron Gutman, Marcos Alano
In-Reply-To: <401b1d94-1348-15fd-b48f-a80e8885c7a4@gmail.com>
On Wed, Jan 05, 2022 at 12:30:20AM +0100, Ismael Ferreras Morezuelas wrote:
> The Linux kernel is notorious for misspelling X-Box, X-box, XBox or XBOX;
> the official spelling is actually just Xbox. Plain and simple.
>
> Tried to respect the existing notes but still following the style guide.
> No functional changes intended. This only affects ancillary parts.
>
> Sounds trivial, but this makes it easier to search the correct
> entries in xmenu by name. It has always been a pet peeve of mine.
>
> Signed-off-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
> ---
Adjusted the patch description a little to remove mention searching by
name (since user-visible names are not touched), and applied.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] Input: tests: add test to cover all input_grab_device() function
From: Dmitry Torokhov @ 2023-05-23 0:00 UTC (permalink / raw)
To: Dana Elfassy; +Cc: eballetb, javierm, linux-input, linux-kernel, Dana Elfassy
In-Reply-To: <20230522215514.722564-1-dangel101@gmail.com>
On Tue, May 23, 2023 at 12:55:14AM +0300, Dana Elfassy wrote:
> Currently input_grab_device() isn't covered by any tests
> Thus, adding a test to cover the cases:
> 1. The device is grabbed successfully
> 2. Trying to grab a device that is already grabbed by another input
> handle
>
> Signed-off-by: Dana Elfassy <dangel101@gmail.com>
> Tested-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> Changes in v3:
> 1. Retrieve test_handle variable to try and grab the device that's
> currently grabbed by another handle
> 2. Add verification that test_handle can indeed grab the device after
> it's released by the handle that grabbed it
> 3. Remove duplicated call for input_grab_device() in KUNIT_ASSERT_TRUE()
> functions
> Changes in v2:
> - Use input_put_device() to decrement the refcount increased by get().
> - Remove unnecessary struct input_handle test_handle variable.
>
> drivers/input/tests/input_test.c | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/input/tests/input_test.c b/drivers/input/tests/input_test.c
> index 25bbf51b5c87..1939cc12bae0 100644
> --- a/drivers/input/tests/input_test.c
> +++ b/drivers/input/tests/input_test.c
> @@ -124,10 +124,42 @@ static void input_test_match_device_id(struct kunit *test)
> KUNIT_ASSERT_FALSE(test, input_match_device_id(input_dev, &id));
> }
>
> +static void input_test_grab(struct kunit *test)
> +{
> + struct input_dev *input_dev = test->priv;
> + struct input_handle test_handle;
> + struct input_handler handler;
> + struct input_handle handle;
> + struct input_device_id id;
> + int res;
> +
> + handler.name = "handler";
> + handler.id_table = &id;
> +
> + handle.dev = input_get_device(input_dev);
> + handle.name = dev_name(&input_dev->dev);
> + handle.handler = &handler;
> + res = input_grab_device(&handle);
> + KUNIT_ASSERT_TRUE(test, res == 0);
Could you please tell me why you are using KUNIT_ASSERT_TRUE() here but
KUNIT_ASSERT_EQ() below?
> +
> + test_handle.dev = input_get_device(input_dev);
> + test_handle.name = dev_name(&input_dev->dev);
> + test_handle.handler = &handler;
> + res = input_grab_device(&test_handle);
> + KUNIT_ASSERT_EQ(test, res, -EBUSY);
> +
> + input_release_device(&handle);
> + input_put_device(input_dev);
> + res = input_grab_device(&test_handle);
> + KUNIT_ASSERT_TRUE(test, res == 0);
> + input_put_device(input_dev);
> +}
> +
> static struct kunit_case input_tests[] = {
> KUNIT_CASE(input_test_polling),
> KUNIT_CASE(input_test_timestamp),
> KUNIT_CASE(input_test_match_device_id),
> + KUNIT_CASE(input_test_grab),
> { /* sentinel */ }
> };
>
> --
> 2.40.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: ensure timely release of driver-allocated resources
From: Dmitry Torokhov @ 2023-05-22 23:30 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: Stephen Boyd, linux-input, linux-kernel
In-Reply-To: <ZFaeiwBp+5hUXk/j@google.com>
On Sat, May 06, 2023 at 11:38:03AM -0700, Dmitry Torokhov wrote:
> On Fri, May 05, 2023 at 05:09:16PM -0700, Dmitry Torokhov wrote:
> > + if (down_interruptible(&hdev->driver_input_lock))
> > + return -EINTR;
> > +
> > + ret = __hid_device_probe(hdev);
>
> There is an extra space snuck in before "ret", let me know if you want
> me to repost it (or if there are bigger concerns).
Gentle ping on this one...
--
Dmitry
^ permalink raw reply
* RE: [PATCH] Input: synaptics-rmi4 - retry reading SMBus version on resume
From: Andrew Duggan @ 2023-05-22 23:07 UTC (permalink / raw)
To: Jeffery Miller, Dmitry Torokhov
Cc: Andrew Duggan, Jonathan Denose, jdenose@google.com, Lyude Paul,
loic.poulain@linaro.org, benjamin.tissoires@redhat.com,
Jonathan Cameron, Maximilian Luz, Miguel Ojeda,
Uwe Kleine-König, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Vincent Huang
In-Reply-To: <CAAzPG9PpP4_hUxmpYmTGQmH7qd5AbgEBv1fDcE_sYJNnYn=bgA@mail.gmail.com>
> From: Jeffery Miller <jefferymiller@google.com>
> Sent: Friday, May 12, 2023 12:37
> To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Andrew Duggan <andrew@duggan.us>; Jonathan Denose
> <jdenose@chromium.org>; jdenose@google.com; Lyude Paul
> <lyude@redhat.com>; loic.poulain@linaro.org;
> benjamin.tissoires@redhat.com; Andrew Duggan
> <aduggan@synaptics.com>; Jonathan Cameron
> <Jonathan.Cameron@huawei.com>; Maximilian Luz
> <luzmaximilian@gmail.com>; Miguel Ojeda <ojeda@kernel.org>; Uwe Kleine-
> König <u.kleine-koenig@pengutronix.de>; linux-input@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Input: synaptics-rmi4 - retry reading SMBus version on
> resume
>
> CAUTION: Email originated externally, do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
> On Wed, May 10, 2023 at 3:06 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> >
> > I am not really fond of adding random repeats in the code base.
> > Andrew, do you know if the Synaptics device needs certain delay when
> > switching to SMbus mode?
> >
> That's reasonable. It's true this is a sleep to workaround rmi_smbus'
> expectation that
> it is able to successfully read from the i801 i2c smbus addr 0x2c on resume
> when it cannot.
>
> I do not know why the i801 i2c addr 0x2c is not responding on resume.
> Infrequently it won't respond on boot during the initial
> psmouse_smbus_create_companion but that is less noticeable since it will
> stay in ps/2 mode and just lack features.
>
> I do know adding a sleep in-between the psmouse deactivate call and
> rmi_smbus's attempts to read from the 0x2c addr allow it to succeed on this
> machine. I do not know the details as to why however.
Our Windows driver does a 30 ms delay between sending the disable command and trying to communicate over SMBus. I don’t know specifically why this delay is needed, but this is how we handle this case.
>
> I can apply workarounds until the underlying issue can be identified and
> properly resolved.
>
> I can apply patches and provide any sort of debugging or extra information
> that might be useful to anyone familiar with these devices.
>
> The smbus controller in this particular machine is:
> 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family
> SMBus Controller [8086:8c22] (rev 04)
>
> Perhaps there's some way to detect when the addr is available later and have
> it trigger a new probe similar to how psmouse_smbus_notifier is triggered
> when the i801 bus becomes available?
>
> Thank You,
> Jeff
Andrew
^ permalink raw reply
* Re: [PATCH v5 16/44] Input: gameport: add ISA and HAS_IOPORT dependencies
From: Dmitry Torokhov @ 2023-05-22 22:16 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Greg Kroah-Hartman, Bjorn Helgaas,
Uwe Kleine-König, Mauro Carvalho Chehab, Alan Stern,
Rafael J. Wysocki, Geert Uytterhoeven, Paul Walmsley,
Palmer Dabbelt, Albert Ou, linux-kernel, linux-arch, linux-pci,
Arnd Bergmann, linux-input
In-Reply-To: <20230522105049.1467313-17-schnelle@linux.ibm.com>
Hi Niklas,
On Mon, May 22, 2023 at 12:50:21PM +0200, Niklas Schnelle wrote:
> diff --git a/include/linux/gameport.h b/include/linux/gameport.h
> index 8c2f00018e89..4d5720022b63 100644
> --- a/include/linux/gameport.h
> +++ b/include/linux/gameport.h
> @@ -167,16 +167,21 @@ static inline void gameport_trigger(struct gameport *gameport)
> {
> if (gameport->trigger)
> gameport->trigger(gameport);
> +#ifdef CONFIG_HAS_IOPORT
> else
> outb(0xff, gameport->io);
> +#endif
Contrary to the cover letter, this is still kind-of runtime detection
(i.e. broken drivers will silently stop working), we need to have
dev_err[_ratelimited?] here and below.
I also just posted a patch reworking this a bit so this and the chunk
below can be hidden in gameport.c.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: gameport - provide default trigger() and read()
From: Dmitry Torokhov @ 2023-05-22 22:11 UTC (permalink / raw)
To: linux-input; +Cc: Arnd Bergmann, Niklas Schnelle, linux-kernel
Instead of constantly checking pointer(s) for non-NULL-ness provide
default implementations of trigger() and read() and instantiate them during
pore registration if driver-specific versions were not provided.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/gameport/gameport.c | 17 ++++++++++++++++-
include/linux/gameport.h | 11 ++---------
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/input/gameport/gameport.c b/drivers/input/gameport/gameport.c
index db58a01b23d3..26e197942ff9 100644
--- a/drivers/input/gameport/gameport.c
+++ b/drivers/input/gameport/gameport.c
@@ -21,7 +21,7 @@
#include <linux/mutex.h>
#include <linux/timekeeping.h>
-/*#include <asm/io.h>*/
+#include <asm/io.h>
MODULE_AUTHOR("Vojtech Pavlik <vojtech@ucw.cz>");
MODULE_DESCRIPTION("Generic gameport layer");
@@ -518,6 +518,16 @@ void gameport_set_phys(struct gameport *gameport, const char *fmt, ...)
}
EXPORT_SYMBOL(gameport_set_phys);
+static void gameport_default_trigger(struct gameport *gameport)
+{
+ outb(0xff, gameport->io);
+}
+
+static unsigned char gameport_default_read(struct gameport *gameport)
+{
+ return inb(gameport->io);
+}
+
/*
* Prepare gameport port for registration.
*/
@@ -536,6 +546,11 @@ static void gameport_init_port(struct gameport *gameport)
if (gameport->parent)
gameport->dev.parent = &gameport->parent->dev;
+ if (!gameport->trigger)
+ gameport->trigger = gameport_default_trigger;
+ if (!gameport->read)
+ gameport->read = gameport_default_read;
+
INIT_LIST_HEAD(&gameport->node);
spin_lock_init(&gameport->timer_lock);
timer_setup(&gameport->poll_timer, gameport_run_poll_handler, 0);
diff --git a/include/linux/gameport.h b/include/linux/gameport.h
index 8c2f00018e89..0a221e768ea4 100644
--- a/include/linux/gameport.h
+++ b/include/linux/gameport.h
@@ -5,7 +5,6 @@
#ifndef _GAMEPORT_H
#define _GAMEPORT_H
-#include <asm/io.h>
#include <linux/types.h>
#include <linux/list.h>
#include <linux/mutex.h>
@@ -165,18 +164,12 @@ void gameport_unregister_driver(struct gameport_driver *drv);
static inline void gameport_trigger(struct gameport *gameport)
{
- if (gameport->trigger)
- gameport->trigger(gameport);
- else
- outb(0xff, gameport->io);
+ gameport->trigger(gameport);
}
static inline unsigned char gameport_read(struct gameport *gameport)
{
- if (gameport->read)
- return gameport->read(gameport);
- else
- return inb(gameport->io);
+ return gameport->read(gameport);
}
static inline int gameport_cooked_read(struct gameport *gameport, int *axes, int *buttons)
--
2.40.1.698.g37aff9b760-goog
--
Dmitry
^ permalink raw reply related
* [PATCH v3] Input: tests: add test to cover all input_grab_device() function
From: Dana Elfassy @ 2023-05-22 21:55 UTC (permalink / raw)
To: eballetb, dmitry.torokhov, javierm, linux-input, linux-kernel
Cc: Dana Elfassy
Currently input_grab_device() isn't covered by any tests
Thus, adding a test to cover the cases:
1. The device is grabbed successfully
2. Trying to grab a device that is already grabbed by another input
handle
Signed-off-by: Dana Elfassy <dangel101@gmail.com>
Tested-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Changes in v3:
1. Retrieve test_handle variable to try and grab the device that's
currently grabbed by another handle
2. Add verification that test_handle can indeed grab the device after
it's released by the handle that grabbed it
3. Remove duplicated call for input_grab_device() in KUNIT_ASSERT_TRUE()
functions
Changes in v2:
- Use input_put_device() to decrement the refcount increased by get().
- Remove unnecessary struct input_handle test_handle variable.
drivers/input/tests/input_test.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/input/tests/input_test.c b/drivers/input/tests/input_test.c
index 25bbf51b5c87..1939cc12bae0 100644
--- a/drivers/input/tests/input_test.c
+++ b/drivers/input/tests/input_test.c
@@ -124,10 +124,42 @@ static void input_test_match_device_id(struct kunit *test)
KUNIT_ASSERT_FALSE(test, input_match_device_id(input_dev, &id));
}
+static void input_test_grab(struct kunit *test)
+{
+ struct input_dev *input_dev = test->priv;
+ struct input_handle test_handle;
+ struct input_handler handler;
+ struct input_handle handle;
+ struct input_device_id id;
+ int res;
+
+ handler.name = "handler";
+ handler.id_table = &id;
+
+ handle.dev = input_get_device(input_dev);
+ handle.name = dev_name(&input_dev->dev);
+ handle.handler = &handler;
+ res = input_grab_device(&handle);
+ KUNIT_ASSERT_TRUE(test, res == 0);
+
+ test_handle.dev = input_get_device(input_dev);
+ test_handle.name = dev_name(&input_dev->dev);
+ test_handle.handler = &handler;
+ res = input_grab_device(&test_handle);
+ KUNIT_ASSERT_EQ(test, res, -EBUSY);
+
+ input_release_device(&handle);
+ input_put_device(input_dev);
+ res = input_grab_device(&test_handle);
+ KUNIT_ASSERT_TRUE(test, res == 0);
+ input_put_device(input_dev);
+}
+
static struct kunit_case input_tests[] = {
KUNIT_CASE(input_test_polling),
KUNIT_CASE(input_test_timestamp),
KUNIT_CASE(input_test_match_device_id),
+ KUNIT_CASE(input_test_grab),
{ /* sentinel */ }
};
--
2.40.1
^ permalink raw reply related
* Your urgent feedback is highly appreciated.
From: Eun-ji Ha @ 2023-05-22 21:14 UTC (permalink / raw)
To: linux-input
Good day,
My name is Mrs. Eun-ji Ha.
I would like to get in touch with you.
Did you receive my previous email for investment purposes?
Please send your telephone number to enhance communication.
Have a great day!
Best regards,
^ permalink raw reply
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