* [PATCH AUTOSEL 5.10 04/15] HID: intel-ish-hid: ipc: Fix potential use-after-free in work function
From: Sasha Levin @ 2023-03-20 0:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Reka Norman, Srinivas Pandruvada, Jiri Kosina, Sasha Levin, jikos,
benjamin.tissoires, liqiong, linux-input
In-Reply-To: <20230320005559.1429040-1-sashal@kernel.org>
From: Reka Norman <rekanorman@chromium.org>
[ Upstream commit 8ae2f2b0a28416ed2f6d8478ac8b9f7862f36785 ]
When a reset notify IPC message is received, the ISR schedules a work
function and passes the ISHTP device to it via a global pointer
ishtp_dev. If ish_probe() fails, the devm-managed device resources
including ishtp_dev are freed, but the work is not cancelled, causing a
use-after-free when the work function tries to access ishtp_dev. Use
devm_work_autocancel() instead, so that the work is automatically
cancelled if probe fails.
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/intel-ish-hid/ipc/ipc.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c
index a45ac7fa417b9..b950873c300b3 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -5,6 +5,7 @@
* Copyright (c) 2014-2016, Intel Corporation.
*/
+#include <linux/devm-helpers.h>
#include <linux/sched.h>
#include <linux/spinlock.h>
#include <linux/delay.h>
@@ -594,7 +595,6 @@ static void recv_ipc(struct ishtp_device *dev, uint32_t doorbell_val)
case MNG_RESET_NOTIFY:
if (!ishtp_dev) {
ishtp_dev = dev;
- INIT_WORK(&fw_reset_work, fw_reset_work_fn);
}
schedule_work(&fw_reset_work);
break;
@@ -885,6 +885,7 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev)
{
struct ishtp_device *dev;
int i;
+ int ret;
dev = devm_kzalloc(&pdev->dev,
sizeof(struct ishtp_device) + sizeof(struct ish_hw),
@@ -920,6 +921,12 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev)
list_add_tail(&tx_buf->link, &dev->wr_free_list);
}
+ ret = devm_work_autocancel(&pdev->dev, &fw_reset_work, fw_reset_work_fn);
+ if (ret) {
+ dev_err(dev->devc, "Failed to initialise FW reset work\n");
+ return NULL;
+ }
+
dev->ops = &ish_hw_ops;
dev->devc = &pdev->dev;
dev->mtu = IPC_PAYLOAD_SIZE - sizeof(struct ishtp_msg_hdr);
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 01/12] HID: uhid: Over-ride the default maximum data buffer value with our own
From: Sasha Levin @ 2023-03-20 0:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lee Jones, Jiri Kosina, Sasha Levin, david.rheinsberg, jikos,
benjamin.tissoires, linux-input
From: Lee Jones <lee@kernel.org>
[ Upstream commit 1c5d4221240a233df2440fe75c881465cdf8da07 ]
The default maximum data buffer size for this interface is UHID_DATA_MAX
(4k). When data buffers are being processed, ensure this value is used
when ensuring the sanity, rather than a value between the user provided
value and HID_MAX_BUFFER_SIZE (16k).
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/uhid.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
index fc06d8bb42e0f..ba0ca652b9dab 100644
--- a/drivers/hid/uhid.c
+++ b/drivers/hid/uhid.c
@@ -395,6 +395,7 @@ struct hid_ll_driver uhid_hid_driver = {
.parse = uhid_hid_parse,
.raw_request = uhid_hid_raw_request,
.output_report = uhid_hid_output_report,
+ .max_buffer_size = UHID_DATA_MAX,
};
EXPORT_SYMBOL_GPL(uhid_hid_driver);
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 1/9] HID: uhid: Over-ride the default maximum data buffer value with our own
From: Sasha Levin @ 2023-03-20 0:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lee Jones, Jiri Kosina, Sasha Levin, david.rheinsberg, jikos,
benjamin.tissoires, linux-input
From: Lee Jones <lee@kernel.org>
[ Upstream commit 1c5d4221240a233df2440fe75c881465cdf8da07 ]
The default maximum data buffer size for this interface is UHID_DATA_MAX
(4k). When data buffers are being processed, ensure this value is used
when ensuring the sanity, rather than a value between the user provided
value and HID_MAX_BUFFER_SIZE (16k).
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/uhid.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
index 333b6a769189c..b7efc5c055be1 100644
--- a/drivers/hid/uhid.c
+++ b/drivers/hid/uhid.c
@@ -399,6 +399,7 @@ struct hid_ll_driver uhid_hid_driver = {
.parse = uhid_hid_parse,
.raw_request = uhid_hid_raw_request,
.output_report = uhid_hid_output_report,
+ .max_buffer_size = UHID_DATA_MAX,
};
EXPORT_SYMBOL_GPL(uhid_hid_driver);
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 1/9] HID: uhid: Over-ride the default maximum data buffer value with our own
From: Sasha Levin @ 2023-03-20 0:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lee Jones, Jiri Kosina, Sasha Levin, david.rheinsberg, jikos,
benjamin.tissoires, linux-input
From: Lee Jones <lee@kernel.org>
[ Upstream commit 1c5d4221240a233df2440fe75c881465cdf8da07 ]
The default maximum data buffer size for this interface is UHID_DATA_MAX
(4k). When data buffers are being processed, ensure this value is used
when ensuring the sanity, rather than a value between the user provided
value and HID_MAX_BUFFER_SIZE (16k).
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/uhid.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
index e128b9ce156df..44df81d56d9ca 100644
--- a/drivers/hid/uhid.c
+++ b/drivers/hid/uhid.c
@@ -398,6 +398,7 @@ struct hid_ll_driver uhid_hid_driver = {
.parse = uhid_hid_parse,
.raw_request = uhid_hid_raw_request,
.output_report = uhid_hid_output_report,
+ .max_buffer_size = UHID_DATA_MAX,
};
EXPORT_SYMBOL_GPL(uhid_hid_driver);
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.1 04/29] HID: logitech-hidpp: Add support for Logitech MX Master 3S mouse
From: Sasha Levin @ 2023-03-20 0:53 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Rafał Szalecki, Bastien Nocera, Jiri Kosina, Sasha Levin,
jikos, benjamin.tissoires, linux-input
In-Reply-To: <20230320005413.1428452-1-sashal@kernel.org>
From: Rafał Szalecki <perexist7@gmail.com>
[ Upstream commit db50f7a3983f0154e730f1147ef729e0c5c2f90c ]
Add signature for the Logitech MX Master 3S mouse over Bluetooth.
Signed-off-by: Rafał Szalecki <perexist7@gmail.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index fdb66dc065822..e906ee375298a 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4378,6 +4378,8 @@ static const struct hid_device_id hidpp_devices[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01e) },
{ /* MX Master 3 mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb023) },
+ { /* MX Master 3S mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb034) },
{}
};
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 03/12] HID: intel-ish-hid: ipc: Fix potential use-after-free in work function
From: Sasha Levin @ 2023-03-20 0:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Reka Norman, Srinivas Pandruvada, Jiri Kosina, Sasha Levin, jikos,
benjamin.tissoires, liqiong, linux-input
In-Reply-To: <20230320005636.1429242-1-sashal@kernel.org>
From: Reka Norman <rekanorman@chromium.org>
[ Upstream commit 8ae2f2b0a28416ed2f6d8478ac8b9f7862f36785 ]
When a reset notify IPC message is received, the ISR schedules a work
function and passes the ISHTP device to it via a global pointer
ishtp_dev. If ish_probe() fails, the devm-managed device resources
including ishtp_dev are freed, but the work is not cancelled, causing a
use-after-free when the work function tries to access ishtp_dev. Use
devm_work_autocancel() instead, so that the work is automatically
cancelled if probe fails.
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/intel-ish-hid/ipc/ipc.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c
index 8f8dfdf64833e..e23766ca9d3e1 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -5,6 +5,7 @@
* Copyright (c) 2014-2016, Intel Corporation.
*/
+#include <linux/devm-helpers.h>
#include <linux/sched.h>
#include <linux/spinlock.h>
#include <linux/delay.h>
@@ -594,7 +595,6 @@ static void recv_ipc(struct ishtp_device *dev, uint32_t doorbell_val)
case MNG_RESET_NOTIFY:
if (!ishtp_dev) {
ishtp_dev = dev;
- INIT_WORK(&fw_reset_work, fw_reset_work_fn);
}
schedule_work(&fw_reset_work);
break;
@@ -885,6 +885,7 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev)
{
struct ishtp_device *dev;
int i;
+ int ret;
dev = devm_kzalloc(&pdev->dev,
sizeof(struct ishtp_device) + sizeof(struct ish_hw),
@@ -920,6 +921,12 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev)
list_add_tail(&tx_buf->link, &dev->wr_free_list);
}
+ ret = devm_work_autocancel(&pdev->dev, &fw_reset_work, fw_reset_work_fn);
+ if (ret) {
+ dev_err(dev->devc, "Failed to initialise FW reset work\n");
+ return NULL;
+ }
+
dev->ops = &ish_hw_ops;
dev->devc = &pdev->dev;
dev->mtu = IPC_PAYLOAD_SIZE - sizeof(struct ishtp_msg_hdr);
--
2.39.2
^ permalink raw reply related
* [PATCH] Input: elan_i2c - Implement inhibit/uninhibit functions.
From: jingle.wu @ 2023-03-20 1:14 UTC (permalink / raw)
To: linux-kernel, linux-input, dmitry.torokhov
Cc: phoenix, josh.chen, dave.wang, jingle.wu
Add inhibit/uninhibit functions.
Signed-off-by: Jingle.wu <jingle.wu@emc.com.tw>
---
drivers/input/mouse/elan_i2c_core.c | 86 +++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index 5f0d75a45c80..b7100945c9cc 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -329,6 +329,89 @@ static int elan_initialize(struct elan_tp_data *data, bool skip_reset)
return error;
}
+static int elan_reactivate(struct elan_tp_data *data)
+{
+ struct device *dev = &data->client->dev;
+ int ret;
+
+ ret = elan_set_power(data, true);
+ if (ret)
+ dev_err(dev, "failed to restore power: %d\n", ret);
+
+ ret = data->ops->sleep_control(data->client, false);
+ if (ret) {
+ dev_err(dev,
+ "failed to wake device up: %d\n", ret);
+ return ret;
+ }
+
+ return ret;
+}
+
+static void elan_inhibit(struct input_dev *input_dev)
+{
+ struct elan_tp_data *data = input_get_drvdata(input_dev);
+ struct i2c_client *client = data->client;
+ int ret;
+
+ if (data->in_fw_update)
+ return;
+
+ dev_dbg(&client->dev, "inhibiting\n");
+ /*
+ * We are taking the mutex to make sure sysfs operations are
+ * complete before we attempt to bring the device into low[er]
+ * power mode.
+ */
+ ret = mutex_lock_interruptible(&data->sysfs_mutex);
+ if (ret)
+ return;
+
+ disable_irq(client->irq);
+
+ ret = elan_set_power(data, false);
+ if (ret)
+ enable_irq(client->irq);
+
+ mutex_unlock(&data->sysfs_mutex);
+
+}
+
+static void elan_close(struct input_dev *input_dev)
+{
+ if ((input_dev->users) && (!input_dev->inhibited))
+ elan_inhibit(input_dev);
+
+}
+
+static int elan_uninhibit(struct input_dev *input_dev)
+{
+ struct elan_tp_data *data = input_get_drvdata(input_dev);
+ struct i2c_client *client = data->client;
+ int ret;
+
+ dev_dbg(&client->dev, "uninhibiting\n");
+ ret = mutex_lock_interruptible(&data->sysfs_mutex);
+ if (ret)
+ return ret;
+
+ ret = elan_reactivate(data);
+ if (ret == 0)
+ enable_irq(client->irq);
+
+ mutex_unlock(&data->sysfs_mutex);
+
+ return ret;
+}
+
+static int elan_open(struct input_dev *input_dev)
+{
+ if ((input_dev->users) && (input_dev->inhibited))
+ return elan_uninhibit(input_dev);
+
+ return 0;
+}
+
static int elan_query_device_info(struct elan_tp_data *data)
{
int error;
@@ -1175,6 +1258,9 @@ static int elan_setup_input_device(struct elan_tp_data *data)
0, ETP_FINGER_WIDTH * min_width, 0, 0);
}
+ input->open = elan_open;
+ input->close = elan_close;
+
data->input = input;
return 0;
base-commit: 38e04b3e4240a6d8fb43129ebad41608db64bc6f
--
2.34.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 3/9] HID: intel-ish-hid: ipc: Fix potential use-after-free in work function
From: Sasha Levin @ 2023-03-20 0:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Reka Norman, Srinivas Pandruvada, Jiri Kosina, Sasha Levin, jikos,
benjamin.tissoires, liqiong, linux-input
In-Reply-To: <20230320005732.1429533-1-sashal@kernel.org>
From: Reka Norman <rekanorman@chromium.org>
[ Upstream commit 8ae2f2b0a28416ed2f6d8478ac8b9f7862f36785 ]
When a reset notify IPC message is received, the ISR schedules a work
function and passes the ISHTP device to it via a global pointer
ishtp_dev. If ish_probe() fails, the devm-managed device resources
including ishtp_dev are freed, but the work is not cancelled, causing a
use-after-free when the work function tries to access ishtp_dev. Use
devm_work_autocancel() instead, so that the work is automatically
cancelled if probe fails.
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/intel-ish-hid/ipc/ipc.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c
index a3106fcc22539..1d8aae83f50c1 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -13,6 +13,7 @@
* more details.
*/
+#include <linux/devm-helpers.h>
#include <linux/sched.h>
#include <linux/spinlock.h>
#include <linux/delay.h>
@@ -618,7 +619,6 @@ static void recv_ipc(struct ishtp_device *dev, uint32_t doorbell_val)
case MNG_RESET_NOTIFY:
if (!ishtp_dev) {
ishtp_dev = dev;
- INIT_WORK(&fw_reset_work, fw_reset_work_fn);
}
schedule_work(&fw_reset_work);
break;
@@ -909,6 +909,7 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev)
{
struct ishtp_device *dev;
int i;
+ int ret;
dev = kzalloc(sizeof(struct ishtp_device) + sizeof(struct ish_hw),
GFP_KERNEL);
@@ -942,6 +943,12 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev)
list_add_tail(&tx_buf->link, &dev->wr_free_list_head.link);
}
+ ret = devm_work_autocancel(&pdev->dev, &fw_reset_work, fw_reset_work_fn);
+ if (ret) {
+ dev_err(dev->devc, "Failed to initialise FW reset work\n");
+ return NULL;
+ }
+
dev->ops = &ish_hw_ops;
dev->devc = &pdev->dev;
dev->mtu = IPC_PAYLOAD_SIZE - sizeof(struct ishtp_msg_hdr);
--
2.39.2
^ permalink raw reply related
* Re: [PATCH] Input: iforce - Fix exception handling in iforce_usb_probe()
From: Dmitry Torokhov @ 2023-03-20 4:21 UTC (permalink / raw)
To: Markus Elfring
Cc: kernel-janitors, linux-input, Hillf Danton, Tetsuo Handa, cocci,
LKML
In-Reply-To: <521b63e1-9470-58ef-599e-50a1846e5380@web.de>
On Sun, Mar 19, 2023 at 07:03:00PM +0100, Markus Elfring wrote:
> Date: Sun, 19 Mar 2023 18:50:51 +0100
>
> The label “fail” was used to jump to another pointer check despite of
> the detail in the implementation of the function “iforce_usb_probe”
> that it was determined already that a corresponding variable contained
> still a null pointer.
>
> 1. Use more appropriate labels instead.
>
> 2. Reorder jump targets at the end.
>
> 3. Delete a redundant check.
>
>
> This issue was detected by using the Coccinelle software.
I am sorry, but I do not understand what the actual issue is. The fact
that come Coccinelle script complains is not enough to change the code.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: iqs62x-keys - Suppress duplicated error message in .remove()
From: Dmitry Torokhov @ 2023-03-20 4:28 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mattijs Korpershoek, Jeff LaBundy, linux-input, kernel
In-Reply-To: <20230318225110.261439-1-u.kleine-koenig@pengutronix.de>
On Sat, Mar 18, 2023 at 11:51:10PM +0100, Uwe Kleine-König wrote:
> If a platform driver's remove callback returns non-zero the driver core
> emits an error message. In such a case however iqs62x_keys_remove()
> already issued a (better) message. So return zero to suppress the
> generic message.
>
> This patch has no other side effects as platform_remove() ignores the
> return value of .remove() after the warning.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] Fix incorrectly applied patch for MAP_PROFILE_BUTTON
From: Dmitry Torokhov @ 2023-03-20 4:33 UTC (permalink / raw)
To: Andi Shyti
Cc: Matthias Benkmann, linux-input, Nate Yocom, hadess,
benjamin.tissoires, linux-kernel, Pavel Rojtberg
In-Reply-To: <20230318180047.3pzcep5roaon3nph@intel.intel>
On Sat, Mar 18, 2023 at 07:00:47PM +0100, Andi Shyti wrote:
> On Sat, Mar 18, 2023 at 04:21:06PM +0100, Matthias Benkmann wrote:
> > When the linked patch was applied,
>
> Please refer to the patch as "commit fff1011a26d6 ("Input: xpad -
> add X-Box Adaptive Profile button")" and not as "linked patch".
>
> > one hunk ended up in the wrong function. This patch moves it to where
> > it probably belongs.
>
> probably? We need to be sure here :)
>
> Besides, please, use the imperative form, not "this patch moves"
> but "move what where", please be more specific.
Reworded and applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: iforce - Fix exception handling in iforce_usb_probe()
From: Tetsuo Handa @ 2023-03-20 4:34 UTC (permalink / raw)
To: Dmitry Torokhov, Markus Elfring
Cc: kernel-janitors, linux-input, Hillf Danton, cocci, LKML
In-Reply-To: <ZBffPEIWcmYcaXR3@google.com>
On 2023/03/20 13:21, Dmitry Torokhov wrote:
> On Sun, Mar 19, 2023 at 07:03:00PM +0100, Markus Elfring wrote:
>> Date: Sun, 19 Mar 2023 18:50:51 +0100
>>
>> The label “fail” was used to jump to another pointer check despite of
>> the detail in the implementation of the function “iforce_usb_probe”
>> that it was determined already that a corresponding variable contained
>> still a null pointer.
>>
>> 1. Use more appropriate labels instead.
>>
>> 2. Reorder jump targets at the end.
>>
>> 3. Delete a redundant check.
>>
>>
>> This issue was detected by using the Coccinelle software.
>
> I am sorry, but I do not understand what the actual issue is. The fact
> that come Coccinelle script complains is not enough to change the code.
>
Right. There is no issue with the code, for usb_free_urb(NULL) is a no-op.
Proposing as a cleanup, without Fixes: tags, could be possible though.
^ permalink raw reply
* Re: [PATCH v2] input: alps: fix compatibility with -funsigned-char
From: Dmitry Torokhov @ 2023-03-20 4:43 UTC (permalink / raw)
To: msizanoen; +Cc: hdegoede, linux-input, linux-kernel, pali, stable
In-Reply-To: <20230320001731.175969-1-msizanoen@qtmlabs.xyz>
Hi,
On Mon, Mar 20, 2023 at 01:17:31AM +0100, msizanoen wrote:
> The AlpsPS/2 code previously relied on the assumption that `char` is a
> signed type, which was true on x86 platforms (the only place where this
> driver is used) before kernel 6.2. However, on 6.2 and later, this
> assumption is broken due to the introduction of -funsigned-char as a new
> global compiler flag.
>
> Fix this by explicitly specifying the signedness of `char` when sign
> extending the values received from the device.
>
> v2:
> Add explicit signedness to more places
>
> Fixes: f3f33c677699 ("Input: alps - Rushmore and v7 resolution support")
> Cc: stable@vger.kernel.org
> Signed-off-by: msizanoen <msizanoen@qtmlabs.xyz>
Please use s8 instead of signed char. Also, could you please tell me if
"msizanoen" is your real name? It is required in the DCO. Apologies if
it really is.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v3] input: alps: fix compatibility with -funsigned-char
From: msizanoen1 @ 2023-03-20 4:52 UTC (permalink / raw)
To: msizanoen
Cc: dmitry.torokhov, hdegoede, linux-input, linux-kernel, pali,
stable
In-Reply-To: <20230318144206.14309-1-msizanoen@qtmlabs.xyz>
From: msizanoen <msizanoen@qtmlabs.xyz>
The AlpsPS/2 code previously relied on the assumption that `char` is a
signed type, which was true on x86 platforms (the only place where this
driver is used) before kernel 6.2. However, on 6.2 and later, this
assumption is broken due to the introduction of -funsigned-char as a new
global compiler flag.
Fix this by explicitly specifying the signedness of `char` when sign
extending the values received from the device.
v2:
Add explicit signedness to more places
v3:
Use `s8` instead of `signed char`
Fixes: f3f33c677699 ("Input: alps - Rushmore and v7 resolution support")
Cc: stable@vger.kernel.org
Signed-off-by: msizanoen <msizanoen@qtmlabs.xyz>
---
drivers/input/mouse/alps.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 989228b5a0a4..e2c11d9f3868 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -852,8 +852,8 @@ static void alps_process_packet_v6(struct psmouse *psmouse)
x = y = z = 0;
/* Divide 4 since trackpoint's speed is too fast */
- input_report_rel(dev2, REL_X, (char)x / 4);
- input_report_rel(dev2, REL_Y, -((char)y / 4));
+ input_report_rel(dev2, REL_X, (s8)x / 4);
+ input_report_rel(dev2, REL_Y, -((s8)y / 4));
psmouse_report_standard_buttons(dev2, packet[3]);
@@ -1104,8 +1104,8 @@ static void alps_process_trackstick_packet_v7(struct psmouse *psmouse)
((packet[3] & 0x20) << 1);
z = (packet[5] & 0x3f) | ((packet[3] & 0x80) >> 1);
- input_report_rel(dev2, REL_X, (char)x);
- input_report_rel(dev2, REL_Y, -((char)y));
+ input_report_rel(dev2, REL_X, (s8)x);
+ input_report_rel(dev2, REL_Y, -((s8)y));
input_report_abs(dev2, ABS_PRESSURE, z);
psmouse_report_standard_buttons(dev2, packet[1]);
@@ -2294,20 +2294,20 @@ static int alps_get_v3_v7_resolution(struct psmouse *psmouse, int reg_pitch)
if (reg < 0)
return reg;
- x_pitch = (char)(reg << 4) >> 4; /* sign extend lower 4 bits */
+ x_pitch = (s8)(reg << 4) >> 4; /* sign extend lower 4 bits */
x_pitch = 50 + 2 * x_pitch; /* In 0.1 mm units */
- y_pitch = (char)reg >> 4; /* sign extend upper 4 bits */
+ y_pitch = (s8)reg >> 4; /* sign extend upper 4 bits */
y_pitch = 36 + 2 * y_pitch; /* In 0.1 mm units */
reg = alps_command_mode_read_reg(psmouse, reg_pitch + 1);
if (reg < 0)
return reg;
- x_electrode = (char)(reg << 4) >> 4; /* sign extend lower 4 bits */
+ x_electrode = (s8)(reg << 4) >> 4; /* sign extend lower 4 bits */
x_electrode = 17 + x_electrode;
- y_electrode = (char)reg >> 4; /* sign extend upper 4 bits */
+ y_electrode = (s8)reg >> 4; /* sign extend upper 4 bits */
y_electrode = 13 + y_electrode;
x_phys = x_pitch * (x_electrode - 1); /* In 0.1 mm units */
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v3] input: alps: fix compatibility with -funsigned-char
From: Dmitry Torokhov @ 2023-03-20 6:03 UTC (permalink / raw)
To: msizanoen1; +Cc: hdegoede, linux-input, linux-kernel, pali, stable
In-Reply-To: <20230320045228.182259-1-msizanoen@qtmlabs.xyz>
On Mon, Mar 20, 2023 at 05:52:29AM +0100, msizanoen1 wrote:
> From: msizanoen <msizanoen@qtmlabs.xyz>
>
> The AlpsPS/2 code previously relied on the assumption that `char` is a
> signed type, which was true on x86 platforms (the only place where this
> driver is used) before kernel 6.2. However, on 6.2 and later, this
> assumption is broken due to the introduction of -funsigned-char as a new
> global compiler flag.
>
> Fix this by explicitly specifying the signedness of `char` when sign
> extending the values received from the device.
>
> v2:
> Add explicit signedness to more places
>
> v3:
> Use `s8` instead of `signed char`
>
> Fixes: f3f33c677699 ("Input: alps - Rushmore and v7 resolution support")
> Cc: stable@vger.kernel.org
> Signed-off-by: msizanoen <msizanoen@qtmlabs.xyz>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: iforce - Fix exception handling in iforce_usb_probe()
From: Dmitry Torokhov @ 2023-03-20 6:05 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Markus Elfring, kernel-janitors, linux-input, Hillf Danton, cocci,
LKML
In-Reply-To: <6b5de584-b31f-9045-a438-b42da350326b@I-love.SAKURA.ne.jp>
On Mon, Mar 20, 2023 at 01:34:52PM +0900, Tetsuo Handa wrote:
> On 2023/03/20 13:21, Dmitry Torokhov wrote:
> > On Sun, Mar 19, 2023 at 07:03:00PM +0100, Markus Elfring wrote:
> >> Date: Sun, 19 Mar 2023 18:50:51 +0100
> >>
> >> The label “fail” was used to jump to another pointer check despite of
> >> the detail in the implementation of the function “iforce_usb_probe”
> >> that it was determined already that a corresponding variable contained
> >> still a null pointer.
> >>
> >> 1. Use more appropriate labels instead.
> >>
> >> 2. Reorder jump targets at the end.
> >>
> >> 3. Delete a redundant check.
> >>
> >>
> >> This issue was detected by using the Coccinelle software.
> >
> > I am sorry, but I do not understand what the actual issue is. The fact
> > that come Coccinelle script complains is not enough to change the code.
> >
>
> Right. There is no issue with the code, for usb_free_urb(NULL) is a no-op.
> Proposing as a cleanup, without Fixes: tags, could be possible though.
Yes, that would be acceptable.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v9 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Krzysztof Kozlowski @ 2023-03-20 6:44 UTC (permalink / raw)
To: Danny Kaehn, robh+dt, krzysztof.kozlowski+dt, jikos,
benjamin.tissoires
Cc: bartosz.golaszewski, andriy.shevchenko, dmitry.torokhov,
devicetree, linux-input, ethan.twardy, Rob Herring
In-Reply-To: <20230319204802.1364-2-kaehndan@gmail.com>
On 19/03/2023 21:48, Danny Kaehn wrote:
> This is a USB HID device which includes an I2C controller and 8 GPIO pins.
>
> The binding allows describing the chip's gpio and i2c controller in DT
> using the subnodes named "gpio" and "i2c", respectively. This is
> intended to be used in configurations where the CP2112 is permanently
> connected in hardware.
>
> Signed-off-by: Danny Kaehn <kaehndan@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
From where did you get it? There was no such tag at v7:
https://lore.kernel.org/all/20230223213147.268-2-kaehndan@gmail.com/
nor at v6:
https://lore.kernel.org/all/20230217184904.1290-2-kaehndan@gmail.com/
???
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Daniel Kaehn @ 2023-03-20 12:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh+dt, krzysztof.kozlowski+dt, jikos, Benjamin Tissoires,
bartosz.golaszewski, Andy Shevchenko, Dmitry Torokhov, devicetree,
linux-input, ethan.twardy, Rob Herring
In-Reply-To: <a7a20a06-5a06-e196-07a5-c5f62fc7c065@linaro.org>
On Mon, Mar 20, 2023, 1:44 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 19/03/2023 21:48, Danny Kaehn wrote:
> > This is a USB HID device which includes an I2C controller and 8 GPIO pins.
> >
> > The binding allows describing the chip's gpio and i2c controller in DT
> > using the subnodes named "gpio" and "i2c", respectively. This is
> > intended to be used in configurations where the CP2112 is permanently
> > connected in hardware.
> >
> > Signed-off-by: Danny Kaehn <kaehndan@gmail.com>
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> From where did you get it? There was no such tag at v7:
> https://lore.kernel.org/all/20230223213147.268-2-kaehndan@gmail.com/
> nor at v6:
> https://lore.kernel.org/all/20230217184904.1290-2-kaehndan@gmail.com/
>
> ???
Hi Krzysztof,
My apologies. It looks like you reviewed this in v4 [1].
I had received feedback on v7 that I should be carrying tags from
previous reviews
forward if minimal / no changes have been made to the patch reviewed,
out of respect
for reviewers who look at lots of patches (like yourself) [2], and
hadn't retroactively applied
your tag until v8.
Since v4, I'd only made a few changes suggested by Rob, plus added an example of
specifying bus recovery GPIOs in the binding, and thought those would
fall within the
scope of minor changes -- but my apologies if this was a bad
assumption! I can remove
and re-submit if desired.
Thanks,
Danny Kaehn
[1]: https://lore.kernel.org/all/c999c387-401a-e3a1-f431-2770930c5ecc@linaro.org/
[2]: https://lore.kernel.org/all/Y%2FjpME2mb5CqPooj@smile.fi.intel.com/
^ permalink raw reply
* Re: [PATCH v9 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-20 12:58 UTC (permalink / raw)
To: Danny Kaehn
Cc: robh+dt, krzysztof.kozlowski+dt, jikos, benjamin.tissoires,
bartosz.golaszewski, dmitry.torokhov, devicetree, linux-input,
ethan.twardy
In-Reply-To: <20230319204802.1364-4-kaehndan@gmail.com>
On Sun, Mar 19, 2023 at 03:48:02PM -0500, Danny Kaehn wrote:
> Support describing the CP2112's I2C and GPIO interfaces in firmware.
>
> I2C and GPIO child nodes can either be children with names "i2c" and
> "gpio", or, for ACPI, device nodes with _ADR Zero and One,
> respectively.
>
> Additionally, support configuring the I2C bus speed from the
> clock-frequency device property.
Thank you for the update, my comments below.
...
> + struct i2c_timings timings;
> + struct fwnode_handle *child;
Longer line first easier to read.
> + u32 addr;
> + const char *name;
Ditto.
...
> + device_for_each_child_node(&hdev->dev, child) {
> + name = fwnode_get_name(child);
> + ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> +
> + if ((name && strcmp("i2c", name) == 0) || (!ret && addr == 0))
> + device_set_node(&dev->adap.dev, child);
> + else if ((name && strcmp("gpio", name)) == 0 ||
> + (!ret && addr == 1))
> + dev->gc.fwnode = child;
> + }
Please, make addresses defined explicitly. You may also do it with node naming
schema:
#define CP2112_I2C_ADR 0
#define CP2112_GPIO_ADR 1
static const char * const cp2112_cell_names[] = {
[CP2112_I2C_ADR] = "i2c",
[CP2112_GPIO_ADR] = "gpio",
};
device_for_each_child_node(&hdev->dev, child) {
name = fwnode_get_name(child);
if (name) {
ret = match_string(cp2112_cell_names, ARRAY_SIZE(cp2112_cell_names), name);
if (ret >= 0)
addr = ret;
} else
ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
if (ret < 0)
...error handling if needed...
switch (addr) {
case CP2112_I2C_ADR:
device_set_node(&dev->adap.dev, child);
break;
case CP2112_GPIO_ADR:
dev->gc.fwnode = child;
break;
default:
...error handling...
}
}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v9 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-20 13:00 UTC (permalink / raw)
To: Danny Kaehn
Cc: robh+dt, krzysztof.kozlowski+dt, jikos, benjamin.tissoires,
bartosz.golaszewski, dmitry.torokhov, devicetree, linux-input,
ethan.twardy
In-Reply-To: <ZBhYXwjPeRiZwxMT@smile.fi.intel.com>
On Mon, Mar 20, 2023 at 02:58:07PM +0200, Andy Shevchenko wrote:
> On Sun, Mar 19, 2023 at 03:48:02PM -0500, Danny Kaehn wrote:
...
> > + device_for_each_child_node(&hdev->dev, child) {
> > + name = fwnode_get_name(child);
> > + ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> > +
> > + if ((name && strcmp("i2c", name) == 0) || (!ret && addr == 0))
> > + device_set_node(&dev->adap.dev, child);
> > + else if ((name && strcmp("gpio", name)) == 0 ||
> > + (!ret && addr == 1))
> > + dev->gc.fwnode = child;
> > + }
>
> Please, make addresses defined explicitly. You may also do it with node naming
> schema:
>
> #define CP2112_I2C_ADR 0
> #define CP2112_GPIO_ADR 1
>
> static const char * const cp2112_cell_names[] = {
> [CP2112_I2C_ADR] = "i2c",
> [CP2112_GPIO_ADR] = "gpio",
> };
>
> device_for_each_child_node(&hdev->dev, child) {
> name = fwnode_get_name(child);
> if (name) {
> ret = match_string(cp2112_cell_names, ARRAY_SIZE(cp2112_cell_names), name);
> if (ret >= 0)
> addr = ret;
> } else
> ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> if (ret < 0)
> ...error handling if needed...
>
> switch (addr) {
> case CP2112_I2C_ADR:
> device_set_node(&dev->adap.dev, child);
> break;
> case CP2112_GPIO_ADR:
> dev->gc.fwnode = child;
> break;
> default:
> ...error handling...
> }
> }
Btw, don't you use "reg" property for the child nodes? It would be better from
de facto used patterns (we have a couple of mode drivers that have a common
code to read "reg" or _ADR() and that code can be split into a helper and used
here).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v9 3/3] HID: cp2112: Fwnode Support
From: Daniel Kaehn @ 2023-03-20 13:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: robh+dt, krzysztof.kozlowski+dt, jikos, benjamin.tissoires,
bartosz.golaszewski, dmitry.torokhov, devicetree, linux-input,
ethan.twardy
In-Reply-To: <ZBhY5Gp88gVK7q/g@smile.fi.intel.com>
On Mon, Mar 20, 2023 at 8:00 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 20, 2023 at 02:58:07PM +0200, Andy Shevchenko wrote:
> > On Sun, Mar 19, 2023 at 03:48:02PM -0500, Danny Kaehn wrote:
>
> ...
>
> > > + device_for_each_child_node(&hdev->dev, child) {
> > > + name = fwnode_get_name(child);
> > > + ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> > > +
> > > + if ((name && strcmp("i2c", name) == 0) || (!ret && addr == 0))
> > > + device_set_node(&dev->adap.dev, child);
> > > + else if ((name && strcmp("gpio", name)) == 0 ||
> > > + (!ret && addr == 1))
> > > + dev->gc.fwnode = child;
> > > + }
> >
> > Please, make addresses defined explicitly. You may also do it with node naming
> > schema:
> >
> > #define CP2112_I2C_ADR 0
> > #define CP2112_GPIO_ADR 1
> >
> > static const char * const cp2112_cell_names[] = {
> > [CP2112_I2C_ADR] = "i2c",
> > [CP2112_GPIO_ADR] = "gpio",
> > };
> >
> > device_for_each_child_node(&hdev->dev, child) {
> > name = fwnode_get_name(child);
> > if (name) {
> > ret = match_string(cp2112_cell_names, ARRAY_SIZE(cp2112_cell_names), name);
> > if (ret >= 0)
> > addr = ret;
> > } else
> > ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> > if (ret < 0)
> > ...error handling if needed...
> >
> > switch (addr) {
> > case CP2112_I2C_ADR:
> > device_set_node(&dev->adap.dev, child);
> > break;
> > case CP2112_GPIO_ADR:
> > dev->gc.fwnode = child;
> > break;
> > default:
> > ...error handling...
> > }
> > }
>
> Btw, don't you use "reg" property for the child nodes? It would be better from
> de facto used patterns (we have a couple of mode drivers that have a common
> code to read "reg" or _ADR() and that code can be split into a helper and used
> here).
>
Named nodes _seem_ to be preferred in DT for when there isn't a
logical / natural
numbering to the child nodes. A.e. for USB, reg is used to specify
which port, for I2C,
which address on the bus, but for two parallel and independent
functions on the same
device, it seems named nodes would make more sense in DT. Many examples exist
in mainline where named nodes are used in DT in this way. One example
is network cards
which provide an mdio bus bind through the child "mdio". One example
of a specifically a
child i2c controller being bound to "i2c" can be found in
pine64,pinephone-keyboard.yaml.
But it's certainly possible this isn't the desired direction moving
forward in DT -- my opinion
should definitely be taken with a grain of salt. Maybe this is
something I should follow up on
with DT folks on that DT vs. ACPI thread made earlier.
One thing I did notice when looking at the mfd subsystem is that most
DT drivers actually
match on the compatible string of the child nodes, a.e.
"silabs,cp2112", "silabs,cp2112-gpio".
"silabs,cp2112-i2c". We could implement that here, but I think that
would make more sense if
we were to actually split the cp2112 into mfd & platform drivers, and
additionally split the DT
binding by function.
Thanks,
Danny Kaehn
^ permalink raw reply
* Re: [PATCH v9 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-20 14:05 UTC (permalink / raw)
To: Daniel Kaehn
Cc: robh+dt, krzysztof.kozlowski+dt, jikos, benjamin.tissoires,
bartosz.golaszewski, dmitry.torokhov, devicetree, linux-input,
ethan.twardy
In-Reply-To: <CAP+ZCCc=q_=d18UHEZ9N8HVQ6AYQsTfNgS1r93UCJOB-OEodSw@mail.gmail.com>
On Mon, Mar 20, 2023 at 08:40:07AM -0500, Daniel Kaehn wrote:
> On Mon, Mar 20, 2023 at 8:00 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Mar 20, 2023 at 02:58:07PM +0200, Andy Shevchenko wrote:
> > > On Sun, Mar 19, 2023 at 03:48:02PM -0500, Danny Kaehn wrote:
...
> > > > + device_for_each_child_node(&hdev->dev, child) {
> > > > + name = fwnode_get_name(child);
> > > > + ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> > > > +
> > > > + if ((name && strcmp("i2c", name) == 0) || (!ret && addr == 0))
> > > > + device_set_node(&dev->adap.dev, child);
> > > > + else if ((name && strcmp("gpio", name)) == 0 ||
> > > > + (!ret && addr == 1))
> > > > + dev->gc.fwnode = child;
> > > > + }
> > >
> > > Please, make addresses defined explicitly. You may also do it with node naming
> > > schema:
> > >
> > > #define CP2112_I2C_ADR 0
> > > #define CP2112_GPIO_ADR 1
> > >
> > > static const char * const cp2112_cell_names[] = {
> > > [CP2112_I2C_ADR] = "i2c",
> > > [CP2112_GPIO_ADR] = "gpio",
> > > };
> > >
> > > device_for_each_child_node(&hdev->dev, child) {
> > > name = fwnode_get_name(child);
> > > if (name) {
> > > ret = match_string(cp2112_cell_names, ARRAY_SIZE(cp2112_cell_names), name);
> > > if (ret >= 0)
> > > addr = ret;
> > > } else
> > > ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> > > if (ret < 0)
> > > ...error handling if needed...
> > >
> > > switch (addr) {
> > > case CP2112_I2C_ADR:
> > > device_set_node(&dev->adap.dev, child);
> > > break;
> > > case CP2112_GPIO_ADR:
> > > dev->gc.fwnode = child;
> > > break;
> > > default:
> > > ...error handling...
> > > }
> > > }
> >
> > Btw, don't you use "reg" property for the child nodes? It would be better from
> > de facto used patterns (we have a couple of mode drivers that have a common
> > code to read "reg" or _ADR() and that code can be split into a helper and used
> > here).
> >
>
> Named nodes _seem_ to be preferred in DT for when there isn't a logical /
> natural numbering to the child nodes. A.e. for USB, reg is used to specify
> which port, for I2C, which address on the bus, but for two parallel and
> independent functions on the same device, it seems named nodes would make
> more sense in DT. Many examples exist in mainline where named nodes are used
> in DT in this way.
Okay, I'm not an expert in the DT preferable schemas, so I believe DT people
should answer on this.
> One example is network cards which provide an mdio bus
> bind through the child "mdio". One example of a specifically a
> child i2c controller being bound to "i2c" can be found in
> pine64,pinephone-keyboard.yaml.
> But it's certainly possible this isn't the desired direction moving forward
> in DT -- my opinion should definitely be taken with a grain of salt. Maybe
> this is something I should follow up on with DT folks on that DT vs. ACPI
> thread made earlier.
>
> One thing I did notice when looking at the mfd subsystem is that most DT
> drivers actually match on the compatible string of the child nodes, a.e.
> "silabs,cp2112", "silabs,cp2112-gpio". "silabs,cp2112-i2c". We could
> implement that here, but I think that would make more sense if we were to
> actually split the cp2112 into mfd & platform drivers, and additionally split
> the DT binding by function.
IIRC (but might be very well mistaken) the compatible strings for children
are discouraged.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [lvc-project] [PATCH] Input: cypress_ps2 - fix cypress_ps2_sendbyte() result check
From: Igor Artemiev @ 2023-03-20 15:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Igor Artemiev, linux-input, linux-kernel, lvc-project
cypress_ps2_sendbyte() returns 0 or an error code greater than 0.
The cypress_ps2_read_cmd_status() function assumes that
cypress_ps2_read_cmd_status() will return a negative value on error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Igor Artemiev <Igor.A.Artemiev@mcst.ru>
---
drivers/input/mouse/cypress_ps2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/mouse/cypress_ps2.c b/drivers/input/mouse/cypress_ps2.c
index d272f1ec27ba..b170959e2ad3 100644
--- a/drivers/input/mouse/cypress_ps2.c
+++ b/drivers/input/mouse/cypress_ps2.c
@@ -114,7 +114,7 @@ static int cypress_ps2_read_cmd_status(struct psmouse *psmouse,
memset(param, 0, pktsize);
rc = cypress_ps2_sendbyte(psmouse, 0xe9);
- if (rc < 0)
+ if (rc > 0)
goto out;
wait_event_timeout(ps2dev->wait,
--
2.30.2
^ permalink raw reply related
* [PATCH] HID: wiimote: check completion in wiimod_battery_get_property
From: Nikita Zhandarovich @ 2023-03-20 15:34 UTC (permalink / raw)
To: David Rheinsberg
Cc: Nikita Zhandarovich, Jiri Kosina, Benjamin Tissoires,
David Herrmann, linux-input, linux-kernel, lvc-project
wiimote_cmd_wait() in wiimod_battery_get_property() may signal that the
task of getting specific battery property was interrupted or timed out.
There is no need to do any further computation in such cases, so just
return the error.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: dcf392313817 ("HID: wiimote: convert BATTERY to module")
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
---
drivers/hid/hid-wiimote-modules.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-wiimote-modules.c b/drivers/hid/hid-wiimote-modules.c
index dbccdfa63916..9755718d9856 100644
--- a/drivers/hid/hid-wiimote-modules.c
+++ b/drivers/hid/hid-wiimote-modules.c
@@ -220,8 +220,10 @@ static int wiimod_battery_get_property(struct power_supply *psy,
wiiproto_req_status(wdata);
spin_unlock_irqrestore(&wdata->state.lock, flags);
- wiimote_cmd_wait(wdata);
+ ret = wiimote_cmd_wait(wdata);
wiimote_cmd_release(wdata);
+ if (ret)
+ return ret;
spin_lock_irqsave(&wdata->state.lock, flags);
state = wdata->state.cmd_battery;
--
2.25.1
^ permalink raw reply related
* [dtor-input:next] BUILD SUCCESS 6906f5060d39f95aa0be30e998e0cc1179ba3d04
From: kernel test robot @ 2023-03-20 16:53 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: 6906f5060d39f95aa0be30e998e0cc1179ba3d04 Input: iqs62x-keys - suppress duplicated error message in .remove()
elapsed time: 727m
configs tested: 303
configs skipped: 20
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha buildonly-randconfig-r001-20230320 gcc
alpha buildonly-randconfig-r005-20230319 gcc
alpha defconfig gcc
alpha randconfig-r005-20230319 gcc
alpha randconfig-r011-20230319 gcc
alpha randconfig-r014-20230319 gcc
alpha randconfig-r023-20230319 gcc
alpha randconfig-r033-20230319 gcc
alpha randconfig-r035-20230319 gcc
alpha randconfig-r036-20230319 gcc
arc allyesconfig gcc
arc buildonly-randconfig-r001-20230319 gcc
arc buildonly-randconfig-r003-20230319 gcc
arc buildonly-randconfig-r005-20230320 gcc
arc defconfig gcc
arc nsimosci_defconfig gcc
arc randconfig-r006-20230319 gcc
arc randconfig-r024-20230319 gcc
arc randconfig-r043-20230319 gcc
arc randconfig-r043-20230320 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm assabet_defconfig gcc
arm buildonly-randconfig-r005-20230319 gcc
arm defconfig gcc
arm nhk8815_defconfig gcc
arm randconfig-r003-20230319 clang
arm randconfig-r012-20230319 gcc
arm randconfig-r013-20230319 gcc
arm randconfig-r025-20230319 gcc
arm randconfig-r032-20230319 clang
arm randconfig-r046-20230319 gcc
arm randconfig-r046-20230320 clang
arm stm32_defconfig gcc
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r003-20230320 clang
csky alldefconfig gcc
csky defconfig gcc
csky randconfig-r001-20230319 gcc
csky randconfig-r003-20230319 gcc
csky randconfig-r006-20230319 gcc
csky randconfig-r014-20230319 gcc
csky randconfig-r022-20230319 gcc
csky randconfig-r031-20230319 gcc
csky randconfig-r033-20230319 gcc
csky randconfig-r035-20230320 gcc
hexagon buildonly-randconfig-r001-20230319 clang
hexagon buildonly-randconfig-r003-20230319 clang
hexagon buildonly-randconfig-r004-20230319 clang
hexagon randconfig-r001-20230319 clang
hexagon randconfig-r004-20230320 clang
hexagon randconfig-r021-20230319 clang
hexagon randconfig-r022-20230319 clang
hexagon randconfig-r032-20230319 clang
hexagon randconfig-r041-20230319 clang
hexagon randconfig-r041-20230320 clang
hexagon randconfig-r045-20230319 clang
hexagon randconfig-r045-20230320 clang
i386 allyesconfig gcc
i386 buildonly-randconfig-r006-20230320 clang
i386 debian-10.3-func gcc
i386 debian-10.3-kselftests gcc
i386 debian-10.3-kunit gcc
i386 debian-10.3-kvm gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230320 clang
i386 randconfig-a001 gcc
i386 randconfig-a002-20230320 clang
i386 randconfig-a002 clang
i386 randconfig-a003-20230320 clang
i386 randconfig-a003 gcc
i386 randconfig-a004-20230320 clang
i386 randconfig-a004 clang
i386 randconfig-a005-20230320 clang
i386 randconfig-a005 gcc
i386 randconfig-a006-20230320 clang
i386 randconfig-a006 clang
i386 randconfig-a011-20230320 gcc
i386 randconfig-a011 clang
i386 randconfig-a012-20230320 gcc
i386 randconfig-a012 gcc
i386 randconfig-a013-20230320 gcc
i386 randconfig-a013 clang
i386 randconfig-a014-20230320 gcc
i386 randconfig-a014 gcc
i386 randconfig-a015-20230320 gcc
i386 randconfig-a015 clang
i386 randconfig-a016-20230320 gcc
i386 randconfig-a016 gcc
i386 randconfig-c001 gcc
ia64 allmodconfig gcc
ia64 buildonly-randconfig-r003-20230319 gcc
ia64 defconfig gcc
ia64 randconfig-r004-20230319 gcc
ia64 randconfig-r021-20230319 gcc
ia64 randconfig-r033-20230319 gcc
ia64 randconfig-r036-20230319 gcc
ia64 randconfig-r036-20230320 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch buildonly-randconfig-r003-20230320 gcc
loongarch buildonly-randconfig-r006-20230319 gcc
loongarch defconfig gcc
loongarch randconfig-r005-20230319 gcc
loongarch randconfig-r011-20230319 gcc
loongarch randconfig-r013-20230319 gcc
loongarch randconfig-r014-20230319 gcc
loongarch randconfig-r015-20230319 gcc
loongarch randconfig-r022-20230319 gcc
loongarch randconfig-r025-20230320 gcc
loongarch randconfig-r026-20230320 gcc
loongarch randconfig-r031-20230319 gcc
loongarch randconfig-r032-20230319 gcc
loongarch randconfig-r034-20230319 gcc
m68k allmodconfig gcc
m68k amiga_defconfig gcc
m68k defconfig gcc
m68k randconfig-r005-20230319 gcc
m68k randconfig-r014-20230319 gcc
m68k randconfig-r015-20230319 gcc
m68k randconfig-r026-20230319 gcc
m68k randconfig-r031-20230319 gcc
m68k virt_defconfig gcc
microblaze buildonly-randconfig-r001-20230319 gcc
microblaze randconfig-r005-20230319 gcc
microblaze randconfig-r014-20230319 gcc
microblaze randconfig-r026-20230319 gcc
microblaze randconfig-r034-20230319 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips gpr_defconfig gcc
mips malta_defconfig clang
mips maltasmvp_defconfig gcc
mips randconfig-r004-20230319 clang
mips randconfig-r005-20230319 clang
mips randconfig-r026-20230319 gcc
mips randconfig-r034-20230320 gcc
mips rs90_defconfig clang
nios2 3c120_defconfig gcc
nios2 buildonly-randconfig-r005-20230320 gcc
nios2 buildonly-randconfig-r006-20230319 gcc
nios2 buildonly-randconfig-r006-20230320 gcc
nios2 defconfig gcc
nios2 randconfig-r002-20230319 gcc
nios2 randconfig-r003-20230319 gcc
nios2 randconfig-r004-20230320 gcc
nios2 randconfig-r005-20230320 gcc
nios2 randconfig-r006-20230319 gcc
nios2 randconfig-r015-20230319 gcc
nios2 randconfig-r023-20230320 gcc
nios2 randconfig-r026-20230319 gcc
nios2 randconfig-r035-20230319 gcc
nios2 randconfig-r036-20230319 gcc
openrisc buildonly-randconfig-r004-20230319 gcc
openrisc randconfig-r001-20230319 gcc
openrisc randconfig-r006-20230319 gcc
openrisc randconfig-r021-20230319 gcc
openrisc randconfig-r022-20230319 gcc
openrisc randconfig-r023-20230319 gcc
openrisc randconfig-r024-20230319 gcc
openrisc randconfig-r025-20230319 gcc
openrisc randconfig-r034-20230319 gcc
openrisc randconfig-r035-20230319 gcc
parisc defconfig gcc
parisc randconfig-r002-20230320 gcc
parisc randconfig-r022-20230319 gcc
parisc randconfig-r025-20230319 gcc
parisc randconfig-r031-20230319 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc buildonly-randconfig-r002-20230319 clang
powerpc buildonly-randconfig-r004-20230319 clang
powerpc canyonlands_defconfig gcc
powerpc icon_defconfig clang
powerpc klondike_defconfig gcc
powerpc ksi8560_defconfig clang
powerpc mgcoge_defconfig gcc
powerpc microwatt_defconfig clang
powerpc mpc834x_mds_defconfig gcc
powerpc mpc85xx_cds_defconfig gcc
powerpc pq2fads_defconfig gcc
powerpc randconfig-r002-20230319 gcc
powerpc randconfig-r021-20230319 clang
powerpc randconfig-r021-20230320 gcc
powerpc randconfig-r024-20230319 clang
powerpc randconfig-r025-20230319 clang
powerpc randconfig-r033-20230319 gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r002-20230319 clang
riscv defconfig gcc
riscv nommu_k210_defconfig gcc
riscv randconfig-r001-20230320 clang
riscv randconfig-r002-20230319 gcc
riscv randconfig-r004-20230319 gcc
riscv randconfig-r005-20230319 gcc
riscv randconfig-r006-20230319 gcc
riscv randconfig-r012-20230319 clang
riscv randconfig-r016-20230319 clang
riscv randconfig-r032-20230319 gcc
riscv randconfig-r036-20230319 gcc
riscv randconfig-r042-20230319 clang
riscv randconfig-r042-20230320 gcc
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 buildonly-randconfig-r001-20230319 clang
s390 buildonly-randconfig-r002-20230319 clang
s390 defconfig gcc
s390 randconfig-r001-20230320 clang
s390 randconfig-r004-20230320 clang
s390 randconfig-r006-20230320 clang
s390 randconfig-r015-20230319 clang
s390 randconfig-r023-20230319 clang
s390 randconfig-r044-20230319 clang
s390 randconfig-r044-20230320 gcc
sh allmodconfig gcc
sh ap325rxa_defconfig gcc
sh apsh4ad0a_defconfig gcc
sh buildonly-randconfig-r002-20230320 gcc
sh buildonly-randconfig-r004-20230319 gcc
sh r7785rp_defconfig gcc
sh randconfig-r006-20230320 gcc
sh randconfig-r011-20230319 gcc
sh randconfig-r023-20230319 gcc
sh randconfig-r024-20230319 gcc
sh randconfig-r032-20230319 gcc
sh randconfig-r034-20230319 gcc
sh rsk7269_defconfig gcc
sh se7721_defconfig gcc
sh se7722_defconfig gcc
sh sh03_defconfig gcc
sh sh7710voipgw_defconfig gcc
sh sh7785lcr_defconfig gcc
sparc buildonly-randconfig-r004-20230320 gcc
sparc buildonly-randconfig-r006-20230319 gcc
sparc defconfig gcc
sparc randconfig-r001-20230319 gcc
sparc randconfig-r004-20230319 gcc
sparc randconfig-r012-20230319 gcc
sparc randconfig-r015-20230319 gcc
sparc randconfig-r016-20230319 gcc
sparc randconfig-r021-20230319 gcc
sparc randconfig-r022-20230319 gcc
sparc randconfig-r024-20230320 gcc
sparc randconfig-r031-20230319 gcc
sparc randconfig-r035-20230319 gcc
sparc64 defconfig gcc
sparc64 randconfig-r001-20230319 gcc
sparc64 randconfig-r011-20230319 gcc
sparc64 randconfig-r016-20230319 gcc
sparc64 randconfig-r025-20230319 gcc
sparc64 randconfig-r033-20230319 gcc
sparc64 randconfig-r035-20230319 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230320 clang
x86_64 randconfig-a001 clang
x86_64 randconfig-a002-20230320 clang
x86_64 randconfig-a002 gcc
x86_64 randconfig-a003-20230320 clang
x86_64 randconfig-a003 clang
x86_64 randconfig-a004-20230320 clang
x86_64 randconfig-a004 gcc
x86_64 randconfig-a005-20230320 clang
x86_64 randconfig-a005 clang
x86_64 randconfig-a006-20230320 clang
x86_64 randconfig-a006 gcc
x86_64 randconfig-a011 gcc
x86_64 randconfig-a012 clang
x86_64 randconfig-a013 gcc
x86_64 randconfig-a014 clang
x86_64 randconfig-a015 gcc
x86_64 randconfig-a016 clang
x86_64 randconfig-k001 clang
x86_64 randconfig-r006-20230320 clang
x86_64 randconfig-r022-20230320 gcc
x86_64 rhel-8.3-bpf gcc
x86_64 rhel-8.3-kunit gcc
x86_64 rhel-8.3-kvm gcc
x86_64 rhel-8.3-syz gcc
x86_64 rhel-8.3 gcc
xtensa cadence_csp_defconfig gcc
xtensa common_defconfig gcc
xtensa defconfig gcc
xtensa iss_defconfig gcc
xtensa randconfig-r002-20230319 gcc
xtensa randconfig-r003-20230319 gcc
xtensa randconfig-r003-20230320 gcc
xtensa randconfig-r004-20230319 gcc
xtensa randconfig-r013-20230319 gcc
xtensa randconfig-r031-20230319 gcc
xtensa randconfig-r033-20230320 gcc
xtensa randconfig-r034-20230319 gcc
xtensa xip_kc705_defconfig gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ 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