* [PATCH 4/4] dt-bindings: input: touchscreen: st1232: add example with ts-virtobj
From: Javier Carrasco @ 2023-05-10 13:50 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch
Cc: linux-kernel, linux-input, devicetree, Javier Carrasco
In-Reply-To: <20230510-feature-ts_virtobj_patch-v1-0-5ae5e81bc264@wolfvision.net>
The st1232 driver supports the virtual-touchscreen and virtual-buttons
objects defined in the generic touchscreen bindings and implemented in
the ts-virtobj module. Add an example where nodes for a virtual
touchscreen and virtual buttons are defined.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
.../input/touchscreen/sitronix,st1232.yaml | 40 ++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
index 1d8ca19fd37a..97a2c063b47c 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
@@ -48,3 +48,43 @@ examples:
gpios = <&gpio1 166 0>;
};
};
+ - |
+ #include <dt-bindings/input/linux-event-codes.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@55 {
+ compatible = "sitronix,st1232";
+ reg = <0x55>;
+ interrupts = <2 0>;
+ gpios = <&gpio1 166 0>;
+
+ virtual-touchscreen {
+ x-origin = <0>;
+ x-size = <240>;
+ y-origin = <40>;
+ y-size = <280>;
+ };
+
+ virtual-buttons {
+ button-light {
+ label = "Camera light";
+ linux,code = <KEY_LIGHTS_TOGGLE>;
+ x-origin = <40>;
+ x-size = <40>;
+ y-origin = <0>;
+ y-size = <40>;
+ };
+
+ button-suspend {
+ label = "Suspend";
+ linux,code = <KEY_SUSPEND>;
+ x-origin = <160>;
+ x-size = <40>;
+ y-origin = <0>;
+ y-size = <40>;
+ };
+ };
+ };
+ };
--
2.39.2
^ permalink raw reply related
* [PATCH 0/4] Input: support virtual objects on touchscreens
From: Javier Carrasco @ 2023-05-10 13:50 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch
Cc: linux-kernel, linux-input, devicetree, Javier Carrasco
Some touchscreens are shipped with a physical layer on top of them where
a number of buttons and a resized touchscreen surface might be available.
In order to generate proper key events by overlay buttons and adjust the
touch events to a clipped surface, these patches offer a documented,
device-tree-based solution by means of helper functions.
An implementation for a specific touchscreen driver is also included.
The functions in ts-virtobj provide a simple workflow to acquire
physical objects from the device tree, map them into the device driver
structures as virtual objects and generate events according to
the object descriptions.
This solution has been tested with a JT240MHQS-E3 display, which uses
the st1624 as a touchscreen and provides two overlay buttons and a frame
that clips its effective surface.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
Javier Carrasco (4):
Input: ts-virtobj - Add touchsreen virtual object handling
dt-bindings: touchscreen: add virtual-touchscreen and virtual-buttons properties
Input: st1232 - add virtual touchscreen and buttons handling
dt-bindings: input: touchscreen: st1232: add example with ts-virtobj
.../input/touchscreen/sitronix,st1232.yaml | 40 +++
.../bindings/input/touchscreen/touchscreen.yaml | 54 ++++
MAINTAINERS | 7 +
drivers/input/touchscreen/Kconfig | 9 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/st1232.c | 87 +++--
drivers/input/touchscreen/ts-virtobj.c | 360 +++++++++++++++++++++
include/linux/input/ts-virtobj.h | 95 ++++++
8 files changed, 635 insertions(+), 18 deletions(-)
---
base-commit: ac9a78681b921877518763ba0e89202254349d1b
change-id: 20230510-feature-ts_virtobj_patch-e267540aae74
Best regards,
--
Javier Carrasco <javier.carrasco@wolfvision.net>
^ permalink raw reply
* Re: [PATCH 0/5] HID: manually unregister leds on device removal to prevent UAFs
From: Pavel Machek @ 2023-05-10 11:41 UTC (permalink / raw)
To: Donald Buczek
Cc: Pietro Borrello, Jiri Kosina, Benjamin Tissoires, Hanno Zulla,
Carlo Caione, Lee Jones, Roderick Colenbrander, Sven Eckelmann,
linux-leds, Cristiano Giuffrida, Bos, H.J., Jakob Koschel,
linux-input, linux-kernel, Jiri Kosina, Roderick Colenbrander
In-Reply-To: <288ed0da-8903-7dda-eb4e-f17037031e68@molgen.mpg.de>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Wed 2023-05-10 12:12:50, Donald Buczek wrote:
> Is this series in a queue somewhere? Seems rather important and I don't find progress.
>
> Also, should be cc: stable@vger.kernel.org , right?
>
> CVE-2023-25012
It has Fixes, stable will pick it up.
And yes, "crafted USB device" can do a bad stuff. Severity is not too
high.
BR,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] HID: manually unregister leds on device removal to prevent UAFs
From: Benjamin Tissoires @ 2023-05-10 10:59 UTC (permalink / raw)
To: Donald Buczek
Cc: Pietro Borrello, Jiri Kosina, Hanno Zulla, Carlo Caione,
Pavel Machek, Lee Jones, Roderick Colenbrander, Sven Eckelmann,
linux-leds, Cristiano Giuffrida, Bos, H.J., Jakob Koschel,
linux-input, linux-kernel, Jiri Kosina, Roderick Colenbrander
In-Reply-To: <288ed0da-8903-7dda-eb4e-f17037031e68@molgen.mpg.de>
On Wed, May 10, 2023 at 12:21 PM Donald Buczek <buczek@molgen.mpg.de> wrote:
>
> Is this series in a queue somewhere?
Yes, but not in that form.
>
>
> Seems rather important and I don't find progress.
Well, there has been a v4 that has been merged already.
>
> Also, should be cc: stable@vger.kernel.org , right?
The fixes are already backported to stable, because Pietro added the
"fixes" tags which is a trigger for them to backport stuff.
>
> CVE-2023-25012
You have no idea how much I hate CVEs and how they are used as a way
to force an answer to an email or to force code inclusion...
Cheers,
Benjamin
>
> Best
>
> Donald
>
> On 1/26/23 1:24 AM, Pietro Borrello wrote:
> > I noticed a recurring pattern is present in multiple hid devices in the
> > Linux tree, where the LED controller of a device schedules a work_struct
> > to interact with the hardware.
> > The work_struct is embedded in the device structure and thus, is freed
> > at device removal.
> >
> > The issue is that a LED worker may be scheduled by a timer concurrently
> > with device removal, causing the work_struct to be accessed after having
> > been freed.
> > I was able to trigger the issue in hid-bigbenff.c and hid-asus.c
> > where the work_structs may be scheduled by the LED controller
> > while the device is disconnecting, triggering use-after-frees.
> > I can attach the reproducer, but it's very simple USB configuration,
> > using the /dev/raw-gadget interface with some more USB interactions
> > to manage LEDs configuration and pass checks in asus_kbd_init()
> > and asus_kbd_get_functions() in case of hid-asus.c.
> > I triggered the issue by connecting a device and immediately
> > disconnecting it, so that the remove function runs before the LED one
> > which remains pending.
> >
> > More drivers have the same pattern (hid-lg-g15.c, hid-playstation.c,
> > hid-sony.c) but I wasn't able to properly pass the right descriptors
> > to trigger the led configurations needed to trigger the workers.
> > Some other drivers manually unregister at removal (hid-corsair.c,
> > hid-gt683r.c, hid-lenovo.c) since they do not use the managed
> > interface, which is safe, to my understanding.
> > Also, a similar pattern is present with callbacks which schedule
> > a worker originating from input_ff_create_memless() (e.g.,
> > in hid-bigbenff.c) but in these cases, I wasn't able to trigger
> > the race condition with the event handling to schedule the worker
> > during device removal. However, I have no experience with the USB
> > protocol and I'm not able to say that they cannot be triggered.
> >
> > I am currently wondering if this is due to some emulation of the
> > /dev/raw-gadget interface or if it's effectively an issue with how each
> > device manages resource removal.
> > But I wonder why syzkaller didn't find any crash while fuzzing the
> > interface with upstream-usb.config, as they seem pretty
> > straightforward to trigger.
> > Configuring the kernel with CONFIG_DEBUG_OBJECTS, it emits
> > a warning in debug_check_no_obj_freed, which makes it clear that
> > device removal is freeing resources in use.
> > KASAN detects them as use-after-free.
> >
> > I am attaching multiple patches for all the drivers I suspect the bug
> > is present.
> > The proposed patches unregister the LED controllers before removing the
> > device itself.
> >
> > I attach the (partial for brevity) ODEBUG dumps:
> >
> > ```hid-bigbenff.c
> > [ 37.803135][ T1170] usb 1-1: USB disconnect, device number 2
> > [ 37.827979][ T1170] ODEBUG: free active (active state 0) object
> > type: work_struct hint: bigben_worker+0x0/0x860
> > [ 37.829634][ T1170] WARNING: CPU: 0 PID: 1170 at
> > lib/debugobjects.c:505 debug_check_no_obj_freed+0x43a/0x630
> > [ 37.830904][ T1170] Modules linked in:
> > [ 37.831413][ T1170] CPU: 0 PID: 1170 Comm: kworker/0:3 Not tainted
> > 6.1.0-rc4-dirty #43
> > [ 37.832465][ T1170] Hardware name: QEMU Standard PC (i440FX + PIIX,
> > 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
> > [ 37.833751][ T1170] Workqueue: usb_hub_wq hub_event
> > [ 37.834409][ T1170] RIP: 0010:debug_check_no_obj_freed+0x43a/0x630
> > [ 37.835218][ T1170] Code: 48 89 ef e8 28 82 58 ff 49 8b 14 24 4c 8b
> > 45 00 48 c7 c7 40 5f 09 87 48 c7 c6 60 5b 09 87 89 d9 4d 89 f9 31 c0
> > e8 46 25 ef fe <0f> 0b 4c 8b 64 24 20 48 ba 00 00 00 00 00 fc ff df ff
> > 05 4f 7c 17
> > [ 37.837667][ T1170] RSP: 0018:ffffc900006fee60 EFLAGS: 00010246
> > [ 37.838503][ T1170] RAX: 0d2d19ffcded3d00 RBX: 0000000000000000
> > RCX: ffff888117fc9b00
> > [ 37.839519][ T1170] RDX: 0000000000000000 RSI: 0000000000000000
> > RDI: 0000000000000000
> > [ 37.840570][ T1170] RBP: ffffffff86e88380 R08: ffffffff8130793b
> > R09: fffff520000dfd85
> > [ 37.841618][ T1170] R10: fffff520000dfd85 R11: 0000000000000000
> > R12: ffffffff87095fb8
> > [ 37.842649][ T1170] R13: ffff888117770ad8 R14: ffff888117770acc
> > R15: ffffffff852b7420
> > [ 37.843728][ T1170] FS: 0000000000000000(0000)
> > GS:ffff8881f6600000(0000) knlGS:0000000000000000
> > [ 37.844877][ T1170] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 37.845749][ T1170] CR2: 00007f992eaab380 CR3: 000000011834b000
> > CR4: 00000000001006f0
> > [ 37.846794][ T1170] Call Trace:
> > [ 37.847245][ T1170] <TASK>
> > [ 37.847643][ T1170] slab_free_freelist_hook+0x89/0x160
> > [ 37.848409][ T1170] ? devres_release_all+0x262/0x350
> > [ 37.849156][ T1170] __kmem_cache_free+0x71/0x110
> > [ 37.849829][ T1170] devres_release_all+0x262/0x350
> > [ 37.850478][ T1170] ? devres_release+0x90/0x90
> > [ 37.851118][ T1170] device_release_driver_internal+0x5e5/0x8a0
> > [ 37.851944][ T1170] bus_remove_device+0x2ea/0x400
> > [ 37.852611][ T1170] device_del+0x64f/0xb40
> > [ 37.853212][ T1170] ? kill_device+0x150/0x150
> > [ 37.853831][ T1170] ? print_irqtrace_events+0x1f0/0x1f0
> > [ 37.854564][ T1170] hid_destroy_device+0x66/0x100
> > [ 37.855226][ T1170] usbhid_disconnect+0x9a/0xc0
> > [ 37.855887][ T1170] usb_unbind_interface+0x1e1/0x890
> > ```
> >
> > ``` hid-asus.c
> > [ 77.409878][ T1169] usb 1-1: USB disconnect, device number 2
> > [ 77.423606][ T1169] ODEBUG: free active (active state 0) object
> > type: work_struct hint: asus_kbd_backlight_work+0x0/0x2c0
> > [ 77.425222][ T1169] WARNING: CPU: 0 PID: 1169 at
> > lib/debugobjects.c:505 debug_check_no_obj_freed+0x43a/0x630
> > [ 77.426599][ T1169] Modules linked in:
> > [ 77.427322][ T1169] CPU: 0 PID: 1169 Comm: kworker/0:3 Not tainted
> > 6.1.0-rc4-dirty #43
> > [ 77.428404][ T1169] Hardware name: QEMU Standard PC (i440FX + PIIX,
> > 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
> > [ 77.429644][ T1169] Workqueue: usb_hub_wq hub_event
> > [ 77.430296][ T1169] RIP: 0010:debug_check_no_obj_freed+0x43a/0x630
> > [ 77.431142][ T1169] Code: 48 89 ef e8 28 82 58 ff 49 8b 14 24 4c 8b
> > 45 00 48 c7 c7 40 5f 09 87 48 c7 c6 60 5b 09 87 89 d9 4d 89 f9 31 c0
> > e8 46 25 ef fe <0f> 0b 4c 8b 64 24 20 48 ba 00 00 00 00 00 fc ff df ff
> > 05 4f 7c 17
> > [ 77.433691][ T1169] RSP: 0018:ffffc9000069ee60 EFLAGS: 00010246
> > [ 77.434470][ T1169] RAX: b85d2b40c12d7600 RBX: 0000000000000000
> > RCX: ffff888117a78000
> > [ 77.435507][ T1169] RDX: 0000000000000000 RSI: 0000000080000000
> > RDI: 0000000000000000
> > [ 77.436521][ T1169] RBP: ffffffff86e88380 R08: ffffffff8130793b
> > R09: ffffed103ecc4ed6
> > [ 77.437582][ T1169] R10: ffffed103ecc4ed6 R11: 0000000000000000
> > R12: ffffffff87095fb8
> > [ 77.438593][ T1169] R13: ffff88810e348fe0 R14: ffff88810e348fd4
> > R15: ffffffff852b5780
> > [ 77.439667][ T1169] FS: 0000000000000000(0000)
> > GS:ffff8881f6600000(0000) knlGS:0000000000000000
> > [ 77.440842][ T1169] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 77.441688][ T1169] CR2: 00007ffc05495ff0 CR3: 000000010cdf0000
> > CR4: 00000000001006f0
> > [ 77.442720][ T1169] Call Trace:
> > [ 77.443167][ T1169] <TASK>
> > [ 77.443555][ T1169] slab_free_freelist_hook+0x89/0x160
> > [ 77.444302][ T1169] ? devres_release_all+0x262/0x350
> > [ 77.444990][ T1169] __kmem_cache_free+0x71/0x110
> > [ 77.445638][ T1169] devres_release_all+0x262/0x350
> > [ 77.446309][ T1169] ? devres_release+0x90/0x90
> > [ 77.446978][ T1169] device_release_driver_internal+0x5e5/0x8a0
> > [ 77.447748][ T1169] bus_remove_device+0x2ea/0x400
> > [ 77.448421][ T1169] device_del+0x64f/0xb40
> > [ 77.448976][ T1169] ? kill_device+0x150/0x150
> > [ 77.449577][ T1169] ? print_irqtrace_events+0x1f0/0x1f0
> > [ 77.450307][ T1169] hid_destroy_device+0x66/0x100
> > [ 77.450938][ T1169] usbhid_disconnect+0x9a/0xc0
> > ```
> >
> > To: Jiri Kosina <jikos@kernel.org>
> > To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > To: Hanno Zulla <kontakt@hanno.de>
> > To: Carlo Caione <carlo@endlessm.com>
> > To: Pavel Machek <pavel@ucw.cz>
> > To: Lee Jones <lee@kernel.org>
> > To: Roderick Colenbrander <roderick.colenbrander@sony.com>
> > To: Sven Eckelmann <sven@narfation.org>
> > Cc: linux-leds@vger.kernel.org
> > Cc: Cristiano Giuffrida <c.giuffrida@vu.nl>
> > Cc: "Bos, H.J." <h.j.bos@vu.nl>
> > Cc: Jakob Koschel <jkl820.git@gmail.com>
> > Cc: linux-input@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: Jiri Kosina <jkosina@suse.cz>
> > Cc: Roderick Colenbrander <roderick@gaikai.com>
> > Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
> >
> > ---
> > Pietro Borrello (5):
> > HID: bigben_remove: manually unregister leds
> > HID: asus_remove: manually unregister led
> > HID: dualsense_remove: manually unregister leds
> > HID: dualshock4_remove: manually unregister leds
> > HID: sony_remove: manually unregister leds
> >
> > drivers/hid/hid-asus.c | 1 +
> > drivers/hid/hid-bigbenff.c | 5 +++++
> > drivers/hid/hid-playstation.c | 8 ++++++++
> > drivers/hid/hid-sony.c | 8 ++++++++
> > 4 files changed, 22 insertions(+)
> > ---
> > base-commit: 2241ab53cbb5cdb08a6b2d4688feb13971058f65
> > change-id: 20230125-hid-unregister-leds-4cbf67099e1d
> >
> > Best regards,
> >
>
>
> --
> Donald Buczek
> buczek@molgen.mpg.de
> Tel: +49 30 8413 1433
>
^ permalink raw reply
* Re: [PATCH 0/5] HID: manually unregister leds on device removal to prevent UAFs
From: Donald Buczek @ 2023-05-10 10:12 UTC (permalink / raw)
To: Pietro Borrello, Jiri Kosina, Benjamin Tissoires, Hanno Zulla,
Carlo Caione, Pavel Machek, Lee Jones, Roderick Colenbrander,
Sven Eckelmann
Cc: linux-leds, Cristiano Giuffrida, Bos, H.J., Jakob Koschel,
linux-input, linux-kernel, Jiri Kosina, Roderick Colenbrander
In-Reply-To: <20230125-hid-unregister-leds-v1-0-9a5192dcef16@diag.uniroma1.it>
Is this series in a queue somewhere? Seems rather important and I don't find progress.
Also, should be cc: stable@vger.kernel.org , right?
CVE-2023-25012
Best
Donald
On 1/26/23 1:24 AM, Pietro Borrello wrote:
> I noticed a recurring pattern is present in multiple hid devices in the
> Linux tree, where the LED controller of a device schedules a work_struct
> to interact with the hardware.
> The work_struct is embedded in the device structure and thus, is freed
> at device removal.
>
> The issue is that a LED worker may be scheduled by a timer concurrently
> with device removal, causing the work_struct to be accessed after having
> been freed.
> I was able to trigger the issue in hid-bigbenff.c and hid-asus.c
> where the work_structs may be scheduled by the LED controller
> while the device is disconnecting, triggering use-after-frees.
> I can attach the reproducer, but it's very simple USB configuration,
> using the /dev/raw-gadget interface with some more USB interactions
> to manage LEDs configuration and pass checks in asus_kbd_init()
> and asus_kbd_get_functions() in case of hid-asus.c.
> I triggered the issue by connecting a device and immediately
> disconnecting it, so that the remove function runs before the LED one
> which remains pending.
>
> More drivers have the same pattern (hid-lg-g15.c, hid-playstation.c,
> hid-sony.c) but I wasn't able to properly pass the right descriptors
> to trigger the led configurations needed to trigger the workers.
> Some other drivers manually unregister at removal (hid-corsair.c,
> hid-gt683r.c, hid-lenovo.c) since they do not use the managed
> interface, which is safe, to my understanding.
> Also, a similar pattern is present with callbacks which schedule
> a worker originating from input_ff_create_memless() (e.g.,
> in hid-bigbenff.c) but in these cases, I wasn't able to trigger
> the race condition with the event handling to schedule the worker
> during device removal. However, I have no experience with the USB
> protocol and I'm not able to say that they cannot be triggered.
>
> I am currently wondering if this is due to some emulation of the
> /dev/raw-gadget interface or if it's effectively an issue with how each
> device manages resource removal.
> But I wonder why syzkaller didn't find any crash while fuzzing the
> interface with upstream-usb.config, as they seem pretty
> straightforward to trigger.
> Configuring the kernel with CONFIG_DEBUG_OBJECTS, it emits
> a warning in debug_check_no_obj_freed, which makes it clear that
> device removal is freeing resources in use.
> KASAN detects them as use-after-free.
>
> I am attaching multiple patches for all the drivers I suspect the bug
> is present.
> The proposed patches unregister the LED controllers before removing the
> device itself.
>
> I attach the (partial for brevity) ODEBUG dumps:
>
> ```hid-bigbenff.c
> [ 37.803135][ T1170] usb 1-1: USB disconnect, device number 2
> [ 37.827979][ T1170] ODEBUG: free active (active state 0) object
> type: work_struct hint: bigben_worker+0x0/0x860
> [ 37.829634][ T1170] WARNING: CPU: 0 PID: 1170 at
> lib/debugobjects.c:505 debug_check_no_obj_freed+0x43a/0x630
> [ 37.830904][ T1170] Modules linked in:
> [ 37.831413][ T1170] CPU: 0 PID: 1170 Comm: kworker/0:3 Not tainted
> 6.1.0-rc4-dirty #43
> [ 37.832465][ T1170] Hardware name: QEMU Standard PC (i440FX + PIIX,
> 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
> [ 37.833751][ T1170] Workqueue: usb_hub_wq hub_event
> [ 37.834409][ T1170] RIP: 0010:debug_check_no_obj_freed+0x43a/0x630
> [ 37.835218][ T1170] Code: 48 89 ef e8 28 82 58 ff 49 8b 14 24 4c 8b
> 45 00 48 c7 c7 40 5f 09 87 48 c7 c6 60 5b 09 87 89 d9 4d 89 f9 31 c0
> e8 46 25 ef fe <0f> 0b 4c 8b 64 24 20 48 ba 00 00 00 00 00 fc ff df ff
> 05 4f 7c 17
> [ 37.837667][ T1170] RSP: 0018:ffffc900006fee60 EFLAGS: 00010246
> [ 37.838503][ T1170] RAX: 0d2d19ffcded3d00 RBX: 0000000000000000
> RCX: ffff888117fc9b00
> [ 37.839519][ T1170] RDX: 0000000000000000 RSI: 0000000000000000
> RDI: 0000000000000000
> [ 37.840570][ T1170] RBP: ffffffff86e88380 R08: ffffffff8130793b
> R09: fffff520000dfd85
> [ 37.841618][ T1170] R10: fffff520000dfd85 R11: 0000000000000000
> R12: ffffffff87095fb8
> [ 37.842649][ T1170] R13: ffff888117770ad8 R14: ffff888117770acc
> R15: ffffffff852b7420
> [ 37.843728][ T1170] FS: 0000000000000000(0000)
> GS:ffff8881f6600000(0000) knlGS:0000000000000000
> [ 37.844877][ T1170] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 37.845749][ T1170] CR2: 00007f992eaab380 CR3: 000000011834b000
> CR4: 00000000001006f0
> [ 37.846794][ T1170] Call Trace:
> [ 37.847245][ T1170] <TASK>
> [ 37.847643][ T1170] slab_free_freelist_hook+0x89/0x160
> [ 37.848409][ T1170] ? devres_release_all+0x262/0x350
> [ 37.849156][ T1170] __kmem_cache_free+0x71/0x110
> [ 37.849829][ T1170] devres_release_all+0x262/0x350
> [ 37.850478][ T1170] ? devres_release+0x90/0x90
> [ 37.851118][ T1170] device_release_driver_internal+0x5e5/0x8a0
> [ 37.851944][ T1170] bus_remove_device+0x2ea/0x400
> [ 37.852611][ T1170] device_del+0x64f/0xb40
> [ 37.853212][ T1170] ? kill_device+0x150/0x150
> [ 37.853831][ T1170] ? print_irqtrace_events+0x1f0/0x1f0
> [ 37.854564][ T1170] hid_destroy_device+0x66/0x100
> [ 37.855226][ T1170] usbhid_disconnect+0x9a/0xc0
> [ 37.855887][ T1170] usb_unbind_interface+0x1e1/0x890
> ```
>
> ``` hid-asus.c
> [ 77.409878][ T1169] usb 1-1: USB disconnect, device number 2
> [ 77.423606][ T1169] ODEBUG: free active (active state 0) object
> type: work_struct hint: asus_kbd_backlight_work+0x0/0x2c0
> [ 77.425222][ T1169] WARNING: CPU: 0 PID: 1169 at
> lib/debugobjects.c:505 debug_check_no_obj_freed+0x43a/0x630
> [ 77.426599][ T1169] Modules linked in:
> [ 77.427322][ T1169] CPU: 0 PID: 1169 Comm: kworker/0:3 Not tainted
> 6.1.0-rc4-dirty #43
> [ 77.428404][ T1169] Hardware name: QEMU Standard PC (i440FX + PIIX,
> 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
> [ 77.429644][ T1169] Workqueue: usb_hub_wq hub_event
> [ 77.430296][ T1169] RIP: 0010:debug_check_no_obj_freed+0x43a/0x630
> [ 77.431142][ T1169] Code: 48 89 ef e8 28 82 58 ff 49 8b 14 24 4c 8b
> 45 00 48 c7 c7 40 5f 09 87 48 c7 c6 60 5b 09 87 89 d9 4d 89 f9 31 c0
> e8 46 25 ef fe <0f> 0b 4c 8b 64 24 20 48 ba 00 00 00 00 00 fc ff df ff
> 05 4f 7c 17
> [ 77.433691][ T1169] RSP: 0018:ffffc9000069ee60 EFLAGS: 00010246
> [ 77.434470][ T1169] RAX: b85d2b40c12d7600 RBX: 0000000000000000
> RCX: ffff888117a78000
> [ 77.435507][ T1169] RDX: 0000000000000000 RSI: 0000000080000000
> RDI: 0000000000000000
> [ 77.436521][ T1169] RBP: ffffffff86e88380 R08: ffffffff8130793b
> R09: ffffed103ecc4ed6
> [ 77.437582][ T1169] R10: ffffed103ecc4ed6 R11: 0000000000000000
> R12: ffffffff87095fb8
> [ 77.438593][ T1169] R13: ffff88810e348fe0 R14: ffff88810e348fd4
> R15: ffffffff852b5780
> [ 77.439667][ T1169] FS: 0000000000000000(0000)
> GS:ffff8881f6600000(0000) knlGS:0000000000000000
> [ 77.440842][ T1169] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 77.441688][ T1169] CR2: 00007ffc05495ff0 CR3: 000000010cdf0000
> CR4: 00000000001006f0
> [ 77.442720][ T1169] Call Trace:
> [ 77.443167][ T1169] <TASK>
> [ 77.443555][ T1169] slab_free_freelist_hook+0x89/0x160
> [ 77.444302][ T1169] ? devres_release_all+0x262/0x350
> [ 77.444990][ T1169] __kmem_cache_free+0x71/0x110
> [ 77.445638][ T1169] devres_release_all+0x262/0x350
> [ 77.446309][ T1169] ? devres_release+0x90/0x90
> [ 77.446978][ T1169] device_release_driver_internal+0x5e5/0x8a0
> [ 77.447748][ T1169] bus_remove_device+0x2ea/0x400
> [ 77.448421][ T1169] device_del+0x64f/0xb40
> [ 77.448976][ T1169] ? kill_device+0x150/0x150
> [ 77.449577][ T1169] ? print_irqtrace_events+0x1f0/0x1f0
> [ 77.450307][ T1169] hid_destroy_device+0x66/0x100
> [ 77.450938][ T1169] usbhid_disconnect+0x9a/0xc0
> ```
>
> To: Jiri Kosina <jikos@kernel.org>
> To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> To: Hanno Zulla <kontakt@hanno.de>
> To: Carlo Caione <carlo@endlessm.com>
> To: Pavel Machek <pavel@ucw.cz>
> To: Lee Jones <lee@kernel.org>
> To: Roderick Colenbrander <roderick.colenbrander@sony.com>
> To: Sven Eckelmann <sven@narfation.org>
> Cc: linux-leds@vger.kernel.org
> Cc: Cristiano Giuffrida <c.giuffrida@vu.nl>
> Cc: "Bos, H.J." <h.j.bos@vu.nl>
> Cc: Jakob Koschel <jkl820.git@gmail.com>
> Cc: linux-input@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Jiri Kosina <jkosina@suse.cz>
> Cc: Roderick Colenbrander <roderick@gaikai.com>
> Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
>
> ---
> Pietro Borrello (5):
> HID: bigben_remove: manually unregister leds
> HID: asus_remove: manually unregister led
> HID: dualsense_remove: manually unregister leds
> HID: dualshock4_remove: manually unregister leds
> HID: sony_remove: manually unregister leds
>
> drivers/hid/hid-asus.c | 1 +
> drivers/hid/hid-bigbenff.c | 5 +++++
> drivers/hid/hid-playstation.c | 8 ++++++++
> drivers/hid/hid-sony.c | 8 ++++++++
> 4 files changed, 22 insertions(+)
> ---
> base-commit: 2241ab53cbb5cdb08a6b2d4688feb13971058f65
> change-id: 20230125-hid-unregister-leds-4cbf67099e1d
>
> Best regards,
>
--
Donald Buczek
buczek@molgen.mpg.de
Tel: +49 30 8413 1433
^ permalink raw reply
* Re: [PATCH 0/2] Input: st1232: wakeup in Suspend to idle
From: Javier Carrasco @ 2023-05-10 8:42 UTC (permalink / raw)
To: linux-input, linux-kernel
Cc: Dmitry Torokhov, Jonathan Cameron, Linus Walleij, Uwe Kleine-g,
Michael Riesch
In-Reply-To: <20230403124707.102986-1-javier.carrasco@wolfvision.net>
Gentle ping.
On 03.04.23 14:47, Javier Carrasco wrote:
> The st1232 touchscreen provides an interrupt line that can be configured
> as a wakeup source, and currently it is possible to use this mechanism in
> "Suspend to RAM" and "Hibernate" power states.
>
> Unfortunately, that does not work in "Suspend to idle" (freeze) because
> the device driver disables the interrupts in its suspend callback.
> Given that the interrupt handling prior to entering the mentioned power
> state modes is managed by the power subsystem, the irq enabling/disabling
> can be removed from the touchscreen driver, allowing the device to work
> as a wakeup source in "Suspend to idle".
>
> Given that the st1232 device driver does not reflect its wakeup events
> in sysfs, this series also adds pm_wakeup_event to the interrupt
> handler.
>
> These changes have been successfully tested with an ST1624-N32C and a
> Rockchip-based platform.
>
> Javier Carrasco (2):
> Input: st1232 - remove enable/disable irq in resume/suspend callbacks
> Input: st1232 - add wake up event counting
>
> drivers/input/touchscreen/st1232.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* RE: [PATCH] Input: adxl34x - do not hardcode interrupt trigger type
From: Hennerich, Michael @ 2023-05-10 7:34 UTC (permalink / raw)
To: Marek Vasut, linux-input@vger.kernel.org; +Cc: Dmitry Torokhov
In-Reply-To: <20230509203555.549158-1-marex@denx.de>
> -----Original Message-----
> From: Marek Vasut <marex@denx.de>
> Sent: Dienstag, 9. Mai 2023 22:36
> To: linux-input@vger.kernel.org
> Cc: Marek Vasut <marex@denx.de>; Dmitry Torokhov
> <dmitry.torokhov@gmail.com>; Hennerich, Michael
> <Michael.Hennerich@analog.com>
> Subject: [PATCH] Input: adxl34x - do not hardcode interrupt trigger type
>
> Instead of hardcoding IRQ trigger type to IRQF_TRIGGER_HIGH, let's respect
> the settings specified in the firmware description.
>
> Fixes: e27c729219ad2 ("Input: add driver for ADXL345/346 Digital
> Accelerometers")
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Michael Hennerich <michael.hennerich@analog.com>
> Cc: linux-input@vger.kernel.org
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
> ---
> drivers/input/misc/adxl34x.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/input/misc/adxl34x.c b/drivers/input/misc/adxl34x.c index
> eecca671b5884..a3f45e0ee0c75 100644
> --- a/drivers/input/misc/adxl34x.c
> +++ b/drivers/input/misc/adxl34x.c
> @@ -817,8 +817,7 @@ struct adxl34x *adxl34x_probe(struct device *dev, int
> irq,
> AC_WRITE(ac, POWER_CTL, 0);
>
> err = request_threaded_irq(ac->irq, NULL, adxl34x_irq,
> - IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> - dev_name(dev), ac);
> + IRQF_ONESHOT, dev_name(dev), ac);
> if (err) {
> dev_err(dev, "irq %d busy?\n", ac->irq);
> goto err_free_mem;
> --
> 2.39.2
^ permalink raw reply
* [PATCH AUTOSEL 4.19 2/2] Input: xpad - add constants for GIP interface numbers
From: Sasha Levin @ 2023-05-09 21:21 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vicki Pfau, Dmitry Torokhov, Sasha Levin, rojtberg, nate,
mkorpershoek, matthias.benkmann, chaorace, s.demassari,
linux-input
In-Reply-To: <20230509212110.22736-1-sashal@kernel.org>
From: Vicki Pfau <vi@endrift.com>
[ Upstream commit f9b2e603c6216824e34dc9a67205d98ccc9a41ca ]
Wired GIP devices present multiple interfaces with the same USB identification
other than the interface number. This adds constants for differentiating two of
them and uses them where appropriate
Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20230411031650.960322-2-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/joystick/xpad.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index c125cd42faee7..0a85f0817662a 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -503,6 +503,9 @@ struct xboxone_init_packet {
}
+#define GIP_WIRED_INTF_DATA 0
+#define GIP_WIRED_INTF_AUDIO 1
+
/*
* This packet is required for all Xbox One pads with 2015
* or later firmware installed (or present from the factory).
@@ -1827,7 +1830,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
}
if (xpad->xtype == XTYPE_XBOXONE &&
- intf->cur_altsetting->desc.bInterfaceNumber != 0) {
+ intf->cur_altsetting->desc.bInterfaceNumber != GIP_WIRED_INTF_DATA) {
/*
* The Xbox One controller lists three interfaces all with the
* same interface class, subclass and protocol. Differentiate by
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.10 5/5] Input: xpad - add constants for GIP interface numbers
From: Sasha Levin @ 2023-05-09 21:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vicki Pfau, Dmitry Torokhov, Sasha Levin, rojtberg, nate,
mkorpershoek, pgriffais, chaorace, s.demassari, linux-input
In-Reply-To: <20230509212044.22294-1-sashal@kernel.org>
From: Vicki Pfau <vi@endrift.com>
[ Upstream commit f9b2e603c6216824e34dc9a67205d98ccc9a41ca ]
Wired GIP devices present multiple interfaces with the same USB identification
other than the interface number. This adds constants for differentiating two of
them and uses them where appropriate
Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20230411031650.960322-2-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/joystick/xpad.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 70dedc0f7827c..0bd55e1fca372 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -489,6 +489,9 @@ struct xboxone_init_packet {
}
+#define GIP_WIRED_INTF_DATA 0
+#define GIP_WIRED_INTF_AUDIO 1
+
/*
* This packet is required for all Xbox One pads with 2015
* or later firmware installed (or present from the factory).
@@ -1813,7 +1816,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
}
if (xpad->xtype == XTYPE_XBOXONE &&
- intf->cur_altsetting->desc.bInterfaceNumber != 0) {
+ intf->cur_altsetting->desc.bInterfaceNumber != GIP_WIRED_INTF_DATA) {
/*
* The Xbox One controller lists three interfaces all with the
* same interface class, subclass and protocol. Differentiate by
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 2/2] Input: xpad - add constants for GIP interface numbers
From: Sasha Levin @ 2023-05-09 21:21 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vicki Pfau, Dmitry Torokhov, Sasha Levin, rojtberg, nate,
mkorpershoek, radon86dev, s.demassari, chaorace, linux-input
In-Reply-To: <20230509212115.22774-1-sashal@kernel.org>
From: Vicki Pfau <vi@endrift.com>
[ Upstream commit f9b2e603c6216824e34dc9a67205d98ccc9a41ca ]
Wired GIP devices present multiple interfaces with the same USB identification
other than the interface number. This adds constants for differentiating two of
them and uses them where appropriate
Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20230411031650.960322-2-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/joystick/xpad.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 1a12f95227301..f1c2bc108fd76 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -506,6 +506,9 @@ struct xboxone_init_packet {
}
+#define GIP_WIRED_INTF_DATA 0
+#define GIP_WIRED_INTF_AUDIO 1
+
/*
* This packet is required for all Xbox One pads with 2015
* or later firmware installed (or present from the factory).
@@ -1830,7 +1833,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
}
if (xpad->xtype == XTYPE_XBOXONE &&
- intf->cur_altsetting->desc.bInterfaceNumber != 0) {
+ intf->cur_altsetting->desc.bInterfaceNumber != GIP_WIRED_INTF_DATA) {
/*
* The Xbox One controller lists three interfaces all with the
* same interface class, subclass and protocol. Differentiate by
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 4/4] Input: xpad - add constants for GIP interface numbers
From: Sasha Levin @ 2023-05-09 21:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vicki Pfau, Dmitry Torokhov, Sasha Levin, rojtberg, nate,
mkorpershoek, pgriffais, chaorace, s.demassari, linux-input
In-Reply-To: <20230509212058.22651-1-sashal@kernel.org>
From: Vicki Pfau <vi@endrift.com>
[ Upstream commit f9b2e603c6216824e34dc9a67205d98ccc9a41ca ]
Wired GIP devices present multiple interfaces with the same USB identification
other than the interface number. This adds constants for differentiating two of
them and uses them where appropriate
Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20230411031650.960322-2-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/joystick/xpad.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 70dedc0f7827c..0bd55e1fca372 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -489,6 +489,9 @@ struct xboxone_init_packet {
}
+#define GIP_WIRED_INTF_DATA 0
+#define GIP_WIRED_INTF_AUDIO 1
+
/*
* This packet is required for all Xbox One pads with 2015
* or later firmware installed (or present from the factory).
@@ -1813,7 +1816,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
}
if (xpad->xtype == XTYPE_XBOXONE &&
- intf->cur_altsetting->desc.bInterfaceNumber != 0) {
+ intf->cur_altsetting->desc.bInterfaceNumber != GIP_WIRED_INTF_DATA) {
/*
* The Xbox One controller lists three interfaces all with the
* same interface class, subclass and protocol. Differentiate by
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.15 13/13] Input: xpad - add constants for GIP interface numbers
From: Sasha Levin @ 2023-05-09 21:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vicki Pfau, Dmitry Torokhov, Sasha Levin, rojtberg, nate,
mkorpershoek, pgriffais, aicommander, chaorace, s.demassari,
linux-input
In-Reply-To: <20230509212023.22105-1-sashal@kernel.org>
From: Vicki Pfau <vi@endrift.com>
[ Upstream commit f9b2e603c6216824e34dc9a67205d98ccc9a41ca ]
Wired GIP devices present multiple interfaces with the same USB identification
other than the interface number. This adds constants for differentiating two of
them and uses them where appropriate
Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20230411031650.960322-2-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/joystick/xpad.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index dbfabd229a7c6..a7af9b56e338f 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -493,6 +493,9 @@ struct xboxone_init_packet {
}
+#define GIP_WIRED_INTF_DATA 0
+#define GIP_WIRED_INTF_AUDIO 1
+
/*
* This packet is required for all Xbox One pads with 2015
* or later firmware installed (or present from the factory).
@@ -1821,7 +1824,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
}
if (xpad->xtype == XTYPE_XBOXONE &&
- intf->cur_altsetting->desc.bInterfaceNumber != 0) {
+ intf->cur_altsetting->desc.bInterfaceNumber != GIP_WIRED_INTF_DATA) {
/*
* The Xbox One controller lists three interfaces all with the
* same interface class, subclass and protocol. Differentiate by
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.2 15/18] Input: xpad - add constants for GIP interface numbers
From: Sasha Levin @ 2023-05-09 21:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vicki Pfau, Dmitry Torokhov, Sasha Levin, rojtberg, nate,
mkorpershoek, s.demassari, chaorace, linux-input
In-Reply-To: <20230509211958.21596-1-sashal@kernel.org>
From: Vicki Pfau <vi@endrift.com>
[ Upstream commit f9b2e603c6216824e34dc9a67205d98ccc9a41ca ]
Wired GIP devices present multiple interfaces with the same USB identification
other than the interface number. This adds constants for differentiating two of
them and uses them where appropriate
Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20230411031650.960322-2-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/joystick/xpad.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index cd36cf7165423..d06a6199a1961 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -557,6 +557,9 @@ struct xboxone_init_packet {
#define GIP_MOTOR_LT BIT(3)
#define GIP_MOTOR_ALL (GIP_MOTOR_R | GIP_MOTOR_L | GIP_MOTOR_RT | GIP_MOTOR_LT)
+#define GIP_WIRED_INTF_DATA 0
+#define GIP_WIRED_INTF_AUDIO 1
+
/*
* This packet is required for all Xbox One pads with 2015
* or later firmware installed (or present from the factory).
@@ -2001,7 +2004,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
}
if (xpad->xtype == XTYPE_XBOXONE &&
- intf->cur_altsetting->desc.bInterfaceNumber != 0) {
+ intf->cur_altsetting->desc.bInterfaceNumber != GIP_WIRED_INTF_DATA) {
/*
* The Xbox One controller lists three interfaces all with the
* same interface class, subclass and protocol. Differentiate by
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.3 15/18] Input: xpad - add constants for GIP interface numbers
From: Sasha Levin @ 2023-05-09 21:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vicki Pfau, Dmitry Torokhov, Sasha Levin, rojtberg, nate,
mkorpershoek, chaorace, pgriffais, s.demassari, linux-input
In-Reply-To: <20230509211928.21010-1-sashal@kernel.org>
From: Vicki Pfau <vi@endrift.com>
[ Upstream commit f9b2e603c6216824e34dc9a67205d98ccc9a41ca ]
Wired GIP devices present multiple interfaces with the same USB identification
other than the interface number. This adds constants for differentiating two of
them and uses them where appropriate
Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20230411031650.960322-2-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/joystick/xpad.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 29131f1a2f067..f617b2c60819c 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -559,6 +559,9 @@ struct xboxone_init_packet {
#define GIP_MOTOR_LT BIT(3)
#define GIP_MOTOR_ALL (GIP_MOTOR_R | GIP_MOTOR_L | GIP_MOTOR_RT | GIP_MOTOR_LT)
+#define GIP_WIRED_INTF_DATA 0
+#define GIP_WIRED_INTF_AUDIO 1
+
/*
* This packet is required for all Xbox One pads with 2015
* or later firmware installed (or present from the factory).
@@ -2003,7 +2006,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
}
if (xpad->xtype == XTYPE_XBOXONE &&
- intf->cur_altsetting->desc.bInterfaceNumber != 0) {
+ intf->cur_altsetting->desc.bInterfaceNumber != GIP_WIRED_INTF_DATA) {
/*
* The Xbox One controller lists three interfaces all with the
* same interface class, subclass and protocol. Differentiate by
--
2.39.2
^ permalink raw reply related
* [PATCH] Input: adxl34x - do not hardcode interrupt trigger type
From: Marek Vasut @ 2023-05-09 20:35 UTC (permalink / raw)
To: linux-input; +Cc: Marek Vasut, Dmitry Torokhov, Michael Hennerich
Instead of hardcoding IRQ trigger type to IRQF_TRIGGER_HIGH, let's
respect the settings specified in the firmware description.
Fixes: e27c729219ad2 ("Input: add driver for ADXL345/346 Digital Accelerometers")
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: linux-input@vger.kernel.org
---
drivers/input/misc/adxl34x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/input/misc/adxl34x.c b/drivers/input/misc/adxl34x.c
index eecca671b5884..a3f45e0ee0c75 100644
--- a/drivers/input/misc/adxl34x.c
+++ b/drivers/input/misc/adxl34x.c
@@ -817,8 +817,7 @@ struct adxl34x *adxl34x_probe(struct device *dev, int irq,
AC_WRITE(ac, POWER_CTL, 0);
err = request_threaded_irq(ac->irq, NULL, adxl34x_irq,
- IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- dev_name(dev), ac);
+ IRQF_ONESHOT, dev_name(dev), ac);
if (err) {
dev_err(dev, "irq %d busy?\n", ac->irq);
goto err_free_mem;
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v4 1/2] dt-bindings: gpio: Convert STMPE GPIO to YAML schema
From: Krzysztof Kozlowski @ 2023-05-09 17:25 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Maxime Coquelin, Alexandre Torgue,
Dmitry Torokhov, Lee Jones, Philippe Schenker, Stefan Agner,
Marek Vasut, Steffen Trumtrar
Cc: linux-gpio, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, linux-input
In-Reply-To: <20230426-stmpe-dt-bindings-v4-1-36fdd53d9919@linaro.org>
On 08/05/2023 14:35, Linus Walleij wrote:
> This rewrites the STMPE GPIO bindings to a YAML schema.
>
> We add the properties that are used in the widely used
> STMPE GPIO device nodes found in the wild, most notably
> interrupt support, so interrupt-cells and
> interrupt-controller is now part of the bindings.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] Input: cs40l26: Support for CS40L26 Boosted Haptic Amplifier
From: Charles Keepax @ 2023-05-09 10:22 UTC (permalink / raw)
To: Jeff LaBundy
Cc: Fred Treven, dmitry.torokhov@gmail.com, Ben Bright,
James Ogletree, lee@kernel.org, jdelvare@suse.de, joel@jms.id.au,
cy_huang@richtek.com, rdunlap@infradead.org,
eajames@linux.ibm.com, ping.bai@nxp.com, msp@baylibre.com,
arnd@arndb.de, bartosz.golaszewski@linaro.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
patches@opensource.cirrus.com
In-Reply-To: <ZFa42bBbX+SDuoXg@nixie71>
On Sat, May 06, 2023 at 03:30:17PM -0500, Jeff LaBundy wrote:
> On Thu, May 04, 2023 at 09:51:37PM +0000, Fred Treven wrote:
> > >> +const struct dev_pm_ops cs40l26_pm_ops = {
> > >> + SET_RUNTIME_PM_OPS(cs40l26_suspend, cs40l26_resume, NULL)
> > >> + SET_SYSTEM_SLEEP_PM_OPS(cs40l26_sys_suspend, cs40l26_sys_resume)
> > >> + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(cs40l26_sys_suspend_noirq, cs40l26_sys_resume_noirq)
> > >> +};
> > >> +EXPORT_SYMBOL_GPL(cs40l26_pm_ops);
> > >
> > > Please use latest macros (e.g. DEFINE_SIMPLE_DEV_PM_OPS).
> >
> > When looking at these *_PM_OPS* macros that replace the deprecated versions,
> > it is unclear to me how to maintain support for *_sys_* and
> > *_sys_*_noirq* functions. Would these all need to be separately defined
> > via DEFINE_SIMPLE_DEV_PM_OPS?
> > Would the *_sys_* definitions still be defined through a struct i.e.
> > const struct dev_pm_ops cs40l26_sys_pm_ops which is then exported as it
> > is in my initial submission?
> > I’m unsure how to handle these cases with the latest macros.
>
> I don't happen to see macros for suspend_noirq and resume_noirq, so maybe you
> cannot use macros here after all and will instead have to fall back to tacking
> on __maybe_unused to these callbacks to accommodate the !CONFIG_PM case.
>
Correct this device can not presently use the simple macros.
> That being said, what are you ultimately trying to accomplish here with these
> noirq variants? For example the print statement says "early resume" when in
> fact a different callback exists for that (resume_early).
>
> On that note, why to disable interrupts during system suspend? I can imagine a
> use-case where a customer ties the output of a force sensor to a CS40L26 GPIO
> for low-latency haptic trigger, and then the CS40L26 interrupt output to the
> SoC as a wake-up trigger. Does the part not support this use-case? I vaguely
> seem to remember an issue with this on L25.
>
> Also, why is the logic inverted for the noirq variants? These are simply meant
> to accommodate additional tasks that need a guarantee the device's interrupt
> handler is not running (for example, clear or acknowledge a pending interrupt).
> In case I have misunderstood the intent, please let me know.
>
This is a generic issue with devices that use PM runtime, but
also have IRQs. The system suspend process re-enables IRQs before it
re-enables the PM runtime. This means if your IRQ handler uses PM
runtime and you get an IRQ in that window things don't work. The
simplest solution is to disable IRQs across the window. Ideally
one day this would probably get fixed in the PM core, but that is
likely a massively non-trivial amount of work.
To be clear the code allows IRQs whilst in system suspend (aka wakes)
and whilst resumed. As the IRQ output of the chip is level based, the
temporary disable only causes a slight delay in handling the IRQ.
> One last gripe, then I promise to stop bringing it up :) But the mental gymnastics
> required to explain the no-fewer-than-six PM callbacks used here, as well as how
> to support the !CONFIG_PM case, are in some ways additional nudges toward getting
> rid of this massive amount of PM overhead and relying on the device's internal
> power management as so many modern input devices now do. As a rule of thumb, if
> you're having to jump through a lot of hoops to do simple things that others seem
> to be doing with less work, something is wrong.
>
I am not sure there are significant issues supporting the
!CONFIG_PM case, you need a couple __maybe_unused's. What issues
are you expecting here? Yeah ok you get worse power consumption
in that case, but you did turn off power management, presumably
you were not that concerned about power consumption.
> In your defense, however, you are unlikely to come across many devices that do
> not enable CONFIG_PM given this device's target application. That being said, it
> is not unheard of for OEMs building wall-powered devices to enable CONFIG_PM but
> inhibit system suspend using a wake_lock because of some HW bug.
>
Again remember the system vs runtime suspend here. Holding a
system wake lock will have no effect on the runtime PM.
> Therefore, it seems a bit unfortunate that those use-cases wouldn't get to enjoy
> the power savings this devices offers. That's just my $.02; I also understand
> the reasons behind the current implementation and won't push you to change it.
The power savings from not blocking suspend are tiny, at least
outwith the !CONFIG_PM case. The driver is only blocking hibernate
when it is actively talking to the device, during which time the
device will very likely not be hibernating anyway.
I think really it is up to Fred and Ben who are supporting the
driver. If they feel the device will work reliably that way,
I certainly won't stand in the way. But I would be keen to avoid
a situation where all the downstream implementations (ie. most
of the testing) use PM runtime and the upstream code is full of
corner cases that haven't been ironed out, so I would like to
know they are going to be moving our customers over to this new
mode of operation if they decide to switch to it. Certainly you
are not wrong that it would save a fair amount of code from the
driver and make it look a lot cleaner.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH] touchscreen_dmi: Add info for the Dexp Ursus KX210i
From: Hans de Goede @ 2023-05-09 8:53 UTC (permalink / raw)
To: Andrey Avdeev, linux-input
In-Reply-To: <ZE4gRgzRQCjXFYD0@avdeevavpc>
Hi,
On 4/30/23 10:01, Andrey Avdeev wrote:
> Add touchscreen info for the Dexp Ursus KX210i
>
> Signed-off-by: Andrey Avdeev <jamesstoun@gmail.com>
Thank you for your patch, I've applied this patch to my fixes
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=fixes
Note it will show up in my fixes branch once I've pushed my
local branch there, which might take a while.
I will include this patch in my next fixes pull-req to Linus
for the current kernel development cycle.
Regards,
Hans
> ---
> drivers/platform/x86/touchscreen_dmi.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
> index 13802a3c3591..0d3ac1e7a43c 100644
> --- a/drivers/platform/x86/touchscreen_dmi.c
> +++ b/drivers/platform/x86/touchscreen_dmi.c
> @@ -336,6 +336,22 @@ static const struct ts_dmi_data dexp_ursus_7w_data = {
> .properties = dexp_ursus_7w_props,
> };
>
> +static const struct property_entry dexp_ursus_kx210i_props[] = {
> + PROPERTY_ENTRY_U32("touchscreen-min-x", 5),
> + PROPERTY_ENTRY_U32("touchscreen-min-y", 2),
> + PROPERTY_ENTRY_U32("touchscreen-size-x", 1720),
> + PROPERTY_ENTRY_U32("touchscreen-size-y", 1137),
> + PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-dexp-ursus-kx210i.fw"),
> + PROPERTY_ENTRY_U32("silead,max-fingers", 10),
> + PROPERTY_ENTRY_BOOL("silead,home-button"),
> + { }
> +};
> +
> +static const struct ts_dmi_data dexp_ursus_kx210i_data = {
> + .acpi_name = "MSSL1680:00",
> + .properties = dexp_ursus_kx210i_props,
> +};
> +
> static const struct property_entry digma_citi_e200_props[] = {
> PROPERTY_ENTRY_U32("touchscreen-size-x", 1980),
> PROPERTY_ENTRY_U32("touchscreen-size-y", 1500),
> @@ -1185,6 +1201,14 @@ const struct dmi_system_id touchscreen_dmi_table[] = {
> DMI_MATCH(DMI_PRODUCT_NAME, "7W"),
> },
> },
> + {
> + /* DEXP Ursus KX210i */
> + .driver_data = (void *)&dexp_ursus_kx210i_data,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "INSYDE Corp."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "S107I"),
> + },
> + },
> {
> /* Digma Citi E200 */
> .driver_data = (void *)&digma_citi_e200_data,
^ permalink raw reply
* Pompy ciepła - nowe warunki
From: Damian Hordych @ 2023-05-08 7:45 UTC (permalink / raw)
To: linux-input
Dzień dobry,
w ramach nowej edycji programu Czyste Powietrze dla klientów indywidualnych mogą otrzymać Państwo do 135 tys. zł wsparcia na zakup pompy ciepła.
Prócz wyższego dofinansowania program zakłada m.in. podwyższenie progów dochodowych oraz możliwość złożenia kolejnego wniosku o dofinansowanie dla tych, którzy już wcześniej skorzystali z Programu.
Jako firma specjalizująca się w dostawie, montażu i serwisie pomp ciepła pomożemy Państwu w uzyskaniu dofinansowania wraz z kompleksową realizacją całego projektu.
Są Państwo zainteresowani?
Pozdrawiam
Damian Hordych
^ permalink raw reply
* [PATCH 3/5] HID: amd_sfh: Split sensor and HID initialization
From: Basavaraj Natikar @ 2023-05-09 6:58 UTC (permalink / raw)
To: jikos, benjamin.tissoires, linux-input; +Cc: Basavaraj Natikar
In-Reply-To: <20230509065857.4170013-1-Basavaraj.Natikar@amd.com>
Sensors are enabled independently of HID device initialization. Sensor
initialization should be kept separate in this case, while HID devices
should be initialized according to the sensor state. Hence split sensor
initialization and HID initialization into separate blocks.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
---
drivers/hid/amd-sfh-hid/amd_sfh_client.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_client.c b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
index 3d62527f87d3..bdb578e0899f 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_client.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
@@ -215,7 +215,7 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
struct device *dev;
u32 feature_report_size;
u32 input_report_size;
- int rc, i, status;
+ int rc, i;
u8 cl_idx;
req_list = &cl_data->req_list;
@@ -286,12 +286,15 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
if (rc)
goto cleanup;
mp2_ops->start(privdata, info);
- status = amd_sfh_wait_for_response
- (privdata, cl_data->sensor_idx[i], SENSOR_ENABLED);
- if (status == SENSOR_ENABLED) {
+ cl_data->sensor_sts[i] = amd_sfh_wait_for_response
+ (privdata, cl_data->sensor_idx[i], SENSOR_ENABLED);
+ }
+
+ for (i = 0; i < cl_data->num_hid_devices; i++) {
+ cl_data->cur_hid_dev = i;
+ if (cl_data->sensor_sts[i] == SENSOR_ENABLED) {
cl_data->is_any_sensor_enabled = true;
- cl_data->sensor_sts[i] = SENSOR_ENABLED;
- rc = amdtp_hid_probe(cl_data->cur_hid_dev, cl_data);
+ rc = amdtp_hid_probe(i, cl_data);
if (rc)
goto cleanup;
} else {
@@ -301,6 +304,7 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
cl_data->sensor_idx[i], get_sensor_name(cl_data->sensor_idx[i]),
cl_data->sensor_sts[i]);
}
+
if (!cl_data->is_any_sensor_enabled ||
(mp2_ops->discovery_status && mp2_ops->discovery_status(privdata) == 0)) {
dev_warn(dev, "Failed to discover, sensors not enabled is %d\n", cl_data->is_any_sensor_enabled);
--
2.25.1
^ permalink raw reply related
* [PATCH 5/5] HID: amd_sfh: Split sensor and HID initialization for SFH1.1
From: Basavaraj Natikar @ 2023-05-09 6:58 UTC (permalink / raw)
To: jikos, benjamin.tissoires, linux-input; +Cc: Basavaraj Natikar
In-Reply-To: <20230509065857.4170013-1-Basavaraj.Natikar@amd.com>
Sensors are enabled independently of HID device initialization. Sensor
initialization should be kept separate in this case, while HID devices
should be initialized according to the sensor state. Hence split sensor
initialization and HID initialization for SFH1.1 into separate blocks.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
---
drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c
index 2102d53bd51f..e9c6413af24a 100644
--- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c
+++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c
@@ -168,16 +168,16 @@ static int amd_sfh1_1_hid_client_init(struct amd_mp2_dev *privdata)
status = amd_sfh_wait_for_response
(privdata, cl_data->sensor_idx[i], ENABLE_SENSOR);
- status = (status == 0) ? SENSOR_ENABLED : SENSOR_DISABLED;
+ cl_data->sensor_sts[i] = (status == 0) ? SENSOR_ENABLED : SENSOR_DISABLED;
+ }
- if (status == SENSOR_ENABLED) {
+ for (i = 0; i < cl_data->num_hid_devices; i++) {
+ cl_data->cur_hid_dev = i;
+ if (cl_data->sensor_sts[i] == SENSOR_ENABLED) {
cl_data->is_any_sensor_enabled = true;
- cl_data->sensor_sts[i] = SENSOR_ENABLED;
rc = amdtp_hid_probe(i, cl_data);
if (rc)
goto cleanup;
- } else {
- cl_data->sensor_sts[i] = SENSOR_DISABLED;
}
dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
cl_data->sensor_idx[i], get_sensor_name(cl_data->sensor_idx[i]),
--
2.25.1
^ permalink raw reply related
* [PATCH 1/5] HID: amd_sfh: Remove unnecessary log
From: Basavaraj Natikar @ 2023-05-09 6:58 UTC (permalink / raw)
To: jikos, benjamin.tissoires, linux-input; +Cc: Basavaraj Natikar
In-Reply-To: <20230509065857.4170013-1-Basavaraj.Natikar@amd.com>
There is a duplicate log message that is not necessary. Hence remove
unnecessary log message.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
---
drivers/hid/amd-sfh-hid/amd_sfh_client.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_client.c b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
index d9b7b01900b5..7e4a3b6c0ac7 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_client.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
@@ -306,10 +306,6 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
}
} else {
cl_data->sensor_sts[i] = SENSOR_DISABLED;
- dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
- cl_data->sensor_idx[i],
- get_sensor_name(cl_data->sensor_idx[i]),
- cl_data->sensor_sts[i]);
}
dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
cl_data->sensor_idx[i], get_sensor_name(cl_data->sensor_idx[i]),
--
2.25.1
^ permalink raw reply related
* [PATCH 2/5] HID: amd_sfh: Remove duplicate cleanup
From: Basavaraj Natikar @ 2023-05-09 6:58 UTC (permalink / raw)
To: jikos, benjamin.tissoires, linux-input; +Cc: Basavaraj Natikar
In-Reply-To: <20230509065857.4170013-1-Basavaraj.Natikar@amd.com>
A number of duplicate cleanups are performed that are not necessary. As a
result, remove duplicate cleanups and use common cleanup.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
---
drivers/hid/amd-sfh-hid/amd_sfh_client.c | 27 ++++--------------------
1 file changed, 4 insertions(+), 23 deletions(-)
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_client.c b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
index 7e4a3b6c0ac7..3d62527f87d3 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_client.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
@@ -292,18 +292,8 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
cl_data->is_any_sensor_enabled = true;
cl_data->sensor_sts[i] = SENSOR_ENABLED;
rc = amdtp_hid_probe(cl_data->cur_hid_dev, cl_data);
- if (rc) {
- mp2_ops->stop(privdata, cl_data->sensor_idx[i]);
- status = amd_sfh_wait_for_response
- (privdata, cl_data->sensor_idx[i], SENSOR_DISABLED);
- if (status != SENSOR_ENABLED)
- cl_data->sensor_sts[i] = SENSOR_DISABLED;
- dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
- cl_data->sensor_idx[i],
- get_sensor_name(cl_data->sensor_idx[i]),
- cl_data->sensor_sts[i]);
+ if (rc)
goto cleanup;
- }
} else {
cl_data->sensor_sts[i] = SENSOR_DISABLED;
}
@@ -313,25 +303,16 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
}
if (!cl_data->is_any_sensor_enabled ||
(mp2_ops->discovery_status && mp2_ops->discovery_status(privdata) == 0)) {
- amd_sfh_hid_client_deinit(privdata);
- for (i = 0; i < cl_data->num_hid_devices; i++) {
- devm_kfree(dev, cl_data->feature_report[i]);
- devm_kfree(dev, in_data->input_report[i]);
- devm_kfree(dev, cl_data->report_descr[i]);
- }
dev_warn(dev, "Failed to discover, sensors not enabled is %d\n", cl_data->is_any_sensor_enabled);
- return -EOPNOTSUPP;
+ rc = -EOPNOTSUPP;
+ goto cleanup;
}
schedule_delayed_work(&cl_data->work_buffer, msecs_to_jiffies(AMD_SFH_IDLE_LOOP));
return 0;
cleanup:
+ amd_sfh_hid_client_deinit(privdata);
for (i = 0; i < cl_data->num_hid_devices; i++) {
- if (in_data->sensor_virt_addr[i]) {
- dma_free_coherent(&privdata->pdev->dev, 8 * sizeof(int),
- in_data->sensor_virt_addr[i],
- cl_data->sensor_dma_addr[i]);
- }
devm_kfree(dev, cl_data->feature_report[i]);
devm_kfree(dev, in_data->input_report[i]);
devm_kfree(dev, cl_data->report_descr[i]);
--
2.25.1
^ permalink raw reply related
* [PATCH 4/5] HID: amd_sfh: Remove duplicate cleanup for SFH1.1
From: Basavaraj Natikar @ 2023-05-09 6:58 UTC (permalink / raw)
To: jikos, benjamin.tissoires, linux-input; +Cc: Basavaraj Natikar
In-Reply-To: <20230509065857.4170013-1-Basavaraj.Natikar@amd.com>
A duplicate cleanup is performed that is not necessary. As a result,
remove duplicate cleanup and use common cleanup.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
---
drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c
index bb8bd7892b67..2102d53bd51f 100644
--- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c
+++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c
@@ -174,20 +174,8 @@ static int amd_sfh1_1_hid_client_init(struct amd_mp2_dev *privdata)
cl_data->is_any_sensor_enabled = true;
cl_data->sensor_sts[i] = SENSOR_ENABLED;
rc = amdtp_hid_probe(i, cl_data);
- if (rc) {
- mp2_ops->stop(privdata, cl_data->sensor_idx[i]);
- status = amd_sfh_wait_for_response
- (privdata, cl_data->sensor_idx[i], DISABLE_SENSOR);
- if (status == 0)
- status = SENSOR_DISABLED;
- if (status != SENSOR_ENABLED)
- cl_data->sensor_sts[i] = SENSOR_DISABLED;
- dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
- cl_data->sensor_idx[i],
- get_sensor_name(cl_data->sensor_idx[i]),
- cl_data->sensor_sts[i]);
+ if (rc)
goto cleanup;
- }
} else {
cl_data->sensor_sts[i] = SENSOR_DISABLED;
}
--
2.25.1
^ permalink raw reply related
* [PATCH 0/5] cleanups to amd-sfh
From: Basavaraj Natikar @ 2023-05-09 6:58 UTC (permalink / raw)
To: jikos, benjamin.tissoires, linux-input; +Cc: Basavaraj Natikar
Changes of code cleanup includes duplicate log removal, cleanup
sequence and spliting into multiple functional blocks.
Basavaraj Natikar (5):
HID: amd_sfh: Remove unnecessary log
HID: amd_sfh: Remove duplicate cleanup
HID: amd_sfh: Split sensor and HID initialization
HID: amd_sfh: Remove duplicate cleanup for SFH1.1
HID: amd_sfh: Split sensor and HID initialization for SFH1.1
drivers/hid/amd-sfh-hid/amd_sfh_client.c | 47 ++++++-------------
drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 24 +++-------
2 files changed, 20 insertions(+), 51 deletions(-)
--
2.25.1
^ 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