* [dtor-input:next] BUILD SUCCESS 54116d442e001e1b6bd482122043b1870998a1f3
From: kernel test robot @ 2023-08-02 13:06 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 54116d442e001e1b6bd482122043b1870998a1f3 Input: rpckbd - fix the return value handle for platform_get_irq()
elapsed time: 726m
configs tested: 146
configs skipped: 8
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-r023-20230731 gcc
alpha randconfig-r032-20230731 gcc
alpha randconfig-r036-20230731 gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-r026-20230731 gcc
arc randconfig-r043-20230731 gcc
arc randconfig-r043-20230801 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm randconfig-r004-20230801 clang
arm randconfig-r024-20230731 gcc
arm randconfig-r033-20230731 clang
arm randconfig-r034-20230731 clang
arm randconfig-r046-20230731 gcc
arm randconfig-r046-20230801 gcc
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r004-20230731 gcc
arm64 randconfig-r033-20230731 gcc
csky defconfig gcc
csky randconfig-r012-20230801 gcc
csky randconfig-r031-20230731 gcc
hexagon randconfig-r003-20230731 clang
hexagon randconfig-r012-20230731 clang
hexagon randconfig-r015-20230731 clang
hexagon randconfig-r016-20230801 clang
hexagon randconfig-r021-20230731 clang
hexagon randconfig-r041-20230731 clang
hexagon randconfig-r041-20230801 clang
hexagon randconfig-r045-20230731 clang
hexagon randconfig-r045-20230801 clang
i386 allyesconfig gcc
i386 buildonly-randconfig-r004-20230731 gcc
i386 buildonly-randconfig-r004-20230802 clang
i386 buildonly-randconfig-r005-20230731 gcc
i386 buildonly-randconfig-r005-20230802 clang
i386 buildonly-randconfig-r006-20230731 gcc
i386 buildonly-randconfig-r006-20230802 clang
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-i001-20230731 gcc
i386 randconfig-i002-20230731 gcc
i386 randconfig-i003-20230731 gcc
i386 randconfig-i004-20230731 gcc
i386 randconfig-i005-20230731 gcc
i386 randconfig-i006-20230731 gcc
i386 randconfig-i011-20230801 clang
i386 randconfig-i012-20230801 clang
i386 randconfig-i013-20230801 clang
i386 randconfig-i014-20230801 clang
i386 randconfig-i015-20230801 clang
i386 randconfig-i016-20230801 clang
i386 randconfig-r014-20230731 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
m68k allmodconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
microblaze randconfig-r005-20230801 gcc
microblaze randconfig-r013-20230801 gcc
microblaze randconfig-r025-20230731 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips randconfig-r011-20230801 gcc
mips randconfig-r022-20230731 gcc
mips randconfig-r036-20230731 clang
nios2 defconfig gcc
nios2 randconfig-r001-20230801 gcc
nios2 randconfig-r011-20230731 gcc
openrisc randconfig-r003-20230731 gcc
openrisc randconfig-r032-20230731 gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-r023-20230731 gcc
parisc randconfig-r024-20230731 gcc
parisc randconfig-r036-20230731 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc randconfig-r004-20230731 gcc
powerpc randconfig-r014-20230801 clang
powerpc randconfig-r035-20230731 gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv allyesconfig gcc
riscv defconfig gcc
riscv randconfig-r006-20230731 gcc
riscv randconfig-r021-20230731 clang
riscv randconfig-r031-20230731 gcc
riscv randconfig-r042-20230731 clang
riscv randconfig-r042-20230801 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r015-20230801 clang
s390 randconfig-r031-20230731 gcc
s390 randconfig-r044-20230731 clang
s390 randconfig-r044-20230801 clang
sh allmodconfig gcc
sh randconfig-r005-20230731 gcc
sh randconfig-r006-20230801 gcc
sparc allyesconfig gcc
sparc defconfig gcc
sparc randconfig-r002-20230731 gcc
sparc randconfig-r003-20230801 gcc
sparc64 randconfig-r001-20230731 gcc
sparc64 randconfig-r013-20230731 gcc
sparc64 randconfig-r016-20230731 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allyesconfig gcc
x86_64 buildonly-randconfig-r001-20230731 gcc
x86_64 buildonly-randconfig-r001-20230802 clang
x86_64 buildonly-randconfig-r002-20230731 gcc
x86_64 buildonly-randconfig-r002-20230802 clang
x86_64 buildonly-randconfig-r003-20230731 gcc
x86_64 buildonly-randconfig-r003-20230802 clang
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-x001-20230731 clang
x86_64 randconfig-x002-20230731 clang
x86_64 randconfig-x003-20230731 clang
x86_64 randconfig-x004-20230731 clang
x86_64 randconfig-x005-20230731 clang
x86_64 randconfig-x006-20230731 clang
x86_64 randconfig-x011-20230731 gcc
x86_64 randconfig-x012-20230731 gcc
x86_64 randconfig-x013-20230731 gcc
x86_64 randconfig-x014-20230731 gcc
x86_64 randconfig-x015-20230731 gcc
x86_64 randconfig-x016-20230731 gcc
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa randconfig-r022-20230731 gcc
xtensa randconfig-r034-20230731 gcc
xtensa randconfig-r035-20230731 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: add more DRM dependencies
From: Doug Anderson @ 2023-08-02 14:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jiri Kosina, Benjamin Tissoires, Maxime Ripard, Arnd Bergmann,
Hans de Goede, linux-input, linux-kernel
In-Reply-To: <20230802124947.1355415-1-arnd@kernel.org>
Hi,
On Wed, Aug 2, 2023 at 5:49 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> When a symbol is selected that has extra dependencies,
> anything that selects it must have the same dependencies.
> With the added CONFIG_DRM reference from I2C_HID_CORE,
> this broke a couple of drivers that now also depend
> on DRM:
>
> WARNING: unmet direct dependencies detected for I2C_HID_CORE
> Depends on [m]: HID_SUPPORT [=y] && I2C_HID [=y] && (DRM [=m] || !DRM [=m])
> Selected by [y]:
> - I2C_HID_OF [=y] && HID_SUPPORT [=y] && I2C_HID [=y]
> - I2C_HID_ACPI [=y] && HID_SUPPORT [=y] && I2C_HID [=y] && ACPI [=y]
> - I2C_HID_OF_GOODIX [=y] && HID_SUPPORT [=y] && I2C_HID [=y] && OF [=y]
> x86_64-linux-ld: vmlinux.o: in function `i2c_hid_core_remove':
> (.text+0xfc8826): undefined reference to `drm_panel_remove_follower'
> x86_64-linux-ld: vmlinux.o: in function `i2c_hid_core_probe':
> (.text+0xfc8da0): undefined reference to `drm_is_panel_follower'
>
> Add the corresponding DRM||!DRM dependencies on each one that
> is affected.
>
> Fixes: 96a37bfd232ae ("HID: i2c-hid: Support being a panel follower")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/hid/i2c-hid/Kconfig | 4 ++++
> 1 file changed, 4 insertions(+)
This makes sense. Thanks for the fix!
I'm happy to land this in drm-misc-next (where the original patch
landed), but I'd prefer an Ack from Benjamin first, if possible. If
this is still outstanding tomorrow I'll land it anyway since it's a
small fix and he Acked the commit that this is fixing.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
-Doug
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: input: i2c-hid: Introduce Ilitek ili9882t
From: Doug Anderson @ 2023-08-02 16:02 UTC (permalink / raw)
To: Cong Yang
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, dmitry.torokhov, jikos,
benjamin.tissoires, hsinyi, linux-input, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20230802071947.1683318-2-yangcong5@huaqin.corp-partner.google.com>
Hi,
On Wed, Aug 2, 2023 at 12:20 AM Cong Yang
<yangcong5@huaqin.corp-partner.google.com> wrote:
>
> The ili9882t touch screen chip same as Elan eKTH6915 controller
> has a reset gpio. The difference is that ili9882t needs to use
> vccio-supply instead of vcc33-supply. Doug's series[1] allows panels
> and touchscreens to power on/off together, let's add a phandle for this.
>
> [1]: https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> ---
> .../bindings/input/ilitek,ili9882t.yaml | 67 +++++++++++++++++++
> 1 file changed, 67 insertions(+)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH v6 2/2] HID: i2c-hid: elan: Add ili9882t timing
From: Doug Anderson @ 2023-08-02 16:09 UTC (permalink / raw)
To: Cong Yang, benjamin.tissoires, Benjamin Tissoires
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, dmitry.torokhov, jikos,
hsinyi, linux-input, devicetree, linux-kernel
In-Reply-To: <20230802071947.1683318-3-yangcong5@huaqin.corp-partner.google.com>
Benjamin,
On Wed, Aug 2, 2023 at 12:20 AM Cong Yang
<yangcong5@huaqin.corp-partner.google.com> wrote:
>
> The ili9882t is a TDDI IC (Touch with Display Driver). The
> datasheet specifies there should be 60ms between touch SDA
> sleep and panel RESX. Doug's series[1] allows panels and
> touchscreens to power on/off together, so we can add the 65 ms
> delay in i2c_hid_core_suspend before panel_unprepare.
>
> Because ili9882t touchscrgeen is a panel follower, and
> needs to use vccio-supply instead of vcc33-supply, so set
> it NULL to ili9882t_chip_data, then not use vcc33 regulator.
>
> [1]: https://lore.kernel.org/all/20230727171750.633410-1-dianders@chromium.org
>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> ---
> drivers/hid/i2c-hid/i2c-hid-of-elan.c | 50 ++++++++++++++++++++-------
> 1 file changed, 38 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-of-elan.c b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
> index 029045d9661c..31abab57ad44 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-of-elan.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
> @@ -18,9 +18,11 @@
> #include "i2c-hid.h"
>
> struct elan_i2c_hid_chip_data {
> - unsigned int post_gpio_reset_delay_ms;
> + unsigned int post_gpio_reset_on_delay_ms;
> + unsigned int post_gpio_reset_off_delay_ms;
> unsigned int post_power_delay_ms;
> u16 hid_descriptor_address;
> + const char *main_supply_name;
> };
>
> struct i2c_hid_of_elan {
> @@ -38,9 +40,11 @@ static int elan_i2c_hid_power_up(struct i2chid_ops *ops)
> container_of(ops, struct i2c_hid_of_elan, ops);
> int ret;
>
> - ret = regulator_enable(ihid_elan->vcc33);
> - if (ret)
> - return ret;
> + if (ihid_elan->vcc33) {
> + ret = regulator_enable(ihid_elan->vcc33);
> + if (ret)
> + return ret;
> + }
>
> ret = regulator_enable(ihid_elan->vccio);
> if (ret) {
> @@ -52,8 +56,8 @@ static int elan_i2c_hid_power_up(struct i2chid_ops *ops)
> msleep(ihid_elan->chip_data->post_power_delay_ms);
>
> gpiod_set_value_cansleep(ihid_elan->reset_gpio, 0);
> - if (ihid_elan->chip_data->post_gpio_reset_delay_ms)
> - msleep(ihid_elan->chip_data->post_gpio_reset_delay_ms);
> + if (ihid_elan->chip_data->post_gpio_reset_on_delay_ms)
> + msleep(ihid_elan->chip_data->post_gpio_reset_on_delay_ms);
>
> return 0;
> }
> @@ -64,8 +68,12 @@ static void elan_i2c_hid_power_down(struct i2chid_ops *ops)
> container_of(ops, struct i2c_hid_of_elan, ops);
>
> gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
> + if (ihid_elan->chip_data->post_gpio_reset_off_delay_ms)
> + msleep(ihid_elan->chip_data->post_gpio_reset_off_delay_ms);
> +
> regulator_disable(ihid_elan->vccio);
> - regulator_disable(ihid_elan->vcc33);
> + if (ihid_elan->vcc33)
> + regulator_disable(ihid_elan->vcc33);
> }
>
> static int i2c_hid_of_elan_probe(struct i2c_client *client)
> @@ -89,24 +97,42 @@ static int i2c_hid_of_elan_probe(struct i2c_client *client)
> if (IS_ERR(ihid_elan->vccio))
> return PTR_ERR(ihid_elan->vccio);
>
> - ihid_elan->vcc33 = devm_regulator_get(&client->dev, "vcc33");
> - if (IS_ERR(ihid_elan->vcc33))
> - return PTR_ERR(ihid_elan->vcc33);
> -
> ihid_elan->chip_data = device_get_match_data(&client->dev);
>
> + if (ihid_elan->chip_data->main_supply_name) {
> + ihid_elan->vcc33 = devm_regulator_get(&client->dev,
> + ihid_elan->chip_data->main_supply_name);
> + if (IS_ERR(ihid_elan->vcc33))
> + return PTR_ERR(ihid_elan->vcc33);
> + }
> +
> return i2c_hid_core_probe(client, &ihid_elan->ops,
> ihid_elan->chip_data->hid_descriptor_address, 0);
> }
>
> static const struct elan_i2c_hid_chip_data elan_ekth6915_chip_data = {
> .post_power_delay_ms = 1,
> - .post_gpio_reset_delay_ms = 300,
> + .post_gpio_reset_on_delay_ms = 300,
> + .hid_descriptor_address = 0x0001,
> + .main_supply_name = "vcc33",
> +};
> +
> +static const struct elan_i2c_hid_chip_data ilitek_ili9882t_chip_data = {
> + .post_power_delay_ms = 1,
> + .post_gpio_reset_on_delay_ms = 200,
> + .post_gpio_reset_off_delay_ms = 65,
> .hid_descriptor_address = 0x0001,
> + /*
> + * this touchscreen is tightly integrated with the panel and assumes
> + * that the relevant power rails (other than the IO rail) have already
> + * been turned on by the panel driver because we're a panel follower.
> + */
> + .main_supply_name = NULL,
> };
>
> static const struct of_device_id elan_i2c_hid_of_match[] = {
> { .compatible = "elan,ekth6915", .data = &elan_ekth6915_chip_data },
> + { .compatible = "ilitek,ili9882t", .data = &ilitek_ili9882t_chip_data },
Logically, this patch depends on the panel-follower series that's now
landed in drm-misc-next. With your Ack, I'm willing to land these two
patches into drm-misc-next too. Other options:
a) We could land the two patches in the i2c-hid tree since they don't
appear to conflict. The touchscreen won't actually function until the
patches meetup in linux-next but I don't think they'll give any
compile errors (I haven't double-checked that, but I can). ...though
it's possible that the dt bindings might generate errors? Again, I can
investigate if we want to go this way.
b) We can snooze this for a few months and you can pick it to i2c-hid
when my series reaches mainline.
Let me know how you'd like to proceed.
-Doug
^ permalink raw reply
* Re: Lenovo N24: Touchpad lost sync at byte 6
From: Jonathan Denose @ 2023-08-02 16:27 UTC (permalink / raw)
To: linux-input
In-Reply-To: <CALNJtpVH0DAcnkJ+++H0ng2AWW1t1ZW0RCfbHn=fyRnRN9CJ8w@mail.gmail.com>
On Mon, Jul 17, 2023 at 2:59 PM Jonathan Denose <jdenose@chromium.org> wrote:
>
> Hello,
>
> I am on a Lenovo N24 laptop.
>
> When this device resumes after closing the lid, the mouse freezes and
> is unusable. After right-clicking multiple times the touchpad resumes
> working. I am seeing the following in the logs:
>
> [ 1188.690138] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
> sync at byte 6
> [ 1188.699636] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
> sync at byte 6
> [ 1188.709124] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
> sync at byte 6
> [ 1188.718557] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
> sync at byte 6
> [ 1188.728110] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
> sync at byte 6
> [ 1188.975964] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
> sync at byte 6
> [ 1188.985456] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
> sync at byte 6
> [ 1188.994954] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
> sync at byte 6
> [ 1189.004443] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
> sync at byte 6
> [ 1189.013930] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
> sync at byte 6
>
> This device has an ETPS/2 Elantech Touchpad. I am on kernel version:
> 5.15.117-19629-gf1eb3139d206.
>
> Greg KH suggested that I try later kernel versions, and I've tried 6.4
> and 6.1 and the issue is present on both of those versions. This issue
> is also present on 5.10.
>
> Currently the device suspends to ram when the lid closes. When the
> device idles without the lid closing, the touchpad works fine on
> resume.
>
> I have tried adding various i8042 and psmouse kernel parameters from
> searching different forums related to these error messages, but none
> of them fix the issue. I have tried
> - psmouse.resetafter=0
> - psmouse.resetafter=1
> - i8042.nomux=1
> - i8042.resetafter=1/0
> - i8042.reset=1 i8042.nomux=1
> - i8042.noloop=1 i8042.nopnp=1 i8042.nomux=1 i8042.reset=1
>
> I was able to resolve this issue by doing `modprobe -r psmouse &&
> modprobe.psmouse proto=imps`. proto=bare and proto=exps also resolve
> the issue. However, with those options enabled I can no longer use
> gestures like two-finger scroll.
>
> This issue reproduces on ChromeOS Flex and Ubuntu 22.04 but not on
> Windows. On Windows the touchpad resuming after closing the lid works
> fine.
>
> What can I do to resolve this issue while also keeping touchpad gestures?
>
> Any help is greatly appreciated!
Hello,
As an update, this error is getting thrown from case 4 in elantech_process_byte:
```
static psmouse_ret_t elantech_process_byte(struct psmouse *psmouse)
{
...
case 4:
packet_type = elantech_packet_check_v4(psmouse);
switch (packet_type) {
case PACKET_UNKNOWN:
return PSMOUSE_BAD_DATA;
case PACKET_TRACKPOINT:
elantech_report_trackpoint(psmouse, packet_type);
break;
default:
elantech_report_absolute_v4(psmouse, packet_type);
break;
}
break;
}
return PSMOUSE_FULL_PACKET;
}
```
The issue is fixed by running `rmmod psmouse && modprobe psmouse` but
I haven't found a good way to replicate that in code for the failure
case.
^ permalink raw reply
* Re: [PATCH v3 02/10] drm/panel: Check for already prepared/enabled in drm_panel
From: Chris Morgan @ 2023-08-02 17:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Doug Anderson, Jiri Kosina, Benjamin Tissoires, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Frank Rowand, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Sam Ravnborg, Maarten Lankhorst,
Thomas Zimmermann, cros-qcom-dts-watchers, linux-input, hsinyi,
linux-arm-msm, dri-devel, linux-kernel, Dmitry Torokhov,
devicetree, Daniel Vetter, yangcong5
In-Reply-To: <kuctj2p353nsae24lrhcymqqpfajbc7qoqly63zpwvdp6lgu3b@kk4gpzsapxnn>
On Mon, Jul 31, 2023 at 07:03:07PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Mon, Jul 31, 2023 at 11:33:22AM -0500, Chris Morgan wrote:
> > In my case a few different panel drivers disable the regulators in the
> > unprepare/disable routines.
>
> And that's totally fine.
>
> > For at least the Rockchip DSI implementations for some reason the
> > panel gets unprepared more than once, which triggers an unbalanced
> > regulator disable.
>
> "For some reason" being that DW-DSI apparently finds it ok to bypass any
> kind of abstraction and randomly calling panel functions by itself:
>
> https://elixir.bootlin.com/linux/v6.4.7/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L868
>
> It looks like it's fixed it current drm-misc-next though.
Good, when I get a chance I will test it out with the existing panels
I have at my disposal and submit some patches to clean them up.
>
> > Obviously though the correct course of action is to fix the reason why
> > the panel is disabled more than once, but that's at least the root
> > cause of this behavior on the few panels I've worked with.
>
> Like I said we already have a commit on the way to fix that, so it
> shouldn't be an issue anymore.
>
> I stand by what I was saying earlier though, I think it's mostly
> cargo-cult or drivers being very wrong. If anything, the DW-DSI stuff
> made me even more convinced that we shouldn't even entertain that idea
> :)
>
> Maxime
Thank you, and yes if a driver is doing something it shouldn't we
shouldn't be patching around that, we should be fixing things. Thanks
for providing me with the additional info.
Chris
^ permalink raw reply
* Re: [PATCH v3 02/10] drm/panel: Check for already prepared/enabled in drm_panel
From: Dave Stevenson @ 2023-08-02 17:50 UTC (permalink / raw)
To: Chris Morgan
Cc: Maxime Ripard, dri-devel, linux-kernel, Benjamin Tissoires,
Krzysztof Kozlowski, Sam Ravnborg, Frank Rowand, linux-input,
hsinyi, devicetree, Conor Dooley, cros-qcom-dts-watchers,
linux-arm-msm, yangcong5, Jiri Kosina, Rob Herring,
Neil Armstrong, Bjorn Andersson, Dmitry Torokhov, Doug Anderson,
Konrad Dybcio, Thomas Zimmermann
In-Reply-To: <64ca91a3.0d0a0220.8e58d.89b3@mx.google.com>
On Wed, 2 Aug 2023 at 18:26, Chris Morgan <macroalpha82@gmail.com> wrote:
>
> * Spam *
> On Mon, Jul 31, 2023 at 07:03:07PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, Jul 31, 2023 at 11:33:22AM -0500, Chris Morgan wrote:
> > > In my case a few different panel drivers disable the regulators in the
> > > unprepare/disable routines.
> >
> > And that's totally fine.
> >
> > > For at least the Rockchip DSI implementations for some reason the
> > > panel gets unprepared more than once, which triggers an unbalanced
> > > regulator disable.
> >
> > "For some reason" being that DW-DSI apparently finds it ok to bypass any
> > kind of abstraction and randomly calling panel functions by itself:
> >
> > https://elixir.bootlin.com/linux/v6.4.7/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L868
> >
> > It looks like it's fixed it current drm-misc-next though.
>
> Good, when I get a chance I will test it out with the existing panels
> I have at my disposal and submit some patches to clean them up.
>
> >
> > > Obviously though the correct course of action is to fix the reason why
> > > the panel is disabled more than once, but that's at least the root
> > > cause of this behavior on the few panels I've worked with.
> >
> > Like I said we already have a commit on the way to fix that, so it
> > shouldn't be an issue anymore.
> >
> > I stand by what I was saying earlier though, I think it's mostly
> > cargo-cult or drivers being very wrong. If anything, the DW-DSI stuff
> > made me even more convinced that we shouldn't even entertain that idea
> > :)
DW-DSI is hacking around the fact that DSI panels may want to send DCS
commands in unprepare, however the DSI host driver shuts down the
controller in the DSI bridge post_disable which gets called first.
That ordering can now be reversed with pre_enable_prev_first flag in
struct drm_bridge, or prepare_prev_first in drm_panel, hence no need
for the DSI controller to jump around the bridge chain.
Dave
> > Maxime
>
> Thank you, and yes if a driver is doing something it shouldn't we
> shouldn't be patching around that, we should be fixing things. Thanks
> for providing me with the additional info.
>
> Chris
>
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: input: i2c-hid: Introduce Ilitek ili9882t
From: Krzysztof Kozlowski @ 2023-08-03 11:12 UTC (permalink / raw)
To: Cong Yang, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.torokhov, dianders, jikos, benjamin.tissoires, hsinyi
Cc: linux-input, devicetree, linux-kernel
In-Reply-To: <20230802071947.1683318-2-yangcong5@huaqin.corp-partner.google.com>
On 02/08/2023 09:19, Cong Yang wrote:
> The ili9882t touch screen chip same as Elan eKTH6915 controller
> has a reset gpio. The difference is that ili9882t needs to use
> vccio-supply instead of vcc33-supply. Doug's series[1] allows panels
> and touchscreens to power on/off together, let's add a phandle for this.
>
> [1]: https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> ---
> .../bindings/input/ilitek,ili9882t.yaml | 67 +++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
It's v6 but this still misses the changelog.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH AUTOSEL 6.4 6/7] HID: logitech-hidpp: Add wired USB id for Logitech G502 Lightspeed
From: Sasha Levin @ 2023-08-03 13:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stuart Hayhurst, Bastien Nocera, Benjamin Tissoires, Sasha Levin,
jikos, benjamin.tissoires, linux-input
In-Reply-To: <20230803130321.641516-1-sashal@kernel.org>
From: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
[ Upstream commit a343a7682acc56182d4b54777c358f5ec6d274e7 ]
Previously, support for the G502 had been attempted in commit
'27fc32fd9417 ("HID: logitech-hidpp: add USB PID for a few more supported
mice")'
This caused some issues and was reverted by
'addf3382c47c ("Revert "HID: logitech-hidpp: add USB PID for a few more
supported mice"")'.
Since then, a new version of this mouse has been released (Lightpseed
Wireless), and works correctly.
This device has support for battery reporting with the driver
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230630113818.13005-1-stuart.a.hayhurst@gmail.com
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index f7e06d433a915..22d5ba88954fc 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4598,6 +4598,8 @@ static const struct hid_device_id hidpp_devices[] = {
{ /* Logitech G403 Wireless Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC082) },
+ { /* Logitech G502 Lightspeed Wireless Gaming Mouse over USB */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC08D) },
{ /* Logitech G703 Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC087) },
{ /* Logitech G703 Hero Gaming Mouse over USB */
--
2.40.1
^ permalink raw reply related
* [PATCH AUTOSEL 6.1 4/5] HID: logitech-hidpp: Add wired USB id for Logitech G502 Lightspeed
From: Sasha Levin @ 2023-08-03 13:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stuart Hayhurst, Bastien Nocera, Benjamin Tissoires, Sasha Levin,
jikos, benjamin.tissoires, linux-input
In-Reply-To: <20230803130333.641625-1-sashal@kernel.org>
From: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
[ Upstream commit a343a7682acc56182d4b54777c358f5ec6d274e7 ]
Previously, support for the G502 had been attempted in commit
'27fc32fd9417 ("HID: logitech-hidpp: add USB PID for a few more supported
mice")'
This caused some issues and was reverted by
'addf3382c47c ("Revert "HID: logitech-hidpp: add USB PID for a few more
supported mice"")'.
Since then, a new version of this mouse has been released (Lightpseed
Wireless), and works correctly.
This device has support for battery reporting with the driver
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230630113818.13005-1-stuart.a.hayhurst@gmail.com
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 0b4204b9a253c..a3c88e35ac44e 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4393,6 +4393,8 @@ static const struct hid_device_id hidpp_devices[] = {
{ /* Logitech G403 Wireless Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC082) },
+ { /* Logitech G502 Lightspeed Wireless Gaming Mouse over USB */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC08D) },
{ /* Logitech G703 Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC087) },
{ /* Logitech G703 Hero Gaming Mouse over USB */
--
2.40.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.15 2/2] HID: logitech-hidpp: Add wired USB id for Logitech G502 Lightspeed
From: Sasha Levin @ 2023-08-03 13:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stuart Hayhurst, Bastien Nocera, Benjamin Tissoires, Sasha Levin,
jikos, benjamin.tissoires, linux-input
In-Reply-To: <20230803130343.641695-1-sashal@kernel.org>
From: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
[ Upstream commit a343a7682acc56182d4b54777c358f5ec6d274e7 ]
Previously, support for the G502 had been attempted in commit
'27fc32fd9417 ("HID: logitech-hidpp: add USB PID for a few more supported
mice")'
This caused some issues and was reverted by
'addf3382c47c ("Revert "HID: logitech-hidpp: add USB PID for a few more
supported mice"")'.
Since then, a new version of this mouse has been released (Lightpseed
Wireless), and works correctly.
This device has support for battery reporting with the driver
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230630113818.13005-1-stuart.a.hayhurst@gmail.com
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index c61da859cd3c6..d6c92c5b2bb42 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4367,6 +4367,8 @@ static const struct hid_device_id hidpp_devices[] = {
{ /* Logitech G403 Wireless Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC082) },
+ { /* Logitech G502 Lightspeed Wireless Gaming Mouse over USB */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC08D) },
{ /* Logitech G703 Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC087) },
{ /* Logitech G703 Hero Gaming Mouse over USB */
--
2.40.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.10 2/2] HID: logitech-hidpp: Add wired USB id for Logitech G502 Lightspeed
From: Sasha Levin @ 2023-08-03 13:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stuart Hayhurst, Bastien Nocera, Benjamin Tissoires, Sasha Levin,
jikos, benjamin.tissoires, linux-input
In-Reply-To: <20230803130349.641732-1-sashal@kernel.org>
From: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
[ Upstream commit a343a7682acc56182d4b54777c358f5ec6d274e7 ]
Previously, support for the G502 had been attempted in commit
'27fc32fd9417 ("HID: logitech-hidpp: add USB PID for a few more supported
mice")'
This caused some issues and was reverted by
'addf3382c47c ("Revert "HID: logitech-hidpp: add USB PID for a few more
supported mice"")'.
Since then, a new version of this mouse has been released (Lightpseed
Wireless), and works correctly.
This device has support for battery reporting with the driver
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230630113818.13005-1-stuart.a.hayhurst@gmail.com
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 2e32a21bbcbfc..e1db47f5077fb 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4081,6 +4081,8 @@ static const struct hid_device_id hidpp_devices[] = {
{ /* Logitech G403 Wireless Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC082) },
+ { /* Logitech G502 Lightspeed Wireless Gaming Mouse over USB */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC08D) },
{ /* Logitech G703 Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC087) },
{ /* Logitech G703 Hero Gaming Mouse over USB */
--
2.40.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 2/2] HID: logitech-hidpp: Add wired USB id for Logitech G502 Lightspeed
From: Sasha Levin @ 2023-08-03 13:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stuart Hayhurst, Bastien Nocera, Benjamin Tissoires, Sasha Levin,
jikos, benjamin.tissoires, linux-input
In-Reply-To: <20230803130354.641771-1-sashal@kernel.org>
From: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
[ Upstream commit a343a7682acc56182d4b54777c358f5ec6d274e7 ]
Previously, support for the G502 had been attempted in commit
'27fc32fd9417 ("HID: logitech-hidpp: add USB PID for a few more supported
mice")'
This caused some issues and was reverted by
'addf3382c47c ("Revert "HID: logitech-hidpp: add USB PID for a few more
supported mice"")'.
Since then, a new version of this mouse has been released (Lightpseed
Wireless), and works correctly.
This device has support for battery reporting with the driver
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230630113818.13005-1-stuart.a.hayhurst@gmail.com
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index b8558292801ec..d661e44232586 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3864,6 +3864,8 @@ static const struct hid_device_id hidpp_devices[] = {
{ /* Logitech G403 Wireless Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC082) },
+ { /* Logitech G502 Lightspeed Wireless Gaming Mouse over USB */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC08D) },
{ /* Logitech G703 Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC087) },
{ /* Logitech G703 Hero Gaming Mouse over USB */
--
2.40.1
^ permalink raw reply related
* [PATCH] MAINTAINERS: update my email address
From: David Rheinsberg @ 2023-08-03 13:40 UTC (permalink / raw)
To: linux-input; +Cc: Jiri Kosina, Benjamin Tissoires, David Rheinsberg
Update my email-address in MAINTAINERS to <david@readahead.eu>. Also add
.mailmap entries to map my old surname and email-addresses.
Signed-off-by: David Rheinsberg <david@readahead.eu>
---
.mailmap | 3 +++
MAINTAINERS | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/.mailmap b/.mailmap
index 5dd318121982..0ed8a8674a03 100644
--- a/.mailmap
+++ b/.mailmap
@@ -139,6 +139,9 @@ Daniel Borkmann <daniel@iogearbox.net> <dborkman@redhat.com>
Daniel Borkmann <daniel@iogearbox.net> <dxchgb@gmail.com>
David Brownell <david-b@pacbell.net>
David Collins <quic_collinsd@quicinc.com> <collinsd@codeaurora.org>
+David Rheinsberg <david@readahead.eu> <dh.herrmann@gmail.com>
+David Rheinsberg <david@readahead.eu> <dh.herrmann@googlemail.com>
+David Rheinsberg <david@readahead.eu> <david.rheinsberg@gmail.com>
David Woodhouse <dwmw2@shinybook.infradead.org>
Dedy Lansky <quic_dlansky@quicinc.com> <dlansky@codeaurora.org>
Deepak Kumar Singh <quic_deesin@quicinc.com> <deesin@codeaurora.org>
diff --git a/MAINTAINERS b/MAINTAINERS
index 53b7ca804465..b671495df3b8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21798,7 +21798,7 @@ F: Documentation/admin-guide/ufs.rst
F: fs/ufs/
UHID USERSPACE HID IO DRIVER
-M: David Rheinsberg <david.rheinsberg@gmail.com>
+M: David Rheinsberg <david@readahead.eu>
L: linux-input@vger.kernel.org
S: Maintained
F: drivers/hid/uhid.c
@@ -22922,7 +22922,7 @@ S: Maintained
F: drivers/rtc/rtc-sd3078.c
WIIMOTE HID DRIVER
-M: David Rheinsberg <david.rheinsberg@gmail.com>
+M: David Rheinsberg <david@readahead.eu>
L: linux-input@vger.kernel.org
S: Maintained
F: drivers/hid/hid-wiimote*
--
2.41.0
^ permalink raw reply related
* Re: [PATCH] HID: i2c-hid: add more DRM dependencies
From: Doug Anderson @ 2023-08-03 14:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jiri Kosina, Benjamin Tissoires, Maxime Ripard, Arnd Bergmann,
Hans de Goede, linux-input, linux-kernel
In-Reply-To: <CAD=FV=Um=OsKA8LaHeOx0n=-1PJAdc6DJsWX9zmQZ+syFEa6vg@mail.gmail.com>
Hi,
On Wed, Aug 2, 2023 at 7:16 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Aug 2, 2023 at 5:49 AM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > When a symbol is selected that has extra dependencies,
> > anything that selects it must have the same dependencies.
> > With the added CONFIG_DRM reference from I2C_HID_CORE,
> > this broke a couple of drivers that now also depend
> > on DRM:
> >
> > WARNING: unmet direct dependencies detected for I2C_HID_CORE
> > Depends on [m]: HID_SUPPORT [=y] && I2C_HID [=y] && (DRM [=m] || !DRM [=m])
> > Selected by [y]:
> > - I2C_HID_OF [=y] && HID_SUPPORT [=y] && I2C_HID [=y]
> > - I2C_HID_ACPI [=y] && HID_SUPPORT [=y] && I2C_HID [=y] && ACPI [=y]
> > - I2C_HID_OF_GOODIX [=y] && HID_SUPPORT [=y] && I2C_HID [=y] && OF [=y]
> > x86_64-linux-ld: vmlinux.o: in function `i2c_hid_core_remove':
> > (.text+0xfc8826): undefined reference to `drm_panel_remove_follower'
> > x86_64-linux-ld: vmlinux.o: in function `i2c_hid_core_probe':
> > (.text+0xfc8da0): undefined reference to `drm_is_panel_follower'
> >
> > Add the corresponding DRM||!DRM dependencies on each one that
> > is affected.
> >
> > Fixes: 96a37bfd232ae ("HID: i2c-hid: Support being a panel follower")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > drivers/hid/i2c-hid/Kconfig | 4 ++++
> > 1 file changed, 4 insertions(+)
>
> This makes sense. Thanks for the fix!
>
> I'm happy to land this in drm-misc-next (where the original patch
> landed), but I'd prefer an Ack from Benjamin first, if possible. If
> this is still outstanding tomorrow I'll land it anyway since it's a
> small fix and he Acked the commit that this is fixing.
>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
It's tomorrow, so I've landed this in drm-misc-next.
a0769f25a3a6 HID: i2c-hid: add more DRM dependencies
-Doug
^ permalink raw reply
* Re: [PATCH v1 00/12] HID: cp2112: Cleanups and refactorings
From: Andy Shevchenko @ 2023-08-04 6:40 UTC (permalink / raw)
To: linux-input, linux-kernel; +Cc: Jiri Kosina, Benjamin Tissoires
In-Reply-To: <ZMK60UphgVuj4Z+L@smile.fi.intel.com>
On Thu, Jul 27, 2023 at 09:43:29PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 03, 2023 at 09:52:10PM +0300, Andy Shevchenko wrote:
> > After I updated GPIO library for the case Benjamin has with CP2112,
> > I have a brief look into the CP2112 driver itself.
> >
> > From GPIO perspective it has two main (maitenance) issues:
> > - usage of ->to_irq() with IRQ chip present;
> > - having IRQ chip not immutable.
> >
> > Besides that there are plenty small cleanups here and there.
> > Hence this series.
>
> Any comments on this?
Gentle ping^2 for this...
Anything should I do to improve it or is it okay to go as is?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] HID: logitech-hidpp: rework one more time the retries attempts
From: Linux regression tracking (Thorsten Leemhuis) @ 2023-08-04 9:13 UTC (permalink / raw)
To: bentiss, Filipe Laíns, Bastien Nocera, Jiri Kosina, Greg KH
Cc: linux-input, linux-kernel, Benjamin Tissoires, stable,
Linux kernel regressions list
In-Reply-To: <20230621-logitech-fixes-v2-1-3635f7f9c8af@kernel.org>
Hi Benjamin, /me again! :-D
On 12.07.23 17:02, bentiss@kernel.org wrote:
> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> Extract the internal code inside a helper function, fix the
> initialization of the parameters used in the helper function
> (`hidpp->answer_available` was not reset and `*response` wasn't either),
> and use a `do {...} while();` loop.
>
> Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy")
> Cc: stable@vger.kernel.org
From what I understood there was hope that this would cure the last
remains (occasional init problems iirc) of the recent regressions with
this driver and their fixes. But things look stalled. Is there a reason?
Lack of reviews? Is there nevertheless hope that this will make it at
least into 6.6?
Ciao, Thorsten
> Reviewed-by: Bastien Nocera <hadess@hadess.net>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
> as requested by https://lore.kernel.org/all/CAHk-=wiMbF38KCNhPFiargenpSBoecSXTLQACKS2UMyo_Vu2ww@mail.gmail.com/
> This is a rewrite of that particular piece of code.
> ---
> Changes in v2:
> - added __must_hold() for KASAN
> - Reworked the comment describing the functions and their return values
> - Link to v1: https://lore.kernel.org/r/20230621-logitech-fixes-v1-1-32e70933c0b0@redhat.com
> ---
> drivers/hid/hid-logitech-hidpp.c | 115 +++++++++++++++++++++++++--------------
> 1 file changed, 75 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index 129b01be488d..09ba2086c95c 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -275,21 +275,22 @@ static int __hidpp_send_report(struct hid_device *hdev,
> }
>
> /*
> - * hidpp_send_message_sync() returns 0 in case of success, and something else
> - * in case of a failure.
> - * - If ' something else' is positive, that means that an error has been raised
> - * by the protocol itself.
> - * - If ' something else' is negative, that means that we had a classic error
> - * (-ENOMEM, -EPIPE, etc...)
> + * Effectively send the message to the device, waiting for its answer.
> + *
> + * Must be called with hidpp->send_mutex locked
> + *
> + * Same return protocol than hidpp_send_message_sync():
> + * - success on 0
> + * - negative error means transport error
> + * - positive value means protocol error
> */
> -static int hidpp_send_message_sync(struct hidpp_device *hidpp,
> +static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
> struct hidpp_report *message,
> struct hidpp_report *response)
> {
> - int ret = -1;
> - int max_retries = 3;
> + int ret;
>
> - mutex_lock(&hidpp->send_mutex);
> + __must_hold(&hidpp->send_mutex);
>
> hidpp->send_receive_buf = response;
> hidpp->answer_available = false;
> @@ -300,47 +301,74 @@ static int hidpp_send_message_sync(struct hidpp_device *hidpp,
> */
> *response = *message;
>
> - for (; max_retries != 0 && ret; max_retries--) {
> - ret = __hidpp_send_report(hidpp->hid_dev, message);
> + ret = __hidpp_send_report(hidpp->hid_dev, message);
> + if (ret) {
> + dbg_hid("__hidpp_send_report returned err: %d\n", ret);
> + memset(response, 0, sizeof(struct hidpp_report));
> + return ret;
> + }
>
> - if (ret) {
> - dbg_hid("__hidpp_send_report returned err: %d\n", ret);
> - memset(response, 0, sizeof(struct hidpp_report));
> - break;
> - }
> + 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));
> + return -ETIMEDOUT;
> + }
>
> - 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;
> - break;
> - }
> + if (response->report_id == REPORT_ID_HIDPP_SHORT &&
> + response->rap.sub_id == HIDPP_ERROR) {
> + ret = response->rap.params[1];
> + dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
> + return ret;
> + }
>
> - if (response->report_id == REPORT_ID_HIDPP_SHORT &&
> - response->rap.sub_id == HIDPP_ERROR) {
> - ret = response->rap.params[1];
> - dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
> + if ((response->report_id == REPORT_ID_HIDPP_LONG ||
> + response->report_id == REPORT_ID_HIDPP_VERY_LONG) &&
> + response->fap.feature_index == HIDPP20_ERROR) {
> + ret = response->fap.params[1];
> + dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * hidpp_send_message_sync() returns 0 in case of success, and something else
> + * in case of a failure.
> + *
> + * See __do_hidpp_send_message_sync() for a detailed explanation of the returned
> + * value.
> + */
> +static int hidpp_send_message_sync(struct hidpp_device *hidpp,
> + struct hidpp_report *message,
> + struct hidpp_report *response)
> +{
> + int ret;
> + int max_retries = 3;
> +
> + mutex_lock(&hidpp->send_mutex);
> +
> + do {
> + ret = __do_hidpp_send_message_sync(hidpp, message, response);
> + if (ret != HIDPP20_ERROR_BUSY)
> break;
> - }
>
> - if ((response->report_id == REPORT_ID_HIDPP_LONG ||
> - response->report_id == REPORT_ID_HIDPP_VERY_LONG) &&
> - response->fap.feature_index == HIDPP20_ERROR) {
> - ret = response->fap.params[1];
> - if (ret != HIDPP20_ERROR_BUSY) {
> - dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
> - break;
> - }
> - dbg_hid("%s:got busy hidpp 2.0 error %02X, retrying\n", __func__, ret);
> - }
> - }
> + dbg_hid("%s:got busy hidpp 2.0 error %02X, retrying\n", __func__, ret);
> + } while (--max_retries);
>
> mutex_unlock(&hidpp->send_mutex);
> return ret;
>
> }
>
> +/*
> + * hidpp_send_fap_command_sync() returns 0 in case of success, and something else
> + * in case of a failure.
> + *
> + * See __do_hidpp_send_message_sync() for a detailed explanation of the returned
> + * value.
> + */
> static int hidpp_send_fap_command_sync(struct hidpp_device *hidpp,
> u8 feat_index, u8 funcindex_clientid, u8 *params, int param_count,
> struct hidpp_report *response)
> @@ -373,6 +401,13 @@ static int hidpp_send_fap_command_sync(struct hidpp_device *hidpp,
> return ret;
> }
>
> +/*
> + * hidpp_send_rap_command_sync() returns 0 in case of success, and something else
> + * in case of a failure.
> + *
> + * See __do_hidpp_send_message_sync() for a detailed explanation of the returned
> + * value.
> + */
> static int hidpp_send_rap_command_sync(struct hidpp_device *hidpp_dev,
> u8 report_id, u8 sub_id, u8 reg_address, u8 *params, int param_count,
> struct hidpp_report *response)
>
> ---
> base-commit: 87854366176403438d01f368b09de3ec2234e0f5
> change-id: 20230621-logitech-fixes-a4c0e66ea2ad
>
> Best regards,
^ permalink raw reply
* Fwd: Regression: ALS/ACS stops working on amd-sfh
From: Bagas Sanjaya @ 2023-08-04 12:45 UTC (permalink / raw)
To: Basavaraj Natikar, Jiri Kosina, Kai-Heng Feng
Cc: Linux Kernel Mailing List, Linux Regressions, Linux Input Devices
Hi,
I notice a very concise regression report on Bugzilla [1]. That is,
quoting from it:
> Since commit a33e5e393171ae8384d3381db5cd159ba877cfcb ("HID: amd_sfh: Fix illuminance value"), the in_illuminance_raw is 0 all the time.
>
> Before that commit, the ACS/ALS has normal value.
See Bugzilla for the full thread.
Anyway, I'm adding this regression to be tracked by regzbot:
#regzbot introduced: a33e5e393171ae https://bugzilla.kernel.org/show_bug.cgi?id=217762
#regzbot title: Fixing in_illuminance_raw value hard-codes ACS/ALS to 0
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217762
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply
* Fwd: DELL0A78:00 27C6:0D42 Touchpad (gestures) doesn't work properly after resuming from suspend.
From: Bagas Sanjaya @ 2023-08-04 12:59 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Dmitry Torokhov, Hans de Goede,
Thomas Weißschuh, Raul E Rangel, Douglas Anderson, bishal
Cc: Linux Kernel Mailing List, Linux Input Devices
Hi,
I notice a bug report on Bugzilla [1]. Quoting from it:
> Description:
> ------------
> The touchpad doesn't function normally after resuming from suspend. Touch works most of the time so does the hardware click buttons. The things which don't work are touchpad multitouch gestures (2 fingers and 3 fingers) and cursor movement is also somewhat laggy.
>
> Workaround:
> -----------
> removing the module i2c_hid_acpi just before suspend and adding it after resume seems to solve the problem.
>
> Script: (output of `cat /usr/lib/systemd/system-sleep/make-touchpad-work.sleep`)
> -----------------------------------------------------------------------------
>
> #!/bin/sh
>
> case $1/$2 in
> pre/*)
> echo "Going to $2..."
> # Place your pre suspend commands here, or `exit 0` if no pre suspend action required
> echo "Removing i2c_hid_acpi module before suspend."
> modprobe -r i2c_hid_acpi
> ;;
> post/*)
> echo "Waking up from $2..."
> # Place your post suspend (resume) commands here, or `exit 0` if no post suspend action required
> sleep 2
> echo "Adding i2c_hid_acpi module after suspend (before resuming)."
> modprobe i2c_hid_acpi
> ;;
> esac
> -----------------------------------------------------------------------------
>
> When was it discovered?
> -------------------------
> I had prior hardware issues with the touchpad so I didn't notice
> it for a very long time, each time such an issue appeared I thought it was a hardware issue. But the issue is still there even after fixing the hardware (loose ribbon cable). Before the hardware issue, there was an issue with resuming from suspend on my laptop (because of laptop begin particularly new AMD variant). So, if I remember correctly, the touchpad worked fine for particular duration between suspend issue being fixed and hardware issue appearing.
>
> GNU/Linux version:
> ------------------
> Linux localhost.localdomain 6.5.0-rc4-1-default+
> #1 SMP PREEMPT_DYNAMIC Thu Aug 3 20:15:04 +0545 2023 x86_64 x86_64 x86_64 GNU/Linux
>
> Touchpad information:
> ------------------------
> PS/2 00.0: 10500 PS/2 Mouse
> [Created at input.249]
> Unique ID: AH6Q.rKa1+aijZtE
> Hardware Class: mouse
> Model: "DELL0A78:00 27C6:0D42 Touchpad"
> Vendor: 0x27c6
> Device: 0x0d42 "DELL0A78:00 27C6:0D42 Touchpad"
> Compatible to: int 0x0210 0x0001
> Device File: /dev/input/mice (/dev/input/mouse2)
> Device Files: /dev/input/mice, /dev/input/mouse2, /dev/input/event3, /dev/input/by-path/platform-AMDI0010:03-event-mouse, /dev/input/by-path/platform-AMDI0010:03-mouse
> Device Number: char 13:63 (char 13:34)
> Driver Info #0:
> Buttons: 1
> Wheels: 0
> XFree86 Protocol: explorerps/2
> GPM Protocol: exps2
> Config Status: cfg=no, avail=yes, need=no, active=unknown
>
>
> Prior to testing on mainline kernel, it was tested on opensuse tumbleweed and reported here: https://bugzilla.suse.com/show_bug.cgi?id=1212779
See Bugzilla for the full thread.
FYI, I forward the BZ report because it was assigned to generic `Kernel`
component instead, which missed linux-input list. I also add the reporter's
address to To: list so that you can reach him without having to go to
Bugzilla.
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217761
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply
* Re: Fwd: 6.5 - 6.4.7 Regression : ASUS UM5302TA Keyboard don't work
From: August Wikerfors @ 2023-08-04 15:26 UTC (permalink / raw)
To: Linux regressions mailing list
Cc: Mario Limonciello, Linux Input Devices, ACPI Asus,
Linux x86 Platform Drivers, Linux Kernel Mailing List,
Bagas Sanjaya, Dmitry Torokhov, Corentin Chary, Guilhem Lettron
In-Reply-To: <8ee87fe1-684f-ad59-21c7-4401a4e70bee@leemhuis.info>
On 2023-07-30 06:49, Linux regression tracking (Thorsten Leemhuis) wrote:
> Lo!
>
> On 30.07.23 04:41, Bagas Sanjaya wrote:
>>
>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>
>>> On a kernel 6.4.5 and less, the keyboard is working fine.
>>>
>>> Beginning with 6.5 rc1 and 6.4.7 any key don't respond.
>
> That is a AMD Ryzen Laptop. And if that really started from
> v6.4.6..v6.4.7 then I guess there is a decent chance that this is caused
> by ```ACPI: resource: Remove "Zen" specific match and quirks``` from
> Mario. Hence adding him to the list of recipients.
Confirmed now, see https://bugzilla.kernel.org/show_bug.cgi?id=217726#c9
#regzbot introduced: a9c4a912b7dc7ff922d4b9261160c001558f9755
^ permalink raw reply
* Re: [PATCH V2] Input: xpad - Add HyperX Clutch Gladiate Support
From: HP Dev @ 2023-08-04 20:19 UTC (permalink / raw)
To: rrameshbabu
Cc: carl.ng, chris.toledanes, dmitry.torokhov, hphyperxdev,
linux-input, maxwell.nguyen
In-Reply-To: <87o7k027p9.fsf@nvidia.com>
Hi Rahul,
Is there anything else we need to provide? When can we expect the patch to be rolled in?
^ permalink raw reply
* Fwd: keyboard not working Asus Expertbook B2502CVA
From: Bagas Sanjaya @ 2023-08-05 10:56 UTC (permalink / raw)
To: Dmitry Torokhov, Corentin Chary, gnap
Cc: Linux Kernel Mailing List, Linux Input Devices, ACPI Asus
Hi,
I notice a bug report on Bugzilla [1]. Quoting from it:
> Hi everynoe,
>
> Component: Asus Expertbook B2502CVA
> OS: Ubuntu 22.04.2 LTS
>
> I am having a keyboard issue after installing Ubuntu 22.04 LTS on my Asus ExpertBook B2502CVA, I discovered that the built-in keyboard is not functioning. The keyboard works perfectly under Windows 11, which leads me to reasonably suspect a hardware compatibility issue with Linux.
>
> I found that BUG 216158, Bug 216864, Bug 217323 has similarities to my situation, attachment is my dmesg.
See Bugzilla for the full thread and attached logs (dmesg, dmidecode,
lsmod, and xinput outputs).
AFAIK, this looks like hardware support for Asus B2502CVA is missing
(maybe the quirk?). The reporter also confirms that this bug is
also present on current mainline kernel.
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217760
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply
* Re: Fwd: 6.5 - 6.4.7 Regression : ASUS UM5302TA Keyboard don't work
From: Hans de Goede @ 2023-08-05 13:09 UTC (permalink / raw)
To: August Wikerfors, Linux regressions mailing list
Cc: Mario Limonciello, Linux Input Devices, ACPI Asus,
Linux x86 Platform Drivers, Linux Kernel Mailing List,
Bagas Sanjaya, Dmitry Torokhov, Corentin Chary, Guilhem Lettron
In-Reply-To: <b7df9a02-3b81-4f8c-aeba-222c298180d4@augustwikerfors.se>
Hi,
On 8/4/23 17:26, August Wikerfors wrote:
> On 2023-07-30 06:49, Linux regression tracking (Thorsten Leemhuis) wrote:
>> Lo!
>>
>> On 30.07.23 04:41, Bagas Sanjaya wrote:
>>>
>>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>>
>>>> On a kernel 6.4.5 and less, the keyboard is working fine.
>>>>
>>>> Beginning with 6.5 rc1 and 6.4.7 any key don't respond.
>>
>> That is a AMD Ryzen Laptop. And if that really started from
>> v6.4.6..v6.4.7 then I guess there is a decent chance that this is caused
>> by ```ACPI: resource: Remove "Zen" specific match and quirks``` from
>> Mario. Hence adding him to the list of recipients.
>
> Confirmed now, see https://bugzilla.kernel.org/show_bug.cgi?id=217726#c9
>
> #regzbot introduced: a9c4a912b7dc7ff922d4b9261160c001558f9755
We just have received 2 bug reports for Fedora which I believe are also
this issue (not confirmed yet):
https://bugzilla.redhat.com/show_bug.cgi?id=2229165
https://bugzilla.redhat.com/show_bug.cgi?id=2229317
I'm going to create a Fedora 6.4.y test-kernel with a9c4a912b7dc7ff
reverted.
IMHO we really should revert a9c4a912b7dc7ff upstream,
at least for the 6.4.y series where it seems to be doing
more harm then good.
And propably also for 6.5-rc# for now until we figure out
a better solution.
Regards,
Hans
^ permalink raw reply
* Re: Fwd: 6.5 - 6.4.7 Regression : ASUS UM5302TA Keyboard don't work
From: Linux regression tracking (Thorsten Leemhuis) @ 2023-08-05 13:37 UTC (permalink / raw)
To: Hans de Goede, Mario Limonciello
Cc: Linux Input Devices, ACPI Asus, Linux x86 Platform Drivers,
Linux Kernel Mailing List, Bagas Sanjaya, Dmitry Torokhov,
Corentin Chary, Guilhem Lettron, Linux regressions mailing list,
August Wikerfors
In-Reply-To: <cc9e37b4-b5cb-fd4d-84b8-5b824afe710a@redhat.com>
On 05.08.23 15:09, Hans de Goede wrote:
> On 8/4/23 17:26, August Wikerfors wrote:
>> On 2023-07-30 06:49, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> Lo!
>>>
>>> On 30.07.23 04:41, Bagas Sanjaya wrote:
>>>>
>>>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>>>
>>>>> On a kernel 6.4.5 and less, the keyboard is working fine.
>>>>>
>>>>> Beginning with 6.5 rc1 and 6.4.7 any key don't respond.
>>>
>>> That is a AMD Ryzen Laptop. And if that really started from
>>> v6.4.6..v6.4.7 then I guess there is a decent chance that this is caused
>>> by ```ACPI: resource: Remove "Zen" specific match and quirks``` from
>>> Mario. Hence adding him to the list of recipients.
>>
>> Confirmed now, see https://bugzilla.kernel.org/show_bug.cgi?id=217726#c9
>>
>> #regzbot introduced: a9c4a912b7dc7ff922d4b9261160c001558f9755
>
> We just have received 2 bug reports for Fedora which I believe are also
> this issue (not confirmed yet):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2229165
> https://bugzilla.redhat.com/show_bug.cgi?id=2229317
Interesting, thx for sharing! I just asked people there to share
dmidecode and acpidump to check if those are different machines.
> I'm going to create a Fedora 6.4.y test-kernel with a9c4a912b7dc7ff
> reverted.
>
> IMHO we really should revert a9c4a912b7dc7ff upstream,
> at least for the 6.4.y series
That is unlikely to be a option, because as explained in
Documentation/process/handling-regressions.rst Greg's stance in cases
like this usually is "fix it in mainline, and then I'll pick up the fix".
> where it seems to be doing more harm then good.
>
> And propably also for 6.5-rc# for now until we figure out
> a better solution.
Hmmm, looks like the issue and the fix for one of the machines[1] didn't
make much progress this week, so I tend to agree. Mario?
[1]
https://lore.kernel.org/all/20230728191408.18141-1-mario.limonciello@amd.com/
Ciao, Thorsten
^ permalink raw reply
* Re: Fwd: 6.5 - 6.4.7 Regression : ASUS UM5302TA Keyboard don't work
From: Hans de Goede @ 2023-08-06 15:19 UTC (permalink / raw)
To: August Wikerfors, Linux regressions mailing list
Cc: Mario Limonciello, Linux Input Devices, ACPI Asus,
Linux x86 Platform Drivers, Linux Kernel Mailing List,
Bagas Sanjaya, Dmitry Torokhov, Corentin Chary, Guilhem Lettron
In-Reply-To: <cc9e37b4-b5cb-fd4d-84b8-5b824afe710a@redhat.com>
Hi,
On 8/5/23 15:09, Hans de Goede wrote:
> Hi,
>
> On 8/4/23 17:26, August Wikerfors wrote:
>> On 2023-07-30 06:49, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> Lo!
>>>
>>> On 30.07.23 04:41, Bagas Sanjaya wrote:
>>>>
>>>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>>>
>>>>> On a kernel 6.4.5 and less, the keyboard is working fine.
>>>>>
>>>>> Beginning with 6.5 rc1 and 6.4.7 any key don't respond.
>>>
>>> That is a AMD Ryzen Laptop. And if that really started from
>>> v6.4.6..v6.4.7 then I guess there is a decent chance that this is caused
>>> by ```ACPI: resource: Remove "Zen" specific match and quirks``` from
>>> Mario. Hence adding him to the list of recipients.
>>
>> Confirmed now, see https://bugzilla.kernel.org/show_bug.cgi?id=217726#c9
>>
>> #regzbot introduced: a9c4a912b7dc7ff922d4b9261160c001558f9755
>
> We just have received 2 bug reports for Fedora which I believe are also
> this issue (not confirmed yet):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2229165
> https://bugzilla.redhat.com/show_bug.cgi?id=2229317
>
> I'm going to create a Fedora 6.4.y test-kernel with a9c4a912b7dc7ff
> reverted.
>
> IMHO we really should revert a9c4a912b7dc7ff upstream,
> at least for the 6.4.y series where it seems to be doing
> more harm then good.
>
> And propably also for 6.5-rc# for now until we figure out
> a better solution.
Testing has shown that reverting also fixes the 2 Fedora bugs.
I have submitted a revert of a9c4a912b7dc ("ACPI: resource: Remove "Zen" specific match and quirks") upstream now, because I believe that that is the best way to fix the regressions caused by this (until we figure out a better way to deal with the kbd interrupt trigger-type issues):
https://lore.kernel.org/linux-acpi/20230806151453.10690-1-hdegoede@redhat.com/
Regards,
Hans
^ 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