* Re: [hid-logitech-dj] Inaccurate Mouse Wheel Behaviour using G502 with Logitech Lightspeed Receiver (USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1)
From: Sewer56 @ 2023-08-18 22:16 UTC (permalink / raw)
To: linux-input
[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]
When scrolling with a Logitech G502 Lightspeed mouse (046d:c08d) in wireless mode
with the official wireless receiver (046d:c539, i.e. USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1
in `hid-logitech-dj.c`), the REL_WHEEL event is not fired consistently on mouse wheel notch/tick.
[Note: This only affects wireless through receiver; wired works as expected]
Rather than the event being fired when the mouse skips a notch/tick on the scroll
wheel, it feels like the REL_WHEEL event is fired somewhere roughly around the middle
point of the last notch/tick and the next notch/tick.
I recorded a quick video to demonstrate this:
https://youtu.be/IwaQAMDkotg
In this clip I scroll the mouse wheel gently up and down, back and forth. Notice the
appearance of REL_WHEEL_HI_RES with the value changing from 15 to -15 as the direction
is changed; the wheel is being scrolled past the notch, but the REL_WHEEL event is not fired.
When the hid-logitech-dj module is blacklisted, and linux defaults to a more generic
driver (usbhid); this issue is not present; which can be seen here: https://youtu.be/8AkVWHUe88M
To put this into a realistic end user perspective: If you try to play a game on Linux
with the current behaviour; and perform an action that requires the use of a scroll wheel
[for example; changing the current weapon in a shooter], the input is often 'dropped' from
the user perspective, leading to frustration.
I'm not exactly sure what further sort of information I could provide; I've only got back
to using Linux on the desktop after 7 years; and it's my first time raising a kernel issue.
That said, I'm happy to provide any further feedback, or even play with the kernel sources
if someone could give me ideas of what I should experiment with.
[-- Attachment #2: evtest samples.zip --]
[-- Type: application/zip, Size: 2654 bytes --]
^ permalink raw reply
* [PATCH v5] hid-mcp2200: added driver for GPIOs of MCP2200
From: johannes @ 2023-08-18 10:48 UTC (permalink / raw)
To: jikos
Cc: benjamin.tissoires, linux-kernel, linux-input, andi.shyti,
christophe.jaillet, rdunlap, ak, Johannes Roith
From: Johannes Roith <johannes@gnu-linux.rocks>
Added a gpiochip compatible driver to control the 8 GPIOs of
the MCP2200 by using the HID interface.
Using GPIOs with alternative functions (GP0<->SSPND, GP1<->USBCFG,
GP6<->RXLED, GP7<->TXLED) will reset the functions, if set (unset by
default).
The driver was tested while also using the UART of the chip. Setting
and reading the GPIOs has no effect on the UART communication. However,
a reset is triggered after the CONFIGURE command. If the GPIO Direction
is constantly changed, this will affect the communication at low baud
rates. This is a hardware problem of the MCP2200 and is not caused by
the driver.
Feedback from reviewers Christophe JAILLET <christophe.jaillet@wanadoo.fr>
and Andi Shyti <andi.shyti@kernel.org> was added.
Changelog:
- v1: added driver
- v2: added ProductID in hid-ids.h
- v3: added feedback from review and make patch compilable
- v4: added more feedback from second review, tested as module and
builtin on x86 and arm64
- v5: adopted Kconfig to style guidelines, fixed mcp_set_direction
Signed-off-by: Johannes Roith <johannes@gnu-linux.rocks>
---
drivers/hid/Kconfig | 10 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-mcp2200.c | 419 ++++++++++++++++++++++++++++++++++++++
4 files changed, 431 insertions(+)
create mode 100644 drivers/hid/hid-mcp2200.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index e11c1c803676..efe01b473cc2 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1301,6 +1301,16 @@ config HID_MCP2221
To compile this driver as a module, choose M here: the module
will be called hid-mcp2221.ko.
+config HID_MCP2200
+ tristate "Microchip MCP2200 HID USB-to-GPIO bridge"
+ depends on USB_HID
+ imply GPIOLIB
+ help
+ Provides GPIO functionality over USB-HID through MCP2200 device.
+
+ To compile this driver as a module, choose M here: the module
+ will be called hid-mcp2200.ko.
+
config HID_KUNIT_TEST
tristate "KUnit tests for HID" if !KUNIT_ALL_TESTS
depends on KUNIT
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 7a9e160158f7..050f740304c4 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_HID_MACALLY) += hid-macally.o
obj-$(CONFIG_HID_MAGICMOUSE) += hid-magicmouse.o
obj-$(CONFIG_HID_MALTRON) += hid-maltron.o
obj-$(CONFIG_HID_MCP2221) += hid-mcp2221.o
+obj-$(CONFIG_HID_MCP2200) += hid-mcp2200.o
obj-$(CONFIG_HID_MAYFLASH) += hid-mf.o
obj-$(CONFIG_HID_MEGAWORLD_FF) += hid-megaworld.o
obj-$(CONFIG_HID_MICROSOFT) += hid-microsoft.o
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 8a310f8ff20f..4926ca41225b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -914,6 +914,7 @@
#define USB_DEVICE_ID_PICK16F1454_V2 0xf2f7
#define USB_DEVICE_ID_LUXAFOR 0xf372
#define USB_DEVICE_ID_MCP2221 0x00dd
+#define USB_DEVICE_ID_MCP2200 0x00df
#define USB_VENDOR_ID_MICROSOFT 0x045e
#define USB_DEVICE_ID_SIDEWINDER_GV 0x003b
diff --git a/drivers/hid/hid-mcp2200.c b/drivers/hid/hid-mcp2200.c
new file mode 100644
index 000000000000..ed4483fa5bdf
--- /dev/null
+++ b/drivers/hid/hid-mcp2200.c
@@ -0,0 +1,419 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * MCP2200 - Microchip USB to GPIO bridge
+ *
+ * Copyright (c) 2023, Johannes Roith <johannes@gnu-linux.rocks>
+ *
+ * Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/22228A.pdf
+ * App Note for HID: https://ww1.microchip.com/downloads/en/DeviceDoc/93066A.pdf
+ */
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio/driver.h>
+#include <linux/hid.h>
+#include <linux/hidraw.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include "hid-ids.h"
+
+/* Commands codes in a raw output report */
+#define SET_CLEAR_OUTPUTS 0x08
+#define CONFIGURE 0x10
+#define READ_EE 0x20
+#define WRITE_EE 0x40
+#define READ_ALL 0x80
+
+/* MCP GPIO direction encoding */
+enum MCP_IO_DIR {
+ MCP2200_DIR_OUT = 0x00,
+ MCP2200_DIR_IN = 0x01,
+};
+
+/* Altternative pin assignments */
+#define TXLED 2
+#define RXLED 3
+#define USBCFG 6
+#define SSPND 7
+#define MCP_NGPIO 8
+
+/* CMD to set or clear a GPIO output */
+struct mcp_set_clear_outputs {
+ u8 cmd;
+ u8 dummys1[10];
+ u8 set_bmap;
+ u8 clear_bmap;
+ u8 dummys2[3];
+} __packed;
+
+/* CMD to configure the IOs */
+struct mcp_configure {
+ u8 cmd;
+ u8 dummys1[3];
+ u8 io_bmap;
+ u8 config_alt_pins;
+ u8 io_default_val_bmap;
+ u8 config_alt_options;
+ u8 baud_h;
+ u8 baud_l;
+ u8 dummys2[6];
+} __packed;
+
+/* CMD to read all parameters */
+struct mcp_read_all {
+ u8 cmd;
+ u8 dummys[15];
+} __packed;
+
+/* Response to the read all cmd */
+struct mcp_read_all_resp {
+ u8 cmd;
+ u8 eep_addr;
+ u8 dummy;
+ u8 eep_val;
+ u8 io_bmap;
+ u8 config_alt_pins;
+ u8 io_default_val_bmap;
+ u8 config_alt_options;
+ u8 baud_h;
+ u8 baud_l;
+ u8 io_port_val_bmap;
+ u8 dummys[5];
+} __packed;
+
+struct mcp2200 {
+ struct hid_device *hdev;
+ struct mutex lock;
+ struct completion wait_in_report;
+ u8 gpio_dir;
+ u8 gpio_val;
+ u8 gpio_inval;
+ u8 baud_h;
+ u8 baud_l;
+ u8 config_alt_pins;
+ u8 gpio_reset_val;
+ u8 config_alt_options;
+ int status;
+ struct gpio_chip gc;
+};
+
+/* this executes the READ_ALL cmd */
+static int mcp_cmd_read_all(struct mcp2200 *mcp)
+{
+ struct mcp_read_all *read_all;
+ int len, t;
+
+ reinit_completion(&mcp->wait_in_report);
+ read_all = kzalloc(sizeof(struct mcp_read_all), GFP_KERNEL);
+ if (!read_all)
+ return -ENOMEM;
+
+ read_all->cmd = READ_ALL;
+
+ mutex_lock(&mcp->lock);
+ len = hid_hw_output_report(mcp->hdev, (u8 *) read_all,
+ sizeof(struct mcp_read_all));
+
+ mutex_unlock(&mcp->lock);
+ kfree(read_all);
+
+ if (len != sizeof(struct mcp_read_all))
+ return -EINVAL;
+
+ t = wait_for_completion_timeout(&mcp->wait_in_report,
+ msecs_to_jiffies(4000));
+ if (!t)
+ return -ETIMEDOUT;
+
+ /* return status, negative value if wrong response was received */
+ return mcp->status;
+}
+
+static void mcp_set_multiple(struct gpio_chip *gc, unsigned long *mask,
+ unsigned long *bits)
+{
+ struct mcp2200 *mcp = gpiochip_get_data(gc);
+ u8 value;
+ int status;
+ struct mcp_set_clear_outputs *cmd;
+
+ cmd = kzalloc(sizeof(struct mcp_set_clear_outputs), GFP_KERNEL);
+ if (!cmd)
+ return;
+
+ mutex_lock(&mcp->lock);
+
+ value = mcp->gpio_val & ~*mask;
+ value |= (*mask & *bits);
+
+ cmd->cmd = SET_CLEAR_OUTPUTS;
+ cmd->set_bmap = value;
+ cmd->clear_bmap = ~(value);
+
+ status = hid_hw_output_report(mcp->hdev, (u8 *) cmd,
+ sizeof(struct mcp_set_clear_outputs));
+
+ if (status == sizeof(struct mcp_set_clear_outputs))
+ mcp->gpio_val = value;
+
+ mutex_unlock(&mcp->lock);
+ kfree(cmd);
+}
+
+static void mcp_set(struct gpio_chip *gc, unsigned int gpio_nr, int value)
+{
+ unsigned long mask = 1 << gpio_nr;
+ unsigned long bmap_value = value << gpio_nr;
+
+ mcp_set_multiple(gc, &mask, &bmap_value);
+}
+
+static int mcp_get_multiple(struct gpio_chip *gc, unsigned long *mask,
+ unsigned long *bits)
+{
+ u32 val;
+ struct mcp2200 *mcp = gpiochip_get_data(gc);
+ int status;
+
+ status = mcp_cmd_read_all(mcp);
+ if (status != 0)
+ return status;
+
+ val = mcp->gpio_inval;
+ *bits = (val & *mask);
+ return 0;
+}
+
+static int mcp_get(struct gpio_chip *gc, unsigned int gpio_nr)
+{
+ unsigned long mask = 0, bits = 0;
+
+ mask = (1 << gpio_nr);
+ mcp_get_multiple(gc, &mask, &bits);
+ return bits > 0;
+}
+
+static int mcp_get_direction(struct gpio_chip *gc, unsigned int gpio_nr)
+{
+ struct mcp2200 *mcp = gpiochip_get_data(gc);
+
+ return (mcp->gpio_dir & (MCP2200_DIR_IN << gpio_nr))
+ ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT;
+}
+
+static int mcp_set_direction(struct gpio_chip *gc, unsigned int gpio_nr,
+ enum MCP_IO_DIR io_direction)
+{
+ struct mcp2200 *mcp = gpiochip_get_data(gc);
+ struct mcp_configure *conf;
+ int status;
+ /* after the configure cmd we will need to set the outputs again */
+ unsigned long mask = ~(mcp->gpio_dir); /* only set outputs */
+ unsigned long bits = mcp->gpio_val;
+ /* Offsets of alternative pins in config_alt_pins, 0 is not used */
+ u8 alt_pin_conf[8] = {SSPND, USBCFG, 0, 0, 0, 0, RXLED, TXLED};
+ u8 config_alt_pins = mcp->config_alt_pins;
+
+ /* Read in the reset baudrate first, we need it later */
+ status = mcp_cmd_read_all(mcp);
+ if (status != 0)
+ return status;
+
+ conf = kzalloc(sizeof(struct mcp_configure), GFP_KERNEL);
+ if (!conf)
+ return -ENOMEM;
+
+ mutex_lock(&mcp->lock);
+
+ /* configure will reset the chip! */
+ conf->cmd = CONFIGURE;
+ conf->io_bmap = (mcp->gpio_dir & ~(1 << gpio_nr))
+ | (io_direction << gpio_nr);
+ /* Don't overwrite the reset parameters */
+ conf->baud_h = mcp->baud_h;
+ conf->baud_l = mcp->baud_l;
+ conf->config_alt_options = mcp->config_alt_options;
+ conf->io_default_val_bmap = mcp->gpio_reset_val;
+ /* Adjust alt. func if necessary */
+ if (alt_pin_conf[gpio_nr])
+ config_alt_pins &= ~(1 << alt_pin_conf[gpio_nr]);
+ conf->config_alt_pins = config_alt_pins;
+
+ status = hid_hw_output_report(mcp->hdev, (u8 *) conf,
+ sizeof(struct mcp_set_clear_outputs));
+
+ if (status == sizeof(struct mcp_set_clear_outputs)) {
+ mcp->gpio_dir = conf->io_bmap;
+ mcp->config_alt_pins = config_alt_pins;
+ } else {
+ mutex_unlock(&mcp->lock);
+ kfree(conf);
+ return -EIO;
+ }
+
+ mutex_unlock(&mcp->lock);
+ kfree(conf);
+
+ /* Configure CMD will clear all IOs -> rewrite them */
+ mcp_set_multiple(gc, &mask, &bits);
+ return 0;
+}
+
+static int mcp_direction_input(struct gpio_chip *gc, unsigned int gpio_nr)
+{
+ return mcp_set_direction(gc, gpio_nr, MCP2200_DIR_IN);
+}
+
+static int mcp_direction_output(struct gpio_chip *gc, unsigned int gpio_nr,
+ int value)
+{
+ int ret;
+ unsigned long mask, bmap_value;
+
+ mask = 1 << gpio_nr;
+ bmap_value = value << gpio_nr;
+
+ ret = mcp_set_direction(gc, gpio_nr, MCP2200_DIR_OUT);
+ if (ret == 0)
+ mcp_set_multiple(gc, &mask, &bmap_value);
+ return ret;
+}
+
+static const struct gpio_chip template_chip = {
+ .label = "mcp2200",
+ .owner = THIS_MODULE,
+ .get_direction = mcp_get_direction,
+ .direction_input = mcp_direction_input,
+ .direction_output = mcp_direction_output,
+ .set = mcp_set,
+ .set_multiple = mcp_set_multiple,
+ .get = mcp_get,
+ .get_multiple = mcp_get_multiple,
+ .base = -1,
+ .ngpio = MCP_NGPIO,
+ .can_sleep = true,
+};
+
+/*
+ * MCP2200 uses interrupt endpoint for input reports. This function
+ * is called by HID layer when it receives i/p report from mcp2200,
+ * which is actually a response to the previously sent command.
+ */
+static int mcp2200_raw_event(struct hid_device *hdev, struct hid_report *report,
+ u8 *data, int size)
+{
+ struct mcp2200 *mcp = hid_get_drvdata(hdev);
+ struct mcp_read_all_resp *all_resp;
+
+ switch (data[0]) {
+ case READ_ALL:
+ all_resp = (struct mcp_read_all_resp *) data;
+ mcp->status = 0;
+ mcp->gpio_inval = all_resp->io_port_val_bmap;
+ mcp->baud_h = all_resp->baud_h;
+ mcp->baud_l = all_resp->baud_l;
+ mcp->gpio_reset_val = all_resp->io_default_val_bmap;
+ mcp->config_alt_pins = all_resp->config_alt_pins;
+ mcp->config_alt_options = all_resp->config_alt_options;
+ break;
+ default:
+ mcp->status = -EIO;
+ break;
+ }
+
+ complete(&mcp->wait_in_report);
+ return 1;
+}
+
+static void mcp2200_hid_unregister(void *ptr)
+{
+ struct hid_device *hdev = ptr;
+
+ hid_hw_close(hdev);
+ hid_hw_stop(hdev);
+}
+
+static int mcp2200_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+ struct mcp2200 *mcp;
+
+ mcp = devm_kzalloc(&hdev->dev, sizeof(*mcp), GFP_KERNEL);
+ if (!mcp)
+ return -ENOMEM;
+
+ ret = hid_parse(hdev);
+ if (ret) {
+ hid_err(hdev, "can't parse reports\n");
+ return ret;
+ }
+
+ /*
+ * This driver uses the .raw_event callback and therefore does not need any
+ * HID_CONNECT_xxx flags.
+ */
+ ret = hid_hw_start(hdev, 0);
+ if (ret) {
+ hid_err(hdev, "can't start hardware\n");
+ return ret;
+ }
+
+ hid_info(hdev, "USB HID v%x.%02x Device [%s] on %s\n", hdev->version >> 8,
+ hdev->version & 0xff, hdev->name, hdev->phys);
+
+ ret = hid_hw_open(hdev);
+ if (ret) {
+ hid_err(hdev, "can't open device\n");
+ return ret;
+ }
+
+ mutex_init(&mcp->lock);
+ init_completion(&mcp->wait_in_report);
+ hid_set_drvdata(hdev, mcp);
+ mcp->hdev = hdev;
+
+ ret = devm_add_action_or_reset(&hdev->dev, mcp2200_hid_unregister, hdev);
+ if (ret)
+ return ret;
+
+ mcp->gc = template_chip;
+ mcp->gc.parent = &hdev->dev;
+
+ ret = devm_gpiochip_add_data(&hdev->dev, &mcp->gc, mcp);
+ if (ret < 0) {
+ hid_err(hdev, "Unable to register gpiochip\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void mcp2200_remove(struct hid_device *hdev)
+{
+ (void) hdev;
+ /*
+ * With no remove function you sometimes get a segmentation fault when
+ * unloading the module or disconnecting the USB device
+ */
+}
+
+static const struct hid_device_id mcp2200_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_MCP2200) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, mcp2200_devices);
+
+static struct hid_driver mcp2200_driver = {
+ .name = "mcp2200",
+ .id_table = mcp2200_devices,
+ .probe = mcp2200_probe,
+ .remove = mcp2200_remove,
+ .raw_event = mcp2200_raw_event,
+};
+
+/* Register with HID core */
+module_hid_driver(mcp2200_driver);
+
+MODULE_AUTHOR("Johannes Roith <johannes@gnu-linux.rocks>");
+MODULE_DESCRIPTION("MCP2200 Microchip HID USB to GPIO bridge");
+MODULE_LICENSE("GPL");
--
2.41.0
^ permalink raw reply related
* Pytanie o samochód
From: Jakub Lemczak @ 2023-08-18 8:15 UTC (permalink / raw)
To: linux-input
Dzień dobry,
Czy interesuje Państwa rozwiązanie umożliwiające monitorowanie samochodów firmowych oraz optymalizację kosztów ich utrzymania?
Pozdrawiam,
Jakub Lemczak
^ permalink raw reply
* Re: [PATCH v10 2/2] Input: Add Novatek NT36xxx touchscreen driver
From: Joel Selvaraj @ 2023-08-17 22:17 UTC (permalink / raw)
To: Konrad Dybcio, AngeloGioacchino Del Regno, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Henrik Rydberg
Cc: Marijn Suijten, linux-input, devicetree, linux-kernel, Dang Huynh,
Amit Pundir
In-Reply-To: <17542518-42ff-46f6-8304-fb8a214bfa77@linaro.org>
Hi Konrad,
On 8/16/23 12:36, Konrad Dybcio wrote:
> Do you have your end outcome somewhere?
Here is the driver changes on top of upstream
"drivers/input/touchscreen/novatek-nvt-ts.c"
Link:
https://gitlab.com/sdm845-mainline/linux/-/commit/d2f7702a7f6a72eaf2655840036668398942c194
and here is how I specified it in the Poco F1 dts:
Link:
https://gitlab.com/sdm845-mainline/linux/-/commit/4dd6e4578cc737d2584c7f9657f9f185effe9035
Regards
Joel Selvaraj
^ permalink raw reply
* Dell Pro Wireless Keyboard and Mouse KM5221W require HID_QUIRK_ALWAYS_POLL patch
From: Robert Ayrapetyan @ 2023-08-17 18:17 UTC (permalink / raw)
To: linux-input
Hello.
Dell Pro Wireless Keyboard and Mouse KM5221W constantly reconnect with
a following error messages:
kernel: usb 1-1: USB disconnect, device number 28
acpid[762]: input device has been disconnected, fd 20
acpid[762]: input device has been disconnected, fd 21
acpid[762]: input device has been disconnected, fd 22
kernel: usb 1-1: new full-speed USB device number 29 using xhci_hcd
kernel: usb 1-1: New USB device found, idVendor=413c, idProduct=4503,
bcdDevice= 2.40
kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 1-1: Product: Dell Universal Receiver
kernel: usb 1-1: Manufacturer: Dell Computer Corp
kernel: input: Dell Computer Corp Dell Universal Receiver as
/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/0003:413C:4503.000D/input/input35
kernel: hid-generic 0003:413C:4503.000D: input,hidraw4: USB HID v1.11
Keyboard [Dell Computer Corp Dell Universal Receiver] on
usb-0000:00:14.0-1/input0
kernel: input: Dell Computer Corp Dell Universal Receiver Mouse as
/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1/0003:413C:4503.000E/input/input36
kernel: input: Dell Computer Corp Dell Universal Receiver Consumer
Control as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1/0003:413C:4503.000E/input/input37
dbus-daemon[1442]: [session uid=1000 pid=1442] Activating service
name='org.xfce.Xfconf' requested by ':1.2053' (uid=1000 pid=271244
comm="/usr/bin/Thunar --daemon")
kernel: input: Dell Computer Corp Dell Universal Receiver System
Control as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1/0003:413C:4503.000E/input/input38
kernel: hid-generic 0003:413C:4503.000E: input,hidraw5: USB HID v1.11
Mouse [Dell Computer Corp Dell Universal Receiver] on
usb-0000:00:14.0-1/input1
kernel: hid-generic 0003:413C:4503.000F: hiddev1,hidraw6: USB HID
v1.11 Device [Dell Computer Corp Dell Universal Receiver] on
usb-0000:00:14.0-1/input2
A patch similar to
https://marc.info/?l=linux-usb&m=149675002229952&w=2 resolves the
issue (tested via the GRUB kernel options override).
Please add HID_QUIRK_ALWAYS_POLL patch for the 413C:4503 device into the kernel.
Thanks.
^ permalink raw reply
* Re: [PATCH v4] hid-mcp2200: added driver for GPIOs of MCP2200
From: kernel test robot @ 2023-08-17 17:11 UTC (permalink / raw)
To: johannes, jikos
Cc: oe-kbuild-all, benjamin.tissoires, linux-kernel, linux-input,
andi.shyti, christophe.jaillet, ak, Johannes Roith
In-Reply-To: <20230817091505.213318-1-johannes@gnu-linux.rocks>
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on hid/for-next]
[also build test WARNING on linus/master v6.5-rc6 next-20230817]
[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/johannes-gnu-linux-rocks/hid-mcp2200-added-driver-for-GPIOs-of-MCP2200/20230817-172246
base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link: https://lore.kernel.org/r/20230817091505.213318-1-johannes%40gnu-linux.rocks
patch subject: [PATCH v4] hid-mcp2200: added driver for GPIOs of MCP2200
config: sparc-allyesconfig (https://download.01.org/0day-ci/archive/20230818/202308180056.nB1KSUap-lkp@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 12.3.0
reproduce: (https://download.01.org/0day-ci/archive/20230818/202308180056.nB1KSUap-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/202308180056.nB1KSUap-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/hid/hid-mcp2200.c: In function 'mcp2200_remove':
>> drivers/hid/hid-mcp2200.c:395:25: warning: variable 'mcp' set but not used [-Wunused-but-set-variable]
395 | struct mcp2200 *mcp;
| ^~~
vim +/mcp +395 drivers/hid/hid-mcp2200.c
392
393 static void mcp2200_remove(struct hid_device *hdev)
394 {
> 395 struct mcp2200 *mcp;
396
397 mcp = hid_get_drvdata(hdev);
398 }
399
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4] hid-mcp2200: added driver for GPIOs of MCP2200
From: Randy Dunlap @ 2023-08-17 14:42 UTC (permalink / raw)
To: johannes, jikos
Cc: benjamin.tissoires, linux-kernel, linux-input, andi.shyti,
christophe.jaillet, ak
In-Reply-To: <20230817091505.213318-1-johannes@gnu-linux.rocks>
Hi--
On 8/17/23 02:15, johannes@gnu-linux.rocks wrote:
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index e11c1c803676..791cc5c8fa0d 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -1301,6 +1301,16 @@ config HID_MCP2221
> To compile this driver as a module, choose M here: the module
> will be called hid-mcp2221.ko.
>
> +config HID_MCP2200
> + tristate "Microchip MCP2200 HID USB-to-GPIO bridge"
> + depends on USB_HID
> + imply GPIOLIB
> + help
> + Provides GPIO functionality over USB-HID through MCP2200 device.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called hid-mcp2200.ko.
> +
Please follow coding-style.rst for Kconfig files, copied here with
an example:
10) Kconfig configuration files
-------------------------------
For all of the Kconfig* configuration files throughout the source tree,
the indentation is somewhat different. Lines under a ``config`` definition
are indented with one tab, while help text is indented an additional two
spaces. Example::
config AUDIT
bool "Auditing support"
depends on NET
help
Enable auditing infrastructure that can be used with another
kernel subsystem, such as SELinux (which requires this for
logging of avc messages output). Does not do system-call
auditing without CONFIG_AUDITSYSCALL.
> config HID_KUNIT_TEST
> tristate "KUnit tests for HID" if !KUNIT_ALL_TESTS
> depends on KUNIT
thanks.
--
~Randy
^ permalink raw reply
* [PATCH -next] HID: intel-ish-hid: Remove unused declarations
From: Yue Haibing @ 2023-08-17 13:50 UTC (permalink / raw)
To: srinivas.pandruvada, jikos, benjamin.tissoires, yuehaibing; +Cc: linux-input
Commit 3703f53b99e4 ("HID: intel_ish-hid: ISH Transport layer")
declared ishtp_remove_all_clients()/ishtp_can_client_connect()
but never implemented them.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
---
drivers/hid/intel-ish-hid/ishtp/bus.h | 1 -
drivers/hid/intel-ish-hid/ishtp/client.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.h b/drivers/hid/intel-ish-hid/ishtp/bus.h
index 5bb85c932e4c..53645ac89ee8 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.h
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.h
@@ -46,7 +46,6 @@ struct ishtp_cl_device {
};
int ishtp_bus_new_client(struct ishtp_device *dev);
-void ishtp_remove_all_clients(struct ishtp_device *dev);
int ishtp_cl_device_bind(struct ishtp_cl *cl);
void ishtp_cl_bus_rx_event(struct ishtp_cl_device *device);
diff --git a/drivers/hid/intel-ish-hid/ishtp/client.h b/drivers/hid/intel-ish-hid/ishtp/client.h
index fc62dd1495da..d9d398fadcf7 100644
--- a/drivers/hid/intel-ish-hid/ishtp/client.h
+++ b/drivers/hid/intel-ish-hid/ishtp/client.h
@@ -109,7 +109,6 @@ struct ishtp_cl {
};
/* Client connection managenment internal functions */
-int ishtp_can_client_connect(struct ishtp_device *ishtp_dev, guid_t *uuid);
int ishtp_fw_cl_by_id(struct ishtp_device *dev, uint8_t client_id);
void ishtp_cl_send_msg(struct ishtp_device *dev, struct ishtp_cl *cl);
void recv_ishtp_cl_msg(struct ishtp_device *dev,
--
2.34.1
^ permalink raw reply related
* [PATCH -next] HID: amd_sfh: Remove unused declarations
From: Yue Haibing @ 2023-08-17 13:51 UTC (permalink / raw)
To: basavaraj.natikar, jikos, benjamin.tissoires; +Cc: linux-input, yuehaibing
Commit 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor
Fusion Hub (SFH)") declared but never implemented them.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
---
drivers/hid/amd-sfh-hid/amd_sfh_hid.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_hid.h b/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
index 97296f587bc7..1c91be8daedd 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
@@ -73,8 +73,6 @@ struct amdtp_hid_data {
};
/* Interface functions between HID LL driver and AMD SFH client */
-void hid_amdtp_set_feature(struct hid_device *hid, char *buf, u32 len, int report_id);
-void hid_amdtp_get_report(struct hid_device *hid, int report_id, int report_type);
int amdtp_hid_probe(u32 cur_hid_dev, struct amdtp_cl_data *cli_data);
void amdtp_hid_remove(struct amdtp_cl_data *cli_data);
int amd_sfh_get_report(struct hid_device *hid, int report_id, int report_type);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] Input: pwm-beeper - Support volume setting via sysfs
From: Marek Vasut @ 2023-08-17 10:50 UTC (permalink / raw)
To: Dmitry Torokhov, Traut Manuel LCPF-CH, John Watts
Cc: Takashi Iwai, Jeff LaBundy, linux-input@vger.kernel.org,
Uwe Kleine-König, Frieder Schrempf, Thierry Reding,
linux-pwm@vger.kernel.org, alsa-devel@alsa-project.org,
Jaroslav Kysela, Takashi Iwai
In-Reply-To: <ZNvvE3usP86bgctB@google.com>
On 8/15/23 23:33, Dmitry Torokhov wrote:
> On Fri, Aug 11, 2023 at 10:47:34AM +0000, Traut Manuel LCPF-CH wrote:
>> Hi
>>
>>> On Fri, 11 Aug 2023 06:19:50 +0200,
>>> Jeff LaBundy wrote:
>>>>
>>>> Hi Marek, Dmitry and Takashi,
>>>>
>>>> On Tue, Aug 01, 2023 at 01:51:50PM +0200, Marek Vasut wrote:
>>>>> On 8/1/23 09:28, Dmitry Torokhov wrote:
>>>>>> On Mon, Jul 31, 2023 at 09:56:09PM -0500, Jeff LaBundy wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> On Mon, Jul 31, 2023 at 07:49:50PM +0200, Marek Vasut wrote:
>>>>>>>> On 7/31/23 18:24, Dmitry Torokhov wrote:
>>>>>>>>> On Mon, Jul 31, 2023 at 04:36:01PM +0200, Marek Vasut wrote:
>>>>>>>>>> On 7/31/23 16:20, Takashi Iwai wrote:
>>>>>>>>>>
>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>>>>>> Uh, I don't need a full sound device to emit
>>>>>>>>>>>>>> beeps, that's not even possible with this hardware.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Heh, I also don't recommend that route, either :)
>>>>>>>>>>>>> (Though, it must be possible to create a sound
>>>>>>>>>>>>> device with that beep control in theory)
>>>>>>>>>>>>
>>>>>>>>>>>> I mean, I can imagine one could possibly use PCM DMA
>>>>>>>>>>>> to cook samples to feed some of the PWM devices so
>>>>>>>>>>>> they could possibly be used to generate low quality
>>>>>>>>>>>> audio, as a weird limited DAC, but ... that's not really generic,
>>> and not what I want.
>>>>>>>>>>>
>>>>>>>>>>> Oh I see how the misunderstanding came; I didn't mean
>>>>>>>>>>> the PCM implementation like pcsp driver. The pcsp
>>>>>>>>>>> driver is a real hack and it's there just for fun, not for any real
>>> practical use.
>>>>>>>>>>
>>>>>>>>>> Ah :)
>>>>>>>>>>
>>>>>>>>>>> What I meant was rather that you can create a sound
>>>>>>>>>>> device containing a mixer volume control that serves
>>>>>>>>>>> exactly like the sysfs or whatever other interface, without any
>>> PCM stream or other interface.
>>>>>>>>>>
>>>>>>>>>> Ahhh, hum, I still feel like this might be a bit overkill here.
>>>>>>>>>>
>>>>>>>>>>>>>> I only need to control loudness of the beeper that
>>>>>>>>>>>>>> is controlled by PWM output. That's why I am
>>>>>>>>>>>>>> trying to extend the pwm-beeper driver, which
>>>>>>>>>>>>>> seems the best fit for such a device, it is only missing this
>>> one feature (loudness control).
>>>>>>>>>>>>>
>>>>>>>>>>>>> So the question is what's expected from user-space
>>>>>>>>>>>>> POV. If a more generic control of beep volume is
>>>>>>>>>>>>> required, e.g. for desktop-like usages, an implementation
>>> of sound driver wouldn't be too bad.
>>>>>>>>>>>>> OTOH, for other specific use-cases, it doesn't
>>>>>>>>>>>>> matter much in which interface it's implemented, and sysfs
>>> could be an easy choice.
>>>>>>>>>>>>
>>>>>>>>>>>> The whole discussion above has been exactly about
>>>>>>>>>>>> this. Basically the thing is, we can either have:
>>>>>>>>>>>> - SND_TONE (via some /dev/input/eventX) + sysfs volume
>>> control
>>>>>>>>>>>> -> This is simple, but sounds racy between input
>>>>>>>>>>>> and sysfs accesses
>>>>>>>>>>>
>>>>>>>>>>> Hmm, how can it be racy if you do proper locking?
>>>>>>>>>>
>>>>>>>>>> I can imagine two applications can each grab one of the
>>>>>>>>>> controls and that makes the interface a bit not nice. That
>>>>>>>>>> would require extra synchronization in userspace and so on.
>>>>>>>>>>
>>>>>>>>>>>> - SND_TONE + SND_TONE_SET_VOLUME
>>>>>>>>>>>> -> User needs to do two ioctls, hum
>>>>>>>>>>>> - some new SND_TONE_WITH_VOLUME
>>>>>>>>>>>> -> Probably the best option, user sets both tone frequency
>>> and volume
>>>>>>>>>>>> in one go, and it also only extends the IOCTL interface, so
>>> older
>>>>>>>>>>>> userspace won't have issues
>>>>>>>>>>>
>>>>>>>>>>> Those are "extensions" I have mentioned, and I'm not a
>>>>>>>>>>> big fan for that, honestly speaking.
>>>>>>>>>>>
>>>>>>>>>>> The fact that the beep *output* stuff is provided by the
>>>>>>>>>>> *input* device is already confusing
>>>>>>>>>>
>>>>>>>>>> I agree, this confused me as well.
>>>>>>>>>
>>>>>>>>> This comes from the times when keyboards themselves were
>>>>>>>>> capable of emitting bells (SUN, DEC, etc). In hindsight it
>>>>>>>>> was not the best way of structuring things, same with the
>>>>>>>>> keyboard LEDs (that are now plugged into the LED subsystem, but
>>> still allow be driven through input).
>>>>>>>>>
>>>>>>>>> And in the same vein I wonder if we should bite the bullet
>>>>>>>>> and pay with a bit of complexity but move sound-related things to
>>> sound subsystem.
>>>>>>>>
>>>>>>>> I am not sure that's the right approach here, since the device
>>>>>>>> cannot do PCM playback, just bleeps.
>>>>>>>>
>>>>>>>>>>> (it was so just because of historical reason), and yet
>>>>>>>>>>> you start implementing more full-featured mixer control.
>>>>>>>>>>> I'd rather keep fingers away.
>>>>>>>>>>>
>>>>>>>>>>> Again, if user-space requires the compatible behavior
>>>>>>>>>>> like the existing desktop usages
>>>>>>>>>>
>>>>>>>>>> It does not. These pwm-beeper devices keep showing up in
>>>>>>>>>> various embedded devices these days.
>>>>>>>>>>
>>>>>>>>>>> , it can be implemented in a similar way like the
>>>>>>>>>>> existing ones; i.e. provide a mixer control with a
>>>>>>>>>>> proper sound device. The sound device doesn't need to
>>>>>>>>>>> provide a PCM interface but just with a mixer interface.
>>>>>>>>>>>
>>>>>>>>>>> Or, if the purpose of your target device is a special
>>>>>>>>>>> usage, you don't need to consider too much about the
>>>>>>>>>>> existing interface, and try to keep the change as
>>>>>>>>>>> minimal as possible without too intrusive API changes.
>>>>>>>>>>
>>>>>>>>>> My use case is almost perfectly matched by the current
>>>>>>>>>> input pwm-beeper driver, the only missing bit is the
>>>>>>>>>> ability to control the loudness at runtime. I think adding
>>>>>>>>>> the SND_TONE_WITH_VOLUME parameter would cover it, with
>>> least intrusive API changes.
>>>>>>>>>>
>>>>>>>>>> The SND_TONE already supports configuring tone frequency
>>>>>>>>>> in Hz as its parameter. Since anything above 64 kHz is
>>>>>>>>>> certainly not hearable by humans, I would say the
>>>>>>>>>> SND_TONE_WITH_VOLUME could use 16 LSbits for frequency (so
>>> up to 65535 Hz , 0 is OFF), and 16 MSbits for volume .
>>>>>>>>>>
>>>>>>>>>> I'm hesitant to overcomplicate something which can
>>>>>>>>>> currently be controlled via single ioctl by pulling in sound
>>> subsystem into the picture.
>>>>>>>>>
>>>>>>>>> Can you tell a bit more about your use case? What needs to
>>>>>>>>> control the volume of beeps? Is this the only source of sounds on
>>> the system?
>>>>>>>>
>>>>>>>> Custom user space application. The entire userspace is custom
>>>>>>>> built in this case.
>>>>>>>>
>>>>>>>> In this case, it is a single-use device (think e.g. the kind
>>>>>>>> of thermometer you stick in your ear when you're ill, to find out
>>> how warm you are).
>>>>>>>>
>>>>>>>> The beeper there is used to do just that, bleep (with
>>>>>>>> different frequencies to indicate different stuff), and that
>>>>>>>> works. What I need in addition to that is control the volume
>>>>>>>> of the bleeps from the application, so it isn't too noisy. And
>>>>>>>> that needs to be user-controllable at runtime, so not something that
>>> goes in DT.
>>>>>>>>
>>>>>>>> Right now there is just the bleeper , yes.
>>>>>>>
>>>>>>> It sounds like we essentially need an option within pcsp to
>>>>>>> drive PWM instead of PCM, but input already has pwm-beeper; it
>>>>>>> seems harmless to gently extend the latter for this use-case as
>>>>>>> opposed to reworking the former.
>>>>>>>
>>>>>>> I agree that we should not invest too heavily in a legacy ABI,
>>>>>>> however something like SND_BELL_VOL seems like a low-cost
>>>>>>> addition that doesn't work against extending pcsp in the future.
>>>>>>> In fact, input already has precedent for this exact same thing
>>>>>>> by way of FF rumble effects, which are often PWM-based themselves.
>>>>>>>
>>>>>>> If SND_BELL_VOL or similar is not acceptable, then the original
>>>>>>> sysfs approach seems like the next-best compromise. My only
>>>>>>> issue with it was that I felt the range was not abstracted enough.
>>>>>>
>>>>>> If we want to extend the API we will need to define exactly how it
>>>>>> will all work. I.e. what happens if userspace mixes the old
>>>>>> SND_TONE and SND_BELL with the new SND_BELL_VOL or whatever.
>>> Does
>>>>>> it play with previously set volume? The default one?
>>>>>
>>>>> Default one, to preserve current behavior, yes.
>>>>
>>>> This was my idea as well, but I appreciate that the devil is in the
>>>> details and each driver may have to duplicate some overhead.
>>>>
>>>>>
>>>>>> How to set the default one?
>>>>>
>>>>> We do not, we can call pwm_get_duty_cycle() to get the current duty
>>>>> cycle of the PWM to figure out the default.
>>>>>
>>>>>> How
>>>>>> to figure out what the current volume is if we decide to make
>>>>>> volume "sticky"?
>>>>>
>>>>> The patch stores the current volume configured via sysfs into
>>>>> beeper->duty_cycle .
>>>>>
>>>>>> As far as userspace I expect it is more common to have one program
>>>>>> (or component of a program) to set volume and then something else
>>>>>> requests sound, so having one-shot API is of dubious value to me.
>>>>>
>>>>> Currently the use case I have for this is a single user facing
>>>>> application which configures both.
>>>>>
>>>>>> I hope we can go with Takashi's proposal downthread, but if not I
>>>>>> wonder if the sysfs approach is not the simplest one. Do we expect
>>>>>> more beepers that can control volume besides pwm-beeper?
>>>>>
>>>>> It seems to me pulling in dependency on the entire sound subsystem
>>>>> only to set beeper volume is overkill. I currently don't even have
>>>>> sound subsystem compiled in.
>>>>
>>>> I like Takashi's patch; it seems like a more scalable solution.
>>>> However, I can appreciate the reluctance to bring in the entire sound
>>>> subsytem for what is probably a tiny piezoelectric buzzer.
>>>>
>>>> It seems like the sysfs solution is the best compromise in the
>>>> meantime. If more and more users need to shoe-horn these kind of
>>>> features in the future, we can make more informed decisions as to how to
>>> extend the API (if at all).
>>>
>>> That's my impression, too. The original sysfs usage would be the right fit at
>>> this moment.
>>
>> I am fine with both using the Sound API and sysfs. I would additionally like to
>> specify the pwm values in device-tree like done in pwm-backlight. It really depends
>> on the hardware which values actually make a difference in volume.
>
> OK, let's go with the sysfs API for now as I am not sure if we have more
> drivers being able to control volume of beeps.
>
> Marek, I think there were some minor comments on the patch, could you
> please address them and respin?
I mean, yeah, but I think the input from John makes sense -- can we go
with new TONE_WITH_VOLUME parameter instead of the sysfs interface ?
That would be much nicer to work with .
^ permalink raw reply
* [PATCH v4] hid-mcp2200: added driver for GPIOs of MCP2200
From: johannes @ 2023-08-17 9:15 UTC (permalink / raw)
To: jikos
Cc: benjamin.tissoires, linux-kernel, linux-input, andi.shyti,
christophe.jaillet, ak, Johannes Roith
From: Johannes Roith <johannes@gnu-linux.rocks>
Added a gpiochip compatible driver to control the 8 GPIOs of the MCP2200
by using the HID interface.
Using GPIOs with alternative functions (GP0<->SSPND, GP1<->USBCFG,
GP6<->RXLED, GP7<->TXLED) will reset the functions, if set (unset by
default).
The driver was tested while also using the UART of the chip. Setting
and reading the GPIOs has no effect on the UART communication. However,
a reset is triggered after the CONFIGURE command. If the GPIO Direction
is constantly changed, this will affect the communication at low baud
rates. This is a hardware problem of the MCP2200 and is not caused by
the driver.
Feedback from reviewers Christophe JAILLET <christophe.jaillet@wanadoo.fr>
and Andi Shyti <andi.shyti@kernel.org> was added.
Changelog:
- v1: added driver
- v2: added ProductID in hid-ids.h
- v3: added feedback from review and make patch compilable
- v4: added more feedback from second review, tested as module and
buildin on x86 and arm64
Signed-off-by: Johannes Roith <johannes@gnu-linux.rocks>
---
drivers/hid/Kconfig | 10 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-mcp2200.c | 419 ++++++++++++++++++++++++++++++++++++++
4 files changed, 431 insertions(+)
create mode 100644 drivers/hid/hid-mcp2200.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index e11c1c803676..791cc5c8fa0d 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1301,6 +1301,16 @@ config HID_MCP2221
To compile this driver as a module, choose M here: the module
will be called hid-mcp2221.ko.
+config HID_MCP2200
+ tristate "Microchip MCP2200 HID USB-to-GPIO bridge"
+ depends on USB_HID
+ imply GPIOLIB
+ help
+ Provides GPIO functionality over USB-HID through MCP2200 device.
+
+ To compile this driver as a module, choose M here: the module
+ will be called hid-mcp2200.ko.
+
config HID_KUNIT_TEST
tristate "KUnit tests for HID" if !KUNIT_ALL_TESTS
depends on KUNIT
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 7a9e160158f7..050f740304c4 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_HID_MACALLY) += hid-macally.o
obj-$(CONFIG_HID_MAGICMOUSE) += hid-magicmouse.o
obj-$(CONFIG_HID_MALTRON) += hid-maltron.o
obj-$(CONFIG_HID_MCP2221) += hid-mcp2221.o
+obj-$(CONFIG_HID_MCP2200) += hid-mcp2200.o
obj-$(CONFIG_HID_MAYFLASH) += hid-mf.o
obj-$(CONFIG_HID_MEGAWORLD_FF) += hid-megaworld.o
obj-$(CONFIG_HID_MICROSOFT) += hid-microsoft.o
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 8a310f8ff20f..4926ca41225b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -914,6 +914,7 @@
#define USB_DEVICE_ID_PICK16F1454_V2 0xf2f7
#define USB_DEVICE_ID_LUXAFOR 0xf372
#define USB_DEVICE_ID_MCP2221 0x00dd
+#define USB_DEVICE_ID_MCP2200 0x00df
#define USB_VENDOR_ID_MICROSOFT 0x045e
#define USB_DEVICE_ID_SIDEWINDER_GV 0x003b
diff --git a/drivers/hid/hid-mcp2200.c b/drivers/hid/hid-mcp2200.c
new file mode 100644
index 000000000000..7ea927583894
--- /dev/null
+++ b/drivers/hid/hid-mcp2200.c
@@ -0,0 +1,419 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * MCP2200 - Microchip USB to GPIO bridge
+ *
+ * Copyright (c) 2023, Johannes Roith <johannes@gnu-linux.rocks>
+ *
+ * Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/22228A.pdf
+ * App Note for HID: https://ww1.microchip.com/downloads/en/DeviceDoc/93066A.pdf
+ */
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio/driver.h>
+#include <linux/hid.h>
+#include <linux/hidraw.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+//#include "hid-ids.h"
+#define USB_DEVICE_ID_MCP2200 0x00df
+#define USB_VENDOR_ID_MICROCHIP 0x04d8
+
+/* Commands codes in a raw output report */
+#define SET_CLEAR_OUTPUTS 0x08
+#define CONFIGURE 0x10
+#define READ_EE 0x20
+#define WRITE_EE 0x40
+#define READ_ALL 0x80
+
+/* MCP GPIO direction encoding */
+enum MCP_IO_DIR {
+ MCP2200_DIR_OUT = 0x00,
+ MCP2200_DIR_IN = 0x01,
+};
+
+/* Altternative pin assignments */
+#define TXLED 2
+#define RXLED 3
+#define USBCFG 6
+#define SSPND 7
+#define MCP_NGPIO 8
+
+/* CMD to set or clear a GPIO output */
+struct mcp_set_clear_outputs {
+ u8 cmd;
+ u8 dummys1[10];
+ u8 set_bmap;
+ u8 clear_bmap;
+ u8 dummys2[3];
+} __packed;
+
+/* CMD to configure the IOs */
+struct mcp_configure {
+ u8 cmd;
+ u8 dummys1[3];
+ u8 io_bmap;
+ u8 config_alt_pins;
+ u8 io_default_val_bmap;
+ u8 config_alt_options;
+ u8 baud_h;
+ u8 baud_l;
+ u8 dummys2[6];
+} __packed;
+
+/* CMD to read all parameters */
+struct mcp_read_all {
+ u8 cmd;
+ u8 dummys[15];
+} __packed;
+
+/* Response to the read all cmd */
+struct mcp_read_all_resp {
+ u8 cmd;
+ u8 eep_addr;
+ u8 dummy;
+ u8 eep_val;
+ u8 io_bmap;
+ u8 config_alt_pins;
+ u8 io_default_val_bmap;
+ u8 config_alt_options;
+ u8 baud_h;
+ u8 baud_l;
+ u8 io_port_val_bmap;
+ u8 dummys[5];
+} __packed;
+
+struct mcp2200 {
+ struct hid_device *hdev;
+ struct mutex lock;
+ struct completion wait_in_report;
+ u8 gpio_dir;
+ u8 gpio_val;
+ u8 gpio_inval;
+ u8 baud_h;
+ u8 baud_l;
+ u8 config_alt_pins;
+ u8 gpio_reset_val;
+ u8 config_alt_options;
+ int status;
+ struct gpio_chip gc;
+};
+
+/* this executes the READ_ALL cmd */
+static int mcp_cmd_read_all(struct mcp2200 *mcp)
+{
+ struct mcp_read_all *read_all;
+ int len, t;
+
+ reinit_completion(&mcp->wait_in_report);
+ read_all = kzalloc(sizeof(struct mcp_read_all), GFP_KERNEL);
+ if (!read_all)
+ return -ENOMEM;
+
+ read_all->cmd = READ_ALL;
+
+ mutex_lock(&mcp->lock);
+ len = hid_hw_output_report(mcp->hdev, (u8 *) read_all,
+ sizeof(struct mcp_read_all));
+
+ mutex_unlock(&mcp->lock);
+ kfree(read_all);
+
+ if (len != sizeof(struct mcp_read_all))
+ return -EINVAL;
+
+ t = wait_for_completion_timeout(&mcp->wait_in_report,
+ msecs_to_jiffies(4000));
+ if (!t)
+ return -ETIMEDOUT;
+
+ /* return status, negative value if wrong response was received */
+ return mcp->status;
+}
+
+static void mcp_set_multiple(struct gpio_chip *gc, unsigned long *mask,
+ unsigned long *bits)
+{
+ struct mcp2200 *mcp = gpiochip_get_data(gc);
+ u8 value;
+ int status;
+ struct mcp_set_clear_outputs *cmd;
+
+ cmd = kzalloc(sizeof(struct mcp_set_clear_outputs), GFP_KERNEL);
+ if (!cmd)
+ return;
+
+ mutex_lock(&mcp->lock);
+
+ value = mcp->gpio_val & ~*mask;
+ value |= (*mask & *bits);
+
+ cmd->cmd = SET_CLEAR_OUTPUTS;
+ cmd->set_bmap = value;
+ cmd->clear_bmap = ~(value);
+
+ status = hid_hw_output_report(mcp->hdev, (u8 *) cmd,
+ sizeof(struct mcp_set_clear_outputs));
+
+ if (status == sizeof(struct mcp_set_clear_outputs))
+ mcp->gpio_val = value;
+
+ mutex_unlock(&mcp->lock);
+ kfree(cmd);
+}
+
+static void mcp_set(struct gpio_chip *gc, unsigned int gpio_nr, int value)
+{
+ unsigned long mask = 1 << gpio_nr;
+ unsigned long bmap_value = value << gpio_nr;
+
+ mcp_set_multiple(gc, &mask, &bmap_value);
+}
+
+static int mcp_get_multiple(struct gpio_chip *gc, unsigned long *mask,
+ unsigned long *bits)
+{
+ u32 val;
+ struct mcp2200 *mcp = gpiochip_get_data(gc);
+ int status;
+
+ status = mcp_cmd_read_all(mcp);
+ if (status != 0)
+ return status;
+
+ val = mcp->gpio_inval;
+ *bits = (val & *mask);
+ return 0;
+}
+
+static int mcp_get(struct gpio_chip *gc, unsigned int gpio_nr)
+{
+ unsigned long mask = 0, bits = 0;
+
+ mask = (1 << gpio_nr);
+ mcp_get_multiple(gc, &mask, &bits);
+ return bits > 0;
+}
+
+static int mcp_get_direction(struct gpio_chip *gc, unsigned int gpio_nr)
+{
+ struct mcp2200 *mcp = gpiochip_get_data(gc);
+
+ return (mcp->gpio_dir & (MCP2200_DIR_IN << gpio_nr))
+ ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT;
+}
+
+static int mcp_set_direction(struct gpio_chip *gc, unsigned int gpio_nr,
+ enum MCP_IO_DIR io_direction)
+{
+ struct mcp2200 *mcp = gpiochip_get_data(gc);
+ struct mcp_configure *conf;
+ int status;
+ /* after the configure cmd we will need to set the outputs again */
+ unsigned long mask = ~(mcp->gpio_dir); /* only set outputs */
+ unsigned long bits = mcp->gpio_val;
+ /* Offsets of alternative pins in config_alt_pins, 0 is not used */
+ u8 alt_pin_conf[8] = {SSPND, USBCFG, 0, 0, 0, 0, RXLED, TXLED};
+ u8 config_alt_pins = mcp->config_alt_pins;
+
+ /* Read in the reset baudrate first, we need it later */
+ status = mcp_cmd_read_all(mcp);
+ if (status != 0)
+ return status;
+
+ conf = kzalloc(sizeof(struct mcp_configure), GFP_KERNEL);
+ if (!conf)
+ return -ENOMEM;
+
+ mutex_lock(&mcp->lock);
+
+ /* configure will reset the chip! */
+ conf->cmd = CONFIGURE;
+ conf->io_bmap = (mcp->gpio_dir & ~(1 << gpio_nr))
+ | (io_direction << gpio_nr);
+ /* Don't overwrite the reset parameters */
+ conf->baud_h = mcp->baud_h;
+ conf->baud_l = mcp->baud_l;
+ conf->config_alt_options = mcp->config_alt_options;
+ conf->io_default_val_bmap = mcp->gpio_reset_val;
+ /* Adjust alt. func if necessary */
+ if (alt_pin_conf[gpio_nr])
+ config_alt_pins &= ~(1 << alt_pin_conf[gpio_nr]);
+ conf->config_alt_pins = config_alt_pins;
+
+ status = hid_hw_output_report(mcp->hdev, (u8 *) conf,
+ sizeof(struct mcp_set_clear_outputs));
+
+ if (status == sizeof(struct mcp_set_clear_outputs)) {
+ mcp->gpio_dir &= ~(1 << gpio_nr);
+ mcp->config_alt_pins = config_alt_pins;
+ } else {
+ mutex_unlock(&mcp->lock);
+ kfree(conf);
+ return -EIO;
+ }
+
+ mutex_unlock(&mcp->lock);
+ kfree(conf);
+
+ /* Configure CMD will clear all IOs -> rewrite them */
+ mcp_set_multiple(gc, &mask, &bits);
+ return 0;
+}
+
+static int mcp_direction_input(struct gpio_chip *gc, unsigned int gpio_nr)
+{
+ return mcp_set_direction(gc, gpio_nr, MCP2200_DIR_IN);
+}
+
+static int mcp_direction_output(struct gpio_chip *gc, unsigned int gpio_nr,
+ int value)
+{
+ int ret;
+ unsigned long mask, bmap_value;
+
+ mask = 1 << gpio_nr;
+ bmap_value = value << gpio_nr;
+
+ ret = mcp_set_direction(gc, gpio_nr, MCP2200_DIR_OUT);
+ if (ret == 0)
+ mcp_set_multiple(gc, &mask, &bmap_value);
+ return ret;
+}
+
+static const struct gpio_chip template_chip = {
+ .label = "mcp2200",
+ .owner = THIS_MODULE,
+ .get_direction = mcp_get_direction,
+ .direction_input = mcp_direction_input,
+ .direction_output = mcp_direction_output,
+ .set = mcp_set,
+ .set_multiple = mcp_set_multiple,
+ .get = mcp_get,
+ .get_multiple = mcp_get_multiple,
+ .base = -1,
+ .ngpio = MCP_NGPIO,
+ .can_sleep = true,
+};
+
+/*
+ * MCP2200 uses interrupt endpoint for input reports. This function
+ * is called by HID layer when it receives i/p report from mcp2200,
+ * which is actually a response to the previously sent command.
+ */
+static int mcp2200_raw_event(struct hid_device *hdev, struct hid_report *report,
+ u8 *data, int size)
+{
+ struct mcp2200 *mcp = hid_get_drvdata(hdev);
+ struct mcp_read_all_resp *all_resp;
+
+ switch (data[0]) {
+ case READ_ALL:
+ all_resp = (struct mcp_read_all_resp *) data;
+ mcp->status = 0;
+ mcp->gpio_inval = all_resp->io_port_val_bmap;
+ mcp->baud_h = all_resp->baud_h;
+ mcp->baud_l = all_resp->baud_l;
+ mcp->gpio_reset_val = all_resp->io_default_val_bmap;
+ mcp->config_alt_pins = all_resp->config_alt_pins;
+ mcp->config_alt_options = all_resp->config_alt_options;
+ break;
+ default:
+ mcp->status = -EIO;
+ break;
+ }
+
+ complete(&mcp->wait_in_report);
+ return 1;
+}
+
+static void mcp2200_hid_unregister(void *ptr)
+{
+ struct hid_device *hdev = ptr;
+
+ hid_hw_close(hdev);
+ hid_hw_stop(hdev);
+}
+
+static int mcp2200_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+ struct mcp2200 *mcp;
+
+ mcp = devm_kzalloc(&hdev->dev, sizeof(*mcp), GFP_KERNEL);
+ if (!mcp)
+ return -ENOMEM;
+
+ ret = hid_parse(hdev);
+ if (ret) {
+ hid_err(hdev, "can't parse reports\n");
+ return ret;
+ }
+
+ /*
+ * This driver uses the .raw_event callback and therefore does not need any
+ * HID_CONNECT_xxx flags.
+ */
+ ret = hid_hw_start(hdev, 0);
+ if (ret) {
+ hid_err(hdev, "can't start hardware\n");
+ return ret;
+ }
+
+ hid_info(hdev, "USB HID v%x.%02x Device [%s] on %s\n", hdev->version >> 8,
+ hdev->version & 0xff, hdev->name, hdev->phys);
+
+ ret = hid_hw_open(hdev);
+ if (ret) {
+ hid_err(hdev, "can't open device\n");
+ return ret;
+ }
+
+ mutex_init(&mcp->lock);
+ init_completion(&mcp->wait_in_report);
+ hid_set_drvdata(hdev, mcp);
+ mcp->hdev = hdev;
+
+ ret = devm_add_action_or_reset(&hdev->dev, mcp2200_hid_unregister, hdev);
+ if (ret)
+ return ret;
+
+ mcp->gc = template_chip;
+ mcp->gc.parent = &hdev->dev;
+
+ ret = devm_gpiochip_add_data(&hdev->dev, &mcp->gc, mcp);
+ if (ret < 0) {
+ hid_err(hdev, "Unable to register gpiochip\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void mcp2200_remove(struct hid_device *hdev)
+{
+ struct mcp2200 *mcp;
+
+ mcp = hid_get_drvdata(hdev);
+}
+
+static const struct hid_device_id mcp2200_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_MCP2200) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, mcp2200_devices);
+
+static struct hid_driver mcp2200_driver = {
+ .name = "mcp2200",
+ .id_table = mcp2200_devices,
+ .probe = mcp2200_probe,
+ .remove = mcp2200_remove,
+ .raw_event = mcp2200_raw_event,
+};
+
+/* Register with HID core */
+module_hid_driver(mcp2200_driver);
+
+MODULE_AUTHOR("Johannes Roith <johannes@gnu-linux.rocks>");
+MODULE_DESCRIPTION("MCP2200 Microchip HID USB to GPIO bridge");
+MODULE_LICENSE("GPL");
--
2.41.0
^ permalink raw reply related
* Re: [PATCH v2] HID: i2c-hid: use print_hex_dump_debug to print report descriptor
From: Rahul Rameshbabu @ 2023-08-17 4:25 UTC (permalink / raw)
To: Riwen Lu
Cc: jikos, benjamin.tissoires, dmitry.torokhov, linux, hdegoede,
rrangel, u.kleine-koenig, linux-input, linux-kernel, Riwen Lu
In-Reply-To: <OS3P286MB259916DCE3D992135FF05F4CB115A@OS3P286MB2599.JPNP286.PROD.OUTLOOK.COM>
On Wed, 16 Aug, 2023 16:38:19 +0800 "Riwen Lu" <luriwen@hotmail.com> wrote:
> From: Riwen Lu <luriwen@kylinos.cn>
>
> The format '%*ph' print up to 64 bytes long as a hex string with ' '
> sepatator. Usually the size of report descriptor is larger than 64
> bytes, so consider using print_hex_dump_debug to print out all of it for
> better debugging.
>
> Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
>
> ---
> v1->v2:
> - Add a prefix for the hex dump.
> ---
> drivers/hid/i2c-hid/i2c-hid-core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index efbba0465eef..fd82e9042da5 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -772,7 +772,9 @@ static int i2c_hid_parse(struct hid_device *hid)
> }
> }
>
> - i2c_hid_dbg(ihid, "Report Descriptor: %*ph\n", rsize, rdesc);
> + i2c_hid_dbg(ihid, "Report Descriptor\n");
Instead of just indicating that the report descriptor dump begins with
the above print, I think it makes more sense for the print to be changed
to a pair of begin/end or "cut here" prints similar to what you see in
oops messages. This will help individuals reading reports copied by bug
reporters validate that the complete descriptor dump is present.
Something along the lines of what is done in sound/soc/sof/debug.c.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sof/debug.c?id=4853c74bd7ab7fdb83f319bd9ace8a08c031e9b6#n407
> + print_hex_dump_debug("Report Descriptor: ", DUMP_PREFIX_OFFSET, 16, 1,
> + rdesc, rsize, false);
>
--
Thanks,
Rahul Rameshbabu
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: cs40l50 - Initial support for Cirrus Logic CS40L50
From: James Ogletree @ 2023-08-16 21:02 UTC (permalink / raw)
To: Jeff LaBundy
Cc: Dmitry Torokhov, Fred Treven, Ben Bright, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Joel Stanley,
Arnd Bergmann, Jacky Bai, Jean Delvare, Eddie James,
Markus Schneider-Pargmann, ChiYuan Huang, Randy Dunlap,
Wolfram Sang, patches@opensource.cirrus.com,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ZNWz7F7qLeNKDlG/@nixie71>
> On Aug 10, 2023, at 11:07 PM, Jeff LaBundy <jeff@labundy.com> wrote:
>
> On Wed, Aug 09, 2023 at 07:10:28PM +0000, James Ogletree wrote:
>> Introduce support for Cirrus Logic Device CS40L50: a
>> haptics driver with waveform memory DSP and closed-loop
>> algorithms.
>
> From my extremely naive point of view, some of the code that follows
> bares resemblance to the recently reviewed L26. My assumption is that
> these devices are different enough in nature to warrant completely
> different drivers; is that accurate?
>
> One reason for asking is because the L26 driver included a cornucopia
> of power-management overhead, yet we see none of that here. Assuming
> both L50 and L26 are built around the same Halo DSP, why is there such
> a fundamental difference between the two in terms of power management?
>
> To that end, how does this driver handle hibernation? Is hibernation
> not supported, or do we simply defer to the DSP? In the case of the
> latter, why is L50 given this freedom but not L26?
One key difference is that L50’s Halo Core DSP is self-booting; the firmware
is burned in and no firmware download is required. On L26, firmware
downloading is compulsory. This differentiates dealing with the DSP in the
two drivers, because the L50 driver does not need to do a look up every
time it reads or writes to a firmware control. The registers are all static.
Minor reasons are that they have different power supply configurations that
require different register settings, they have errata differences, and a different set
of exposed features (L50 being much more simplistic). I think taken cumulatively
these differences warrant separate drivers. Though, I will take Charles’
recommendation to factor out the similarities into a shared library that both L50
and L26 can use.
Let me know whether you disagree on the above points or have followup
questions.
With respect to power management, I did not think that that there was any merit
in itself in maintaining equality with L26’s approach, and I was inclined to accept
your reasoning for using retry logic over the runtime PM facilities (not that the
latter way is incorrect).
Regarding the need for I2S streaming support, signs point to maybe. I will
migrate this driver to MFD for V4.
>
>> + return cs40l50_dsp_write(cs40l50, CS40L50_BST_LPMODE_SEL, CS40L50_DCM_LOW_POWER);
>> +}
>> +
>> +static int cs40l50_patch_firmware(struct cs40l50_private *cs40l50)
>> +{
>> + const struct firmware *bin = NULL, *wmfw = NULL;
>> + int error = 0;
>> +
>> + if (request_firmware(&bin, "cs40l50.bin", cs40l50->dev))
>> + dev_info(cs40l50->dev, "Could not request wavetable file: %d\n", error);
>> +
>> + if (request_firmware(&wmfw, "cs40l50.wmfw", cs40l50->dev))
>> + dev_info(cs40l50->dev, "Could not request firmware patch file: %d\n", error);
>> +
>> + if (wmfw) {
>
> It is a much more common design pattern to bail if request_firmware() returns
> an error, than to proceed and check against the FW pointer remaining NULL.
>
> Is this done because cs_dsp_power_up() must be called, with or without a wmfw
> or coefficient file being available?
I don’t think that cs_dsp_power_up() must be called in the case of non-existent .wmfw
and .bin files, so I will take your suggestion and optimize this function. I will also switch
to asynchronous firmware requesting for V4.
I will also incorporate the rest of your review comments not mentioned here in V4.
Thank you for the thorough review.
Regards,
James Ogletree
^ permalink raw reply
* [linux-next:master] BUILD REGRESSION ef66bf8aeb91fd331cf8f5dca8f9d7bca9ab2849
From: kernel test robot @ 2023-08-16 20:11 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Memory Management List, bpf, dri-devel, linux-arm-kernel,
linux-arm-msm, linux-crypto, linux-csky, linux-doc, linux-fsdevel,
linux-input, linux-media, linux-rdma, linux-rtc, linux-spi,
linux-wireless, loongarch, netdev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: ef66bf8aeb91fd331cf8f5dca8f9d7bca9ab2849 Add linux-next specific files for 20230816
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202307281049.40t8s0uv-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202307301850.i9xFNWT6-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202308111853.ISf5a6VC-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202308112307.TPmYbd3L-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202308112326.AJAVWCOC-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202308162234.Y7j8JEIF-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202308170007.OzhdwITj-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202308170206.fZG3V1Gy-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202308170227.ymiFlMbT-lkp@intel.com
Error/Warning: (recently discovered and may have been fixed)
../lib/gcc/loongarch64-linux/12.3.0/plugin/include/config/loongarch/loongarch-opts.h:31:10: fatal error: loongarch-def.h: No such file or directory
Documentation/gpu/rfc/i915_scheduler.rst:138: WARNING: Unknown directive type "c:namespace-push".
Documentation/gpu/rfc/i915_scheduler.rst:143: WARNING: Unknown directive type "c:namespace-pop".
Warning: kernel/Kconfig.kexec references a file that doesn't exist: file:Documentation/s390/zfcpdump.rst
arch/csky/include/asm/ptrace.h:100:11: error: expected ';' before 'void'
arch/csky/include/asm/ptrace.h:99:11: error: expected ';' before 'int'
arch/csky/include/asm/traps.h:43:11: error: expected ';' before 'void'
arch/loongarch/kernel/asm-offsets.c:172:6: warning: no previous prototype for 'output_thread_lbt_defines' [-Wmissing-prototypes]
drivers/gpu/drm/drm_gpuva_mgr.c:1079:32: warning: variable 'prev' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/drm_gpuva_mgr.c:1079:39: warning: variable 'prev' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/tests/drm_kunit_helpers.c:172: warning: expecting prototype for drm_kunit_helper_context_alloc(). Prototype was for drm_kunit_helper_acquire_ctx_alloc() instead
drivers/media/pci/intel/ivsc/mei_csi.c:342:10: error: call to undeclared function 'v4l2_subdev_get_try_format'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
drivers/media/pci/intel/ivsc/mei_csi.c:342:10: error: incompatible integer to pointer conversion returning 'int' from a function with result type 'struct v4l2_mbus_framefmt *' [-Wint-conversion]
drivers/media/pci/intel/ivsc/mei_csi.c:360:14: error: incompatible integer to pointer conversion assigning to 'struct v4l2_mbus_framefmt *' from 'int' [-Wint-conversion]
drivers/video/backlight/lp855x_bl.c:252:11: warning: variable 'ret' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
fs/fuse/dir.c:353:6: warning: no previous declaration for 'fuse_valid_size' [-Wmissing-declarations]
include/linux/build_bug.h:16:51: error: bit-field '<anonymous>' width not an integer constant
kernel/bpf/map_iter.c:201:17: warning: no previous declaration for 'bpf_map_sum_elem_count' [-Wmissing-declarations]
net/bpf/test_run.c:558:15: warning: no previous declaration for 'bpf_fentry_test_sinfo' [-Wmissing-declarations]
net/bpf/test_run.c:559:15: warning: no previous declaration for 'bpf_fentry_test_sinfo' [-Wmissing-declarations]
net/bpf/test_run.c:568:17: warning: no previous declaration for 'bpf_modify_return_test2' [-Wmissing-declarations]
Unverified Error/Warning (likely false positive, please contact us if interested):
drivers/input/touchscreen/iqs7211.c:1761 iqs7211_parse_cycles() error: buffer overflow 'cycle_alloc[0]' 2 <= 41
drivers/mtd/nand/raw/qcom_nandc.c:2590 qcom_op_cmd_mapping() error: uninitialized symbol 'ret'.
drivers/mtd/nand/raw/qcom_nandc.c:3017 qcom_check_op() warn: was && intended here instead of ||?
drivers/net/ethernet/mellanox/mlx5/core/lib/devcom.c:264 mlx5_devcom_send_event() warn: variable dereferenced before IS_ERR check 'devcom' (see line 259)
drivers/net/wireless/mediatek/mt76/mt792x_mac.c:362 mt792x_pm_power_save_work() warn: can 'dev->fw_assert' even be NULL?
drivers/pwm/pwm-atmel.c:479 atmel_pwm_enable_clk_if_on() warn: missing error code 'ret'
drivers/regulator/max77857-regulator.c:430:28: sparse: sparse: symbol 'max77857_id' was not declared. Should it be static?
drivers/rtc/rtc-pcf2127.c:1063 pcf2127_enable_ts() warn: missing error code? 'ret'
kernel/workqueue.c:325:40: sparse: sparse: duplicate [noderef]
kernel/workqueue.c:325:40: sparse: sparse: multiple address spaces given: __percpu & __rcu
lib/crypto/mpi/mpi-inv.c:34:15: warning: variable 'k' set but not used [-Wunused-but-set-variable]
net/xdp/xsk.c:696 xsk_build_skb() error: 'skb' dereferencing possible ERR_PTR()
sh4-linux-gcc: internal compiler error: Segmentation fault signal terminated program cc1
{standard input}: Warning: end of file not at end of a line; newline inserted
{standard input}:927: Error: pcrel too far
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- arc-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- arc-axs101_defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- arc-randconfig-r005-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- arc-randconfig-r013-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- arc-randconfig-r043-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- arm-allmodconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- arm-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- arm-defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- arm-randconfig-r046-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- arm-randconfig-r093-20230816
| |-- drivers-regulator-max77857-regulator.c:sparse:sparse:symbol-max77857_id-was-not-declared.-Should-it-be-static
| |-- kernel-workqueue.c:sparse:sparse:duplicate-noderef
| `-- kernel-workqueue.c:sparse:sparse:multiple-address-spaces-given:__percpu-__rcu
|-- arm-spear6xx_defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- arm-tegra_defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- arm-u8500_defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- arm64-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- arm64-defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- csky-randconfig-r003-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- csky-randconfig-r013-20230816
| |-- arch-csky-include-asm-ptrace.h:error:expected-before-int
| |-- arch-csky-include-asm-ptrace.h:error:expected-before-void
| `-- arch-csky-include-asm-traps.h:error:expected-before-void
|-- csky-randconfig-r015-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- csky-randconfig-r026-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- csky-randconfig-r083-20230816
| |-- arch-csky-include-asm-ptrace.h:error:expected-before-int
| |-- arch-csky-include-asm-ptrace.h:error:expected-before-void
| |-- arch-csky-include-asm-traps.h:error:expected-before-void
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| |-- kernel-workqueue.c:sparse:sparse:duplicate-noderef
| `-- kernel-workqueue.c:sparse:sparse:multiple-address-spaces-given:__percpu-__rcu
|-- i386-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- i386-buildonly-randconfig-r004-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- i386-debian-10.3
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- i386-defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- i386-randconfig-i001-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- i386-randconfig-i002-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- i386-randconfig-i004-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- i386-randconfig-i005-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- i386-randconfig-i052-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- net-bpf-test_run.c:warning:no-previous-declaration-for-bpf_fentry_test_sinfo
|-- i386-randconfig-i054-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| |-- fs-fuse-dir.c:warning:no-previous-declaration-for-fuse_valid_size
| `-- net-bpf-test_run.c:warning:no-previous-declaration-for-bpf_fentry_test_sinfo
|-- i386-randconfig-i061-20230816
| |-- kernel-workqueue.c:sparse:sparse:duplicate-noderef
| `-- kernel-workqueue.c:sparse:sparse:multiple-address-spaces-given:__percpu-__rcu
|-- i386-randconfig-i063-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| |-- kernel-workqueue.c:sparse:sparse:duplicate-noderef
| `-- kernel-workqueue.c:sparse:sparse:multiple-address-spaces-given:__percpu-__rcu
|-- i386-randconfig-r081-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| |-- drivers-regulator-max77857-regulator.c:sparse:sparse:symbol-max77857_id-was-not-declared.-Should-it-be-static
| |-- kernel-workqueue.c:sparse:sparse:duplicate-noderef
| `-- kernel-workqueue.c:sparse:sparse:multiple-address-spaces-given:__percpu-__rcu
|-- loongarch-allmodconfig
| `-- lib-gcc-loongarch64-linux-..-plugin-include-config-loongarch-loongarch-opts.h:fatal-error:loongarch-def.h:No-such-file-or-directory
|-- loongarch-allnoconfig
| `-- arch-loongarch-kernel-asm-offsets.c:warning:no-previous-prototype-for-output_thread_lbt_defines
|-- loongarch-defconfig
| |-- arch-loongarch-kernel-asm-offsets.c:warning:no-previous-prototype-for-output_thread_lbt_defines
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- include-linux-build_bug.h:error:bit-field-anonymous-width-not-an-integer-constant
|-- loongarch-randconfig-r014-20230816
| `-- arch-loongarch-kernel-asm-offsets.c:warning:no-previous-prototype-for-output_thread_lbt_defines
|-- loongarch-randconfig-r032-20230816
| `-- arch-loongarch-kernel-asm-offsets.c:warning:no-previous-prototype-for-output_thread_lbt_defines
|-- loongarch-randconfig-r035-20230816
| `-- lib-gcc-loongarch64-linux-..-plugin-include-config-loongarch-loongarch-opts.h:fatal-error:loongarch-def.h:No-such-file-or-directory
|-- m68k-allmodconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- m68k-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- mips-allmodconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- mips-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- nios2-randconfig-r012-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- nios2-randconfig-r062-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- parisc-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- parisc-defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- parisc64-defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- powerpc-allmodconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- powerpc-randconfig-r001-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- riscv-allmodconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- riscv-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- riscv-defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- riscv-randconfig-r091-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| |-- kernel-workqueue.c:sparse:sparse:duplicate-noderef
| `-- kernel-workqueue.c:sparse:sparse:multiple-address-spaces-given:__percpu-__rcu
|-- riscv-rv32_defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- s390-allmodconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- s390-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- s390-randconfig-r063-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- sh-allmodconfig
| |-- sh4-linux-gcc:internal-compiler-error:Segmentation-fault-signal-terminated-program-cc1
| |-- standard-input:Error:pcrel-too-far
| `-- standard-input:Warning:end-of-file-not-at-end-of-a-line-newline-inserted
|-- sparc-allmodconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- sparc-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- sparc-randconfig-m031-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- sparc-randconfig-r052-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- sparc-randconfig-r092-20230816
| |-- kernel-workqueue.c:sparse:sparse:duplicate-noderef
| `-- kernel-workqueue.c:sparse:sparse:multiple-address-spaces-given:__percpu-__rcu
|-- um-randconfig-r072-20230816
| |-- drivers-regulator-max77857-regulator.c:sparse:sparse:symbol-max77857_id-was-not-declared.-Should-it-be-static
| |-- kernel-workqueue.c:sparse:sparse:duplicate-noderef
| `-- kernel-workqueue.c:sparse:sparse:multiple-address-spaces-given:__percpu-__rcu
|-- um-randconfig-r082-20230816
| |-- drivers-regulator-max77857-regulator.c:sparse:sparse:symbol-max77857_id-was-not-declared.-Should-it-be-static
| |-- kernel-workqueue.c:sparse:sparse:duplicate-noderef
| `-- kernel-workqueue.c:sparse:sparse:multiple-address-spaces-given:__percpu-__rcu
|-- x86_64-allnoconfig
| |-- Documentation-gpu-rfc-i915_scheduler.rst:WARNING:Unknown-directive-type-c:namespace-pop-.
| |-- Documentation-gpu-rfc-i915_scheduler.rst:WARNING:Unknown-directive-type-c:namespace-push-.
| `-- Warning:kernel-Kconfig.kexec-references-a-file-that-doesn-t-exist:file:Documentation-s390-zfcpdump.rst
|-- x86_64-allyesconfig
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| |-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
| |-- drivers-input-touchscreen-iqs7211.c-iqs7211_parse_cycles()-error:buffer-overflow-cycle_alloc
| |-- drivers-mtd-nand-raw-qcom_nandc.c-qcom_check_op()-warn:was-intended-here-instead-of
| |-- drivers-mtd-nand-raw-qcom_nandc.c-qcom_op_cmd_mapping()-error:uninitialized-symbol-ret-.
| |-- drivers-net-ethernet-mellanox-mlx5-core-lib-devcom.c-mlx5_devcom_send_event()-warn:variable-dereferenced-before-IS_ERR-check-devcom-(see-line-)
| |-- drivers-net-wireless-mediatek-mt76-mt792x_mac.c-mt792x_pm_power_save_work()-warn:can-dev-fw_assert-even-be-NULL
| |-- drivers-pwm-pwm-atmel.c-atmel_pwm_enable_clk_if_on()-warn:missing-error-code-ret
| |-- drivers-rtc-rtc-pcf2127.c-pcf2127_enable_ts()-warn:missing-error-code-ret
| `-- net-xdp-xsk.c-xsk_build_skb()-error:skb-dereferencing-possible-ERR_PTR()
|-- x86_64-buildonly-randconfig-r002-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- x86_64-buildonly-randconfig-r003-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
|-- x86_64-defconfig
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-randconfig-r032-20230816
| |-- fs-fuse-dir.c:warning:no-previous-declaration-for-fuse_valid_size
| |-- kernel-bpf-map_iter.c:warning:no-previous-declaration-for-bpf_map_sum_elem_count
| |-- net-bpf-test_run.c:warning:no-previous-declaration-for-bpf_fentry_test_sinfo
| `-- net-bpf-test_run.c:warning:no-previous-declaration-for-bpf_modify_return_test2
|-- x86_64-randconfig-x014-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-randconfig-x015-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-randconfig-x051-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-randconfig-x052-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-randconfig-x053-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-randconfig-x071-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-randconfig-x072-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-randconfig-x073-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-randconfig-x074-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-randconfig-x076-20230816
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- x86_64-rhel-8.3
| `-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
|-- xtensa-randconfig-r001-20230816
| |-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
| `-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
`-- xtensa-randconfig-r005-20230816
`-- drivers-gpu-drm-drm_gpuva_mgr.c:warning:variable-prev-set-but-not-used
clang_recent_errors
|-- arm-randconfig-r002-20230816
| |-- drivers-video-backlight-lp855x_bl.c:warning:variable-ret-is-used-uninitialized-whenever-if-condition-is-false
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- arm-randconfig-r003-20230816
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- arm-randconfig-r031-20230816
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- arm64-randconfig-r011-20230816
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- hexagon-randconfig-r041-20230816
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- hexagon-randconfig-r045-20230816
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- powerpc-pmac32_defconfig
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- riscv-randconfig-r042-20230816
| |-- drivers-gpu-drm-tests-drm_kunit_helpers.c:warning:expecting-prototype-for-drm_kunit_helper_context_alloc().-Prototype-was-for-drm_kunit_helper_acquire_ctx_alloc()-instead
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- s390-randconfig-r044-20230816
| |-- drivers-video-backlight-lp855x_bl.c:warning:variable-ret-is-used-uninitialized-whenever-if-condition-is-false
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- x86_64-randconfig-r015-20230816
| `-- drivers-spi-spi-amd.o:warning:objtool:amd_spi_host_transfer()-falls-through-to-next-function-amd_spi_max_transfer_size()
|-- x86_64-randconfig-r025-20230816
| |-- drivers-video-backlight-lp855x_bl.c:warning:variable-ret-is-used-uninitialized-whenever-if-condition-is-false
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- x86_64-randconfig-x001-20230816
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- x86_64-randconfig-x002-20230816
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- x86_64-randconfig-x003-20230816
| |-- drivers-video-backlight-lp855x_bl.c:warning:variable-ret-is-used-uninitialized-whenever-if-condition-is-false
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- x86_64-randconfig-x004-20230816
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- x86_64-randconfig-x005-20230816
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- x86_64-randconfig-x006-20230816
| `-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
|-- x86_64-randconfig-x074-20230817
| |-- drivers-media-pci-intel-ivsc-mei_csi.c:error:call-to-undeclared-function-v4l2_subdev_get_try_format-ISO-C99-and-later-do-not-support-implicit-function-declarations
| |-- drivers-media-pci-intel-ivsc-mei_csi.c:error:incompatible-integer-to-pointer-conversion-assigning-to-struct-v4l2_mbus_framefmt-from-int
| `-- drivers-media-pci-intel-ivsc-mei_csi.c:error:incompatible-integer-to-pointer-conversion-returning-int-from-a-function-with-result-type-struct-v4l2_mbus_framefmt
`-- x86_64-rhel-8.3-rust
|-- drivers-video-backlight-lp855x_bl.c:warning:variable-ret-is-used-uninitialized-whenever-if-condition-is-false
`-- lib-crypto-mpi-mpi-inv.c:warning:variable-k-set-but-not-used
elapsed time: 731m
configs tested: 140
configs skipped: 3
tested configs:
alpha allyesconfig gcc
alpha defconfig gcc
arc allyesconfig gcc
arc axs101_defconfig gcc
arc defconfig gcc
arc haps_hs_smp_defconfig gcc
arc randconfig-r005-20230816 gcc
arc randconfig-r013-20230816 gcc
arc randconfig-r043-20230816 gcc
arc tb10x_defconfig gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm am200epdkit_defconfig clang
arm assabet_defconfig gcc
arm defconfig gcc
arm imx_v4_v5_defconfig gcc
arm jornada720_defconfig gcc
arm mv78xx0_defconfig clang
arm randconfig-r002-20230816 clang
arm randconfig-r003-20230816 clang
arm randconfig-r031-20230816 clang
arm randconfig-r046-20230816 gcc
arm spear6xx_defconfig gcc
arm spitz_defconfig clang
arm tegra_defconfig gcc
arm u8500_defconfig gcc
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r006-20230816 gcc
arm64 randconfig-r011-20230816 clang
csky defconfig gcc
csky randconfig-r003-20230816 gcc
csky randconfig-r015-20230816 gcc
csky randconfig-r026-20230816 gcc
hexagon randconfig-r041-20230816 clang
hexagon randconfig-r045-20230816 clang
i386 allyesconfig gcc
i386 buildonly-randconfig-r004-20230816 gcc
i386 buildonly-randconfig-r005-20230816 gcc
i386 buildonly-randconfig-r006-20230816 gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-i001-20230816 gcc
i386 randconfig-i002-20230816 gcc
i386 randconfig-i003-20230816 gcc
i386 randconfig-i004-20230816 gcc
i386 randconfig-i005-20230816 gcc
i386 randconfig-i006-20230816 gcc
i386 randconfig-r002-20230816 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-r014-20230816 gcc
loongarch randconfig-r032-20230816 gcc
loongarch randconfig-r035-20230816 gcc
m68k allmodconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k m5407c3_defconfig gcc
m68k randconfig-r012-20230816 gcc
m68k randconfig-r034-20230816 gcc
microblaze randconfig-r022-20230816 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips decstation_defconfig gcc
mips rt305x_defconfig gcc
nios2 defconfig gcc
nios2 randconfig-r012-20230816 gcc
openrisc defconfig gcc
openrisc randconfig-r016-20230816 gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-r006-20230816 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc cm5200_defconfig gcc
powerpc currituck_defconfig gcc
powerpc eiger_defconfig gcc
powerpc pmac32_defconfig clang
powerpc randconfig-r001-20230816 gcc
powerpc randconfig-r033-20230816 gcc
powerpc tqm8548_defconfig gcc
powerpc walnut_defconfig clang
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv allyesconfig gcc
riscv defconfig gcc
riscv randconfig-r042-20230816 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r044-20230816 clang
s390 zfcpdump_defconfig gcc
sh allmodconfig gcc
sh ap325rxa_defconfig gcc
sh microdev_defconfig gcc
sh randconfig-r014-20230816 gcc
sh randconfig-r021-20230816 gcc
sh se7721_defconfig gcc
sh sh03_defconfig gcc
sparc allyesconfig gcc
sparc defconfig gcc
sparc randconfig-r004-20230816 gcc
sparc randconfig-r024-20230816 gcc
sparc sparc64_defconfig gcc
sparc64 randconfig-r036-20230816 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allyesconfig gcc
x86_64 buildonly-randconfig-r001-20230816 gcc
x86_64 buildonly-randconfig-r002-20230816 gcc
x86_64 buildonly-randconfig-r003-20230816 gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-r025-20230816 clang
x86_64 randconfig-x001-20230816 clang
x86_64 randconfig-x002-20230816 clang
x86_64 randconfig-x003-20230816 clang
x86_64 randconfig-x004-20230816 clang
x86_64 randconfig-x005-20230816 clang
x86_64 randconfig-x006-20230816 clang
x86_64 randconfig-x011-20230816 gcc
x86_64 randconfig-x012-20230816 gcc
x86_64 randconfig-x013-20230816 gcc
x86_64 randconfig-x014-20230816 gcc
x86_64 randconfig-x015-20230816 gcc
x86_64 randconfig-x016-20230816 gcc
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa common_defconfig gcc
xtensa randconfig-r001-20230816 gcc
xtensa randconfig-r004-20230816 gcc
xtensa randconfig-r005-20230816 gcc
xtensa randconfig-r015-20230816 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: touchscreen: convert neonode,zforce to json-schema
From: Conor Dooley @ 2023-08-16 17:55 UTC (permalink / raw)
To: Andreas Kemnade
Cc: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, linux-imx, rydberg,
u.kleine-koenig, linus.walleij, Jonathan.Cameron, linux-input,
devicetree, linux-kernel, linux-arm-kernel, heiko
In-Reply-To: <20230816192049.630fbf6c@aktux>
[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]
On Wed, Aug 16, 2023 at 07:20:49PM +0200, Andreas Kemnade wrote:
> On Wed, 16 Aug 2023 15:52:16 +0100
> Conor Dooley <conor@kernel.org> wrote:
>
> > On Tue, Aug 15, 2023 at 08:29:45PM +0200, Andreas Kemnade wrote:
> > > Convert Neonode infrared touchscreen controller binding to DT schema.
> > >
> > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > > ---
> > > .../input/touchscreen/neonode,zforce.yaml | 67 +++++++++++++++++++
> > > .../bindings/input/touchscreen/zforce_ts.txt | 34 ----------
> > > 2 files changed, 67 insertions(+), 34 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> > > delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> > > new file mode 100644
> > > index 000000000000..1c45adb2407a
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> > > @@ -0,0 +1,67 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/input/touchscreen/neonode,zforce.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Neonode infrared touchscreen controller
> > > +
> > > +maintainers:
> > > + - Heiko Stuebner <heiko.stuebner@bqreaders.com>
> >
> > It;d be good to CC the person you're volunteering! I've done so.
> >
> well, apparently my get_maintainer.pl | confirm_and_add_addresses | git send-email
> script did not run in the kernel checkout I applied the patch to, so it did
> not catch that address. Sorry.
> BTW: What is common practice for the maintainer address
> in the binding in conversions? Here I looked at the commits of the plaintext binding.
Yeah, that seems reasonable to me.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v10 2/2] Input: Add Novatek NT36xxx touchscreen driver
From: Konrad Dybcio @ 2023-08-16 17:36 UTC (permalink / raw)
To: Joel Selvaraj, AngeloGioacchino Del Regno, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Henrik Rydberg
Cc: Marijn Suijten, linux-input, devicetree, linux-kernel, Dang Huynh,
Amit Pundir
In-Reply-To: <2980f5e6-40b0-4ab2-ae73-bceeb97b4de5@gmail.com>
On 16.08.2023 03:09, Joel Selvaraj wrote:
> Hi Konrad Dybcio,
>
> On 8/8/23 18:38, Konrad Dybcio wrote:
>> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>
>> This is a driver for the Novatek in-cell touch controller and
>> supports various chips from the NT36xxx family, currently
>> including NT36525, NT36672A, NT36676F, NT36772 and NT36870.
>
> In kernel v6.4, a basic novatek touchscreen driver was introduced [1].
> I was able to tweak IT a bit (add devicetree compatible, regulator support, remove chip id hardcode) and get it properly working in my Xiaomi Poco F1 which has Novatek NT36672A touchscreen. Probably the other ICs will also work. So, do we really need a separate touchscreen driver? Maybe the existing one can be improved to add more features if needed?
Do you have your end outcome somewhere?
I can take a look and compare if anything's missing..
>
> Personally I have been looking forward to the v10 of this patchseries :) Thanks for working on this! But, yeah, we need to decide if we need this to be a separate driver.
We'll see, I was hoping I could add firmware loading, SPI transport and
eventually pen support..
Konrad
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: touchscreen: convert neonode,zforce to json-schema
From: Andreas Kemnade @ 2023-08-16 17:20 UTC (permalink / raw)
To: Conor Dooley
Cc: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, linux-imx, rydberg,
u.kleine-koenig, linus.walleij, Jonathan.Cameron, linux-input,
devicetree, linux-kernel, linux-arm-kernel, heiko
In-Reply-To: <20230816-customary-service-8d9c5e5dbf1b@spud>
On Wed, 16 Aug 2023 15:52:16 +0100
Conor Dooley <conor@kernel.org> wrote:
> On Tue, Aug 15, 2023 at 08:29:45PM +0200, Andreas Kemnade wrote:
> > Convert Neonode infrared touchscreen controller binding to DT schema.
> >
> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > ---
> > .../input/touchscreen/neonode,zforce.yaml | 67 +++++++++++++++++++
> > .../bindings/input/touchscreen/zforce_ts.txt | 34 ----------
> > 2 files changed, 67 insertions(+), 34 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> > delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> > new file mode 100644
> > index 000000000000..1c45adb2407a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> > @@ -0,0 +1,67 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/input/touchscreen/neonode,zforce.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Neonode infrared touchscreen controller
> > +
> > +maintainers:
> > + - Heiko Stuebner <heiko.stuebner@bqreaders.com>
>
> It;d be good to CC the person you're volunteering! I've done so.
>
well, apparently my get_maintainer.pl | confirm_and_add_addresses | git send-email
script did not run in the kernel checkout I applied the patch to, so it did
not catch that address. Sorry. BTW: What is common practice for the maintainer address
in the binding in conversions? Here I looked at the commits of the plaintext binding.
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: touchscreen: convert neonode,zforce to json-schema
From: Heiko Stübner @ 2023-08-16 17:18 UTC (permalink / raw)
To: Andreas Kemnade, Conor Dooley
Cc: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, linux-imx, rydberg,
u.kleine-koenig, linus.walleij, Jonathan.Cameron, linux-input,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20230816-customary-service-8d9c5e5dbf1b@spud>
Hi,
Am Mittwoch, 16. August 2023, 16:52:16 CEST schrieb Conor Dooley:
> On Tue, Aug 15, 2023 at 08:29:45PM +0200, Andreas Kemnade wrote:
> > Convert Neonode infrared touchscreen controller binding to DT schema.
> >
> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > ---
> > .../input/touchscreen/neonode,zforce.yaml | 67 +++++++++++++++++++
> > .../bindings/input/touchscreen/zforce_ts.txt | 34 ----------
> > 2 files changed, 67 insertions(+), 34 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> > delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> > new file mode 100644
> > index 000000000000..1c45adb2407a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> > @@ -0,0 +1,67 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/input/touchscreen/neonode,zforce.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Neonode infrared touchscreen controller
> > +
> > +maintainers:
> > + - Heiko Stuebner <heiko.stuebner@bqreaders.com>
>
> It;d be good to CC the person you're volunteering! I've done so.
BQ the company is no more. So I have no issue with me being in there,
afterall I did that driver back then, but I guess my main and permanent
address of heiko@sntech.de might be more appropriate :-)
Heiko
> > +
> > +properties:
> > + compatible:
> > + const: neonode,zforce
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + reset-gpios:
> > + maxItems: 1
> > +
> > + irq-gpios:
> > + maxItems: 1
> > +
> > + x-size:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > + y-size:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > + vdd-supply: true
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - reset-gpios
> > + - x-size
> > + - y-size
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > +
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + touchscreen@50 {
> > + compatible = "neonode,zforce";
> > + reg = <0x50>;
> > + interrupts = <2 0>;
> > + vdd-supply = <®_zforce_vdd>;
> > +
> > + reset-gpios = <&gpio5 9 0>; /* RST */
> > + irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
> > +
> > + x-size = <800>;
> > + y-size = <600>;
> > + };
> > + };
> > +...
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
> > deleted file mode 100644
> > index e3c27c4fd9c8..000000000000
> > --- a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
> > +++ /dev/null
> > @@ -1,34 +0,0 @@
> > -* Neonode infrared touchscreen controller
> > -
> > -Required properties:
> > -- compatible: must be "neonode,zforce"
> > -- reg: I2C address of the chip
> > -- interrupts: interrupt to which the chip is connected
> > -- reset-gpios: reset gpio the chip is connected to
> > -- x-size: horizontal resolution of touchscreen
> > -- y-size: vertical resolution of touchscreen
> > -
> > -Optional properties:
> > -- irq-gpios : interrupt gpio the chip is connected to
> > -- vdd-supply: Regulator controlling the controller supply
> > -
> > -Example:
> > -
> > - i2c@00000000 {
> > - /* ... */
> > -
> > - zforce_ts@50 {
> > - compatible = "neonode,zforce";
> > - reg = <0x50>;
> > - interrupts = <2 0>;
> > - vdd-supply = <®_zforce_vdd>;
> > -
> > - reset-gpios = <&gpio5 9 0>; /* RST */
> > - irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
> > -
> > - x-size = <800>;
> > - y-size = <600>;
> > - };
> > -
> > - /* ... */
> > - };
>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: touchscreen: convert neonode,zforce to json-schema
From: Conor Dooley @ 2023-08-16 14:52 UTC (permalink / raw)
To: Andreas Kemnade
Cc: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, linux-imx, rydberg,
u.kleine-koenig, linus.walleij, Jonathan.Cameron, linux-input,
devicetree, linux-kernel, linux-arm-kernel, heiko
In-Reply-To: <20230815182948.212575-2-andreas@kemnade.info>
[-- Attachment #1: Type: text/plain, Size: 3774 bytes --]
On Tue, Aug 15, 2023 at 08:29:45PM +0200, Andreas Kemnade wrote:
> Convert Neonode infrared touchscreen controller binding to DT schema.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
> .../input/touchscreen/neonode,zforce.yaml | 67 +++++++++++++++++++
> .../bindings/input/touchscreen/zforce_ts.txt | 34 ----------
> 2 files changed, 67 insertions(+), 34 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> new file mode 100644
> index 000000000000..1c45adb2407a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
> @@ -0,0 +1,67 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/touchscreen/neonode,zforce.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Neonode infrared touchscreen controller
> +
> +maintainers:
> + - Heiko Stuebner <heiko.stuebner@bqreaders.com>
It;d be good to CC the person you're volunteering! I've done so.
> +
> +properties:
> + compatible:
> + const: neonode,zforce
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> +
> + irq-gpios:
> + maxItems: 1
> +
> + x-size:
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + y-size:
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + vdd-supply: true
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - reset-gpios
> + - x-size
> + - y-size
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + touchscreen@50 {
> + compatible = "neonode,zforce";
> + reg = <0x50>;
> + interrupts = <2 0>;
> + vdd-supply = <®_zforce_vdd>;
> +
> + reset-gpios = <&gpio5 9 0>; /* RST */
> + irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
> +
> + x-size = <800>;
> + y-size = <600>;
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
> deleted file mode 100644
> index e3c27c4fd9c8..000000000000
> --- a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -* Neonode infrared touchscreen controller
> -
> -Required properties:
> -- compatible: must be "neonode,zforce"
> -- reg: I2C address of the chip
> -- interrupts: interrupt to which the chip is connected
> -- reset-gpios: reset gpio the chip is connected to
> -- x-size: horizontal resolution of touchscreen
> -- y-size: vertical resolution of touchscreen
> -
> -Optional properties:
> -- irq-gpios : interrupt gpio the chip is connected to
> -- vdd-supply: Regulator controlling the controller supply
> -
> -Example:
> -
> - i2c@00000000 {
> - /* ... */
> -
> - zforce_ts@50 {
> - compatible = "neonode,zforce";
> - reg = <0x50>;
> - interrupts = <2 0>;
> - vdd-supply = <®_zforce_vdd>;
> -
> - reset-gpios = <&gpio5 9 0>; /* RST */
> - irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
> -
> - x-size = <800>;
> - y-size = <600>;
> - };
> -
> - /* ... */
> - };
> --
> 2.39.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] HID: apple: Add "Hailuck" to the list of non-apple keyboards
From: Jiri Kosina @ 2023-08-16 13:21 UTC (permalink / raw)
To: Nils Tonnaett
Cc: Benjamin Tissoires, linux-input, linux-kernel, Rahul Rameshbabu
In-Reply-To: <20230815201959.17569-1-ntonnatt@ccrma.stanford.edu>
On Tue, 15 Aug 2023, Nils Tonnaett wrote:
> Powzan keyboards KB750 and KB770 identify as
> "Hailuck Co.,Ltd USB Keyboard". Adding "Hailuck" to the list
> of non-apple keyboards fixes function keys for these models.
>
> Signed-off-by: Nils Tonnaett <ntonnatt@ccrma.stanford.edu>
> ---
> V1 -> V2:
> - Start commit message subject with HID: apple: instead of hid:
> - Comma terminate last member of array
>
> drivers/hid/hid-apple.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> index d7b932925730..3ca45975c686 100644
> --- a/drivers/hid/hid-apple.c
> +++ b/drivers/hid/hid-apple.c
> @@ -343,7 +343,8 @@ static const struct apple_non_apple_keyboard non_apple_keyboards[] = {
> { "SONiX USB DEVICE" },
> { "Keychron" },
> { "AONE" },
> - { "GANSS" }
> + { "GANSS" },
> + { "Hailuck" },
> };
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* RE: [HID Patchsets v1 2/2] HID: Removed USB Validation check
From: sandeep.cs @ 2023-08-16 9:46 UTC (permalink / raw)
To: 'Benjamin Tissoires'
Cc: 'Jiri Kosina', 'Benjamin Tissoires', junwan.cho,
jitender.s21, suhyun_.kim, ih0923.kim, gaudium.lee, linux-input,
linux-kernel
In-Reply-To: <np2hnhy7jcc66rsfwym42qwteqda6slszinrjqb6jg7ie4qt3e@2fllxsza544p>
Hi Benjamin,
I hope this email finds you well.
I wanted to remind you about our last email where we discussed about moving
USB validation check.
Your thoughts and input are important to us.
Please guide!
Thanks & regards
Sandeep C S
-----Original Message-----
From: sandeep.cs <sandeep.cs@samsung.com>
Sent: 31 July 2023 16:44
To: 'Benjamin Tissoires' <bentiss@kernel.org>
Cc: 'Jiri Kosina' <jikos@kernel.org>; 'Benjamin Tissoires'
<benjamin.tissoires@redhat.com>; 'junwan.cho@samsung.com'
<junwan.cho@samsung.com>; 'jitender.s21@samsung.com'
<jitender.s21@samsung.com>; 'suhyun_.kim@samsung.com'
<suhyun_.kim@samsung.com>; 'ih0923.kim@samsung.com'
<ih0923.kim@samsung.com>; 'gaudium.lee@samsung.com'
<gaudium.lee@samsung.com>; 'linux-input@vger.kernel.org'
<linux-input@vger.kernel.org>; 'linux-kernel@vger.kernel.org'
<linux-kernel@vger.kernel.org>
Subject: RE: [HID Patchsets v1 2/2] HID: Removed USB Validation check
Hi Benjamin,
Thanks for the quick review our changes
As suggested we will refactor as below and send you an update shortly.
1. USB check validation moving to appropriate function
(samsung_kbd_mouse_input_mapping())
2. fix the checkpatch complain
3+ Split the remaining changes one per device
Clarifying for the Point 1 , below is the pseudocode:
static int samsung_kbd_mouse_input_mapping(struct hid_device *hdev,
struct hid_input *hi, struct hid_field *field, struct hid_usage *usage,
unsigned long **bit, int *max)
{
+ if (!hid_is_usb(hdev))
+ return 0;
...
}
Thanks & Regards
Sandeep C S
-----Original Message-----
From: Benjamin Tissoires <bentiss@kernel.org>
Sent: 24 July 2023 15:40
To: sandeep.cs <sandeep.cs@samsung.com>
Cc: Jiri Kosina <jikos@kernel.org>; Benjamin Tissoires
<benjamin.tissoires@redhat.com>; junwan.cho@samsung.com;
jitender.s21@samsung.com; suhyun_.kim@samsung.com; ih0923.kim@samsung.com;
gaudium.lee@samsung.com; linux-input@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [HID Patchsets v1 2/2] HID: Removed USB Validation check
Hi Sandeep,
On Jul 24 2023, sandeep.cs wrote:
> Earlier Samsung driver only handles USB HID devices and returns an error
if it encounters a Bluetooth type of HID device.
> By removing this USB validation check, we allow the driver to handle other
types of HID devices including Bluetooth HID devices, which were previously
excluded.
Please no, not with that patch at least.
hid_is_usb() protects the kernel from making an oops if the actual transport
layer is not USB, let's say an emulated uhid device. So by removing that
check you are just allowing anybody with root access to access random memory
in the kernel.
The correct fix is to move the check where it's needed, in
samsung_kbd_mouse_input_mapping().
I'll let you decide what need should be done if it's not a USB device
there: consider the interface to be 0 or just abort the function.
Cheers,
Benjamin
>
> This change improves driver compatibility and extends its support for a
wide range of devices.
>
> Signed-off-by: Sandeep C S<sandeep.cs@samsung.com>
> Signed-off-by: Junwan Cho <junwan.cho@samsung.com>
> Signed-off-by: Jitender Sajwan <jitender.s21@samsung.com>
> ---
> drivers/hid/hid-samsung.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/hid/hid-samsung.c b/drivers/hid/hid-samsung.c
> index 33e963303d11..3cafbf4d9dc6 100644
> --- a/drivers/hid/hid-samsung.c
> +++ b/drivers/hid/hid-samsung.c
> @@ -517,9 +517,6 @@ static int samsung_probe(struct hid_device *hdev,
> int ret;
> unsigned int cmask = HID_CONNECT_DEFAULT;
>
> - if (!hid_is_usb(hdev))
> - return -EINVAL;
> -
> ret = hid_parse(hdev);
> if (ret) {
> hid_err(hdev, "parse failed\n");
> --
> 2.25.1
>
^ permalink raw reply
* [PATCH v2] HID: i2c-hid: use print_hex_dump_debug to print report descriptor
From: Riwen Lu @ 2023-08-16 8:38 UTC (permalink / raw)
To: jikos, benjamin.tissoires, dmitry.torokhov, linux, hdegoede,
rrangel, u.kleine-koenig
Cc: linux-input, linux-kernel, sergeantsagara, Riwen Lu
In-Reply-To: <TYCP286MB2607175E9C15DB17A2102AEAB114A@TYCP286MB2607.JPNP286.PROD.OUTLOOK.COM>
From: Riwen Lu <luriwen@kylinos.cn>
The format '%*ph' print up to 64 bytes long as a hex string with ' '
sepatator. Usually the size of report descriptor is larger than 64
bytes, so consider using print_hex_dump_debug to print out all of it for
better debugging.
Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
---
v1->v2:
- Add a prefix for the hex dump.
---
drivers/hid/i2c-hid/i2c-hid-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index efbba0465eef..fd82e9042da5 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -772,7 +772,9 @@ static int i2c_hid_parse(struct hid_device *hid)
}
}
- i2c_hid_dbg(ihid, "Report Descriptor: %*ph\n", rsize, rdesc);
+ i2c_hid_dbg(ihid, "Report Descriptor\n");
+ print_hex_dump_debug("Report Descriptor: ", DUMP_PREFIX_OFFSET, 16, 1,
+ rdesc, rsize, false);
ret = hid_parse_report(hid, rdesc, rsize);
if (!use_override)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] Input: cs40l50 - Initial support for Cirrus Logic CS40L50
From: Charles Keepax @ 2023-08-16 8:11 UTC (permalink / raw)
To: James Ogletree
Cc: Dmitry Torokhov, Fred Treven, Ben Bright, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Jeff LaBundy,
Joel Stanley, Arnd Bergmann, Jacky Bai, Jean Delvare, Eddie James,
Markus Schneider-Pargmann, ChiYuan Huang, Randy Dunlap,
Wolfram Sang, patches@opensource.cirrus.com,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <51826BD7-BB75-4D1F-B947-A7AC2C642F62@cirrus.com>
On Tue, Aug 15, 2023 at 10:33:00PM +0000, James Ogletree wrote:
>
>
> > On Aug 10, 2023, at 5:30 AM, Charles Keepax <ckeepax@opensource.cirrus.com> wrote:
> >
> > On Wed, Aug 09, 2023 at 07:10:28PM +0000, James Ogletree wrote:
> >> +
> >> +static int cs40l50_pseq_write(struct cs40l50_private *cs40l50, u32 addr, u32 data)
> >> +{
> >> +
> >> +static int cs40l50_owt_upload(struct cs40l50_private *cs40l50, s16 *in_data, u32 in_data_nibbles)
> >> +{
> >
> > These pseq and OWT bits, could they be shared with l26?
> > Definitely worth syncing with those guys, my assumption is the
> > wavetable/pseq won't have changed much and it might be nice to
> > factor these bits out into some library code that both drivers
> > can use.
>
> The pseq code most certainly can, likely the OWT code, perhaps others. I assume it is
> acceptable to move some of these functions to a library in this patch set, even though this is
> the only driver utilizing them as far as mainline is concerned? In other words, we shouldn’t
> wait for one of L26 or L50 drivers to be accepted before splitting off the common code as part
> of the others’ patchset? I’m probably overcomplicating; just want to be sure on the process here.
>
> Everything else in your review will be fixed in V4. Thank you.
>
I think this makes sense to do now, just need to make sure the
next series of L26 is synced up to it.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v2] HID: apple: Add "Hailuck" to the list of non-apple keyboards
From: Rahul Rameshbabu @ 2023-08-16 2:23 UTC (permalink / raw)
To: Nils Tonnaett; +Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20230815201959.17569-1-ntonnatt@ccrma.stanford.edu>
On Tue, 15 Aug, 2023 13:19:59 -0700 "Nils Tonnaett" <ntonnatt@ccrma.Stanford.EDU> wrote:
> Powzan keyboards KB750 and KB770 identify as
> "Hailuck Co.,Ltd USB Keyboard". Adding "Hailuck" to the list
> of non-apple keyboards fixes function keys for these models.
>
> Signed-off-by: Nils Tonnaett <ntonnatt@ccrma.stanford.edu>
> ---
> V1 -> V2:
> - Start commit message subject with HID: apple: instead of hid:
> - Comma terminate last member of array
>
> drivers/hid/hid-apple.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> index d7b932925730..3ca45975c686 100644
> --- a/drivers/hid/hid-apple.c
> +++ b/drivers/hid/hid-apple.c
> @@ -343,7 +343,8 @@ static const struct apple_non_apple_keyboard non_apple_keyboards[] = {
> { "SONiX USB DEVICE" },
> { "Keychron" },
> { "AONE" },
> - { "GANSS" }
> + { "GANSS" },
> + { "Hailuck" },
> };
>
> static bool apple_is_non_apple_keyboard(struct hid_device *hdev)
Reviewed-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
^ permalink raw reply
* Re: [PATCH v10 2/2] Input: Add Novatek NT36xxx touchscreen driver
From: Joel Selvaraj @ 2023-08-16 1:09 UTC (permalink / raw)
To: Konrad Dybcio, AngeloGioacchino Del Regno, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Henrik Rydberg
Cc: Marijn Suijten, linux-input, devicetree, linux-kernel, Dang Huynh,
Amit Pundir
In-Reply-To: <20230808-topic-nt36xxx-v10-2-dd135dfa0b5e@linaro.org>
Hi Konrad Dybcio,
On 8/8/23 18:38, Konrad Dybcio wrote:
> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> This is a driver for the Novatek in-cell touch controller and
> supports various chips from the NT36xxx family, currently
> including NT36525, NT36672A, NT36676F, NT36772 and NT36870.
In kernel v6.4, a basic novatek touchscreen driver was introduced [1].
I was able to tweak IT a bit (add devicetree compatible, regulator
support, remove chip id hardcode) and get it properly working in my
Xiaomi Poco F1 which has Novatek NT36672A touchscreen. Probably the
other ICs will also work. So, do we really need a separate touchscreen
driver? Maybe the existing one can be improved to add more features if
needed?
Personally I have been looking forward to the v10 of this patchseries :)
Thanks for working on this! But, yeah, we need to decide if we need this
to be a separate driver.
Link:
https://lore.kernel.org/all/20230326212308.55730-1-hdegoede@redhat.com/
Regards
Joel Selvaraj
^ 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