* Re: [PATCH regression fix 0/2] Input: atkbd - Fix Dell XPS 13 line suspend/resume regression
From: Linux regression tracking (Thorsten Leemhuis) @ 2024-02-01 11:12 UTC (permalink / raw)
To: Hans de Goede, Dmitry Torokhov
Cc: Paul Menzel, stable, regressions, linux-input
In-Reply-To: <20240126160724.13278-1-hdegoede@redhat.com>
On 26.01.24 17:07, Hans de Goede wrote:
> Hi Dmitry,
>
> There have been multiple reports that the keyboard on
> Dell XPS 13 9350 / 9360 / 9370 models has stopped working after
> a suspend/resume after the merging of commit 936e4d49ecbc ("Input:
> atkbd - skip ATKBD_CMD_GETID in translated mode").
>
> See the 4 closes tags in the first patch for 4 reports of this.
>
> I have been working with the first reporter on resolving this
> and testing on his Dell XPS 13 9360 confirms that these patches
> fix things.
>
> Unfortunately the commit causing the issue has also been picked
> up by multiple stable kernel series now. Can you please send
> these fixes to Linus ASAP, so that they can also be backported
> to the stable series ASAP ?
Dmitry, Hans, what's the status here? I wonder if there is still a
chance to get this into -rc3 so that Greg can fix the affected stable
trees as well next week or so.
Ciao, Thorsten
> Hans de Goede (2):
> Input: atkbd - Skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID
> Input: atkbd - Do not skip atkbd_deactivate() when skipping
> ATKBD_CMD_GETID
>
> drivers/input/keyboard/atkbd.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
^ permalink raw reply
* Re: [PATCH regression fix 0/2] Input: atkbd - Fix Dell XPS 13 line suspend/resume regression
From: Hans de Goede @ 2024-02-01 11:41 UTC (permalink / raw)
To: Linux regressions mailing list, Dmitry Torokhov
Cc: Paul Menzel, stable, linux-input
In-Reply-To: <dcb4cfe6-1a50-43cb-ad92-76905c05dde3@leemhuis.info>
Hi,
On 2/1/24 12:12, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 26.01.24 17:07, Hans de Goede wrote:
>> Hi Dmitry,
>>
>> There have been multiple reports that the keyboard on
>> Dell XPS 13 9350 / 9360 / 9370 models has stopped working after
>> a suspend/resume after the merging of commit 936e4d49ecbc ("Input:
>> atkbd - skip ATKBD_CMD_GETID in translated mode").
>>
>> See the 4 closes tags in the first patch for 4 reports of this.
>>
>> I have been working with the first reporter on resolving this
>> and testing on his Dell XPS 13 9360 confirms that these patches
>> fix things.
>>
>> Unfortunately the commit causing the issue has also been picked
>> up by multiple stable kernel series now. Can you please send
>> these fixes to Linus ASAP, so that they can also be backported
>> to the stable series ASAP ?
>
> Dmitry, Hans, what's the status here? I wonder if there is still a
> chance to get this into -rc3 so that Greg can fix the affected stable
> trees as well next week or so.
From my pov these are ready to go. I'm waiting for feedback
from Dmitry on these.
Regards,
Hans
^ permalink raw reply
* [PATCH 0/7] HID: unused struct members cleanup
From: Jiri Slaby (SUSE) @ 2024-02-01 11:53 UTC (permalink / raw)
To: jikos; +Cc: linux-input, linux-kernel, Jiri Slaby (SUSE)
Hi,
the patches deal with unused members of structures as found by
clang-struct.
Sometimes even whole structures are removed.
Jiri Slaby (SUSE) (7):
HID: apple: remove unused members from struct apple_sc_backlight
HID: wacom: remove unused hid_data::pressure
HID: protect hid_device::bpf by CONFIG_HID_BPF
HID: hid-lg3ff: remove unused struct lg3ff_device
HID: hid-multitouch: remove unused mt_application::dev_time
HID: hid-prodikeys: remove unused struct pcmidi_snd members
HID: hid-prodikeys: remove struct pk_device
drivers/hid/hid-apple.c | 1 -
drivers/hid/hid-lg3ff.c | 4 --
drivers/hid/hid-multitouch.c | 1 -
drivers/hid/hid-prodikeys.c | 115 ++++++++++++-----------------------
drivers/hid/wacom_wac.h | 1 -
include/linux/hid.h | 4 +-
6 files changed, 42 insertions(+), 84 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/7] HID: apple: remove unused members from struct apple_sc_backlight
From: Jiri Slaby (SUSE) @ 2024-02-01 11:53 UTC (permalink / raw)
To: jikos
Cc: linux-input, linux-kernel, Jiri Slaby (SUSE), Paul Pawlowski,
Aun-Ali Zaidi, Aditya Garg, Benjamin Tissoires
In-Reply-To: <20240201115320.684-1-jirislaby@kernel.org>
The backlight members in struct apple_sc_backlight are unused. They were
added in commit 9018eacbe623 (HID: apple: Add support for keyboard
backlight on certain T2 Macs.), but never used.
As this is not a struct to communicate with the HW, remove these.
Found by https://github.com/jirislaby/clang-struct.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Paul Pawlowski <paul@mrarm.io>
Cc: Aun-Ali Zaidi <admin@kodeit.net>
Cc: Aditya Garg <gargaditya08@live.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-apple.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index b9c7c0ed7bcc..bd022e004356 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -79,7 +79,6 @@ struct apple_non_apple_keyboard {
struct apple_sc_backlight {
struct led_classdev cdev;
struct hid_device *hdev;
- unsigned short backlight_off, backlight_on_min, backlight_on_max;
};
struct apple_sc {
--
2.43.0
^ permalink raw reply related
* [PATCH 2/7] HID: wacom: remove unused hid_data::pressure
From: Jiri Slaby (SUSE) @ 2024-02-01 11:53 UTC (permalink / raw)
To: jikos
Cc: linux-input, linux-kernel, Jiri Slaby (SUSE), Ping Cheng,
Jason Gerecke, Benjamin Tissoires
In-Reply-To: <20240201115320.684-1-jirislaby@kernel.org>
The pressure member in struct hid_data is unused. It was
added in commit 5ae6e89f7409 (HID: wacom: implement the finger part of
the HID generic handling), but never used.
As this is not a struct to communicate with the HW, remove that member.
Found by https://github.com/jirislaby/clang-struct.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Ping Cheng <ping.cheng@wacom.com>
Cc: Jason Gerecke <jason.gerecke@wacom.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/wacom_wac.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
index e63b1e806e34..6ec499841f70 100644
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -309,7 +309,6 @@ struct hid_data {
bool confidence;
int x;
int y;
- int pressure;
int width;
int height;
int id;
--
2.43.0
^ permalink raw reply related
* [PATCH 3/7] HID: protect hid_device::bpf by CONFIG_HID_BPF
From: Jiri Slaby (SUSE) @ 2024-02-01 11:53 UTC (permalink / raw)
To: jikos; +Cc: linux-input, linux-kernel, Jiri Slaby (SUSE), Benjamin Tissoires
In-Reply-To: <20240201115320.684-1-jirislaby@kernel.org>
And not by CONFIG_BPF. BPF can be selected while HID_BPF does not have
to. It actually cannot be on some platforms due to Kconfig dependences.
This saves quite some bytes on those setups.
Found by https://github.com/jirislaby/clang-struct.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
include/linux/hid.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 7c26db874ff0..b12cb1c8e682 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -683,9 +683,9 @@ struct hid_device { /* device report descriptor */
unsigned int id; /* system unique id */
-#ifdef CONFIG_BPF
+#ifdef CONFIG_HID_BPF
struct hid_bpf bpf; /* hid-bpf data */
-#endif /* CONFIG_BPF */
+#endif /* CONFIG_HID_BPF */
};
void hiddev_free(struct kref *ref);
--
2.43.0
^ permalink raw reply related
* [PATCH 4/7] HID: hid-lg3ff: remove unused struct lg3ff_device
From: Jiri Slaby (SUSE) @ 2024-02-01 11:53 UTC (permalink / raw)
To: jikos
Cc: linux-input, linux-kernel, Jiri Slaby (SUSE), Gary Stein,
Benjamin Tissoires
In-Reply-To: <20240201115320.684-1-jirislaby@kernel.org>
struct lg3ff_device is present in the driver since its addition by
commit 74f292ca8c7a (HID: add driver for the Logitech Flight System
G940).
But it was never used, remove it.
Found by https://github.com/jirislaby/clang-struct.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Gary Stein <LordCnidarian@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-lg3ff.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/hid/hid-lg3ff.c b/drivers/hid/hid-lg3ff.c
index b7e1949f3cf7..109735b89b7a 100644
--- a/drivers/hid/hid-lg3ff.c
+++ b/drivers/hid/hid-lg3ff.c
@@ -41,10 +41,6 @@
* I'm sure these are effects that I don't know enough about them
*/
-struct lg3ff_device {
- struct hid_report *report;
-};
-
static int hid_lg3ff_play(struct input_dev *dev, void *data,
struct ff_effect *effect)
{
--
2.43.0
^ permalink raw reply related
* [PATCH 5/7] HID: hid-multitouch: remove unused mt_application::dev_time
From: Jiri Slaby (SUSE) @ 2024-02-01 11:53 UTC (permalink / raw)
To: jikos; +Cc: linux-input, linux-kernel, Jiri Slaby (SUSE), Benjamin Tissoires
In-Reply-To: <20240201115320.684-1-jirislaby@kernel.org>
dev_time was moved to struct mt_application in commit f146d1c4d7ea (HID:
multitouch: Store per collection multitouch data), but is not used since
then. Remove it.
Found by https://github.com/jirislaby/clang-struct.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-multitouch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index fd5b0637dad6..40475c42b9f6 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -130,7 +130,6 @@ struct mt_application {
* > 1 means hybrid (multitouch) protocol
*/
- __s32 dev_time; /* the scan time provided by the device */
unsigned long jiffies; /* the frame's jiffies */
int timestamp; /* the timestamp to be sent */
int prev_scantime; /* scantime reported previously */
--
2.43.0
^ permalink raw reply related
* [PATCH 6/7] HID: hid-prodikeys: remove unused struct pcmidi_snd members
From: Jiri Slaby (SUSE) @ 2024-02-01 11:53 UTC (permalink / raw)
To: jikos; +Cc: linux-input, linux-kernel, Jiri Slaby (SUSE), Benjamin Tissoires
In-Reply-To: <20240201115320.684-1-jirislaby@kernel.org>
struct pcmidi_snd contains two unused members: out_substream and
out_active. They were added along the driver in commit 3a370ca1dcf8
(HID: Prodikeys PC-MIDI HID Driver), but not used.
Drop them.
Found by https://github.com/jirislaby/clang-struct.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-prodikeys.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/hid/hid-prodikeys.c b/drivers/hid/hid-prodikeys.c
index c16d2ba6ea16..439f4320f1d2 100644
--- a/drivers/hid/hid-prodikeys.c
+++ b/drivers/hid/hid-prodikeys.c
@@ -66,9 +66,7 @@ struct pcmidi_snd {
struct snd_card *card;
struct snd_rawmidi *rwmidi;
struct snd_rawmidi_substream *in_substream;
- struct snd_rawmidi_substream *out_substream;
unsigned long in_triggered;
- unsigned long out_active;
};
#define PK_QUIRK_NOGET 0x00010000
--
2.43.0
^ permalink raw reply related
* [PATCH 7/7] HID: hid-prodikeys: remove struct pk_device
From: Jiri Slaby (SUSE) @ 2024-02-01 11:53 UTC (permalink / raw)
To: jikos; +Cc: linux-input, linux-kernel, Jiri Slaby (SUSE), Benjamin Tissoires
In-Reply-To: <20240201115320.684-1-jirislaby@kernel.org>
First, quirks was unused in struct pk_device.
And I see no reason for this additional level of indirection. struct
pcmidi_snd is far enough for the driver. Unless I am missing something?
So drop struct pk_device and convert all the users to use struct
pcmidi_snd directly. No need for doubled kmalloc+kfrees now.
Found by https://github.com/jirislaby/clang-struct.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-prodikeys.c | 113 +++++++++++++-----------------------
1 file changed, 40 insertions(+), 73 deletions(-)
diff --git a/drivers/hid/hid-prodikeys.c b/drivers/hid/hid-prodikeys.c
index 439f4320f1d2..a593ed62c969 100644
--- a/drivers/hid/hid-prodikeys.c
+++ b/drivers/hid/hid-prodikeys.c
@@ -32,13 +32,6 @@
struct pcmidi_snd;
-struct pk_device {
- unsigned long quirks;
-
- struct hid_device *hdev;
- struct pcmidi_snd *pm; /* pcmidi device context */
-};
-
struct pcmidi_sustain {
unsigned long in_use;
struct pcmidi_snd *pm;
@@ -50,7 +43,7 @@ struct pcmidi_sustain {
#define PCMIDI_SUSTAINED_MAX 32
struct pcmidi_snd {
- struct pk_device *pk;
+ struct hid_device *hdev;
unsigned short ifnum;
struct hid_report *pcmidi_report6;
struct input_dev *input_ep82;
@@ -98,11 +91,11 @@ static ssize_t show_channel(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct hid_device *hdev = to_hid_device(dev);
- struct pk_device *pk = hid_get_drvdata(hdev);
+ struct pcmidi_snd *pm = hid_get_drvdata(hdev);
- dbg_hid("pcmidi sysfs read channel=%u\n", pk->pm->midi_channel);
+ dbg_hid("pcmidi sysfs read channel=%u\n", pm->midi_channel);
- return sprintf(buf, "%u (min:%u, max:%u)\n", pk->pm->midi_channel,
+ return sprintf(buf, "%u (min:%u, max:%u)\n", pm->midi_channel,
PCMIDI_CHANNEL_MIN, PCMIDI_CHANNEL_MAX);
}
@@ -111,13 +104,13 @@ static ssize_t store_channel(struct device *dev,
struct device_attribute *attr, const char *buf, size_t count)
{
struct hid_device *hdev = to_hid_device(dev);
- struct pk_device *pk = hid_get_drvdata(hdev);
+ struct pcmidi_snd *pm = hid_get_drvdata(hdev);
unsigned channel = 0;
if (sscanf(buf, "%u", &channel) > 0 && channel <= PCMIDI_CHANNEL_MAX) {
dbg_hid("pcmidi sysfs write channel=%u\n", channel);
- pk->pm->midi_channel = channel;
+ pm->midi_channel = channel;
return strlen(buf);
}
return -EINVAL;
@@ -135,11 +128,11 @@ static ssize_t show_sustain(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct hid_device *hdev = to_hid_device(dev);
- struct pk_device *pk = hid_get_drvdata(hdev);
+ struct pcmidi_snd *pm = hid_get_drvdata(hdev);
- dbg_hid("pcmidi sysfs read sustain=%u\n", pk->pm->midi_sustain);
+ dbg_hid("pcmidi sysfs read sustain=%u\n", pm->midi_sustain);
- return sprintf(buf, "%u (off:%u, max:%u (ms))\n", pk->pm->midi_sustain,
+ return sprintf(buf, "%u (off:%u, max:%u (ms))\n", pm->midi_sustain,
PCMIDI_SUSTAIN_MIN, PCMIDI_SUSTAIN_MAX);
}
@@ -148,15 +141,14 @@ static ssize_t store_sustain(struct device *dev,
struct device_attribute *attr, const char *buf, size_t count)
{
struct hid_device *hdev = to_hid_device(dev);
- struct pk_device *pk = hid_get_drvdata(hdev);
+ struct pcmidi_snd *pm = hid_get_drvdata(hdev);
unsigned sustain = 0;
if (sscanf(buf, "%u", &sustain) > 0 && sustain <= PCMIDI_SUSTAIN_MAX) {
dbg_hid("pcmidi sysfs write sustain=%u\n", sustain);
- pk->pm->midi_sustain = sustain;
- pk->pm->midi_sustain_mode =
- (0 == sustain || !pk->pm->midi_mode) ? 0 : 1;
+ pm->midi_sustain = sustain;
+ pm->midi_sustain_mode = (0 == sustain || !pm->midi_mode) ? 0 : 1;
return strlen(buf);
}
return -EINVAL;
@@ -174,11 +166,11 @@ static ssize_t show_octave(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct hid_device *hdev = to_hid_device(dev);
- struct pk_device *pk = hid_get_drvdata(hdev);
+ struct pcmidi_snd *pm = hid_get_drvdata(hdev);
- dbg_hid("pcmidi sysfs read octave=%d\n", pk->pm->midi_octave);
+ dbg_hid("pcmidi sysfs read octave=%d\n", pm->midi_octave);
- return sprintf(buf, "%d (min:%d, max:%d)\n", pk->pm->midi_octave,
+ return sprintf(buf, "%d (min:%d, max:%d)\n", pm->midi_octave,
PCMIDI_OCTAVE_MIN, PCMIDI_OCTAVE_MAX);
}
@@ -187,14 +179,14 @@ static ssize_t store_octave(struct device *dev,
struct device_attribute *attr, const char *buf, size_t count)
{
struct hid_device *hdev = to_hid_device(dev);
- struct pk_device *pk = hid_get_drvdata(hdev);
+ struct pcmidi_snd *pm = hid_get_drvdata(hdev);
int octave = 0;
if (sscanf(buf, "%d", &octave) > 0 &&
octave >= PCMIDI_OCTAVE_MIN && octave <= PCMIDI_OCTAVE_MAX) {
dbg_hid("pcmidi sysfs write octave=%d\n", octave);
- pk->pm->midi_octave = octave;
+ pm->midi_octave = octave;
return strlen(buf);
}
return -EINVAL;
@@ -268,7 +260,7 @@ static void stop_sustain_timers(struct pcmidi_snd *pm)
static int pcmidi_get_output_report(struct pcmidi_snd *pm)
{
- struct hid_device *hdev = pm->pk->hdev;
+ struct hid_device *hdev = pm->hdev;
struct hid_report *report;
list_for_each_entry(report,
@@ -293,7 +285,7 @@ static int pcmidi_get_output_report(struct pcmidi_snd *pm)
static void pcmidi_submit_output_report(struct pcmidi_snd *pm, int state)
{
- struct hid_device *hdev = pm->pk->hdev;
+ struct hid_device *hdev = pm->hdev;
struct hid_report *report = pm->pcmidi_report6;
report->field[0]->value[0] = 0x01;
report->field[0]->value[1] = state;
@@ -620,7 +612,7 @@ static int pcmidi_snd_initialise(struct pcmidi_snd *pm)
/* Setup sound card */
- err = snd_card_new(&pm->pk->hdev->dev, index[dev], id[dev],
+ err = snd_card_new(&pm->hdev->dev, index[dev], id[dev],
THIS_MODULE, 0, &card);
if (err < 0) {
pk_error("failed to create pc-midi sound card\n");
@@ -658,7 +650,7 @@ static int pcmidi_snd_initialise(struct pcmidi_snd *pm)
&pcmidi_in_ops);
/* create sysfs variables */
- err = device_create_file(&pm->pk->hdev->dev,
+ err = device_create_file(&pm->hdev->dev,
sysfs_device_attr_channel);
if (err < 0) {
pk_error("failed to create sysfs attribute channel: error %d\n",
@@ -666,7 +658,7 @@ static int pcmidi_snd_initialise(struct pcmidi_snd *pm)
goto fail;
}
- err = device_create_file(&pm->pk->hdev->dev,
+ err = device_create_file(&pm->hdev->dev,
sysfs_device_attr_sustain);
if (err < 0) {
pk_error("failed to create sysfs attribute sustain: error %d\n",
@@ -674,7 +666,7 @@ static int pcmidi_snd_initialise(struct pcmidi_snd *pm)
goto fail_attr_sustain;
}
- err = device_create_file(&pm->pk->hdev->dev,
+ err = device_create_file(&pm->hdev->dev,
sysfs_device_attr_octave);
if (err < 0) {
pk_error("failed to create sysfs attribute octave: error %d\n",
@@ -704,11 +696,11 @@ static int pcmidi_snd_initialise(struct pcmidi_snd *pm)
fail_register:
stop_sustain_timers(pm);
- device_remove_file(&pm->pk->hdev->dev, sysfs_device_attr_octave);
+ device_remove_file(&pm->hdev->dev, sysfs_device_attr_octave);
fail_attr_octave:
- device_remove_file(&pm->pk->hdev->dev, sysfs_device_attr_sustain);
+ device_remove_file(&pm->hdev->dev, sysfs_device_attr_sustain);
fail_attr_sustain:
- device_remove_file(&pm->pk->hdev->dev, sysfs_device_attr_channel);
+ device_remove_file(&pm->hdev->dev, sysfs_device_attr_channel);
fail:
if (pm->card) {
snd_card_free(pm->card);
@@ -722,12 +714,9 @@ static int pcmidi_snd_terminate(struct pcmidi_snd *pm)
if (pm->card) {
stop_sustain_timers(pm);
- device_remove_file(&pm->pk->hdev->dev,
- sysfs_device_attr_channel);
- device_remove_file(&pm->pk->hdev->dev,
- sysfs_device_attr_sustain);
- device_remove_file(&pm->pk->hdev->dev,
- sysfs_device_attr_octave);
+ device_remove_file(&pm->hdev->dev, sysfs_device_attr_channel);
+ device_remove_file(&pm->hdev->dev, sysfs_device_attr_sustain);
+ device_remove_file(&pm->hdev->dev, sysfs_device_attr_octave);
snd_card_disconnect(pm->card);
snd_card_free_when_closed(pm->card);
@@ -757,10 +746,7 @@ static int pk_input_mapping(struct hid_device *hdev, struct hid_input *hi,
struct hid_field *field, struct hid_usage *usage,
unsigned long **bit, int *max)
{
- struct pk_device *pk = hid_get_drvdata(hdev);
- struct pcmidi_snd *pm;
-
- pm = pk->pm;
+ struct pcmidi_snd *pm = hid_get_drvdata(hdev);
if (HID_UP_MSVENDOR == (usage->hid & HID_USAGE_PAGE) &&
1 == pm->ifnum) {
@@ -775,16 +761,16 @@ static int pk_input_mapping(struct hid_device *hdev, struct hid_input *hi,
static int pk_raw_event(struct hid_device *hdev, struct hid_report *report,
u8 *data, int size)
{
- struct pk_device *pk = hid_get_drvdata(hdev);
+ struct pcmidi_snd *pm = hid_get_drvdata(hdev);
int ret = 0;
- if (1 == pk->pm->ifnum) {
+ if (1 == pm->ifnum) {
if (report->id == data[0])
switch (report->id) {
case 0x01: /* midi keys (qwerty)*/
case 0x03: /* midi keyboard (musical)*/
case 0x04: /* extra/midi keys (qwerty)*/
- ret = pcmidi_handle_report(pk->pm,
+ ret = pcmidi_handle_report(pm,
report->id, data, size);
break;
}
@@ -799,8 +785,7 @@ static int pk_probe(struct hid_device *hdev, const struct hid_device_id *id)
struct usb_interface *intf;
unsigned short ifnum;
unsigned long quirks = id->driver_data;
- struct pk_device *pk;
- struct pcmidi_snd *pm = NULL;
+ struct pcmidi_snd *pm;
if (!hid_is_usb(hdev))
return -EINVAL;
@@ -808,26 +793,16 @@ static int pk_probe(struct hid_device *hdev, const struct hid_device_id *id)
intf = to_usb_interface(hdev->dev.parent);
ifnum = intf->cur_altsetting->desc.bInterfaceNumber;
- pk = kzalloc(sizeof(*pk), GFP_KERNEL);
- if (pk == NULL) {
- hid_err(hdev, "can't alloc descriptor\n");
- return -ENOMEM;
- }
-
- pk->hdev = hdev;
-
pm = kzalloc(sizeof(*pm), GFP_KERNEL);
if (pm == NULL) {
hid_err(hdev, "can't alloc descriptor\n");
- ret = -ENOMEM;
- goto err_free_pk;
+ return -ENOMEM;
}
- pm->pk = pk;
- pk->pm = pm;
+ pm->hdev = hdev;
pm->ifnum = ifnum;
- hid_set_drvdata(hdev, pk);
+ hid_set_drvdata(hdev, pm);
ret = hid_parse(hdev);
if (ret) {
@@ -854,26 +829,18 @@ static int pk_probe(struct hid_device *hdev, const struct hid_device_id *id)
hid_hw_stop(hdev);
err_free:
kfree(pm);
-err_free_pk:
- kfree(pk);
return ret;
}
static void pk_remove(struct hid_device *hdev)
{
- struct pk_device *pk = hid_get_drvdata(hdev);
- struct pcmidi_snd *pm;
-
- pm = pk->pm;
- if (pm) {
- pcmidi_snd_terminate(pm);
- kfree(pm);
- }
+ struct pcmidi_snd *pm = hid_get_drvdata(hdev);
+ pcmidi_snd_terminate(pm);
hid_hw_stop(hdev);
- kfree(pk);
+ kfree(pm);
}
static const struct hid_device_id pk_devices[] = {
--
2.43.0
^ permalink raw reply related
* [dtor-input:next] BUILD SUCCESS 7d0f351da46098b3bbb147f886f059473b84ff48
From: kernel test robot @ 2024-02-01 15:13 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: 7d0f351da46098b3bbb147f886f059473b84ff48 Input: matrix_keypad - switch to using managed resources
elapsed time: 1200m
configs tested: 195
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240201 gcc
arc randconfig-002-20240201 gcc
arm allmodconfig gcc
arm allnoconfig gcc
arm allyesconfig gcc
arm aspeed_g4_defconfig clang
arm defconfig clang
arm hisi_defconfig gcc
arm mvebu_v7_defconfig clang
arm randconfig-001-20240201 gcc
arm randconfig-002-20240201 gcc
arm randconfig-003-20240201 gcc
arm randconfig-004-20240201 gcc
arm s5pv210_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240201 gcc
arm64 randconfig-002-20240201 gcc
arm64 randconfig-003-20240201 gcc
arm64 randconfig-004-20240201 gcc
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240201 gcc
csky randconfig-002-20240201 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240201 clang
hexagon randconfig-002-20240201 clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20240201 gcc
i386 buildonly-randconfig-002-20240201 gcc
i386 buildonly-randconfig-003-20240201 clang
i386 buildonly-randconfig-003-20240201 gcc
i386 buildonly-randconfig-004-20240201 clang
i386 buildonly-randconfig-004-20240201 gcc
i386 buildonly-randconfig-005-20240201 clang
i386 buildonly-randconfig-005-20240201 gcc
i386 buildonly-randconfig-006-20240201 gcc
i386 defconfig gcc
i386 randconfig-001-20240201 clang
i386 randconfig-001-20240201 gcc
i386 randconfig-002-20240201 clang
i386 randconfig-002-20240201 gcc
i386 randconfig-003-20240201 clang
i386 randconfig-003-20240201 gcc
i386 randconfig-004-20240201 clang
i386 randconfig-004-20240201 gcc
i386 randconfig-005-20240201 gcc
i386 randconfig-006-20240201 clang
i386 randconfig-006-20240201 gcc
i386 randconfig-011-20240201 clang
i386 randconfig-012-20240201 clang
i386 randconfig-012-20240201 gcc
i386 randconfig-013-20240201 clang
i386 randconfig-013-20240201 gcc
i386 randconfig-014-20240201 clang
i386 randconfig-014-20240201 gcc
i386 randconfig-015-20240201 clang
i386 randconfig-016-20240201 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240201 gcc
loongarch randconfig-002-20240201 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k m5275evb_defconfig gcc
m68k multi_defconfig gcc
m68k mvme147_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig clang
mips allyesconfig gcc
mips bmips_stb_defconfig clang
mips db1xxx_defconfig clang
mips ip28_defconfig gcc
mips maltaup_xpa_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240201 gcc
nios2 randconfig-002-20240201 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240201 gcc
parisc randconfig-002-20240201 gcc
parisc64 alldefconfig gcc
parisc64 defconfig gcc
powerpc acadia_defconfig clang
powerpc allmodconfig clang
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc mpc834x_itxgp_defconfig clang
powerpc mpc837x_rdb_defconfig gcc
powerpc pmac32_defconfig clang
powerpc ppa8548_defconfig gcc
powerpc ppc40x_defconfig clang
powerpc ppc44x_defconfig clang
powerpc ps3_defconfig gcc
powerpc randconfig-001-20240201 gcc
powerpc randconfig-002-20240201 gcc
powerpc randconfig-003-20240201 gcc
powerpc socrates_defconfig gcc
powerpc taishan_defconfig clang
powerpc wii_defconfig gcc
powerpc64 randconfig-001-20240201 gcc
powerpc64 randconfig-002-20240201 gcc
powerpc64 randconfig-003-20240201 gcc
riscv allmodconfig gcc
riscv allnoconfig clang
riscv allyesconfig gcc
riscv defconfig gcc
riscv nommu_k210_sdcard_defconfig gcc
riscv randconfig-001-20240201 gcc
riscv randconfig-002-20240201 gcc
riscv rv32_defconfig clang
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20240201 clang
s390 randconfig-002-20240201 clang
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh hp6xx_defconfig gcc
sh kfr2r09_defconfig gcc
sh randconfig-001-20240201 gcc
sh randconfig-002-20240201 gcc
sh se7705_defconfig gcc
sh se7722_defconfig gcc
sh secureedge5410_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc sparc32_defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240201 gcc
sparc64 randconfig-002-20240201 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um allyesconfig gcc
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20240201 gcc
um randconfig-002-20240201 gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240201 gcc
x86_64 buildonly-randconfig-002-20240201 gcc
x86_64 buildonly-randconfig-003-20240201 gcc
x86_64 buildonly-randconfig-004-20240201 gcc
x86_64 buildonly-randconfig-005-20240201 gcc
x86_64 buildonly-randconfig-006-20240201 gcc
x86_64 defconfig gcc
x86_64 randconfig-001-20240201 clang
x86_64 randconfig-002-20240201 clang
x86_64 randconfig-003-20240201 clang
x86_64 randconfig-004-20240201 clang
x86_64 randconfig-005-20240201 clang
x86_64 randconfig-006-20240201 clang
x86_64 randconfig-011-20240201 gcc
x86_64 randconfig-012-20240201 gcc
x86_64 randconfig-013-20240201 gcc
x86_64 randconfig-014-20240201 gcc
x86_64 randconfig-015-20240201 gcc
x86_64 randconfig-016-20240201 gcc
x86_64 randconfig-071-20240201 gcc
x86_64 randconfig-072-20240201 gcc
x86_64 randconfig-073-20240201 gcc
x86_64 randconfig-074-20240201 gcc
x86_64 randconfig-075-20240201 gcc
x86_64 randconfig-076-20240201 gcc
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa nommu_kc705_defconfig gcc
xtensa randconfig-001-20240201 gcc
xtensa randconfig-002-20240201 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [RFC PATCH 2/5] mfd: add 88pm88x driver
From: Karel Balej @ 2024-02-01 15:37 UTC (permalink / raw)
To: Lee Jones
Cc: Karel Balej, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-input, devicetree, linux-kernel,
Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <20240131110311.GI8551@google.com>
Lee Jones, 2024-01-31T11:03:11+00:00:
> On Sun, 28 Jan 2024, Karel Balej wrote:
> > > > + /* GPIO1: DVC, GPIO0: input */
> > > > + REG_SEQ0(PM88X_REG_GPIO_CTRL1, 0x40),
> > >
> > > Shouldn't you set these up using Pintrl?
> >
> > You mean to add a new MFD cell for the pins and write the respective
> > driver? The downstream implementation has no such thing so I'm not sure
> > if I would be able to do that from scratch.
>
> This is not a Pinctrl driver.
>
> Isn't there a generic API you can use?
I'm sorry, I don't think I understand what you mean.
Thank you,
K. B.
^ permalink raw reply
* Re: [PATCH v1 7/7] HID: playstation: DS4: Add VID/PID for SZ-MYPOWER controllers
From: Max Staudt @ 2024-02-01 15:56 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <CAEc3jaDFh3UY8AGnXA3s13DbcKTFnBT8Z7iq4qdqnM5o3nVHFA@mail.gmail.com>
On 2/1/24 01:34, Roderick Colenbrander wrote:
> I agree it sounds like a good idea for now to drop just those 2 paches
> and just see what other devices are out there (SDL2 has a good ds4
> implementation too and they dealt with a lot of devices). May need to
> get some of the 8bitdo and many others to see some patterns.
8BitDo seem to be interesting indeed. IIRC they need the patches for the firmware version, the gyro calibration, and 0x01 events.
Max
^ permalink raw reply
* Re: [PATCH v2 00/33] spi: get rid of some legacy macros
From: Jarkko Sakkinen @ 2024-02-01 21:47 UTC (permalink / raw)
To: Mark Brown, Greg Kroah-Hartman
Cc: Uwe Kleine-König, kernel, Moritz Fischer, Wu Hao, Xu Yilun,
Tom Rix, linux-fpga, linux-kernel, Alexander Aring,
Stefan Schmidt, Miquel Raynal, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-wpan, netdev,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
linux-iio, Dmitry Torokhov, linux-input, Ulf Hansson,
Rayyan Ansari, Andy Shevchenko, Jonathan Cameron, Martin Tuma,
Mauro Carvalho Chehab, linux-media, Sergey Kozlov, Arnd Bergmann,
Yang Yingliang, linux-mmc, Richard Weinberger,
Vignesh Raghavendra, Rob Herring, Heiko Stuebner, Michal Simek,
Amit Kumar Mahapatra via Alsa-devel, linux-mtd,
Martin Blumenstingl, Geert Uytterhoeven, Pali Rohár,
Simon Horman, Ronald Wahl, Benson Leung, Tzung-Bi Shih,
Guenter Roeck, chrome-platform, Max Filippov, linux-spi,
linux-arm-kernel, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
Matthias Brugger, AngeloGioacchino Del Regno, linux-mediatek,
Thomas Zimmermann, Javier Martinez Canillas, Amit Kumar Mahapatra,
dri-devel, linux-fbdev, linux-staging, Viresh Kumar,
Rui Miguel Silva, Johan Hovold, Alex Elder, greybus-dev,
Peter Huewe, Jason Gunthorpe, linux-integrity, Herve Codina,
Alan Stern, Aaro Koskinen, Krzysztof Kozlowski, linux-usb,
Helge Deller, Dario Binacchi, Kalle Valo, Dmitry Antipov,
libertas-dev, linux-wireless, Jonathan Corbet, James Clark,
Bjorn Helgaas, linux-doc
In-Reply-To: <c1e38a30-5075-4d01-af24-ac684e77cf29@sirena.org.uk>
On Wed Jan 24, 2024 at 7:22 PM EET, Mark Brown wrote:
> On Wed, Jan 24, 2024 at 09:13:49AM -0800, Greg Kroah-Hartman wrote:
> > On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote:
>
> > > Note that Jonathan Cameron has already applied patch 3 to his tree, it
> > > didn't appear in a public tree though yet. I still included it here to
> > > make the kernel build bots happy.
>
> > Are we supposed to take the individual changes in our different
> > subsystem trees, or do you want them all to go through the spi tree?
>
> Given that the final patch removes the legacy interfaces I'm expecting
> to take them via SPI.
+1
least fuss approach
BR, Jarkko
^ permalink raw reply
* Re: Re: [PATCH v4 1/3] dt-bindings: HID: i2c-hid: Document reset-related properties
From: Bjorn Andersson @ 2024-02-01 22:08 UTC (permalink / raw)
To: Johan Hovold
Cc: Bjorn Andersson, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Benjamin Tissoires,
Jiri Kosina, Konrad Dybcio, Johan Hovold, linux-arm-msm,
linux-input, devicetree, linux-kernel, Konrad Dybcio,
Krzysztof Kozlowski, Rob Herring
In-Reply-To: <Zbts-9tRDPcXbhYi@hovoldconsulting.com>
On Thu, Feb 01, 2024 at 11:05:47AM +0100, Johan Hovold wrote:
> On Wed, Jan 31, 2024 at 07:07:26PM -0800, Bjorn Andersson wrote:
> > Some I2C HID devices has a reset pin and requires that some specified
> > time elapses after this reset pin is deasserted, before communication
> > with the device is attempted.
> >
> > The Linux implementation is looking for these in the "reset-gpios" and
> > "post-reset-deassert-delay-ms" properties already, so use these property
> > names.
> >
> > Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > ---
> > Documentation/devicetree/bindings/input/hid-over-i2c.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.yaml b/Documentation/devicetree/bindings/input/hid-over-i2c.yaml
> > index 138caad96a29..f07ff4cb3d26 100644
> > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.yaml
> > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.yaml
> > @@ -50,6 +50,12 @@ properties:
> > description: Time required by the device after enabling its regulators
> > or powering it on, before it is ready for communication.
> >
> > + post-reset-deassert-delay-ms:
> > + description: Time required by the device after reset has been deasserted,
> > + before it is ready for communication.
>
> I know that Rob reluctantly acked this, but re-reading the commit
> message for the commit that added support for the reset gpio to the
> driver, and added a comment about this not having been added to the
> devicetree binding, it becomes obvious that the latter was done on
> purpose and that we probably should not be adding the
> 'post-reset-deassert-delay-ms' property after all:
>
> For now the new "post-reset-deassert-delay-ms" property is only
> used on x86/ACPI (non devicetree) devs. IOW it is not used in
> actual devicetree files and the same goes for the reset GPIO.
> The devicetree-bindings maintainers have requested properties
> like these to not be added to the devicetree-bindings, so the
> new property + GPIO are deliberately not added to the existing
> devicetree-bindings.
>
> 2be404486c05 ("HID: i2c-hid-of: Add reset GPIO support to i2c-hid-of")
>
> So perhaps we should just do this properly and add a new compatible
> property for X13s touchscreen which can be used to determine these
> delays (e.g. for cases where some default values are insufficient).
>
So we should add a new binding, with a device-specific compatible and
add a reset-gpios only for that (and not the generic hid-over-i2c
binding), and then in the i2c-hid driver encode the two delays?
I can try to rewrite these patches, if you can provide me with a
compatible.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v7 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
From: kernel test robot @ 2024-02-01 23:00 UTC (permalink / raw)
To: Kamel Bouhara, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Henrik Rydberg, linux-input, linux-kernel,
devicetree, Marco Felsch, Jeff LaBundy
Cc: oe-kbuild-all, catalin.popescu, mark.satterthwaite,
Thomas Petazzoni, Gregory Clement, bsp-development.geo,
Kamel Bouhara
In-Reply-To: <20240131141158.3350344-4-kamel.bouhara@bootlin.com>
Hi Kamel,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on dtor-input/for-linus robh/for-next krzk-dt/for-next linus/master v6.8-rc2 next-20240201]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Kamel-Bouhara/dt-bindings-vendor-prefixes-Add-TouchNetix-AS/20240131-221925
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link: https://lore.kernel.org/r/20240131141158.3350344-4-kamel.bouhara%40bootlin.com
patch subject: [PATCH v7 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
config: s390-randconfig-r131-20240201 (https://download.01.org/0day-ci/archive/20240202/202402020623.8T1Ah513-lkp@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project fdac7d0b6f74f919d319b31a0680c77f66732586)
reproduce: (https://download.01.org/0day-ci/archive/20240202/202402020623.8T1Ah513-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202402020623.8T1Ah513-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/input/touchscreen/touchnetix_axiom.c:181:18: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le32 [usertype] preamble @@ got unsigned int @@
drivers/input/touchscreen/touchnetix_axiom.c:181:18: sparse: expected restricted __le32 [usertype] preamble
drivers/input/touchscreen/touchnetix_axiom.c:181:18: sparse: got unsigned int
>> drivers/input/touchscreen/touchnetix_axiom.c:183:40: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned int reg @@ got restricted __le32 [usertype] preamble @@
drivers/input/touchscreen/touchnetix_axiom.c:183:40: sparse: expected unsigned int reg
drivers/input/touchscreen/touchnetix_axiom.c:183:40: sparse: got restricted __le32 [usertype] preamble
vim +181 drivers/input/touchscreen/touchnetix_axiom.c
171
172 static int axiom_read(struct axiom_data *ts, u8 usage, u8 page, void *buf, u16 len)
173 {
174 struct axiom_cmd_header cmd_header;
175 __le32 preamble;
176 int ret;
177
178 cmd_header.target_address = cpu_to_le16(axiom_usage_to_target_address(ts, usage, page, 0));
179 cmd_header.length = cpu_to_le16(len | AXIOM_CMD_HEADER_READ_MASK);
180
> 181 preamble = get_unaligned_le32((u8 *)&cmd_header);
182
> 183 ret = regmap_write(ts->regmap, preamble, 0);
184 if (ret) {
185 dev_err(ts->dev, "failed to write preamble, error %d\n", ret);
186 return ret;
187 }
188
189 ret = regmap_raw_read(ts->regmap, 0, buf, len);
190 if (ret) {
191 dev_err(ts->dev, "failed to read target address %04x, error %d\n",
192 cmd_header.target_address, ret);
193 return ret;
194 }
195
196 /* Wait device's DMA operations */
197 usleep_range(AXIOM_DMA_OPS_DELAY_USEC, AXIOM_DMA_OPS_DELAY_USEC + 50);
198
199 return 0;
200 }
201
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/7] HID: wacom: remove unused hid_data::pressure
From: Ping Cheng @ 2024-02-02 2:30 UTC (permalink / raw)
To: Jiri Slaby (SUSE)
Cc: jikos, linux-input, linux-kernel, Ping Cheng, Jason Gerecke,
Benjamin Tissoires
In-Reply-To: <20240201115320.684-3-jirislaby@kernel.org>
On Thu, Feb 1, 2024 at 3:53 AM Jiri Slaby (SUSE) <jirislaby@kernel.org> wrote:
>
> The pressure member in struct hid_data is unused. It was
> added in commit 5ae6e89f7409 (HID: wacom: implement the finger part of
> the HID generic handling), but never used.
>
> As this is not a struct to communicate with the HW, remove that member.
>
> Found by https://github.com/jirislaby/clang-struct.
>
> Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Wacom current touch devices do not support pressure. We could add pressure
back when it is necessary in the future. Thank you Jiri.
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Cheers,
Ping
> Cc: Ping Cheng <ping.cheng@wacom.com>
> Cc: Jason Gerecke <jason.gerecke@wacom.com>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
> drivers/hid/wacom_wac.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
> index e63b1e806e34..6ec499841f70 100644
> --- a/drivers/hid/wacom_wac.h
> +++ b/drivers/hid/wacom_wac.h
> @@ -309,7 +309,6 @@ struct hid_data {
> bool confidence;
> int x;
> int y;
> - int pressure;
> int width;
> int height;
> int id;
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH regression fix 0/2] Input: atkbd - Fix Dell XPS 13 line suspend/resume regression
From: Dmitry Torokhov @ 2024-02-02 4:55 UTC (permalink / raw)
To: Hans de Goede; +Cc: Paul Menzel, stable, regressions, linux-input
In-Reply-To: <20240126160724.13278-1-hdegoede@redhat.com>
On Fri, Jan 26, 2024 at 05:07:22PM +0100, Hans de Goede wrote:
> Hi Dmitry,
>
> There have been multiple reports that the keyboard on
> Dell XPS 13 9350 / 9360 / 9370 models has stopped working after
> a suspend/resume after the merging of commit 936e4d49ecbc ("Input:
> atkbd - skip ATKBD_CMD_GETID in translated mode").
>
> See the 4 closes tags in the first patch for 4 reports of this.
>
> I have been working with the first reporter on resolving this
> and testing on his Dell XPS 13 9360 confirms that these patches
> fix things.
>
> Unfortunately the commit causing the issue has also been picked
> up by multiple stable kernel series now. Can you please send
> these fixes to Linus ASAP, so that they can also be backported
> to the stable series ASAP ?
>
> Alternatively we could revert the commit causing this, but that
> commit is know to fix issues on a whole bunch of other laptops
> so I would rather not revert it.
>
> Regards,
>
> Hans
>
>
> Hans de Goede (2):
> Input: atkbd - Skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID
> Input: atkbd - Do not skip atkbd_deactivate() when skipping
> ATKBD_CMD_GETID
Applied the lot to 'for-linus' branch, I will get it into the next push.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH regression fix 2/2] Input: atkbd - Do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID
From: Dmitry Torokhov @ 2024-02-02 4:56 UTC (permalink / raw)
To: Hans de Goede; +Cc: Paul Menzel, stable, regressions, linux-input
In-Reply-To: <20240126160724.13278-3-hdegoede@redhat.com>
On Fri, Jan 26, 2024 at 05:07:24PM +0100, Hans de Goede wrote:
> After commit 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in
> translated mode") not only the getid command is skipped, but also
> the de-activating of the keyboard at the end of atkbd_probe(), potentially
> re-introducing the problem fixed by commit be2d7e4233a4 ("Input: atkbd -
> fix multi-byte scancode handling on reconnect").
>
> Make sure multi-byte scancode handling on reconnect is still handled
> correctly by not skipping the atkbd_deactivate() call.
>
> Fixes: 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/input/keyboard/atkbd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index c229bd6b3f7f..7f67f9f2946b 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -826,7 +826,7 @@ static int atkbd_probe(struct atkbd *atkbd)
>
> if (atkbd_skip_getid(atkbd)) {
> atkbd->id = 0xab83;
> - return 0;
> + goto deactivate_kbd;
> }
>
> /*
> @@ -863,6 +863,7 @@ static int atkbd_probe(struct atkbd *atkbd)
> return -1;
> }
>
> +deactivate_kbd:
> /*
> * Make sure nothing is coming from the keyboard and disturbs our
> * internal state.
I wonder if we need to do the same for the case when we go into SET LEDS
branch... This can be done in a separate patch though.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH regression fix 2/2] Input: atkbd - Do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID
From: Hans de Goede @ 2024-02-02 7:58 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Paul Menzel, stable, regressions, linux-input
In-Reply-To: <Zbx2Cuhfy-rpcvCE@google.com>
Hi Dmitry,
Thank you for picking up these fixes and
sorry about the breakage.
On 2/2/24 05:56, Dmitry Torokhov wrote:
> On Fri, Jan 26, 2024 at 05:07:24PM +0100, Hans de Goede wrote:
>> After commit 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in
>> translated mode") not only the getid command is skipped, but also
>> the de-activating of the keyboard at the end of atkbd_probe(), potentially
>> re-introducing the problem fixed by commit be2d7e4233a4 ("Input: atkbd -
>> fix multi-byte scancode handling on reconnect").
>>
>> Make sure multi-byte scancode handling on reconnect is still handled
>> correctly by not skipping the atkbd_deactivate() call.
>>
>> Fixes: 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
>> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/input/keyboard/atkbd.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
>> index c229bd6b3f7f..7f67f9f2946b 100644
>> --- a/drivers/input/keyboard/atkbd.c
>> +++ b/drivers/input/keyboard/atkbd.c
>> @@ -826,7 +826,7 @@ static int atkbd_probe(struct atkbd *atkbd)
>>
>> if (atkbd_skip_getid(atkbd)) {
>> atkbd->id = 0xab83;
>> - return 0;
>> + goto deactivate_kbd;
>> }
>>
>> /*
>> @@ -863,6 +863,7 @@ static int atkbd_probe(struct atkbd *atkbd)
>> return -1;
>> }
>>
>> +deactivate_kbd:
>> /*
>> * Make sure nothing is coming from the keyboard and disturbs our
>> * internal state.
>
> I wonder if we need to do the same for the case when we go into SET LEDS
> branch... This can be done in a separate patch though.
Right my goal with this series was to make the behavior change from
936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
as small as possible (just skip ATKBD_CMD_GETID and no other behavior
change like calling SET_LEDS).
I'm not sure about doing the same as this patch for the SET_LEDS
path. We only hit that path if GETID fails which means we are
already dealing with quirky hardware and we already have quirks
to skip the deactivate command for some keyboards which don't
like it...
Let me know if you still want to give making the SET_LEDS
path consistent with the others a go and have it call deactive
too. IMHO that would only be something for -next though,
so that it gets the maximum amount of testing time.
Regards,
Hans
^ permalink raw reply
* Re: PS/2 keyboard of laptop Dell XPS 13 9360 goes missing after S3
From: Linux regression tracking #update (Thorsten Leemhuis) @ 2024-02-02 8:05 UTC (permalink / raw)
To: LKML; +Cc: linux-input, linux-pm, regressions
In-Reply-To: <4eaf27ed-66a2-4aeb-a6b9-21e2b0455676@leemhuis.info>
On 27.01.24 09:12, Linux regression tracking #update (Thorsten Leemhuis)
wrote:
> On 18.01.24 13:57, Paul Menzel wrote:
>> #regzbot introduced v6.6.11..v6.7
>
> #regzbot introduced 936e4d49ecbc
> #regzbot ignore-activity
#regzbot monitor:
https://lore.kernel.org/all/20240126160724.13278-1-hdegoede@redhat.com/
#regzbot fix: 683cd8259a9b883a51
#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: [RFC PATCH 2/5] mfd: add 88pm88x driver
From: Lee Jones @ 2024-02-02 12:45 UTC (permalink / raw)
To: Karel Balej
Cc: Karel Balej, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-input, devicetree, linux-kernel,
Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <CYTURHOW0WMR.2UMOT0D1GFZ2W@gimli.ms.mff.cuni.cz>
On Thu, 01 Feb 2024, Karel Balej wrote:
> Lee Jones, 2024-01-31T11:03:11+00:00:
> > On Sun, 28 Jan 2024, Karel Balej wrote:
> > > > > + /* GPIO1: DVC, GPIO0: input */
> > > > > + REG_SEQ0(PM88X_REG_GPIO_CTRL1, 0x40),
> > > >
> > > > Shouldn't you set these up using Pintrl?
> > >
> > > You mean to add a new MFD cell for the pins and write the respective
> > > driver? The downstream implementation has no such thing so I'm not sure
> > > if I would be able to do that from scratch.
> >
> > This is not a Pinctrl driver.
> >
> > Isn't there a generic API you can use?
>
> I'm sorry, I don't think I understand what you mean.
Perhaps I misunderstand the code. It looks like this regmap patch hack
is configuring pins and a bunch of other things. Would that be a
correct assessment?
If so, where do we draw the line here? Do we accept a 1000 line driver
which configures a large SoC with a bunch of bespoke register writes?
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [RFC PATCH 2/5] mfd: add 88pm88x driver
From: Karel Balej @ 2024-02-02 12:55 UTC (permalink / raw)
To: Lee Jones
Cc: Karel Balej, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-input, devicetree, linux-kernel,
Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <20240202124550.GE1379817@google.com>
Lee Jones, 2024-02-02T12:45:50+00:00:
> On Thu, 01 Feb 2024, Karel Balej wrote:
>
> > Lee Jones, 2024-01-31T11:03:11+00:00:
> > > On Sun, 28 Jan 2024, Karel Balej wrote:
> > > > > > + /* GPIO1: DVC, GPIO0: input */
> > > > > > + REG_SEQ0(PM88X_REG_GPIO_CTRL1, 0x40),
> > > > >
> > > > > Shouldn't you set these up using Pintrl?
> > > >
> > > > You mean to add a new MFD cell for the pins and write the respective
> > > > driver? The downstream implementation has no such thing so I'm not sure
> > > > if I would be able to do that from scratch.
> > >
> > > This is not a Pinctrl driver.
> > >
> > > Isn't there a generic API you can use?
> >
> > I'm sorry, I don't think I understand what you mean.
>
> Perhaps I misunderstand the code. It looks like this regmap patch hack
> is configuring pins and a bunch of other things. Would that be a
> correct assessment?
Yes, that sounds correct.
> If so, where do we draw the line here? Do we accept a 1000 line driver
> which configures a large SoC with a bunch of bespoke register writes?
I understand, I just don't know what you mean by "a generic API". I'm
also not clear on whether what you have in mind is simply adding a
dedicated driver for the pins as a new subdevice of this MFD.
Thanks,
K. B.
^ permalink raw reply
* Re: [RFC PATCH 2/5] mfd: add 88pm88x driver
From: Lee Jones @ 2024-02-02 13:29 UTC (permalink / raw)
To: Karel Balej, Linus Walleij
Cc: Karel Balej, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-input, devicetree, linux-kernel,
Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <CYULY1BYVCYK.1EGSBSVNRSTLQ@gimli.ms.mff.cuni.cz>
Linus,
On Fri, 02 Feb 2024, Karel Balej wrote:
> Lee Jones, 2024-02-02T12:45:50+00:00:
> > On Thu, 01 Feb 2024, Karel Balej wrote:
> >
> > > Lee Jones, 2024-01-31T11:03:11+00:00:
> > > > On Sun, 28 Jan 2024, Karel Balej wrote:
> > > > > > > + /* GPIO1: DVC, GPIO0: input */
> > > > > > > + REG_SEQ0(PM88X_REG_GPIO_CTRL1, 0x40),
Do we have a precedent for drivers setting up their own pins like this?
> > > > > > Shouldn't you set these up using Pintrl?
> > > > >
> > > > > You mean to add a new MFD cell for the pins and write the respective
> > > > > driver? The downstream implementation has no such thing so I'm not sure
> > > > > if I would be able to do that from scratch.
> > > >
> > > > This is not a Pinctrl driver.
> > > >
> > > > Isn't there a generic API you can use?
> > >
> > > I'm sorry, I don't think I understand what you mean.
> >
> > Perhaps I misunderstand the code. It looks like this regmap patch hack
> > is configuring pins and a bunch of other things. Would that be a
> > correct assessment?
>
> Yes, that sounds correct.
>
> > If so, where do we draw the line here? Do we accept a 1000 line driver
> > which configures a large SoC with a bunch of bespoke register writes?
>
> I understand, I just don't know what you mean by "a generic API". I'm
> also not clear on whether what you have in mind is simply adding a
> dedicated driver for the pins as a new subdevice of this MFD.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2] Fix strange behavior of touchpad on Clevo NS70PU
From: Werner Sembach @ 2024-02-02 14:26 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20231205163602.16106-1-wse@tuxedocomputers.com>
gentle bump
Am 05.12.23 um 17:36 schrieb Werner Sembach:
> When closing the laptop lid with an external screen connected, the mouse
> pointer has a constant movement to the lower right corner. Opening the
> lid again stops this movement, but after that the touchpad does no longer
> register clicks.
>
> The touchpad is connected both via i2c-hid and PS/2, the predecessor of
> this device (NS70MU) has the same layout in this regard and also strange
> behaviour caused by the psmouse and the i2c-hid driver fighting over
> touchpad control. This fix is reusing the same workaround by just
> disabling the PS/2 aux port, that is only used by the touchpad, to give the
> i2c-hid driver the lone control over the touchpad.
>
> v2: Rebased on current master
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/input/serio/i8042-acpipnpio.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/input/serio/i8042-acpipnpio.h b/drivers/input/serio/i8042-acpipnpio.h
> index 9c39553d30fa2..b31d3285bea69 100644
> --- a/drivers/input/serio/i8042-acpipnpio.h
> +++ b/drivers/input/serio/i8042-acpipnpio.h
> @@ -1200,6 +1200,12 @@ static const struct dmi_system_id i8042_dmi_quirk_table[] __initconst = {
> SERIO_QUIRK_RESET_ALWAYS | SERIO_QUIRK_NOLOOP |
> SERIO_QUIRK_NOPNP)
> },
> + {
> + .matches = {
> + DMI_MATCH(DMI_BOARD_NAME, "NS5x_7xPU"),
> + },
> + .driver_data = (void *)(SERIO_QUIRK_NOAUX)
> + },
> {
> .matches = {
> DMI_MATCH(DMI_BOARD_NAME, "NJ50_70CU"),
^ 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