* Re: [PATCH] dt-bindings: input: touchscreen: st,stmfts: convert to dtschema
From: Rob Herring @ 2023-01-30 21:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, Rob Herring, linux-kernel, linux-arm-kernel,
Maxime Coquelin, Alexandre Torgue, Krzysztof Kozlowski,
linux-stm32, linux-input, Dmitry Torokhov
In-Reply-To: <20230127202040.196411-1-krzysztof.kozlowski@linaro.org>
On Fri, 27 Jan 2023 21:20:40 +0100, Krzysztof Kozlowski wrote:
> Convert the ST-Microelectronics FingerTip touchscreen controller
> bindings to DT schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> .../bindings/input/touchscreen/st,stmfts.txt | 41 -----------
> .../bindings/input/touchscreen/st,stmfts.yaml | 72 +++++++++++++++++++
> 2 files changed, 72 insertions(+), 41 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: mtk-pmic-keys: Ignore power button if pressed before driver loads
From: Mattijs Korpershoek @ 2023-01-30 17:21 UTC (permalink / raw)
To: Arınç ÜNAL, Dmitry Torokhov, Matthias Brugger,
AngeloGioacchino Del Regno, Jonathan Cameron
Cc: linux-input, Linux ARM, moderated list:ARM/Mediatek SoC support,
linux-kernel, Frank Wunderlich, erkin.bozoglu
In-Reply-To: <883798d8-f7d9-eadc-1343-7d241741ff67@arinc9.com>
Hi Arınç,
On lun., janv. 30, 2023 at 16:36, Arınç ÜNAL <arinc.unal@arinc9.com> wrote:
> Hi all,
>
> The power button on my Bananapi BPI-R2 (MT7623NI SoC, mt6323-keys) is
> shorted, so the device automatically boots when there's power. This
> causes the device to reboot when KEYBOARD_MTK_PMIC is loaded because the
> driver sees the power button being pressed.
What evidence do you have that there is actually a "press" event being
received by userspace? Did you tested this with evtest or something
similar?
If a "power button press" is generated, than I imagine that a userspace
process must receive it and halt the system, right?
The PMIC also has a feature to shutdown in case detect a long key-press,
which is controlled by the mediatek,long-press-mode device-tree
property.
So is it the pmic that shutdown your board (probably no evidence in
logs, just a "power cut" behaviour) or is it userspace?
>
> I was wondering if it's possible to change the driver in a way that
> doesn't break in this situation. Maybe don't do anything if the first
> state of the the power button the driver sees is being pressed, and if
> the state doesn't change.
If the driver is an issue, can't we blacklist it from being probed
instead? or do you want to use the home key feature that that same
driver provides?
Hope that helps,
Mattijs
>
> To address an edge case, if the power button was being pressed before
> the driver loads, look for if it's ever released. Only after then start
> working as usual.
>
> Looking forward to hearing your thoughts.
> Arınç
^ permalink raw reply
* [dtor-input:master] BUILD SUCCESS 04f8b4ea20c85f579e8bbcd9da138779e9d4d36f
From: kernel test robot @ 2023-01-30 16:42 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git master
branch HEAD: 04f8b4ea20c85f579e8bbcd9da138779e9d4d36f Input: pmic8xxx-keypad - fix a Kconfig spelling mistake & hyphenation
elapsed time: 720m
configs tested: 62
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
um i386_defconfig
x86_64 allnoconfig
i386 randconfig-a001-20230130
i386 randconfig-a004-20230130
i386 randconfig-a003-20230130
um x86_64_defconfig
x86_64 rhel-8.3-func
i386 randconfig-a002-20230130
i386 randconfig-a005-20230130
x86_64 randconfig-a001-20230130
arc defconfig
x86_64 defconfig
x86_64 randconfig-a003-20230130
x86_64 rhel-8.3-kselftests
s390 allmodconfig
x86_64 rhel-8.3
x86_64 randconfig-a004-20230130
alpha defconfig
x86_64 randconfig-a002-20230130
x86_64 randconfig-a006-20230130
s390 defconfig
x86_64 randconfig-a005-20230130
x86_64 rhel-8.3-syz
x86_64 rhel-8.3-kunit
x86_64 rhel-8.3-kvm
x86_64 rhel-8.3-bpf
x86_64 allyesconfig
i386 defconfig
arm defconfig
arc randconfig-r043-20230129
arm randconfig-r046-20230129
s390 allyesconfig
arm64 allyesconfig
arm allyesconfig
arm randconfig-r046-20230130
arc randconfig-r043-20230130
i386 allyesconfig
powerpc allnoconfig
sh allmodconfig
mips allyesconfig
powerpc allmodconfig
m68k allyesconfig
m68k allmodconfig
arc allyesconfig
alpha allyesconfig
clang tested configs:
x86_64 rhel-8.3-rust
i386 randconfig-a016-20230130
i386 randconfig-a015-20230130
i386 randconfig-a014-20230130
hexagon randconfig-r041-20230129
riscv randconfig-r042-20230129
riscv randconfig-r042-20230130
s390 randconfig-r044-20230129
hexagon randconfig-r045-20230130
x86_64 randconfig-a013-20230130
x86_64 randconfig-a011-20230130
s390 randconfig-r044-20230130
hexagon randconfig-r041-20230130
hexagon randconfig-r045-20230129
x86_64 randconfig-a014-20230130
x86_64 randconfig-a012-20230130
x86_64 randconfig-a015-20230130
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply
* Re: [PATCH 0/4] DeviceTree Support for USB-HID Devices and CP2112
From: Benjamin Tissoires @ 2023-01-30 16:29 UTC (permalink / raw)
To: Danny Kaehn
Cc: robh+dt, krzysztof.kozlowski+dt, jikos, devicetree, linux-input,
ethan.twardy
In-Reply-To: <20230128202622.12676-1-kaehndan@gmail.com>
Hi Danny,
On Sat, Jan 28, 2023 at 9:26 PM Danny Kaehn <kaehndan@gmail.com> wrote:
>
> This patchset allows USB-HID devices to have DeviceTree bindings through sharing
> the USB of_node with the HID driver, and adds such a binding and driver
> implementation for the CP2112 USB to SMBus Bridge (which necessitated the
> USB-HID change). This change allows a CP2112 permanently attached in hardware to
> be described in DT and interoperate with other drivers, and exposed the threaded
> interrupt bug fixed in patch 0003.
That series is very interesting. I always wondered how I could declare
an I2C device attached to the CP2112 over USB. Ideally if you can make
this compatible with ACPI SSDT, that would be even better :) (one can
always dream).
>
> Plese correct if the assumption made that there is a 1:1 correlation between
> a USB device and its HID device is not always true. If so, patch 0002 would
> then need to be reworked.
I am not sure I understand patch 2 completely, but if your assumption
is that each struct usb_interface can have at most one hid device, it
seems that it is the case. However, nothing prevents another hid
driver to add one more hid device on top of that USB dev. For
instance, hid-logitech-dj does that: when it enumerates the devices
connected to the wireless receiver, it creates matching HID devices
with the parent being the current HID dev.
AFAICT, we already have DT enumeration for i2c-hid devices, so
probably your solution is correct. Though the DT enumeration in
i2c-hid-of.c relies on .of_match_table, which seems a little bit more
integrated than this series (but I don't know enough of DT
unfortunately).
So I personally won't push against that series, but I'd still like to
have a rough idea on what is missing in patch 2 if we consider that
your assumption might not always be the case.
Maybe (just random brain fart) we could have a separate usbhid-of.c in
the usbhid subdir that builds up the same OF matching that
i2c-hid-of.c is doing?
Cheers,
Benjamin
>
>
> Danny Kaehn (4):
> dt-bindings: hid: Add CP2112 HID USB to SMBus Bridge
> Share USB device devicetree node with child HID device
> Fix CP2112 driver not registering GPIO IRQ chip as threaded
> CP2112 Devicetree Support
>
> .../bindings/hid/silabs,cp2112.yaml | 82 +++++++++++++++++++
> drivers/hid/hid-cp2112.c | 10 +++
> drivers/hid/usbhid/hid-core.c | 2 +
> 3 files changed, 94 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hid/silabs,cp2112.yaml
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 2/9] HID: hyperv: Constify lowlevel HID driver
From: Wei Liu @ 2023-01-30 15:42 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Basavaraj Natikar, Jiri Kosina, Benjamin Tissoires,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Filipe Laíns, Srinivas Pandruvada, Maximilian Luz,
Corentin Chary, Hans de Goede, Mark Gross, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, linux-input,
linux-kernel, linux-hyperv, platform-driver-x86, acpi4asus-user,
greybus-dev, linux-staging
In-Reply-To: <20230130-hid-const-ll-driver-v1-2-3fc282b3b1d0@weissschuh.net>
On Mon, Jan 30, 2023 at 03:59:38AM +0000, Thomas Weißschuh wrote:
> Since commit 52d225346904 ("HID: Make lowlevel driver structs const")
> the lowlevel HID drivers are only exposed as const.
>
> Take advantage of this to constify the underlying structure, too.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Wei Liu <wei.liu@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 3/4] dt-bindings: input: pwm-beeper: add volume
From: Rob Herring @ 2023-01-30 15:29 UTC (permalink / raw)
To: Manuel Traut
Cc: Krzysztof Kozlowski, linux-input, Rob Herring, Frieder Schrempf,
linux-kernel, devicetree, Dmitry Torokhov
In-Reply-To: <20230130135650.1407156-4-manuel.traut@mt.com>
On Mon, 30 Jan 2023 14:56:49 +0100, Manuel Traut wrote:
> Adds an array of supported volume levels and a default volume level.
>
> Signed-off-by: Manuel Traut <manuel.traut@mt.com>
> ---
> .../devicetree/bindings/input/pwm-beeper.yaml | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/pwm-beeper.example.dtb: beeper: 'default-volume-level', 'volume-levels' do not match any of the regexes: 'pinctrl-[0-9]+'
From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/pwm-beeper.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230130135650.1407156-4-manuel.traut@mt.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PASEMI] Nemo board doesn't reboot anymore after the commit "HID: usbhid: Add ALWAYS_POLL quirk for some mice" #forregzbot
From: Linux kernel regression tracking (#update) @ 2023-01-30 15:21 UTC (permalink / raw)
To: linux-input, linuxppc-dev, regressions@lists.linux.dev
In-Reply-To: <d0119f9f-421c-069a-91f6-ff7a0187038d@leemhuis.info>
[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]
On 22.12.22 12:24, Thorsten Leemhuis wrote:
> On 22.12.22 11:42, Christian Zigotzky wrote:
>>
>> The Nemo board [1] doesn't reboot anymore since the final kernel 6.1.
>> The reboot works with the RC8 of kernel 6.1.
>> Actually, a reboot works but the CFE firmware is not loaded. Maybe there
>> is still something in the memory after the reboot.
>>
>> I bisected today. [2]
>
> Thanks for the report. To be sure below issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
> tracking bot:
>
> #regzbot ^introduced f6d910a89a23
> #regzbot title hid: PASEMI Nemo board doesn't reboot anymore
> #regzbot ignore-activity
#regzbot fix: cbf44580ce6b310272a73
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
^ permalink raw reply
* Re: [PATCH] HID: add KEY_CAMERA_FOCUS event in HID
From: Jiri Kosina @ 2023-01-30 14:28 UTC (permalink / raw)
To: qi feng; +Cc: linux-input, linux-kernel, fengqi, Benjamin Tissoires
In-Reply-To: <CACOZ=ZWB3grJKn7wAZEZ0BDyN7KJF4VWUTNs-mPxeoW_oiR7=g@mail.gmail.com>
On Sun, 29 Jan 2023, qi feng wrote:
> Hi,
> Our Bluetooth Handle needs the focus function, which is missing in the
> current map
> If our setting is unreasonable, do you have other suggested values
If the device is under your control, wouldn't it be better to let it
produce something more defined by HID standard? (see e.g. 0x90 -- Camera
Control Page).
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v9 4/4] input: pwm-beeper: set volume levels by devicetree
From: Manuel Traut @ 2023-01-30 13:56 UTC (permalink / raw)
To: linux-kernel
Cc: Frieder Schrempf, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Manuel Traut, linux-input, devicetree
In-Reply-To: <20230130135650.1407156-1-manuel.traut@mt.com>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
Add devicetree bindings to define supported volume levels and the
default volume level.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Manuel Traut <manuel.traut@mt.com>
Tested-by: Manuel Traut <manuel.traut@mt.com>
---
drivers/input/misc/pwm-beeper.c | 73 +++++++++++++++++++++++++--------
1 file changed, 55 insertions(+), 18 deletions(-)
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 214d3fa0a06d..fc367a249490 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -93,7 +93,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
state.enabled = true;
state.period = period;
- pwm_set_relative_duty_cycle(&state, beeper->volume_levels[beeper->volume], 1000);
+ pwm_set_relative_duty_cycle(&state, beeper->volume_levels[beeper->volume], 10000);
error = pwm_apply_state(beeper->pwm, &state);
if (error)
@@ -181,8 +181,9 @@ static int pwm_beeper_probe(struct platform_device *pdev)
struct pwm_beeper *beeper;
struct pwm_state state;
u32 bell_frequency;
- int error;
+ int error, i, length;
size_t size;
+ u32 value;
beeper = devm_kzalloc(dev, sizeof(*beeper), GFP_KERNEL);
if (!beeper)
@@ -228,23 +229,59 @@ static int pwm_beeper_probe(struct platform_device *pdev)
beeper->bell_frequency = bell_frequency;
- beeper->max_volume = 4;
-
- size = sizeof(*beeper->volume_levels) *
- (beeper->max_volume + 1);
-
- beeper->volume_levels = devm_kzalloc(&(pdev->dev), size,
- GFP_KERNEL);
- if (!beeper->volume_levels)
- return -ENOMEM;
-
- beeper->volume_levels[0] = 0;
- beeper->volume_levels[1] = 80;
- beeper->volume_levels[2] = 200;
- beeper->volume_levels[3] = 400;
- beeper->volume_levels[4] = 5000;
+ /* determine the number of volume levels */
+ length = device_property_read_u32_array(&pdev->dev, "volume-levels-bp", NULL, 0);
+ if (length <= 0) {
+ dev_dbg(&pdev->dev, "no volume levels specified, using max volume\n");
+ beeper->max_volume = 1;
+ } else
+ beeper->max_volume = length;
+
+ /* read volume levels from DT property */
+ if (beeper->max_volume > 0) {
+ size = sizeof(*beeper->volume_levels) * beeper->max_volume;
+
+ beeper->volume_levels = devm_kzalloc(&(pdev->dev), size,
+ GFP_KERNEL);
+ if (!beeper->volume_levels)
+ return -ENOMEM;
+
+ if (length > 0) {
+ error = device_property_read_u32_array(&pdev->dev, "volume-levels-bp",
+ beeper->volume_levels,
+ beeper->max_volume);
+
+ if (error < 0)
+ return error;
+
+ error = device_property_read_u32(&pdev->dev, "default-volume-level-bp",
+ &value);
+
+ if (error < 0) {
+ dev_dbg(&pdev->dev, "no default volume specified, using max volume\n");
+ value = beeper->max_volume - 1;
+ } else {
+ for (i = 0; i < length; i++) {
+ if (beeper->volume_levels[i] == value) {
+ value = i;
+ break;
+ }
+ }
+ if (value != i) {
+ dev_dbg(&pdev->dev,
+ "default-volume-level-bp %d invalid, using %d\n",
+ value, beeper->max_volume - 1);
+ value = beeper->max_volume - 1;
+ }
+ }
+ } else {
+ beeper->volume_levels[0] = 5000;
+ value = 0;
+ }
- beeper->volume = beeper->max_volume;
+ beeper->volume = value;
+ beeper->max_volume--;
+ }
beeper->input = devm_input_allocate_device(dev);
if (!beeper->input) {
--
2.39.0
^ permalink raw reply related
* [PATCH v9 3/4] dt-bindings: input: pwm-beeper: add volume
From: Manuel Traut @ 2023-01-30 13:56 UTC (permalink / raw)
To: linux-kernel
Cc: Manuel Traut, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
In-Reply-To: <20230130135650.1407156-1-manuel.traut@mt.com>
Adds an array of supported volume levels and a default volume level.
Signed-off-by: Manuel Traut <manuel.traut@mt.com>
---
.../devicetree/bindings/input/pwm-beeper.yaml | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
index 1ebc3a46d934..ca9efab7efbf 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.yaml
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
@@ -25,6 +25,21 @@ properties:
beeper-hz:
description: bell frequency in Hz
+ volume-levels-bp:
+ description: >
+ Array of PWM duty cycle values that correspond to
+ linear volume levels. These need to be in the range of
+ 0 to 5000, while 0 means 0% duty cycle (mute) and 5000
+ means 50% duty cycle (max volume).
+ Please note that the actual volume of most beepers is
+ highly non-linear, which means that low volume levels
+ are probably somewhere in the range of 10 to 300 (0.1-3%
+ duty cycle).
+
+ default-volume-level-bp:
+ description: >
+ The default volume level.
+
required:
- compatible
- pwms
@@ -36,4 +51,6 @@ examples:
beeper {
compatible = "pwm-beeper";
pwms = <&pwm0>;
+ volume-levels = <0 8 20 40 500>;
+ default-volume-level = <4>;
};
--
2.39.0
^ permalink raw reply related
* [PATCH v9 2/4] input: pwm-beeper: add feature to set volume via sysfs
From: Manuel Traut @ 2023-01-30 13:56 UTC (permalink / raw)
To: linux-kernel
Cc: Frieder Schrempf, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Manuel Traut, linux-input, devicetree
In-Reply-To: <20230130135650.1407156-1-manuel.traut@mt.com>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
Make the driver accept switching volume levels via sysfs.
This can be helpful if the beep/bell sound intensity needs
to be adapted to the environment of the device.
The volume adjustment is done by changing the duty cycle of
the pwm signal.
Add a sysfs interface with 5 default volume levels:
0 - mute
..
4 - max. volume
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Manuel Traut <manuel.traut@mt.com>
Tested-by: Manuel Traut <manuel.traut@mt.com>
---
.../ABI/testing/sysfs-devices-pwm-beeper | 17 ++++
drivers/input/misc/pwm-beeper.c | 96 ++++++++++++++++++-
2 files changed, 112 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-pwm-beeper
diff --git a/Documentation/ABI/testing/sysfs-devices-pwm-beeper b/Documentation/ABI/testing/sysfs-devices-pwm-beeper
new file mode 100644
index 000000000000..d2a22516f31d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-pwm-beeper
@@ -0,0 +1,17 @@
+What: /sys/devices/.../pwm-beeper/volume
+Date: January 2023
+KernelVersion:
+Contact: Frieder Schrempf <frieder.schrempf@kontron.de>
+Description:
+ Control the volume of this pwm-beeper. Values
+ are between 0 and max_volume. This file will also
+ show the current volume level stored in the driver.
+
+What: /sys/devices/.../pwm-beeper/max_volume
+Date: February 2023
+KernelVersion:
+Contact: Frieder Schrempf <frieder.schrempf@kontron.de>
+Description:
+ This file shows the maximum volume level that can be
+ assigned to volume.
+
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index d6b12477748a..214d3fa0a06d 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -1,9 +1,14 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright (C) 2010, Lars-Peter Clausen <lars@metafoo.de>
+ *
+ * Copyright (C) 2016, Frieder Schrempf <frieder.schrempf@kontron.de>
+ * (volume support)
+ *
* PWM beeper driver
*/
+#include <linux/device.h>
#include <linux/input.h>
#include <linux/regulator/consumer.h>
#include <linux/module.h>
@@ -24,10 +29,61 @@ struct pwm_beeper {
unsigned int bell_frequency;
bool suspended;
bool amplifier_on;
+ unsigned int volume;
+ unsigned int *volume_levels;
+ unsigned int max_volume;
};
#define HZ_TO_NANOSECONDS(x) (1000000000UL/(x))
+static ssize_t volume_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct pwm_beeper *beeper = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%d\n", beeper->volume);
+}
+
+static ssize_t max_volume_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct pwm_beeper *beeper = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%d\n", beeper->max_volume);
+}
+
+static ssize_t volume_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ int rc;
+ struct pwm_beeper *beeper = dev_get_drvdata(dev);
+ unsigned int volume;
+
+ rc = kstrtouint(buf, 0, &volume);
+ if (rc)
+ return rc;
+
+ if (volume > beeper->max_volume)
+ return -EINVAL;
+ pr_debug("set volume to %u\n", volume);
+ beeper->volume = volume;
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(volume);
+static DEVICE_ATTR_RO(max_volume);
+
+static struct attribute *pwm_beeper_attributes[] = {
+ &dev_attr_volume.attr,
+ &dev_attr_max_volume.attr,
+ NULL,
+};
+
+static struct attribute_group pwm_beeper_attribute_group = {
+ .attrs = pwm_beeper_attributes,
+};
+
static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
{
struct pwm_state state;
@@ -37,7 +93,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
state.enabled = true;
state.period = period;
- pwm_set_relative_duty_cycle(&state, 50, 100);
+ pwm_set_relative_duty_cycle(&state, beeper->volume_levels[beeper->volume], 1000);
error = pwm_apply_state(beeper->pwm, &state);
if (error)
@@ -126,6 +182,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
struct pwm_state state;
u32 bell_frequency;
int error;
+ size_t size;
beeper = devm_kzalloc(dev, sizeof(*beeper), GFP_KERNEL);
if (!beeper)
@@ -171,6 +228,24 @@ static int pwm_beeper_probe(struct platform_device *pdev)
beeper->bell_frequency = bell_frequency;
+ beeper->max_volume = 4;
+
+ size = sizeof(*beeper->volume_levels) *
+ (beeper->max_volume + 1);
+
+ beeper->volume_levels = devm_kzalloc(&(pdev->dev), size,
+ GFP_KERNEL);
+ if (!beeper->volume_levels)
+ return -ENOMEM;
+
+ beeper->volume_levels[0] = 0;
+ beeper->volume_levels[1] = 80;
+ beeper->volume_levels[2] = 200;
+ beeper->volume_levels[3] = 400;
+ beeper->volume_levels[4] = 5000;
+
+ beeper->volume = beeper->max_volume;
+
beeper->input = devm_input_allocate_device(dev);
if (!beeper->input) {
dev_err(dev, "Failed to allocate input device\n");
@@ -192,8 +267,15 @@ static int pwm_beeper_probe(struct platform_device *pdev)
input_set_drvdata(beeper->input, beeper);
+ error = sysfs_create_group(&pdev->dev.kobj, &pwm_beeper_attribute_group);
+ if (error) {
+ dev_err(&pdev->dev, "Failed to create sysfs group: %d\n", error);
+ return error;
+ }
+
error = input_register_device(beeper->input);
if (error) {
+ sysfs_remove_group(&pdev->dev.kobj, &pwm_beeper_attribute_group);
dev_err(dev, "Failed to register input device: %d\n", error);
return error;
}
@@ -203,6 +285,17 @@ static int pwm_beeper_probe(struct platform_device *pdev)
return 0;
}
+static int pwm_beeper_remove(struct platform_device *pdev)
+{
+ struct pwm_beeper *beeper;
+
+ beeper = platform_get_drvdata(pdev);
+ input_unregister_device(beeper->input);
+ sysfs_remove_group(&pdev->dev.kobj, &pwm_beeper_attribute_group);
+
+ return 0;
+}
+
static int __maybe_unused pwm_beeper_suspend(struct device *dev)
{
struct pwm_beeper *beeper = dev_get_drvdata(dev);
@@ -248,6 +341,7 @@ MODULE_DEVICE_TABLE(of, pwm_beeper_match);
static struct platform_driver pwm_beeper_driver = {
.probe = pwm_beeper_probe,
+ .remove = pwm_beeper_remove,
.driver = {
.name = "pwm-beeper",
.pm = &pwm_beeper_pm_ops,
--
2.39.0
^ permalink raw reply related
* [PATCH v9 1/4] dt-bindings: input: pwm-beeper: Convert txt bindings to yaml
From: Manuel Traut @ 2023-01-30 13:56 UTC (permalink / raw)
To: linux-kernel
Cc: Manuel Traut, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
In-Reply-To: <20230130135650.1407156-1-manuel.traut@mt.com>
Converts txt binding to new YAML format.
Signed-off-by: Manuel Traut <manuel.traut@mt.com>
---
.../devicetree/bindings/input/pwm-beeper.txt | 24 ------------
.../devicetree/bindings/input/pwm-beeper.yaml | 39 +++++++++++++++++++
2 files changed, 39 insertions(+), 24 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.txt
create mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.yaml
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt b/Documentation/devicetree/bindings/input/pwm-beeper.txt
deleted file mode 100644
index 8fc0e48c20db..000000000000
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* PWM beeper device tree bindings
-
-Registers a PWM device as beeper.
-
-Required properties:
-- compatible: should be "pwm-beeper"
-- pwms: phandle to the physical PWM device
-
-Optional properties:
-- amp-supply: phandle to a regulator that acts as an amplifier for the beeper
-- beeper-hz: bell frequency in Hz
-
-Example:
-
-beeper_amp: amplifier {
- compatible = "fixed-regulator";
- gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
-};
-
-beeper {
- compatible = "pwm-beeper";
- pwms = <&pwm0>;
- amp-supply = <&beeper_amp>;
-};
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
new file mode 100644
index 000000000000..1ebc3a46d934
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/pwm-beeper.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM beeper
+
+maintainers:
+ - Dmitry Torokhov <dmitry.torokhov@gmail.com>
+
+description: Registers a PWM device as beeper.
+
+properties:
+ compatible:
+ const: pwm-beeper
+
+ pwms:
+ maxItems: 1
+
+ amp-supply:
+ description: >
+ regulator that acts as an amplifier for the beeper
+
+ beeper-hz:
+ description: bell frequency in Hz
+
+required:
+ - compatible
+ - pwms
+
+additionalProperties: false
+
+examples:
+ - |
+ beeper {
+ compatible = "pwm-beeper";
+ pwms = <&pwm0>;
+ };
--
2.39.0
^ permalink raw reply related
* [PATCH v9 0/4] input: pwm-beeper: add feature to set volume level
From: Manuel Traut @ 2023-01-30 13:56 UTC (permalink / raw)
To: linux-kernel
Cc: Manuel Traut, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
This implements volume control for the pwm-beeper via sysfs.
The first patch changes the devicetree documentation from txt to yaml.
The original author of the volume support patches is Frieder Schrempf.
I picked them from this [0] LKML thread from 2017. Since it looks like
his email address changed in the meantime I changed it in the Author
and Signed-off-by, as well as in the copyright statements.
I did some minor changes on the patches that they apply and work with
the current kernel.
checkpatch still reports warnings regarding the changes:
* from txt to yaml of the devicetree documentation:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
WARNING: DT binding docs and includes should be a separate patch.
* and the introduction of Documentation/ABI/testing/sysfs-devices-pwm-beeper:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
I am not sure how to fix these warnings. So any suggestion would be helpful.
Changes since v8 [1]:
* yaml devicetree doc:
* reordered patches to introduce dt-bindings before usage
* drop quotes from $id and $schema references
* amp-supply: simplify description
* examples: remove unneeded amp device node
* use -bp suffix for volume-levels and default-volume
* specify default-volume as value instead of pointer into volume-array
* fixup to work with new dt-binding specification
* squash patches as suggested by Frieder
Changes since v7 [2]:
* yaml devicetree doc:
* Use shorter subject
* Fix indent
* Use units
* 'make dt_binding_check' succeeds
* 'make dtbs_check' does not report new errors
* Reworded commit messages avoiding 'this patch' phrase
* Fix wrong indent in [PATCH 5/5 v7] input: pwm-beeper: handle module unloading properly
* Use current date in Documentation/ABI/testing/sysfs-devices-pwm-beeper
* Hopefully fixed my setup that
* mails are CC'ed correctly
* patches are sent as replies to the cover letter
Changes since v6 [3]:
* Convert devicetree binding documentation from txt to yaml
* Use DEVICE_ATTR_[RO|RW] properly
* Change Frieders Mail address
* Added Signed-off and Tested-by statements
* Fix module unloading
Frieder Schrempf (2):
input: pwm-beeper: add feature to set volume via sysfs
input: pwm-beeper: set volume levels by devicetree
Manuel Traut (2):
dt-bindings: input: pwm-beeper: Convert txt bindings to yaml
dt-bindings: input: pwm-beeper: add volume
.../ABI/testing/sysfs-devices-pwm-beeper | 17 +++
.../devicetree/bindings/input/pwm-beeper.txt | 24 ----
.../devicetree/bindings/input/pwm-beeper.yaml | 56 ++++++++
drivers/input/misc/pwm-beeper.c | 135 +++++++++++++++++-
4 files changed, 206 insertions(+), 26 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-pwm-beeper
delete mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.txt
create mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.yaml
[0] https://lore.kernel.org/all/cover.1487323753.git.frieder.schrempf@exceet.de/
[1] https://lore.kernel.org/lkml/20230126091825.220646-1-manuel.traut@mt.com/
[2] https://lore.kernel.org/all/Y9AIq3cSNzI9T%2FdU@mt.com/
[3] https://lkml.org/lkml/2023/1/24/379
--
2.39.0
^ permalink raw reply
* mtk-pmic-keys: Ignore power button if pressed before driver loads
From: Arınç ÜNAL @ 2023-01-30 13:36 UTC (permalink / raw)
To: Dmitry Torokhov, Matthias Brugger, Mattijs Korpershoek,
AngeloGioacchino Del Regno, Jonathan Cameron
Cc: linux-input, Linux ARM, moderated list:ARM/Mediatek SoC support,
linux-kernel, Frank Wunderlich, erkin.bozoglu
Hi all,
The power button on my Bananapi BPI-R2 (MT7623NI SoC, mt6323-keys) is
shorted, so the device automatically boots when there's power. This
causes the device to reboot when KEYBOARD_MTK_PMIC is loaded because the
driver sees the power button being pressed.
I was wondering if it's possible to change the driver in a way that
doesn't break in this situation. Maybe don't do anything if the first
state of the the power button the driver sees is being pressed, and if
the state doesn't change.
To address an edge case, if the power button was being pressed before
the driver loads, look for if it's ever released. Only after then start
working as usual.
Looking forward to hearing your thoughts.
Arınç
^ permalink raw reply
* Re: [PATCH 0/9] HID: Constify lowlevel HID drivers
From: Hans de Goede @ 2023-01-30 13:28 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Basavaraj Natikar, Jiri Kosina, Benjamin Tissoires,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Filipe Laíns, Srinivas Pandruvada, Maximilian Luz,
Corentin Chary, Mark Gross, Viresh Kumar, Johan Hovold,
Alex Elder, Greg Kroah-Hartman, linux-input, linux-kernel,
linux-hyperv, platform-driver-x86, acpi4asus-user, greybus-dev,
linux-staging
In-Reply-To: <20230130132620.3cmmq5ga3uebazwf@t-8ch.de>
Hi,
On 1/30/23 14:26, Thomas Weißschuh wrote:
> Hi Hans,
>
> On Mon, Jan 30, 2023 at 09:36:32AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 1/30/23 04:59, Thomas Weißschuh wrote:
>>> Since 52d225346904 ("HID: Make lowlevel driver structs const") the
>>> lowlevel HID drivers are only exposed as const.
>>>
>>> Take advantage of this to constify the underlying structures, too.
>>>
>>> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
>>
>> Thanks, series looks good to me:
>>
>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>>
>> I'll also pick up / merge patches 7 + 8 into pdx86/for-next
>> sometime this week.
>
> Please note that patch 7 depends on commit 52d225346904
> ("HID: Make lowlevel driver structs const") which is not yet in Linus'
> tree, only in the HID tree (branch for-6.3/hid-core).
>
> Maybe it's better to take it via the HID tree or I can resend when the
> prerequisites are in Linus' tree.
Ah yes then it would be better to take the entire set through the HID tree,
here is my ack for that:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
>>> ---
>>> Thomas Weißschuh (9):
>>> HID: amd_sfh: Constify lowlevel HID driver
>>> HID: hyperv: Constify lowlevel HID driver
>>> HID: logitech-dj: Constify lowlevel HID driver
>>> HID: steam: Constify lowlevel HID driver
>>> HID: intel-ish-hid: Constify lowlevel HID driver
>>> HID: surface-hid: Constify lowlevel HID driver
>>> platform/x86: asus-tf103c-dock: Constify lowlevel HID driver
>>> platform/x86: asus-tf103c-dock: Constify toprow keymap
>>> staging: greybus: hid: Constify lowlevel HID driver
>>>
>>> drivers/hid/amd-sfh-hid/amd_sfh_hid.c | 2 +-
>>> drivers/hid/hid-hyperv.c | 2 +-
>>> drivers/hid/hid-logitech-dj.c | 4 ++--
>>> drivers/hid/hid-steam.c | 2 +-
>>> drivers/hid/intel-ish-hid/ishtp-hid.c | 2 +-
>>> drivers/hid/surface-hid/surface_hid_core.c | 2 +-
>>> drivers/platform/x86/asus-tf103c-dock.c | 4 ++--
>>> drivers/staging/greybus/hid.c | 2 +-
>>> 8 files changed, 10 insertions(+), 10 deletions(-)
>>> ---
>>> base-commit: e04955db6a7c3fc4a1e6978649b61a6f5f8028e3
>>> change-id: 20230130-hid-const-ll-driver-fcfdd3af11b8
>>>
>>> Best regards,
>>
>
^ permalink raw reply
* Re: [PATCH 0/9] HID: Constify lowlevel HID drivers
From: Thomas Weißschuh @ 2023-01-30 13:26 UTC (permalink / raw)
To: Hans de Goede
Cc: Basavaraj Natikar, Jiri Kosina, Benjamin Tissoires,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Filipe Laíns, Srinivas Pandruvada, Maximilian Luz,
Corentin Chary, Mark Gross, Viresh Kumar, Johan Hovold,
Alex Elder, Greg Kroah-Hartman, linux-input, linux-kernel,
linux-hyperv, platform-driver-x86, acpi4asus-user, greybus-dev,
linux-staging
In-Reply-To: <0937b9a5-0caa-2a73-33c4-82e6cab02ef0@redhat.com>
Hi Hans,
On Mon, Jan 30, 2023 at 09:36:32AM +0100, Hans de Goede wrote:
> Hi,
>
> On 1/30/23 04:59, Thomas Weißschuh wrote:
> > Since 52d225346904 ("HID: Make lowlevel driver structs const") the
> > lowlevel HID drivers are only exposed as const.
> >
> > Take advantage of this to constify the underlying structures, too.
> >
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
>
> Thanks, series looks good to me:
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>
> I'll also pick up / merge patches 7 + 8 into pdx86/for-next
> sometime this week.
Please note that patch 7 depends on commit 52d225346904
("HID: Make lowlevel driver structs const") which is not yet in Linus'
tree, only in the HID tree (branch for-6.3/hid-core).
Maybe it's better to take it via the HID tree or I can resend when the
prerequisites are in Linus' tree.
> Regards,
>
> Hans
>
>
>
> > ---
> > Thomas Weißschuh (9):
> > HID: amd_sfh: Constify lowlevel HID driver
> > HID: hyperv: Constify lowlevel HID driver
> > HID: logitech-dj: Constify lowlevel HID driver
> > HID: steam: Constify lowlevel HID driver
> > HID: intel-ish-hid: Constify lowlevel HID driver
> > HID: surface-hid: Constify lowlevel HID driver
> > platform/x86: asus-tf103c-dock: Constify lowlevel HID driver
> > platform/x86: asus-tf103c-dock: Constify toprow keymap
> > staging: greybus: hid: Constify lowlevel HID driver
> >
> > drivers/hid/amd-sfh-hid/amd_sfh_hid.c | 2 +-
> > drivers/hid/hid-hyperv.c | 2 +-
> > drivers/hid/hid-logitech-dj.c | 4 ++--
> > drivers/hid/hid-steam.c | 2 +-
> > drivers/hid/intel-ish-hid/ishtp-hid.c | 2 +-
> > drivers/hid/surface-hid/surface_hid_core.c | 2 +-
> > drivers/platform/x86/asus-tf103c-dock.c | 4 ++--
> > drivers/staging/greybus/hid.c | 2 +-
> > 8 files changed, 10 insertions(+), 10 deletions(-)
> > ---
> > base-commit: e04955db6a7c3fc4a1e6978649b61a6f5f8028e3
> > change-id: 20230130-hid-const-ll-driver-fcfdd3af11b8
> >
> > Best regards,
>
^ permalink raw reply
* Re: [PATCH] Input: st-keyscan - Use devm_platform_get_and_ioremap_resource()
From: Andy Shevchenko @ 2023-01-30 12:19 UTC (permalink / raw)
To: ye.xingchen; +Cc: dmitry.torokhov, jonathan.cameron, linux-input, linux-kernel
In-Reply-To: <202301281611305841413@zte.com.cn>
On Sat, Jan 28, 2023 at 04:11:30PM +0800, ye.xingchen@zte.com.cn wrote:
> From: ye xingchen <ye.xingchen@zte.com.cn>
>
> Convert platform_get_resource(), devm_ioremap_resource() to a single
> call to devm_platform_get_and_ioremap_resource(), as this is exactly
> what this function does.
...
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - keypad_data->base = devm_ioremap_resource(&pdev->dev, res);
> + keypad_data->base = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
Why?
What we need here is simple devm_platform_ioremap_resource().
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH RESEND] Input: atmel_captouch - drop obsolete dependency on COMPILE_TEST
From: Jean Delvare @ 2023-01-30 11:57 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, LKML, Daniel Hung-yu Wu, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
In-Reply-To: <Y9csSoYNZmN3+eSy@google.com>
Hi Dmitry Torokhov,
On Sun, 29 Jan 2023 18:32:42 -0800, Dmitry Torokhov wrote:
> On Fri, Jan 27, 2023 at 12:28:16PM +0100, Jean Delvare wrote:
> > Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
> > is possible to test-build any driver which depends on OF on any
> > architecture by explicitly selecting OF. Therefore depending on
> > COMPILE_TEST as an alternative is no longer needed.
> >
> > As a nice side effect, dropping the alternative dependency on
> > COMPILE_TEST allows removing preprocessor directives, which will
> > speed up the build.
>
> I believe I already have your patch in my "next" branch that is feeding
> into linux-next.
Oh right, sorry for the noise. I did not receive a formal ack from you
at the time, so I thought it got lost in traffic. I should have
double-checked, by bad.
Thanks,
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [PATCH 6/9] HID: surface-hid: Constify lowlevel HID driver
From: Maximilian Luz @ 2023-01-30 11:53 UTC (permalink / raw)
To: Thomas Weißschuh, Basavaraj Natikar, Jiri Kosina,
Benjamin Tissoires, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Filipe Laíns, Srinivas Pandruvada,
Corentin Chary, Hans de Goede, Mark Gross, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman
Cc: linux-input, linux-kernel, linux-hyperv, platform-driver-x86,
acpi4asus-user, greybus-dev, linux-staging
In-Reply-To: <20230130-hid-const-ll-driver-v1-6-3fc282b3b1d0@weissschuh.net>
On 1/30/23 04:59, Thomas Weißschuh wrote:
> Since commit 52d225346904 ("HID: Make lowlevel driver structs const")
> the lowlevel HID drivers are only exposed as const.
>
> Take advantage of this to constify the underlying structure, too.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Looks good to me.
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
> ---
> drivers/hid/surface-hid/surface_hid_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/surface-hid/surface_hid_core.c b/drivers/hid/surface-hid/surface_hid_core.c
> index 87637f813de2..a3e9cceddfac 100644
> --- a/drivers/hid/surface-hid/surface_hid_core.c
> +++ b/drivers/hid/surface-hid/surface_hid_core.c
> @@ -174,7 +174,7 @@ static int surface_hid_raw_request(struct hid_device *hid, unsigned char reportn
> return -EIO;
> }
>
> -static struct hid_ll_driver surface_hid_ll_driver = {
> +static const struct hid_ll_driver surface_hid_ll_driver = {
> .start = surface_hid_start,
> .stop = surface_hid_stop,
> .open = surface_hid_open,
>
^ permalink raw reply
* Re: [Regression] Bug 216885 - HID++ Logitech G903 generates full scroll wheel events with every hi-res tick when attached via USB
From: Linux kernel regression tracking (Thorsten Leemhuis) @ 2023-01-30 11:10 UTC (permalink / raw)
To: Benjamin Tissoires, Linux regressions mailing list,
Bastien Nocera, Jiri Kosina, David Roth, open list:HID CORE LAYER,
LKML, Linus
In-Reply-To: <Y9efj49RfzZRIDGY@skade.schwarzvogel.de>
On 30.01.23 11:44, Tobias Klausmann wrote:
> On Mon, 30 Jan 2023, Benjamin Tissoires wrote:
>
>> On Mon, Jan 30, 2023 at 10:56 AM Linux kernel regression tracking
>> (Thorsten Leemhuis) <regressions@leemhuis.info> wrote:
>>>
>>> [ccing a few people that CCed to the bug]
>>>
>>> Hi, this is your Linux kernel regression tracker.
>>>
>>> On 05.01.23 09:12, Thorsten Leemhuis wrote:
>>>> [...] Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
>>>>
>>>>> David Roth 2023-01-04 20:37:22 UTC
>>>>>
>>>>> Created attachment 303526 [details]
>>>>> Libinput record with G903 attached directly to USB
>>>>>
>>>>> Since
>>>>> https://lore.kernel.org/linux-input/20220914132146.6435-1-hadess@hadess.net/T/#u
>>>>> my Logitech G903 has gained hi res support. While normally a good
>>>>> thing, it seems that in this case it leads to generating one normal
>>>>> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
>>>>> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
>>>>> notch/tick is reached. This leads to overly sensitive scrolling and
>>>>> makes the wheel basically useless.
>>>
>>> Bastien, Benjamin, Jiri, that problem was reported 25 days ago now and
>>> there is still no fix in sight afaics (please correct me if I'm wrong)
>>> -- and based on the reports I've seen it seem quite a few people are
>>> hitting it. Hence please allow me to ask:
>>>
>>> Wouldn't it be best to revert that change for now (both in mainline and
>>> stable of course) and then reapply it once a fix for this problem is
>>> available? Or
>>
>> Last I heard was that Bastien was actively trying to understand the
>> problem.
Yup, no complains there. Thx for your work on this, Bastien.
But that debugging has already taken some time and it seem more is
needed. And apparently it's more than just a single user or two that is
affected by this. That's why I think it would be better to revert this
temporarily[1], unless a fix suddenly comes into sight.
[1] as strongly suggested by
https://docs.kernel.org/process/handling-regressions.html , which states
that a regression like this should ideally be fixed within a few days
after the report; we are long past this...
>> I do have a G903 here but it is lacking the feature the
>> reporters have, and so I can not reproduce (there is likely a new
>> firmware/model around).
>>
>> After a quick search on
>> https://support.logi.com/hc/en-us/search#q=G903&s=all it seems that
>> there are 2 G903: M-R0081 and M-R0068. I only own the 68 one which
>> explains why I can not reproduce it. :(
>
> I have an affected mouse and am willing to try patches/fixes, but my
> kernel coding fu is weak.
Thx for your help, too.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
^ permalink raw reply
* Re: [Regression] Bug 216885 - HID++ Logitech G903 generates full scroll wheel events with every hi-res tick when attached via USB
From: Tobias Klausmann @ 2023-01-30 10:44 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Linux regressions mailing list, Bastien Nocera, Jiri Kosina,
David Roth, open list:HID CORE LAYER, LKML, Linus
In-Reply-To: <CAO-hwJJtK3B2x8CAAYsB41X8D=1EpEYK+nSuVA+fXuz1LHkmSg@mail.gmail.com>
Hi!
On Mon, 30 Jan 2023, Benjamin Tissoires wrote:
> On Mon, Jan 30, 2023 at 10:56 AM Linux kernel regression tracking
> (Thorsten Leemhuis) <regressions@leemhuis.info> wrote:
> >
> > [ccing a few people that CCed to the bug]
> >
> > Hi, this is your Linux kernel regression tracker.
> >
> > On 05.01.23 09:12, Thorsten Leemhuis wrote:
> > > [...] Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
> > >
> > >> David Roth 2023-01-04 20:37:22 UTC
> > >>
> > >> Created attachment 303526 [details]
> > >> Libinput record with G903 attached directly to USB
> > >>
> > >> Since
> > >> https://lore.kernel.org/linux-input/20220914132146.6435-1-hadess@hadess.net/T/#u
> > >> my Logitech G903 has gained hi res support. While normally a good
> > >> thing, it seems that in this case it leads to generating one normal
> > >> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
> > >> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
> > >> notch/tick is reached. This leads to overly sensitive scrolling and
> > >> makes the wheel basically useless.
> >
> > Bastien, Benjamin, Jiri, that problem was reported 25 days ago now and
> > there is still no fix in sight afaics (please correct me if I'm wrong)
> > -- and based on the reports I've seen it seem quite a few people are
> > hitting it. Hence please allow me to ask:
> >
> > Wouldn't it be best to revert that change for now (both in mainline and
> > stable of course) and then reapply it once a fix for this problem is
> > available? Or
>
> Last I heard was that Bastien was actively trying to understand the
> problem. I do have a G903 here but it is lacking the feature the
> reporters have, and so I can not reproduce (there is likely a new
> firmware/model around).
>
> After a quick search on
> https://support.logi.com/hc/en-us/search#q=G903&s=all it seems that
> there are 2 G903: M-R0081 and M-R0068. I only own the 68 one which
> explains why I can not reproduce it. :(
I have an affected mouse and am willing to try patches/fixes, but my
kernel coding fu is weak.
Best,
Tobias
^ permalink raw reply
* Re: [regression] Bug 216977 - asus t100 touchpad registered but not working
From: Linux kernel regression tracking (#update) @ 2023-01-30 10:44 UTC (permalink / raw)
To: Hans de Goede, Linux regressions mailing list, Jiri Kosina,
Benjamin Tissoires
Cc: LKML, open list:HID CORE LAYER, jessegodfroy
In-Reply-To: <325be2be-0c58-7414-70e9-9585e35874a2@redhat.com>
On 30.01.23 11:16, Hans de Goede wrote:
> Hi All,
>
> On 1/30/23 10:22, Linux kernel regression tracking (Thorsten Leemhuis) wrote:
>> Hi, this is your Linux kernel regression tracker.
>>
>> I noticed a regression report in bugzilla.kernel.org. As many (most?)
>> kernel developer don't keep an eye on it, I decided to forward it by
>> mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216977 :
>>
>>> jessegodfroy@gmail.com 2023-01-29 15:44:34 UTC
>>>
>>> After upgrading the kernel from 6.0 series to the 6.1 the touchpad on my asus t100 no longer works.
>>>
>>> The device is registered in dmesg. I believe hid_asus is responsible for the keyboard and touchpad. The keyboard continues to function, but the touchpad does not.
>>>
>>> Jan 29 09:29:53 t100ta-white kernel: asus 0003:0B05:17E0.0001: input,hidraw0: USB HID v1.11 Keyboard [ASUSTek COMPUTER INC. ASUS Base Station(T100)] on usb-0000:00:14.0-3/input0
>>> Jan 29 09:29:53 t100ta-white kernel: asus 0003:0B05:17E0.0002: Fixing up Asus T100 keyb report descriptor
>>> Jan 29 09:29:53 t100ta-white kernel: asus 0003:0B05:17E0.0002: input,hiddev96,hidraw1: USB HID v1.11 Device [ASUSTek COMPUTER INC. ASUS Base Station(T100)] on usb-0000:00:14.0-3/input1
>>> Jan 29 09:29:53 t100ta-white kernel: asus 0003:0B05:17E0.0003: input,hiddev97,hidraw2: USB HID v1.11 Mouse [ASUSTek COMPUTER INC. ASUS Base Station(T100)] on usb-0000:00:14.0-3/input2
>>>
>>> I do not see any changes to hid_asus that should be responsible for the change in performance.
>> See the ticket for more details.
>
> This is my bad, I accidentally broke SW_TABLET_MODE reporting on
> the Asus T100* and T101* series and it is now reporting that it
> is in tablet mode while it is actually docked and thus in laptop
> mode.
Ahh, interesting, will keep platform code in mind as possible suspect in
case a similar situation arises in the future.
> This is causing libinput to suppress touchpad events, as
> it would for a 360° hinges style 2 in 1 with the keyboard +
> touchpad folded behind the display (so in tablet mode).
>
> A fix for this has already been merged for 6.2-rc6:
>
> "platform/x86: asus-wmi: Fix kbd_dock_devid tablet-switch reporting"
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fdcc0602d64f22185f61c70747214b630049cc33
>
> And the fix is also queued for the next 6.1.y stable series release:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=queue/6.1
>
> I'll also add this info as a comment to the bug.
Ahh, great, thx for the info and your work
#regzbot fix: fdcc0602d64f22185f61
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
#regzbot ignore-activity
^ permalink raw reply
* Re: [Regression] Bug 216885 - HID++ Logitech G903 generates full scroll wheel events with every hi-res tick when attached via USB
From: Benjamin Tissoires @ 2023-01-30 10:35 UTC (permalink / raw)
To: Linux regressions mailing list
Cc: Bastien Nocera, Jiri Kosina, David Roth, open list:HID CORE LAYER,
LKML, Tobias Klausmann, Linus
In-Reply-To: <be545e72-8312-f213-0250-86a128b7b629@leemhuis.info>
On Mon, Jan 30, 2023 at 10:56 AM Linux kernel regression tracking
(Thorsten Leemhuis) <regressions@leemhuis.info> wrote:
>
> [ccing a few people that CCed to the bug]
>
> Hi, this is your Linux kernel regression tracker.
>
> On 05.01.23 09:12, Thorsten Leemhuis wrote:
> > [...] Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
> >
> >> David Roth 2023-01-04 20:37:22 UTC
> >>
> >> Created attachment 303526 [details]
> >> Libinput record with G903 attached directly to USB
> >>
> >> Since
> >> https://lore.kernel.org/linux-input/20220914132146.6435-1-hadess@hadess.net/T/#u
> >> my Logitech G903 has gained hi res support. While normally a good
> >> thing, it seems that in this case it leads to generating one normal
> >> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
> >> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
> >> notch/tick is reached. This leads to overly sensitive scrolling and
> >> makes the wheel basically useless.
>
> Bastien, Benjamin, Jiri, that problem was reported 25 days ago now and
> there is still no fix in sight afaics (please correct me if I'm wrong)
> -- and based on the reports I've seen it seem quite a few people are
> hitting it. Hence please allow me to ask:
>
> Wouldn't it be best to revert that change for now (both in mainline and
> stable of course) and then reapply it once a fix for this problem is
> available? Or
Last I heard was that Bastien was actively trying to understand the
problem. I do have a G903 here but it is lacking the feature the
reporters have, and so I can not reproduce (there is likely a new
firmware/model around).
After a quick search on
https://support.logi.com/hc/en-us/search#q=G903&s=all it seems that
there are 2 G903: M-R0081 and M-R0068. I only own the 68 one which
explains why I can not reproduce it. :(
Cheers,
Benjamin
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> >> Interestingly this only happens when the mouse is connected directly via
> >> cable (PID:0xC091) and not via the Lightspeed wireless dongle
> >> (PID:0x4087) where it will lead to correctly applying the times 8
> >> multiplier and the relevant set of HI_RES and REL_WHEEL event once a
> >> notch is reached.
> >>
> >> I originally thought about patching the module/adding a param to simple
> >> disable high res support in general, assuming this might be something
> >> people might want to configure, but seeing that this can be "fixed" that
> >> way I decided to hold off on the thought.
> >>
> >> However it seems like we'd need to trade one set of quirks for another,
> >> so not sure what the correct approach might be.
> >>
> >> I'll attach some libinput debug logs when the issue happens.
> >
> > See the ticket for more details.
> >
> > BTW, let me use this mail to also add the report to the list of tracked
> > regressions to ensure it's doesn't fall through the cracks:
> >
> > #regzbot introduced: 908d325e1665
> > https://bugzilla.kernel.org/show_bug.cgi?id=216885
> > #regzbot title: hid: overly sensitive scrolling with Logitech G903 that
> > makes the wheel basically useless
> > #regzbot ignore-activity
> >
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > --
> > Everything you wanna know about Linux kernel regression tracking:
> > https://linux-regtracking.leemhuis.info/about/#tldr
> > If I did something stupid, please tell me, as explained on that page.
>
^ permalink raw reply
* Re: [Regression] Bug 216885 - HID++ Logitech G903 generates full scroll wheel events with every hi-res tick when attached via USB
From: Tobias Klausmann @ 2023-01-30 10:09 UTC (permalink / raw)
To: Linux regressions mailing list
Cc: Bastien Nocera, Benjamin Tissoires, Jiri Kosina, David Roth,
open list:HID CORE LAYER, LKML, Linus
In-Reply-To: <be545e72-8312-f213-0250-86a128b7b629@leemhuis.info>
Hi!
On Mon, 30 Jan 2023, Linux kernel regression tracking (Thorsten Leemhuis) wrote:
> [ccing a few people that CCed to the bug]
>
> Hi, this is your Linux kernel regression tracker.
>
> On 05.01.23 09:12, Thorsten Leemhuis wrote:
> > [...] Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
> >
> >> David Roth 2023-01-04 20:37:22 UTC
> >>
> >> Created attachment 303526 [details]
> >> Libinput record with G903 attached directly to USB
> >>
> >> Since
> >> https://lore.kernel.org/linux-input/20220914132146.6435-1-hadess@hadess.net/T/#u
> >> my Logitech G903 has gained hi res support. While normally a good
> >> thing, it seems that in this case it leads to generating one normal
> >> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
> >> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
> >> notch/tick is reached. This leads to overly sensitive scrolling and
> >> makes the wheel basically useless.
>
> Bastien, Benjamin, Jiri, that problem was reported 25 days ago now and
> there is still no fix in sight afaics (please correct me if I'm wrong)
> -- and based on the reports I've seen it seem quite a few people are
> hitting it. Hence please allow me to ask:
>
> Wouldn't it be best to revert that change for now (both in mainline and
> stable of course) and then reapply it once a fix for this problem is
> available? Or
I think there was something cut off or that `Or` is leftovers.
As for no fix: correct, there is no fix yet, though the workaround of
blacklisting the module sortof works. _Not_ having hires support usually
doesn't break anything, as it's a relatively new feature/functionality,
and so many pieces of userland (GTK+, Qt etc) need to be explicitly
configured to use it, and fall back to lowres in a benign way. I would
have never noticed this if I didn't use a distro kernel on one machine
(my hand-built ones omit the module entirely).
That said, figuring out what is going on and what to do is not trivial,
since most people won't think "kernel" when they notice their mouse's
behavior has changed. My liberal reporting of bugs with Debian, libinput
and then the kernel (and linking them) was a deliberate attempt in
leaving breadcrumbs for people to find.
Best,
Tobias
^ permalink raw reply
* Re: [Regression] Bug 216885 - HID++ Logitech G903 generates full scroll wheel events with every hi-res tick when attached via USB
From: Linux kernel regression tracking (Thorsten Leemhuis) @ 2023-01-30 9:56 UTC (permalink / raw)
To: Bastien Nocera, Benjamin Tissoires, Jiri Kosina
Cc: David Roth, open list:HID CORE LAYER, regressions@lists.linux.dev,
LKML, Tobias Klausmann, Linus
In-Reply-To: <1bb93259-1c9f-5335-a0bf-fc8641b26650@leemhuis.info>
[ccing a few people that CCed to the bug]
Hi, this is your Linux kernel regression tracker.
On 05.01.23 09:12, Thorsten Leemhuis wrote:
> [...] Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
>
>> David Roth 2023-01-04 20:37:22 UTC
>>
>> Created attachment 303526 [details]
>> Libinput record with G903 attached directly to USB
>>
>> Since
>> https://lore.kernel.org/linux-input/20220914132146.6435-1-hadess@hadess.net/T/#u
>> my Logitech G903 has gained hi res support. While normally a good
>> thing, it seems that in this case it leads to generating one normal
>> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
>> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
>> notch/tick is reached. This leads to overly sensitive scrolling and
>> makes the wheel basically useless.
Bastien, Benjamin, Jiri, that problem was reported 25 days ago now and
there is still no fix in sight afaics (please correct me if I'm wrong)
-- and based on the reports I've seen it seem quite a few people are
hitting it. Hence please allow me to ask:
Wouldn't it be best to revert that change for now (both in mainline and
stable of course) and then reapply it once a fix for this problem is
available? Or
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
>> Interestingly this only happens when the mouse is connected directly via
>> cable (PID:0xC091) and not via the Lightspeed wireless dongle
>> (PID:0x4087) where it will lead to correctly applying the times 8
>> multiplier and the relevant set of HI_RES and REL_WHEEL event once a
>> notch is reached.
>>
>> I originally thought about patching the module/adding a param to simple
>> disable high res support in general, assuming this might be something
>> people might want to configure, but seeing that this can be "fixed" that
>> way I decided to hold off on the thought.
>>
>> However it seems like we'd need to trade one set of quirks for another,
>> so not sure what the correct approach might be.
>>
>> I'll attach some libinput debug logs when the issue happens.
>
> See the ticket for more details.
>
> BTW, let me use this mail to also add the report to the list of tracked
> regressions to ensure it's doesn't fall through the cracks:
>
> #regzbot introduced: 908d325e1665
> https://bugzilla.kernel.org/show_bug.cgi?id=216885
> #regzbot title: hid: overly sensitive scrolling with Logitech G903 that
> makes the wheel basically useless
> #regzbot ignore-activity
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
^ 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