* Re: [PATCH v2 0/2] Add support for Azoteq IQS7210A/7211A/E
From: Jeff LaBundy @ 2023-07-12 21:26 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt; +Cc: linux-input, devicetree
In-Reply-To: <ZHVD/9OgRTAwBhqx@nixie71>
Hi Dmitry,
On Mon, May 29, 2023 at 07:31:59PM -0500, Jeff LaBundy wrote:
> This series introduces support for the Azoteq IQS7210A, IQS7211A and
> IQS7211E trackpad/touchscreen controllers. Optimized for wearable
> applications, these devices track up to two contacts and are capable
> of reporting an array of gestures.
>
> The IQS7210A includes an additional channel to support an inductive
> or capacitive button, while the IQS7211E adds an advanced assortment
> of gestures. All three devices are demonstrated in [1].
>
> These devices can be configured during production using OTP memory,
> or over I2C using the device tree. For the latter case, the binding
> covers all major parameters called out by the vendor in [2].
>
> [1] https://youtu.be/RjB8rNkzQJQ
> [2] https://www.azoteq.com/images/stories/pdf/azd123_iqs721xy_trackpad_userguide.pdf
>
> Jeff LaBundy (2):
> dt-bindings: input: Add bindings for Azoteq IQS7210A/7211A/E
> Input: add support for Azoteq IQS7210A/7211A/E
>
> .../input/touchscreen/azoteq,iqs7211.yaml | 769 +++++
> drivers/input/touchscreen/Kconfig | 10 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/iqs7211.c | 2569 +++++++++++++++++
> 4 files changed, 3349 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml
> create mode 100644 drivers/input/touchscreen/iqs7211.c
>
> --
> 2.34.1
>
Just bumping this one; any interest in taking it?
Kind regards,
Jeff LaBundy
^ permalink raw reply
* Re: [PATCH] Input: rotary_encoder - don't double assign input->dev.parent
From: Dmitry Torokhov @ 2023-07-12 21:11 UTC (permalink / raw)
To: Roi L; +Cc: linux-input
In-Reply-To: <PH0P220MB0460B69CA018F5515F5FACDDDD53A@PH0P220MB0460.NAMP220.PROD.OUTLOOK.COM>
On Wed, Jun 07, 2023 at 12:10:40PM +0300, Roi L wrote:
> devm_input_allocate_device() already assigns the @dev.parent field of the
> input device/structure, so there's no need to reassign input->dev.parent
> to dev.
>
> Signed-off-by: Roi L <roeilev321_@outlook.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: i8042 - add quirk for TUXEDO Gemini 17 Gen1/Clevo PD70PN
From: Dmitry Torokhov @ 2023-07-12 21:05 UTC (permalink / raw)
To: Werner Sembach; +Cc: linux-input, linux-kernel
In-Reply-To: <20230607173331.851192-1-wse@tuxedocomputers.com>
On Wed, Jun 07, 2023 at 07:33:31PM +0200, Werner Sembach wrote:
> The touchpad of this device is both connected via PS/2 and i2c. This causes
> strange behavior when both driver fight for control. The easy fix is to
> prevent the PS/2 driver from accessing the mouse port as the full feature
> set of the touchpad is only supported in the i2c interface anyway.
>
> The strange behavior in this case is, that when an external screen is
> connected and the notebook is closed, the pointer on the external screen is
> moving to the lower right corner. When the notebook is opened again, this
> movement stops, but the touchpad clicks are unresponsive afterwards until
> reboot.
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Cc: stable@vger.kernel.org
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: bcm-keypad - Correct dev_err_probe() error
From: Dmitry Torokhov @ 2023-07-12 18:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Hans de Goede, Andy Shevchenko, linux-input, linux-kernel,
kernel test robot, Dan Carpenter
In-Reply-To: <20230711072449.43569-1-krzysztof.kozlowski@linaro.org>
On Tue, Jul 11, 2023 at 09:24:49AM +0200, Krzysztof Kozlowski wrote:
> Pass proper PTR_ERR as dev_err_probe() argument.
>
> Fixes: a2c795b696b2 ("Input: bcm-keypad - simplify with dev_err_probe()")
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Closes: https://lore.kernel.org/r/202306261505.wTjCXRIO-lkp@intel.com/
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH v2] HID: logitech-hidpp: rework one more time the retries attempts
From: bentiss @ 2023-07-12 15:02 UTC (permalink / raw)
To: Filipe Laíns, Bastien Nocera, Jiri Kosina, Greg KH
Cc: linux-input, linux-kernel, Benjamin Tissoires, stable
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Extract the internal code inside a helper function, fix the
initialization of the parameters used in the helper function
(`hidpp->answer_available` was not reset and `*response` wasn't either),
and use a `do {...} while();` loop.
Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy")
Cc: stable@vger.kernel.org
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
as requested by https://lore.kernel.org/all/CAHk-=wiMbF38KCNhPFiargenpSBoecSXTLQACKS2UMyo_Vu2ww@mail.gmail.com/
This is a rewrite of that particular piece of code.
---
Changes in v2:
- added __must_hold() for KASAN
- Reworked the comment describing the functions and their return values
- Link to v1: https://lore.kernel.org/r/20230621-logitech-fixes-v1-1-32e70933c0b0@redhat.com
---
drivers/hid/hid-logitech-hidpp.c | 115 +++++++++++++++++++++++++--------------
1 file changed, 75 insertions(+), 40 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 129b01be488d..09ba2086c95c 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -275,21 +275,22 @@ static int __hidpp_send_report(struct hid_device *hdev,
}
/*
- * hidpp_send_message_sync() returns 0 in case of success, and something else
- * in case of a failure.
- * - If ' something else' is positive, that means that an error has been raised
- * by the protocol itself.
- * - If ' something else' is negative, that means that we had a classic error
- * (-ENOMEM, -EPIPE, etc...)
+ * Effectively send the message to the device, waiting for its answer.
+ *
+ * Must be called with hidpp->send_mutex locked
+ *
+ * Same return protocol than hidpp_send_message_sync():
+ * - success on 0
+ * - negative error means transport error
+ * - positive value means protocol error
*/
-static int hidpp_send_message_sync(struct hidpp_device *hidpp,
+static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
struct hidpp_report *message,
struct hidpp_report *response)
{
- int ret = -1;
- int max_retries = 3;
+ int ret;
- mutex_lock(&hidpp->send_mutex);
+ __must_hold(&hidpp->send_mutex);
hidpp->send_receive_buf = response;
hidpp->answer_available = false;
@@ -300,47 +301,74 @@ static int hidpp_send_message_sync(struct hidpp_device *hidpp,
*/
*response = *message;
- for (; max_retries != 0 && ret; max_retries--) {
- ret = __hidpp_send_report(hidpp->hid_dev, message);
+ ret = __hidpp_send_report(hidpp->hid_dev, message);
+ if (ret) {
+ dbg_hid("__hidpp_send_report returned err: %d\n", ret);
+ memset(response, 0, sizeof(struct hidpp_report));
+ return ret;
+ }
- if (ret) {
- dbg_hid("__hidpp_send_report returned err: %d\n", ret);
- memset(response, 0, sizeof(struct hidpp_report));
- break;
- }
+ if (!wait_event_timeout(hidpp->wait, hidpp->answer_available,
+ 5*HZ)) {
+ dbg_hid("%s:timeout waiting for response\n", __func__);
+ memset(response, 0, sizeof(struct hidpp_report));
+ return -ETIMEDOUT;
+ }
- if (!wait_event_timeout(hidpp->wait, hidpp->answer_available,
- 5*HZ)) {
- dbg_hid("%s:timeout waiting for response\n", __func__);
- memset(response, 0, sizeof(struct hidpp_report));
- ret = -ETIMEDOUT;
- break;
- }
+ if (response->report_id == REPORT_ID_HIDPP_SHORT &&
+ response->rap.sub_id == HIDPP_ERROR) {
+ ret = response->rap.params[1];
+ dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
+ return ret;
+ }
- if (response->report_id == REPORT_ID_HIDPP_SHORT &&
- response->rap.sub_id == HIDPP_ERROR) {
- ret = response->rap.params[1];
- dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
+ if ((response->report_id == REPORT_ID_HIDPP_LONG ||
+ response->report_id == REPORT_ID_HIDPP_VERY_LONG) &&
+ response->fap.feature_index == HIDPP20_ERROR) {
+ ret = response->fap.params[1];
+ dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * hidpp_send_message_sync() returns 0 in case of success, and something else
+ * in case of a failure.
+ *
+ * See __do_hidpp_send_message_sync() for a detailed explanation of the returned
+ * value.
+ */
+static int hidpp_send_message_sync(struct hidpp_device *hidpp,
+ struct hidpp_report *message,
+ struct hidpp_report *response)
+{
+ int ret;
+ int max_retries = 3;
+
+ mutex_lock(&hidpp->send_mutex);
+
+ do {
+ ret = __do_hidpp_send_message_sync(hidpp, message, response);
+ if (ret != HIDPP20_ERROR_BUSY)
break;
- }
- if ((response->report_id == REPORT_ID_HIDPP_LONG ||
- response->report_id == REPORT_ID_HIDPP_VERY_LONG) &&
- response->fap.feature_index == HIDPP20_ERROR) {
- ret = response->fap.params[1];
- if (ret != HIDPP20_ERROR_BUSY) {
- dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
- break;
- }
- dbg_hid("%s:got busy hidpp 2.0 error %02X, retrying\n", __func__, ret);
- }
- }
+ dbg_hid("%s:got busy hidpp 2.0 error %02X, retrying\n", __func__, ret);
+ } while (--max_retries);
mutex_unlock(&hidpp->send_mutex);
return ret;
}
+/*
+ * hidpp_send_fap_command_sync() returns 0 in case of success, and something else
+ * in case of a failure.
+ *
+ * See __do_hidpp_send_message_sync() for a detailed explanation of the returned
+ * value.
+ */
static int hidpp_send_fap_command_sync(struct hidpp_device *hidpp,
u8 feat_index, u8 funcindex_clientid, u8 *params, int param_count,
struct hidpp_report *response)
@@ -373,6 +401,13 @@ static int hidpp_send_fap_command_sync(struct hidpp_device *hidpp,
return ret;
}
+/*
+ * hidpp_send_rap_command_sync() returns 0 in case of success, and something else
+ * in case of a failure.
+ *
+ * See __do_hidpp_send_message_sync() for a detailed explanation of the returned
+ * value.
+ */
static int hidpp_send_rap_command_sync(struct hidpp_device *hidpp_dev,
u8 report_id, u8 sub_id, u8 reg_address, u8 *params, int param_count,
struct hidpp_report *response)
---
base-commit: 87854366176403438d01f368b09de3ec2234e0f5
change-id: 20230621-logitech-fixes-a4c0e66ea2ad
Best regards,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply related
* [PATCH] HID: nintendo: cleanup LED code
From: Martino Fontana @ 2023-07-12 12:13 UTC (permalink / raw)
To: linux-input; +Cc: Martino Fontana
- Only turn on the nth LED, instead of all the LEDs up to n. This better matches Nintendo consoles' behaviour, as they never turn on more than one LED (still not a complete match, see https://bugzilla.kernel.org/show_bug.cgi?id=216225)
- Split part of `joycon_home_led_brightness_set` (which is called by hid) into `joycon_set_home_led` (which is what actually sets the LEDs), for consistency with player LEDs
- Instead of first registering the `led_classdev`, then attempting to set the LED and unregistering the `led_classdev` if it fails, first attempt to set the LED, then register the `led_classdev` only if it succeeds (the class is still filled up in either case)
- If setting player LEDs fails, still attempt setting the home LED (I don't know if this is actually possible, but who knows...)
- Use `JC_NUM_LEDS` when appropriate instead of 4
- Print return codes
Signed-off-by: Martino Fontana <tinozzo123@gmail.com>
---
drivers/hid/hid-nintendo.c | 116 ++++++++++++++++++-------------------
1 file changed, 55 insertions(+), 61 deletions(-)
diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index 586c7f8d7..89631e19b 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -699,6 +699,25 @@ static int joycon_set_player_leds(struct joycon_ctlr *ctlr, u8 flash, u8 on)
return joycon_send_subcmd(ctlr, req, 1, HZ/4);
}
+static int joycon_set_home_led(struct joycon_ctlr *ctlr, enum led_brightness brightness)
+{
+ struct joycon_subcmd_request *req;
+ u8 buffer[sizeof(*req) + 5] = { 0 };
+ u8 *data;
+
+ req = (struct joycon_subcmd_request *)buffer;
+ req->subcmd_id = JC_SUBCMD_SET_HOME_LIGHT;
+ data = req->data;
+ data[0] = 0x01;
+ data[1] = brightness << 4;
+ data[2] = brightness | (brightness << 4);
+ data[3] = 0x11;
+ data[4] = 0x11;
+
+ hid_dbg(ctlr->hdev, "setting home led brightness\n");
+ return joycon_send_subcmd(ctlr, req, 5, HZ/4);
+}
+
static int joycon_request_spi_flash_read(struct joycon_ctlr *ctlr,
u32 start_addr, u8 size, u8 **reply)
{
@@ -1849,7 +1868,6 @@ static int joycon_player_led_brightness_set(struct led_classdev *led,
int val = 0;
int i;
int ret;
- int num;
ctlr = hid_get_drvdata(hdev);
if (!ctlr) {
@@ -1857,21 +1875,10 @@ static int joycon_player_led_brightness_set(struct led_classdev *led,
return -ENODEV;
}
- /* determine which player led this is */
- for (num = 0; num < JC_NUM_LEDS; num++) {
- if (&ctlr->leds[num] == led)
- break;
- }
- if (num >= JC_NUM_LEDS)
- return -EINVAL;
+ for (i = 0; i < JC_NUM_LEDS; i++)
+ val |= ctlr->leds[i].brightness << i;
mutex_lock(&ctlr->output_mutex);
- for (i = 0; i < JC_NUM_LEDS; i++) {
- if (i == num)
- val |= brightness << i;
- else
- val |= ctlr->leds[i].brightness << i;
- }
ret = joycon_set_player_leds(ctlr, 0, val);
mutex_unlock(&ctlr->output_mutex);
@@ -1884,9 +1891,6 @@ static int joycon_home_led_brightness_set(struct led_classdev *led,
struct device *dev = led->dev->parent;
struct hid_device *hdev = to_hid_device(dev);
struct joycon_ctlr *ctlr;
- struct joycon_subcmd_request *req;
- u8 buffer[sizeof(*req) + 5] = { 0 };
- u8 *data;
int ret;
ctlr = hid_get_drvdata(hdev);
@@ -1894,25 +1898,13 @@ static int joycon_home_led_brightness_set(struct led_classdev *led,
hid_err(hdev, "No controller data\n");
return -ENODEV;
}
-
- req = (struct joycon_subcmd_request *)buffer;
- req->subcmd_id = JC_SUBCMD_SET_HOME_LIGHT;
- data = req->data;
- data[0] = 0x01;
- data[1] = brightness << 4;
- data[2] = brightness | (brightness << 4);
- data[3] = 0x11;
- data[4] = 0x11;
-
- hid_dbg(hdev, "setting home led brightness\n");
mutex_lock(&ctlr->output_mutex);
- ret = joycon_send_subcmd(ctlr, req, 5, HZ/4);
+ ret = joycon_set_home_led(ctlr, brightness);
mutex_unlock(&ctlr->output_mutex);
-
return ret;
}
-static DEFINE_MUTEX(joycon_input_num_mutex);
+static DEFINE_SPINLOCK(joycon_input_num_spinlock);
static int joycon_leds_create(struct joycon_ctlr *ctlr)
{
struct hid_device *hdev = ctlr->hdev;
@@ -1920,17 +1912,16 @@ static int joycon_leds_create(struct joycon_ctlr *ctlr)
const char *d_name = dev_name(dev);
struct led_classdev *led;
char *name;
- int ret = 0;
+ int ret;
int i;
- static int input_num = 1;
+ unsigned long flags;
+ int player_led_number;
+ static int input_num;
- /* Set the default controller player leds based on controller number */
- mutex_lock(&joycon_input_num_mutex);
- mutex_lock(&ctlr->output_mutex);
- ret = joycon_set_player_leds(ctlr, 0, 0xF >> (4 - input_num));
- if (ret)
- hid_warn(ctlr->hdev, "Failed to set leds; ret=%d\n", ret);
- mutex_unlock(&ctlr->output_mutex);
+ /* Set the player leds based on controller number */
+ spin_lock_irqsave(&joycon_input_num_spinlock, flags);
+ player_led_number = input_num++ % JC_NUM_LEDS;
+ spin_unlock_irqrestore(&joycon_input_num_spinlock, flags);
/* configure the player LEDs */
for (i = 0; i < JC_NUM_LEDS; i++) {
@@ -1938,31 +1929,33 @@ static int joycon_leds_create(struct joycon_ctlr *ctlr)
d_name,
"green",
joycon_player_led_names[i]);
- if (!name) {
- mutex_unlock(&joycon_input_num_mutex);
+ if (!name)
return -ENOMEM;
- }
led = &ctlr->leds[i];
led->name = name;
- led->brightness = ((i + 1) <= input_num) ? 1 : 0;
+ led->brightness = (i == player_led_number) ? 1 : 0;
led->max_brightness = 1;
led->brightness_set_blocking =
joycon_player_led_brightness_set;
led->flags = LED_CORE_SUSPENDRESUME | LED_HW_PLUGGABLE;
+ }
+ mutex_lock(&ctlr->output_mutex);
+ ret = joycon_set_player_leds(ctlr, 0, 0x1 << player_led_number);
+ mutex_unlock(&ctlr->output_mutex);
+ if (ret) {
+ hid_warn(hdev, "Failed to set players LEDs; ret=%d\n", ret);
+ goto home_led;
+ }
+ for (i = 0; i < JC_NUM_LEDS; i++) {
+ led = &ctlr->leds[i];
ret = devm_led_classdev_register(&hdev->dev, led);
- if (ret) {
- hid_err(hdev, "Failed registering %s LED\n", led->name);
- mutex_unlock(&joycon_input_num_mutex);
- return ret;
- }
+ if (ret)
+ hid_err(hdev, "Failed registering %s LED; ret=%d\n", led->name, ret);
}
- if (++input_num > 4)
- input_num = 1;
- mutex_unlock(&joycon_input_num_mutex);
-
+home_led:
/* configure the home LED */
if (jc_type_has_right(ctlr)) {
name = devm_kasprintf(dev, GFP_KERNEL, "%s:%s:%s",
@@ -1978,17 +1971,18 @@ static int joycon_leds_create(struct joycon_ctlr *ctlr)
led->max_brightness = 0xF;
led->brightness_set_blocking = joycon_home_led_brightness_set;
led->flags = LED_CORE_SUSPENDRESUME | LED_HW_PLUGGABLE;
- ret = devm_led_classdev_register(&hdev->dev, led);
- if (ret) {
- hid_err(hdev, "Failed registering home led\n");
- return ret;
- }
+
/* Set the home LED to 0 as default state */
- ret = joycon_home_led_brightness_set(led, 0);
+ mutex_lock(&ctlr->output_mutex);
+ ret = joycon_set_home_led(ctlr, 0);
+ mutex_unlock(&ctlr->output_mutex);
if (ret) {
- hid_warn(hdev, "Failed to set home LED default, unregistering home LED");
- devm_led_classdev_unregister(&hdev->dev, led);
+ hid_warn(hdev, "Failed to set home LED; ret=%d\n", ret);
+ return 0;
}
+ ret = devm_led_classdev_register(&hdev->dev, led);
+ if (ret)
+ hid_err(hdev, "Failed registering home led; ret=%d\n", ret);
}
return 0;
--
2.41.0
^ permalink raw reply related
* [PATCH] HID: nintendo: reinitialize USB Pro Controller after resuming from suspend
From: Martino Fontana @ 2023-07-12 12:10 UTC (permalink / raw)
To: linux-input; +Cc: Martino Fontana
When suspending the computer, a Switch Pro Controller connected via USB will lose its internal status.
However, because the USB connection was technically never lost, when resuming the computer, the driver will attempt to communicate with the controller as if nothing happened (and fail).
Because of this, the user was forced to manually disconnect the controller (or to press the sync button on the controller to power it off), so that it can be re-initialized.
With this patch, the controller will be automatically re-initialized after resuming from suspend.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=216233
Signed-off-by: Martino Fontana <tinozzo123@gmail.com>
---
drivers/hid/hid-nintendo.c | 178 ++++++++++++++++++++++---------------
1 file changed, 106 insertions(+), 72 deletions(-)
diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index 250f5d2f8..586c7f8d7 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -2088,7 +2088,9 @@ static int joycon_read_info(struct joycon_ctlr *ctlr)
struct joycon_input_report *report;
req.subcmd_id = JC_SUBCMD_REQ_DEV_INFO;
+ mutex_lock(&ctlr->output_mutex);
ret = joycon_send_subcmd(ctlr, &req, 0, HZ);
+ mutex_unlock(&ctlr->output_mutex);
if (ret) {
hid_err(ctlr->hdev, "Failed to get joycon info; ret=%d\n", ret);
return ret;
@@ -2117,6 +2119,88 @@ static int joycon_read_info(struct joycon_ctlr *ctlr)
return 0;
}
+static int joycon_init(struct hid_device *hdev)
+{
+ struct joycon_ctlr *ctlr = hid_get_drvdata(hdev);
+ int ret = 0;
+
+ mutex_lock(&ctlr->output_mutex);
+ /* if handshake command fails, assume ble pro controller */
+ if ((jc_type_is_procon(ctlr) || jc_type_is_chrggrip(ctlr)) &&
+ !joycon_send_usb(ctlr, JC_USB_CMD_HANDSHAKE, HZ)) {
+ hid_dbg(hdev, "detected USB controller\n");
+ /* set baudrate for improved latency */
+ ret = joycon_send_usb(ctlr, JC_USB_CMD_BAUDRATE_3M, HZ);
+ if (ret) {
+ hid_err(hdev, "Failed to set baudrate; ret=%d\n", ret);
+ goto err_mutex;
+ }
+ /* handshake */
+ ret = joycon_send_usb(ctlr, JC_USB_CMD_HANDSHAKE, HZ);
+ if (ret) {
+ hid_err(hdev, "Failed handshake; ret=%d\n", ret);
+ goto err_mutex;
+ }
+ /*
+ * Set no timeout (to keep controller in USB mode).
+ * This doesn't send a response, so ignore the timeout.
+ */
+ joycon_send_usb(ctlr, JC_USB_CMD_NO_TIMEOUT, HZ/10);
+ } else if (jc_type_is_chrggrip(ctlr)) {
+ hid_err(hdev, "Failed charging grip handshake\n");
+ ret = -ETIMEDOUT;
+ goto err_mutex;
+ }
+
+ /* get controller calibration data, and parse it */
+ ret = joycon_request_calibration(ctlr);
+ if (ret) {
+ /*
+ * We can function with default calibration, but it may be
+ * inaccurate. Provide a warning, and continue on.
+ */
+ hid_warn(hdev, "Analog stick positions may be inaccurate\n");
+ }
+
+ /* get IMU calibration data, and parse it */
+ ret = joycon_request_imu_calibration(ctlr);
+ if (ret) {
+ /*
+ * We can function with default calibration, but it may be
+ * inaccurate. Provide a warning, and continue on.
+ */
+ hid_warn(hdev, "Unable to read IMU calibration data\n");
+ }
+
+ /* Set the reporting mode to 0x30, which is the full report mode */
+ ret = joycon_set_report_mode(ctlr);
+ if (ret) {
+ hid_err(hdev, "Failed to set report mode; ret=%d\n", ret);
+ goto err_mutex;
+ }
+
+ /* Enable rumble */
+ ret = joycon_enable_rumble(ctlr);
+ if (ret) {
+ hid_err(hdev, "Failed to enable rumble; ret=%d\n", ret);
+ goto err_mutex;
+ }
+
+ /* Enable the IMU */
+ ret = joycon_enable_imu(ctlr);
+ if (ret) {
+ hid_err(hdev, "Failed to enable the IMU; ret=%d\n", ret);
+ goto err_mutex;
+ }
+
+ mutex_unlock(&ctlr->output_mutex);
+ return 0;
+
+err_mutex:
+ mutex_unlock(&ctlr->output_mutex);
+ return ret;
+}
+
/* Common handler for parsing inputs */
static int joycon_ctlr_read_handler(struct joycon_ctlr *ctlr, u8 *data,
int size)
@@ -2248,85 +2332,19 @@ static int nintendo_hid_probe(struct hid_device *hdev,
hid_device_io_start(hdev);
- /* Initialize the controller */
- mutex_lock(&ctlr->output_mutex);
- /* if handshake command fails, assume ble pro controller */
- if ((jc_type_is_procon(ctlr) || jc_type_is_chrggrip(ctlr)) &&
- !joycon_send_usb(ctlr, JC_USB_CMD_HANDSHAKE, HZ)) {
- hid_dbg(hdev, "detected USB controller\n");
- /* set baudrate for improved latency */
- ret = joycon_send_usb(ctlr, JC_USB_CMD_BAUDRATE_3M, HZ);
- if (ret) {
- hid_err(hdev, "Failed to set baudrate; ret=%d\n", ret);
- goto err_mutex;
- }
- /* handshake */
- ret = joycon_send_usb(ctlr, JC_USB_CMD_HANDSHAKE, HZ);
- if (ret) {
- hid_err(hdev, "Failed handshake; ret=%d\n", ret);
- goto err_mutex;
- }
- /*
- * Set no timeout (to keep controller in USB mode).
- * This doesn't send a response, so ignore the timeout.
- */
- joycon_send_usb(ctlr, JC_USB_CMD_NO_TIMEOUT, HZ/10);
- } else if (jc_type_is_chrggrip(ctlr)) {
- hid_err(hdev, "Failed charging grip handshake\n");
- ret = -ETIMEDOUT;
- goto err_mutex;
- }
-
- /* get controller calibration data, and parse it */
- ret = joycon_request_calibration(ctlr);
- if (ret) {
- /*
- * We can function with default calibration, but it may be
- * inaccurate. Provide a warning, and continue on.
- */
- hid_warn(hdev, "Analog stick positions may be inaccurate\n");
- }
-
- /* get IMU calibration data, and parse it */
- ret = joycon_request_imu_calibration(ctlr);
- if (ret) {
- /*
- * We can function with default calibration, but it may be
- * inaccurate. Provide a warning, and continue on.
- */
- hid_warn(hdev, "Unable to read IMU calibration data\n");
- }
-
- /* Set the reporting mode to 0x30, which is the full report mode */
- ret = joycon_set_report_mode(ctlr);
- if (ret) {
- hid_err(hdev, "Failed to set report mode; ret=%d\n", ret);
- goto err_mutex;
- }
-
- /* Enable rumble */
- ret = joycon_enable_rumble(ctlr);
- if (ret) {
- hid_err(hdev, "Failed to enable rumble; ret=%d\n", ret);
- goto err_mutex;
- }
-
- /* Enable the IMU */
- ret = joycon_enable_imu(ctlr);
+ ret = joycon_init(hdev);
if (ret) {
- hid_err(hdev, "Failed to enable the IMU; ret=%d\n", ret);
- goto err_mutex;
+ hid_err(hdev, "Failed to initialize controller; ret=%d\n", ret);
+ goto err_close;
}
ret = joycon_read_info(ctlr);
if (ret) {
hid_err(hdev, "Failed to retrieve controller info; ret=%d\n",
ret);
- goto err_mutex;
+ goto err_close;
}
- mutex_unlock(&ctlr->output_mutex);
-
/* Initialize the leds */
ret = joycon_leds_create(ctlr);
if (ret) {
@@ -2352,8 +2370,6 @@ static int nintendo_hid_probe(struct hid_device *hdev,
hid_dbg(hdev, "probe - success\n");
return 0;
-err_mutex:
- mutex_unlock(&ctlr->output_mutex);
err_close:
hid_hw_close(hdev);
err_stop:
@@ -2383,6 +2399,20 @@ static void nintendo_hid_remove(struct hid_device *hdev)
hid_hw_stop(hdev);
}
+#ifdef CONFIG_PM
+
+static int nintendo_hid_resume(struct hid_device *hdev)
+{
+ int ret = joycon_init(hdev);
+
+ if (ret)
+ hid_err(hdev, "Failed to restore controller after resume");
+
+ return ret;
+}
+
+#endif
+
static const struct hid_device_id nintendo_hid_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_NINTENDO,
USB_DEVICE_ID_NINTENDO_PROCON) },
@@ -2404,6 +2434,10 @@ static struct hid_driver nintendo_hid_driver = {
.probe = nintendo_hid_probe,
.remove = nintendo_hid_remove,
.raw_event = nintendo_hid_event,
+
+#ifdef CONFIG_PM
+ .resume = nintendo_hid_resume,
+#endif
};
module_hid_driver(nintendo_hid_driver);
--
2.41.0
^ permalink raw reply related
* Re: [PATCH 10/17] hid/picolcd: Remove flag FBINFO_FLAG_DEFAULT from fbdev driver
From: Bruno Prémont @ 2023-07-12 9:43 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: deller, javierm, linux-sh, dri-devel, linux-kernel, amd-gfx,
linux-input, linux-media, linux-fbdev, linux-staging,
linux-arm-kernel, linux-geode, linux-nvidia, linux-hyperv,
linux-omap, linuxppc-dev, kvm, Jiri Kosina, Benjamin Tissoires
In-Reply-To: <20230710130113.14563-11-tzimmermann@suse.de>
On Mon, 10 Jul 2023 14:50:14 +0200 Thomas Zimmermann wrote:
> The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
> fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
> not set it.
>
> Flags should signal differences from the default values. After cleaning
> up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: "Bruno Prémont" <bonbons@linux-vserver.org>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Bruno Prémont <bonbons@linux-vserver.org>
Cheers,
Bruno
> ---
> drivers/hid/hid-picolcd_fb.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
> index dabcd054dad9..d726aaafb146 100644
> --- a/drivers/hid/hid-picolcd_fb.c
> +++ b/drivers/hid/hid-picolcd_fb.c
> @@ -527,7 +527,6 @@ int picolcd_init_framebuffer(struct picolcd_data *data)
> info->var = picolcdfb_var;
> info->fix = picolcdfb_fix;
> info->fix.smem_len = PICOLCDFB_SIZE*8;
> - info->flags = FBINFO_FLAG_DEFAULT;
>
> fbdata = info->par;
> spin_lock_init(&fbdata->lock);
^ permalink raw reply
* Re: [PATCH 00/17] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags
From: Thomas Zimmermann @ 2023-07-12 6:44 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-arm-kernel, linux-hyperv, kvm, linux-sh, deller,
linux-staging, javierm, amd-gfx, linux-kernel, dri-devel,
linux-fbdev, linux-input, linux-nvidia, linux-omap, linuxppc-dev,
linux-geode, linux-media
In-Reply-To: <20230711144744.GA117276@ravnborg.org>
[-- Attachment #1.1: Type: text/plain, Size: 2411 bytes --]
Am 11.07.23 um 16:47 schrieb Sam Ravnborg:
> Hi Thomas,
>
> On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
>> Hi Sam
>>
>> Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
>>> Hi Thomas,
>>>
>>> On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
>>>> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
>>>> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
>>>> useful when fbdev had special handling for driver modules. With
>>>> commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
>>>> and have no further effect.
>>>>
>>>> Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
>>>> split this by the way the fb_info struct is being allocated. All flags
>>>> are cleared to zero during the allocation.
>>>>
>>>> Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
>>>> an actual bug in how arch/sh uses the tokne for struct fb_videomode,
>>>> which is unrelated.
>>>>
>>>> Patch 17 removes both flag constants from <linux/fb.h>
>>>
>>> We have a few more flags that are unused - should they be nuked too?
>>> FBINFO_HWACCEL_FILLRECT
>>> FBINFO_HWACCEL_ROTATE
>>> FBINFO_HWACCEL_XPAN
>>
>> It seems those are there for completeness. Nothing sets _ROTATE, the others
>> are simply never checked. According to the comments, some are required, some
>> are optional. I don't know what that means.
>>
>> IIRC there were complains about performance when Daniel tried to remove
>> fbcon acceleration, so not all _HWACCEL_ flags are unneeded.
>>
>> Leaving them in for reference/completeness might be an option; or not. I
>> have no strong feelings about those flags.
>>
>>>
>>> Unused as in no references from fbdev/core/*
>>>
>>> I would rather see one series nuke all unused FBINFO flags in one go.
>>> Assuming my quick grep are right and the above can be dropped.
>>
>> I would not want to extend this series. I'm removing _DEFAULT as it's
>> absolutely pointless and confusing.
>
> OK, makes sense and thanks for the explanation.
>
> The series is:
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
Thanks a lot.
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH] HID: usbhid: Fix use assignment in if condition
From: Bagas Sanjaya @ 2023-07-12 0:53 UTC (permalink / raw)
To: Greg KH, wuyonggang001
Cc: jikos, benjamin.tissoires, linux-usb, linux-input, linux-kernel
In-Reply-To: <2023071100-recoup-rebuild-c55a@gregkh>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
On Tue, Jul 11, 2023 at 06:09:22AM +0200, Greg KH wrote:
> You are receiving this message because of the following common error(s)
> as indicated below:
>
> - Your patch is malformed (tabs converted to spaces, linewrapped, etc.)
> and can not be applied. Please read the file,
> Documentation/process/email-clients.rst in order to fix this.
Hi Greg,
208suo.com people send their patches (including this one) using
Roundcube, which is knwon to corrupt patches as you mentioned. Maybe
I have to send Documentation/process/email-client.rst patch to mention
this, right?
Thanks.
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 07/10] Input: sun4i-lradc-keys - Convert to devm_platform_ioremap_resource()
From: Jernej Škrabec @ 2023-07-11 18:27 UTC (permalink / raw)
To: Hans de Goede, Dmitry Torokhov, Chen-Yu Tsai, Samuel Holland,
Yangtao Li
Cc: Yangtao Li, linux-input, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20230705052346.39337-7-frank.li@vivo.com>
Dne sreda, 05. julij 2023 ob 07:23:43 CEST je Yangtao Li napisal(a):
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li <frank.li@vivo.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
> ---
> drivers/input/keyboard/sun4i-lradc-keys.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c
> b/drivers/input/keyboard/sun4i-lradc-keys.c index
> 15c15c0958b0..95d927cc8b7e 100644
> --- a/drivers/input/keyboard/sun4i-lradc-keys.c
> +++ b/drivers/input/keyboard/sun4i-lradc-keys.c
> @@ -307,8 +307,7 @@ static int sun4i_lradc_probe(struct platform_device
> *pdev)
>
> input_set_drvdata(lradc->input, lradc);
>
> - lradc->base = devm_ioremap_resource(dev,
> - platform_get_resource(pdev,
IORESOURCE_MEM, 0));
> + lradc->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(lradc->base))
> return PTR_ERR(lradc->base);
^ permalink raw reply
* Re: [PATCH 00/17] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags
From: Geert Uytterhoeven @ 2023-07-11 16:04 UTC (permalink / raw)
To: Helge Deller
Cc: Sam Ravnborg, Thomas Zimmermann, javierm, linux-fbdev, kvm,
linux-hyperv, linux-sh, linux-staging, linux-kernel, amd-gfx,
linux-geode, dri-devel, linux-input, linux-nvidia, linux-omap,
linuxppc-dev, linux-arm-kernel, linux-media
In-Reply-To: <bf439387-6b13-0fd9-f61b-1a5cbf731187@gmx.de>
Hi Helge,
On Tue, Jul 11, 2023 at 5:26 PM Helge Deller <deller@gmx.de> wrote:
> On 7/11/23 16:47, Sam Ravnborg wrote:
> > On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
> >> Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
> >>> On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
> >>>> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> >>>> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> >>>> useful when fbdev had special handling for driver modules. With
> >>>> commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
> >>>> and have no further effect.
> >>>>
> >>>> Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
> >>>> split this by the way the fb_info struct is being allocated. All flags
> >>>> are cleared to zero during the allocation.
> >>>>
> >>>> Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
> >>>> an actual bug in how arch/sh uses the tokne for struct fb_videomode,
> >>>> which is unrelated.
> >>>>
> >>>> Patch 17 removes both flag constants from <linux/fb.h>
> >>>
> >>> We have a few more flags that are unused - should they be nuked too?
> >>> FBINFO_HWACCEL_FILLRECT
> >>> FBINFO_HWACCEL_ROTATE
> >>> FBINFO_HWACCEL_XPAN
> >>
> >> It seems those are there for completeness. Nothing sets _ROTATE,
>
> I think some fbdev drivers had hardware acceleration for ROTATE in the
> past. HWACCEL_XPAN is still in some drivers.
>
> >> the others are simply never checked. According to the comments,
> >> some are required, some are optional. I don't know what that
> >> means.
>
> I think it's OK if you remove those flags which aren't used anywhere,
> e.g. FBINFO_HWACCEL_ROTATE.
Indeed.
> >> IIRC there were complains about performance when Daniel tried to remove
> >> fbcon acceleration, so not all _HWACCEL_ flags are unneeded.
>
> Correct. I think COPYAREA and FILLRECT are the bare minimum to accelerate
> fbcon, IMAGEBLIT is for showing the tux penguin (?),
> XPAN/YPAN and YWRAP for some hardware screen panning needed by some drivers
> (not sure if this is still used as I don't have such hardware, Geert?).
Yes, they are used. Anything that is handled in drivers/video/fbdev/core/
is used:
$ git grep HWACCEL_ -- drivers/video/fbdev/core/
drivers/video/fbdev/core/fbcon.c: if ((info->flags &
FBINFO_HWACCEL_COPYAREA) &&
drivers/video/fbdev/core/fbcon.c: !(info->flags &
FBINFO_HWACCEL_DISABLED))
drivers/video/fbdev/core/fbcon.c: int good_pan = (cap &
FBINFO_HWACCEL_YPAN) &&
drivers/video/fbdev/core/fbcon.c: int good_wrap = (cap &
FBINFO_HWACCEL_YWRAP) &&
drivers/video/fbdev/core/fbcon.c: int fast_copyarea = (cap &
FBINFO_HWACCEL_COPYAREA) &&
drivers/video/fbdev/core/fbcon.c: !(cap &
FBINFO_HWACCEL_DISABLED);
drivers/video/fbdev/core/fbcon.c: int fast_imageblit = (cap &
FBINFO_HWACCEL_IMAGEBLIT) &&
drivers/video/fbdev/core/fbcon.c: !(cap &
FBINFO_HWACCEL_DISABLED);
BTW, I'm surprised FBINFO_HWACCEL_FILLRECT is not handled.
But looking at the full history, it never was...
> >> Leaving them in for reference/completeness might be an option; or not. I
> >> have no strong feelings about those flags.
>
> I'd say drop FBINFO_HWACCEL_ROTATE at least ?
Agreed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 00/17] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags
From: Helge Deller @ 2023-07-11 15:24 UTC (permalink / raw)
To: Sam Ravnborg, Thomas Zimmermann
Cc: javierm, linux-fbdev, kvm, linux-hyperv, linux-sh, linux-staging,
linux-kernel, amd-gfx, linux-geode, dri-devel, linux-input,
linux-nvidia, linux-omap, linuxppc-dev, linux-arm-kernel,
linux-media
In-Reply-To: <20230711144744.GA117276@ravnborg.org>
On 7/11/23 16:47, Sam Ravnborg wrote:
> Hi Thomas,
>
> On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
>> Hi Sam
>>
>> Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
>>> Hi Thomas,
>>>
>>> On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
>>>> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
>>>> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
>>>> useful when fbdev had special handling for driver modules. With
>>>> commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
>>>> and have no further effect.
>>>>
>>>> Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
>>>> split this by the way the fb_info struct is being allocated. All flags
>>>> are cleared to zero during the allocation.
>>>>
>>>> Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
>>>> an actual bug in how arch/sh uses the tokne for struct fb_videomode,
>>>> which is unrelated.
>>>>
>>>> Patch 17 removes both flag constants from <linux/fb.h>
>>>
>>> We have a few more flags that are unused - should they be nuked too?
>>> FBINFO_HWACCEL_FILLRECT
>>> FBINFO_HWACCEL_ROTATE
>>> FBINFO_HWACCEL_XPAN
>>
>> It seems those are there for completeness. Nothing sets _ROTATE,
I think some fbdev drivers had hardware acceleration for ROTATE in the
past. HWACCEL_XPAN is still in some drivers.
>> the others are simply never checked. According to the comments,
>> some are required, some are optional. I don't know what that
>> means.
I think it's OK if you remove those flags which aren't used anywhere,
e.g. FBINFO_HWACCEL_ROTATE.
>> IIRC there were complains about performance when Daniel tried to remove
>> fbcon acceleration, so not all _HWACCEL_ flags are unneeded.
Correct. I think COPYAREA and FILLRECT are the bare minimum to accelerate
fbcon, IMAGEBLIT is for showing the tux penguin (?),
XPAN/YPAN and YWRAP for some hardware screen panning needed by some drivers
(not sure if this is still used as I don't have such hardware, Geert?).
>> Leaving them in for reference/completeness might be an option; or not. I
>> have no strong feelings about those flags.
I'd say drop FBINFO_HWACCEL_ROTATE at least ?
>>> Unused as in no references from fbdev/core/*
>>>
>>> I would rather see one series nuke all unused FBINFO flags in one go.
>>> Assuming my quick grep are right and the above can be dropped.
>>
>> I would not want to extend this series. I'm removing _DEFAULT as it's
>> absolutely pointless and confusing.
Yes, Ok.
Helge
^ permalink raw reply
* Re: [PATCH v4 2/3] Input: add ABS_SND_PROFILE
From: Caleb Connolly @ 2023-07-11 15:08 UTC (permalink / raw)
To: Bjorn Andersson, Gergo Koteles, Dmitry Torokhov
Cc: Jonathan Corbet, Andy Gross, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20230407171103.5jf46g4hw3fed7dn@ripper>
On 07/04/2023 18:11, Bjorn Andersson wrote:
> On Wed, Feb 22, 2023 at 01:10:33AM +0100, Gergo Koteles wrote:
>> ABS_SND_PROFILE used to describe the state of a multi-value sound profile
>> switch. This will be used for the alert-slider on OnePlus phones or other
>> phones.
>>
>> Profile values added as SND_PROFLE_(SILENT|VIBRATE|RING) identifiers
>> to input-event-codes.h so they can be used from DTS.
>>
>> Signed-off-by: Gergo Koteles <soyer@irl.hu>
>> ---
>> Documentation/input/event-codes.rst | 6 ++++++
>> drivers/hid/hid-debug.c | 1 +
>> include/uapi/linux/input-event-codes.h | 9 +++++++++
>> 3 files changed, 16 insertions(+)
>>
>> diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
>> index b4557462edd7..d43336e64d6a 100644
>> --- a/Documentation/input/event-codes.rst
>> +++ b/Documentation/input/event-codes.rst
>> @@ -241,6 +241,12 @@ A few EV_ABS codes have special meanings:
>> emitted only when the selected profile changes, indicating the newly
>> selected profile value.
>>
...
>>
>> +/*
>> + * ABS_SND_PROFILE values
>> + */
>> +
>> +#define SND_PROFILE_SILENT 0x00
>> +#define SND_PROFILE_VIBRATE 0x01
>> +#define SND_PROFILE_RING 0x02
>
> The patch looks good to me, bu I'd need these header file additions in
> order to merge the dts patch. Could I get an ack and take it through the
> Qualocmm tree, or could you pick it up for 6.4, and then I can merge the
> dts change after that?
Bump, I think this might have gotten lost.
>
> Regards,
> Bjorn
>
>> +
>> #endif
>> --
>> 2.39.2
>>
--
Kind Regards,
Caleb
^ permalink raw reply
* Re: [PATCH 00/17] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags
From: Sam Ravnborg @ 2023-07-11 14:47 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: deller, javierm, linux-fbdev, kvm, linux-hyperv, linux-sh,
linux-staging, linux-kernel, amd-gfx, linux-geode, dri-devel,
linux-input, linux-nvidia, linux-omap, linuxppc-dev,
linux-arm-kernel, linux-media
In-Reply-To: <ab92f8d9-36ab-06bc-b85b-d52b7a1bfe9a@suse.de>
Hi Thomas,
On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
> Hi Sam
>
> Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
> > Hi Thomas,
> >
> > On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
> > > Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> > > fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> > > useful when fbdev had special handling for driver modules. With
> > > commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
> > > and have no further effect.
> > >
> > > Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
> > > split this by the way the fb_info struct is being allocated. All flags
> > > are cleared to zero during the allocation.
> > >
> > > Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
> > > an actual bug in how arch/sh uses the tokne for struct fb_videomode,
> > > which is unrelated.
> > >
> > > Patch 17 removes both flag constants from <linux/fb.h>
> >
> > We have a few more flags that are unused - should they be nuked too?
> > FBINFO_HWACCEL_FILLRECT
> > FBINFO_HWACCEL_ROTATE
> > FBINFO_HWACCEL_XPAN
>
> It seems those are there for completeness. Nothing sets _ROTATE, the others
> are simply never checked. According to the comments, some are required, some
> are optional. I don't know what that means.
>
> IIRC there were complains about performance when Daniel tried to remove
> fbcon acceleration, so not all _HWACCEL_ flags are unneeded.
>
> Leaving them in for reference/completeness might be an option; or not. I
> have no strong feelings about those flags.
>
> >
> > Unused as in no references from fbdev/core/*
> >
> > I would rather see one series nuke all unused FBINFO flags in one go.
> > Assuming my quick grep are right and the above can be dropped.
>
> I would not want to extend this series. I'm removing _DEFAULT as it's
> absolutely pointless and confusing.
OK, makes sense and thanks for the explanation.
The series is:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: rework one more time the retries attempts
From: Linux regression tracking (Thorsten Leemhuis) @ 2023-07-11 13:56 UTC (permalink / raw)
To: Benjamin Tissoires, Linux regressions mailing list
Cc: Bastien Nocera, Greg KH, Filipe Laíns, Jiri Kosina,
linux-input, linux-kernel, stable
In-Reply-To: <CAO-hwJLc0wzv2a3JARkPDW+ZgbnvwggfRHcAJmWsKy_FMA13=g@mail.gmail.com>
On 11.07.23 15:40, Benjamin Tissoires wrote:
> On Tue, Jul 11, 2023 at 3:10 PM Linux regression tracking (Thorsten
> Leemhuis) <regressions@leemhuis.info> wrote:
>>
>> On 26.06.23 16:02, Benjamin Tissoires wrote:
>>> On Sun, Jun 25, 2023 at 10:30 AM Bastien Nocera <hadess@hadess.net> wrote:
>>>> On Fri, 2023-06-23 at 10:37 +0200, Benjamin Tissoires wrote:
>>>>> On Jun 21 2023, Greg KH wrote:
>>>>>> On Wed, Jun 21, 2023 at 11:42:30AM +0200, Benjamin Tissoires wrote:
>>>>>>> Make the code looks less like Pascal.
>>>>>>>
>>>>>>> Extract the internal code inside a helper function, fix the
>>>>>>> initialization of the parameters used in the helper function
>>>>>>> (`hidpp->answer_available` was not reset and `*response` wasn't
>>>>>>> too),
>>>>>>> and use a `do {...} while();` loop.
>>>>>>>
>>>>>>> Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when
>>>>>>> device is busy")
>>>>>>> Cc: stable@vger.kernel.org
>>>>>>> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>>>>>>> ---
>>>>>>> as requested by
>>>>>>> https://lore.kernel.org/all/CAHk-=wiMbF38KCNhPFiargenpSBoecSXTLQACKS2UMyo_Vu2ww@mail.gmail.com/
>>>>>>> This is a rewrite of that particular piece of code.
>>>>>>> ---
>>>>>>> drivers/hid/hid-logitech-hidpp.c | 102 +++++++++++++++++++++++--
>>>>>>> --------------
>>>>>>> 1 file changed, 61 insertions(+), 41 deletions(-)
>>> [...]
>>>
>>> Some people on the Bz were able to reproduce with multiple reboots.
>>> But it's not as urgent as previously, and we were close to the 6.4
>>> final when I sent it. I'll make sure this goes into 6.5 and gets
>>> proper stable backports FWIW.
>>
>> Did that happen? Doesn't look like it from here, but maybe I'm missing
>> something. Where there maybe other changes to resolve the remaining
>> problems some users encounter sporadically since the urgent fixes went in?
>
> No, there were no other changes that could have solved this. I guess
> the randomness of the problem makes it way harder to detect and to
> reproduce.
>
> I'll send a v2 of that patch with the reviews today or tomorrow and we
> can probably get it through the current 6.5 cycle.
Great, many thx!
Ciao, Thorsten
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: rework one more time the retries attempts
From: Benjamin Tissoires @ 2023-07-11 13:40 UTC (permalink / raw)
To: Linux regressions mailing list
Cc: Bastien Nocera, Greg KH, Filipe Laíns, Jiri Kosina,
linux-input, linux-kernel, stable
In-Reply-To: <cfa28818-9eaf-0dc9-cb4a-1b3de318e627@leemhuis.info>
On Tue, Jul 11, 2023 at 3:10 PM Linux regression tracking (Thorsten
Leemhuis) <regressions@leemhuis.info> wrote:
>
> On 26.06.23 16:02, Benjamin Tissoires wrote:
> > On Sun, Jun 25, 2023 at 10:30 AM Bastien Nocera <hadess@hadess.net> wrote:
> >> On Fri, 2023-06-23 at 10:37 +0200, Benjamin Tissoires wrote:
> >>> On Jun 21 2023, Greg KH wrote:
> >>>> On Wed, Jun 21, 2023 at 11:42:30AM +0200, Benjamin Tissoires wrote:
> >>>>> Make the code looks less like Pascal.
> >>>>>
> >>>>> Extract the internal code inside a helper function, fix the
> >>>>> initialization of the parameters used in the helper function
> >>>>> (`hidpp->answer_available` was not reset and `*response` wasn't
> >>>>> too),
> >>>>> and use a `do {...} while();` loop.
> >>>>>
> >>>>> Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when
> >>>>> device is busy")
> >>>>> Cc: stable@vger.kernel.org
> >>>>> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> >>>>> ---
> >>>>> as requested by
> >>>>> https://lore.kernel.org/all/CAHk-=wiMbF38KCNhPFiargenpSBoecSXTLQACKS2UMyo_Vu2ww@mail.gmail.com/
> >>>>> This is a rewrite of that particular piece of code.
> >>>>> ---
> >>>>> drivers/hid/hid-logitech-hidpp.c | 102 +++++++++++++++++++++++--
> >>>>> --------------
> >>>>> 1 file changed, 61 insertions(+), 41 deletions(-)
> > [...]
> >
> > Some people on the Bz were able to reproduce with multiple reboots.
> > But it's not as urgent as previously, and we were close to the 6.4
> > final when I sent it. I'll make sure this goes into 6.5 and gets
> > proper stable backports FWIW.
>
> Did that happen? Doesn't look like it from here, but maybe I'm missing
> something. Where there maybe other changes to resolve the remaining
> problems some users encounter sporadically since the urgent fixes went in?
No, there were no other changes that could have solved this. I guess
the randomness of the problem makes it way harder to detect and to
reproduce.
I'll send a v2 of that patch with the reviews today or tomorrow and we
can probably get it through the current 6.5 cycle.
Cheers,
Benjamin
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: input: microchip,cap11xx: add advanced sensitivity settings
From: Jiri Valek - 2N @ 2023-07-11 13:22 UTC (permalink / raw)
To: Rob Herring
Cc: krzysztof.kozlowski+dt, dmitry.torokhov, devicetree, linux-input,
linux-kernel, u.kleine-koenig
In-Reply-To: <20230629151635.GA3003066-robh@kernel.org>
On 6/29/23 17:16, Rob Herring wrote:
> On Tue, Jun 27, 2023 at 08:53:15AM +0200, Jiri Valek - 2N wrote:
>> Add support for advanced sensitivity settings and signal guard feature.
>>
>> Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
>> ---
>> .../bindings/input/microchip,cap11xx.yaml | 77 +++++++++++++++++--
>> 1 file changed, 72 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
>> index 5fa625b5c5fb..b69dac1fba0e 100644
>> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
>> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
>> @@ -45,13 +45,13 @@ properties:
>> Enables the Linux input system's autorepeat feature on the input device.
>>
>> linux,keycodes:
>> - minItems: 6
>> - maxItems: 6
>> + minItems: 3
>> + maxItems: 8
>> description: |
>> Specifies an array of numeric keycode values to
>> be used for the channels. If this property is
>> omitted, KEY_A, KEY_B, etc are used as defaults.
>> - The array must have exactly six entries.
>> + The number of entries must correspond to the number of channels.
>
> This change seems unrelated? Or maybe advanced sensitivity means more
> channels? If so, explain this in the commit msg.
This driver is already used for more CAPxxxx types.
The smallest have only 3 inputs and the biggest one have 8 inputs.
So keycode definition array length can be from 3 to 8 items long.
>
>>
>> microchip,sensor-gain:
>> $ref: /schemas/types.yaml#/definitions/uint32
>> @@ -70,6 +70,55 @@ properties:
>> open drain. This property allows using the active
>> high push-pull output.
>>
>> + microchip,sensitivity-delta-sense:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + default: 32
>> + enum: [1, 2, 4, 8, 16, 32, 64, 128]
>> + description:
>> + Optional parameter. Controls the sensitivity multiplier of a touch detection.
>> + At the more sensitive settings, touches are detected for a smaller delta
>> + capacitance corresponding to a “lighter” touch.
>> +
>> + microchip,signal-guard:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 3
>> + maxItems: 8
>> + items:
>> + minimum: 0
>> + maximum: 1
>> + description: |
>> + Optional parameter supported only for CAP129x.
>> + 0 - off
>> + 1 - on
>> + The signal guard isolates the signal from virtual grounds.
>> + If enabled then the behavior of the channel is changed to signal guard.
>> + The number of entries must correspond to the number of channels.
>> +
>> + microchip,input-treshold:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 3
>> + maxItems: 8
>> + items:
>> + minimum: 0
>> + maximum: 127
>> + description:
>> + Optional parameter. Specifies the delta threshold that is used to
>> + determine if a touch has been detected.
>> + The number of entries must correspond to the number of channels.
>> +
>> + microchip,calib-sensitivity:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 3
>> + maxItems: 8
>> + items:
>> + minimum: 1
>> + maximum: 4
>> + description:
>> + Optional parameter supported only for CAP129x. Specifies an array of
>> + numeric values that controls the gain used by the calibration routine to
>> + enable sensor inputs to be more sensitive for proximity detection.
>> + The number of entries must correspond to the number of channels.
>> +
>> patternProperties:
>> "^led@[0-7]$":
>> type: object
>> @@ -98,10 +147,23 @@ allOf:
>> compatible:
>> contains:
>> enum:
>> - - microchip,cap1106
>> + - microchip,cap1188
>> then:
>> patternProperties:
>> - "^led@[0-7]$": false
>> + "^led@[0-7]$": true
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - microchip,cap1293
>> + - microchip,cap1298
>> +
>> + then:
>> + properties:
>> + microchip,signal-guard: true
>> + microchip,calib-sensitivity: true
>
> This 'if' doesn't do anything. These properties are already allowed. You
> need an if for the cases they aren't allowed.
Oh, thanks for the explanation. I will fix it.
>
>>
>> required:
>> - compatible
>> @@ -122,6 +184,11 @@ examples:
>> reg = <0x28>;
>> autorepeat;
>> microchip,sensor-gain = <2>;
>> + microchip,sensitivity-delta-sense = <16>;
>> +
>> + microchip,signal-guard = <0>, <0>, <0>, <0>, <0>, <0>;
>> + microchip,input-treshold = <21>, <18>, <46>, <46>, <46>, <21>;
>> + microchip,calib-sensitivity = <1>, <2>, <2>, <1>, <1>, <2>;
>>
>> linux,keycodes = <103>, /* KEY_UP */
>> <106>, /* KEY_RIGHT */
>> --
>> 2.25.1
>>
BR
Jiri
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: rework one more time the retries attempts
From: Linux regression tracking (Thorsten Leemhuis) @ 2023-07-11 13:09 UTC (permalink / raw)
To: Benjamin Tissoires, Bastien Nocera
Cc: Greg KH, Filipe Laíns, Jiri Kosina, linux-input,
linux-kernel, stable
In-Reply-To: <CAO-hwJLFSUJaGK5DAOz30+YyC1hGgHnbeJbc5iQ47jxBcbRSCg@mail.gmail.com>
On 26.06.23 16:02, Benjamin Tissoires wrote:
> On Sun, Jun 25, 2023 at 10:30 AM Bastien Nocera <hadess@hadess.net> wrote:
>> On Fri, 2023-06-23 at 10:37 +0200, Benjamin Tissoires wrote:
>>> On Jun 21 2023, Greg KH wrote:
>>>> On Wed, Jun 21, 2023 at 11:42:30AM +0200, Benjamin Tissoires wrote:
>>>>> Make the code looks less like Pascal.
>>>>>
>>>>> Extract the internal code inside a helper function, fix the
>>>>> initialization of the parameters used in the helper function
>>>>> (`hidpp->answer_available` was not reset and `*response` wasn't
>>>>> too),
>>>>> and use a `do {...} while();` loop.
>>>>>
>>>>> Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when
>>>>> device is busy")
>>>>> Cc: stable@vger.kernel.org
>>>>> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>>>>> ---
>>>>> as requested by
>>>>> https://lore.kernel.org/all/CAHk-=wiMbF38KCNhPFiargenpSBoecSXTLQACKS2UMyo_Vu2ww@mail.gmail.com/
>>>>> This is a rewrite of that particular piece of code.
>>>>> ---
>>>>> drivers/hid/hid-logitech-hidpp.c | 102 +++++++++++++++++++++++--
>>>>> --------------
>>>>> 1 file changed, 61 insertions(+), 41 deletions(-)
> [...]
>
> Some people on the Bz were able to reproduce with multiple reboots.
> But it's not as urgent as previously, and we were close to the 6.4
> final when I sent it. I'll make sure this goes into 6.5 and gets
> proper stable backports FWIW.
Did that happen? Doesn't look like it from here, but maybe I'm missing
something. Where there maybe other changes to resolve the remaining
problems some users encounter sporadically since the urgent fixes went in?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
^ permalink raw reply
* Re: [PATCH v4 2/2] Input: cap11xx - add advanced sensitivity settings
From: Jiri Valek - 2N @ 2023-07-11 13:05 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: krzysztof.kozlowski+dt, devicetree, linux-input, linux-kernel,
robh+dt, u.kleine-koenig
In-Reply-To: <ZJyEpuat1A8Z+Ft4@google.com>
On 6/28/23 21:06, Dmitry Torokhov wrote:
> Hi Jiri,
>
> On Tue, Jun 27, 2023 at 08:53:16AM +0200, Jiri Valek - 2N wrote:
>> @@ -439,7 +589,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
>> priv->idev->id.bustype = BUS_I2C;
>> priv->idev->evbit[0] = BIT_MASK(EV_KEY);
>>
>> - if (of_property_read_bool(node, "autorepeat"))
>> + if (of_property_read_bool(dev->of_node, "autorepeat"))
>
> It would be good to have this driver switched from of_property_*() to
> device_property_() API.
Yes, I do this after my changes.
>
>> __set_bit(EV_REP, priv->idev->evbit);
>>
>> for (i = 0; i < cap->num_channels; i++)
>> @@ -474,14 +624,8 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
>> if (error)
>> return error;
>>
>> - irq = irq_of_parse_and_map(node, 0);
>> - if (!irq) {
>> - dev_err(dev, "Unable to parse or map IRQ\n");
>> - return -ENXIO;
>> - }
>> -
>> - error = devm_request_threaded_irq(dev, irq, NULL, cap11xx_thread_func,
>> - IRQF_ONESHOT, dev_name(dev), priv);
>> + error = devm_request_threaded_irq(dev, i2c_client->irq, NULL,
>> + cap11xx_thread_func, IRQF_ONESHOT, dev_name(dev), priv);
>
> I would prefer this change be a separate patch.
Agree, I will prepare separate patch
>
> Thanks.
>
BR
Jiri
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS dd24e202ac722b3fea1fadb7f6c0b2db61086e78
From: kernel test robot @ 2023-07-11 10:26 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: dd24e202ac722b3fea1fadb7f6c0b2db61086e78 Input: iqs7222 - add support for Azoteq IQS7222D
elapsed time: 877m
configs tested: 184
configs skipped: 11
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha defconfig gcc
alpha randconfig-r001-20230710 gcc
alpha randconfig-r011-20230710 gcc
alpha randconfig-r014-20230710 gcc
alpha randconfig-r022-20230710 gcc
alpha randconfig-r025-20230710 gcc
alpha randconfig-r032-20230710 gcc
alpha randconfig-r036-20230710 gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-r023-20230710 gcc
arc randconfig-r024-20230710 gcc
arc randconfig-r031-20230710 gcc
arc randconfig-r043-20230710 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm randconfig-r005-20230710 clang
arm randconfig-r024-20230710 gcc
arm randconfig-r025-20230710 gcc
arm randconfig-r046-20230710 gcc
arm randconfig-r046-20230711 clang
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r004-20230710 gcc
arm64 randconfig-r006-20230710 gcc
arm64 randconfig-r034-20230710 gcc
csky defconfig gcc
csky randconfig-r013-20230710 gcc
csky randconfig-r031-20230710 gcc
csky randconfig-r034-20230710 gcc
hexagon randconfig-r033-20230710 clang
hexagon randconfig-r035-20230710 clang
hexagon randconfig-r041-20230710 clang
hexagon randconfig-r041-20230711 clang
hexagon randconfig-r045-20230710 clang
hexagon randconfig-r045-20230711 clang
i386 allyesconfig gcc
i386 buildonly-randconfig-r004-20230710 gcc
i386 buildonly-randconfig-r004-20230711 clang
i386 buildonly-randconfig-r005-20230710 gcc
i386 buildonly-randconfig-r005-20230711 clang
i386 buildonly-randconfig-r006-20230710 gcc
i386 buildonly-randconfig-r006-20230711 clang
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-i001-20230710 gcc
i386 randconfig-i001-20230711 clang
i386 randconfig-i002-20230710 gcc
i386 randconfig-i002-20230711 clang
i386 randconfig-i003-20230710 gcc
i386 randconfig-i003-20230711 clang
i386 randconfig-i004-20230710 gcc
i386 randconfig-i004-20230711 clang
i386 randconfig-i005-20230710 gcc
i386 randconfig-i005-20230711 clang
i386 randconfig-i006-20230710 gcc
i386 randconfig-i006-20230711 clang
i386 randconfig-i011-20230710 clang
i386 randconfig-i011-20230711 gcc
i386 randconfig-i012-20230710 clang
i386 randconfig-i012-20230711 gcc
i386 randconfig-i013-20230710 clang
i386 randconfig-i013-20230711 gcc
i386 randconfig-i014-20230710 clang
i386 randconfig-i014-20230711 gcc
i386 randconfig-i015-20230710 clang
i386 randconfig-i015-20230711 gcc
i386 randconfig-i016-20230710 clang
i386 randconfig-i016-20230711 gcc
i386 randconfig-r003-20230710 gcc
i386 randconfig-r023-20230710 clang
i386 randconfig-r024-20230710 clang
i386 randconfig-r032-20230710 gcc
i386 randconfig-r033-20230710 gcc
i386 randconfig-r035-20230710 gcc
i386 randconfig-r036-20230710 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-r001-20230710 gcc
loongarch randconfig-r015-20230710 gcc
loongarch randconfig-r032-20230710 gcc
loongarch randconfig-r035-20230710 gcc
m68k allmodconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k randconfig-r001-20230710 gcc
m68k randconfig-r004-20230710 gcc
m68k randconfig-r016-20230710 gcc
m68k randconfig-r034-20230710 gcc
microblaze randconfig-r032-20230710 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips cavium_octeon_defconfig clang
mips randconfig-r004-20230710 clang
mips randconfig-r011-20230710 gcc
mips randconfig-r014-20230710 gcc
mips randconfig-r021-20230710 gcc
nios2 defconfig gcc
nios2 randconfig-r011-20230710 gcc
nios2 randconfig-r012-20230710 gcc
nios2 randconfig-r013-20230710 gcc
openrisc randconfig-r003-20230710 gcc
openrisc randconfig-r015-20230710 gcc
openrisc randconfig-r032-20230710 gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-r013-20230710 gcc
parisc randconfig-r025-20230710 gcc
parisc randconfig-r026-20230710 gcc
parisc randconfig-r034-20230710 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc linkstation_defconfig gcc
powerpc makalu_defconfig gcc
powerpc maple_defconfig gcc
powerpc randconfig-r023-20230710 clang
powerpc tqm8548_defconfig gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv allyesconfig gcc
riscv defconfig gcc
riscv randconfig-r002-20230710 gcc
riscv randconfig-r003-20230710 gcc
riscv randconfig-r016-20230710 clang
riscv randconfig-r026-20230710 clang
riscv randconfig-r042-20230710 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r031-20230710 gcc
s390 randconfig-r033-20230710 gcc
s390 randconfig-r036-20230710 gcc
s390 randconfig-r044-20230710 clang
sh allmodconfig gcc
sh randconfig-r004-20230710 gcc
sh randconfig-r016-20230710 gcc
sh randconfig-r033-20230710 gcc
sparc allyesconfig gcc
sparc defconfig gcc
sparc randconfig-r005-20230710 gcc
sparc randconfig-r014-20230710 gcc
sparc64 randconfig-r002-20230710 gcc
sparc64 randconfig-r006-20230710 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-r012-20230710 gcc
um randconfig-r014-20230710 gcc
um randconfig-r016-20230710 gcc
um randconfig-r022-20230710 gcc
um randconfig-r024-20230710 gcc
um x86_64_defconfig gcc
x86_64 allyesconfig gcc
x86_64 buildonly-randconfig-r001-20230710 gcc
x86_64 buildonly-randconfig-r001-20230711 clang
x86_64 buildonly-randconfig-r002-20230710 gcc
x86_64 buildonly-randconfig-r002-20230711 clang
x86_64 buildonly-randconfig-r003-20230710 gcc
x86_64 buildonly-randconfig-r003-20230711 clang
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-x001-20230710 clang
x86_64 randconfig-x002-20230710 clang
x86_64 randconfig-x003-20230710 clang
x86_64 randconfig-x004-20230710 clang
x86_64 randconfig-x005-20230710 clang
x86_64 randconfig-x006-20230710 clang
x86_64 randconfig-x011-20230710 gcc
x86_64 randconfig-x012-20230710 gcc
x86_64 randconfig-x013-20230710 gcc
x86_64 randconfig-x014-20230710 gcc
x86_64 randconfig-x015-20230710 gcc
x86_64 randconfig-x016-20230710 gcc
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa randconfig-r015-20230710 gcc
xtensa randconfig-r035-20230710 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 09/17] auxdisplay: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
From: Miguel Ojeda @ 2023-07-11 10:03 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: deller, javierm, linux-sh, dri-devel, linux-kernel, amd-gfx,
linux-input, linux-media, linux-fbdev, linux-staging,
linux-arm-kernel, linux-geode, linux-nvidia, linux-hyperv,
linux-omap, linuxppc-dev, kvm, Miguel Ojeda, Robin van der Gracht
In-Reply-To: <745347ca-a369-eb01-eac4-75c09cf9e67f@suse.de>
On Tue, Jul 11, 2023 at 8:10 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> I'd like to take the patchset into drm-misc. It's part of a larger
> cleanup of the fbdev modules and its interfaces.
Sounds good, thanks!
Cheers,
Miguel
^ permalink raw reply
* Fotowoltaika - propozycja instalacji
From: Norbert Karecki @ 2023-07-11 8:11 UTC (permalink / raw)
To: linux-input
Dzień dobry,
Czy rozważali Państwo montaż systemu fotowoltaicznego?
Instalacja fotowoltaiczna jest najlepszym sposobem na obniżenie wysokości rachunków za prąd (pozostają tylko opłaty stałe) i zabezpieczenie się przed rosnącymi cenami energii elektrycznej. Jest to w pełni odnawialne i bezemisyjne źródło energii, dzięki czemu przyczyniamy się do ochrony środowiska naturalnego.
Działamy od wielu lat na rynku energetycznym. Przygotujemy projekt, wycenę oraz kompleksowo wykonamy i zgłosimy realizację do zakładu energetycznego.
Czy chcą Państwo poznać naszą propozycję?
Pozdrawiam
Norbert Karecki
^ permalink raw reply
* [PATCH v2] Input: bcm-keypad - Correct dev_err_probe() error
From: Krzysztof Kozlowski @ 2023-07-11 7:24 UTC (permalink / raw)
To: Dmitry Torokhov, Krzysztof Kozlowski, Hans de Goede,
Andy Shevchenko, linux-input, linux-kernel
Cc: kernel test robot, Dan Carpenter
Pass proper PTR_ERR as dev_err_probe() argument.
Fixes: a2c795b696b2 ("Input: bcm-keypad - simplify with dev_err_probe()")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202306261505.wTjCXRIO-lkp@intel.com/
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/input/keyboard/bcm-keypad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/bcm-keypad.c b/drivers/input/keyboard/bcm-keypad.c
index 05b09066df84..bcc480ff7c3b 100644
--- a/drivers/input/keyboard/bcm-keypad.c
+++ b/drivers/input/keyboard/bcm-keypad.c
@@ -367,7 +367,7 @@ static int bcm_kp_probe(struct platform_device *pdev)
/* Enable clock */
kp->clk = devm_clk_get_optional(&pdev->dev, "peri_clk");
if (IS_ERR(kp->clk)) {
- return dev_err_probe(&pdev->dev, error, "Failed to get clock\n");
+ return dev_err_probe(&pdev->dev, PTR_ERR(kp->clk), "Failed to get clock\n");
} else if (!kp->clk) {
dev_dbg(&pdev->dev, "No clock specified. Assuming it's enabled\n");
} else {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] fix Input: bcm-keypad - Correct dev_err_probe() error
From: Krzysztof Kozlowski @ 2023-07-11 7:24 UTC (permalink / raw)
To: Dmitry Torokhov, Hans de Goede, Andy Shevchenko, linux-input,
linux-kernel
Cc: kernel test robot, Dan Carpenter
In-Reply-To: <20230711072254.43273-1-krzysztof.kozlowski@linaro.org>
On 11/07/2023 09:22, Krzysztof Kozlowski wrote:
> Pass proper PTR_ERR as dev_err_probe() argument.
I need to fix subject. :(
Best regards,
Krzysztof
^ 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