All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael Passos" <rafael@rcpassos.me>
To: "Rafael Passos" <rafael@rcpassos.me>,
	"David Rheinsberg" <david@readahead.eu>, <bentiss@kernel.org>,
	<jikos@kernel.org>
Cc: "Shuah Khan" <skhan@linuxfoundation.org>,
	"Brigham Campbell" <me@brighamcampbell.com>,
	"Jori Koolstra" <jkoolstra@xs4all.nl>,
	<linux-input@vger.kernel.org>
Subject: Re: [PATCH v4 0/4] HID: wiimote: new LED behavior on connect + scoped_guards
Date: Thu, 03 Sep 2026 10:30:52 -0300	[thread overview]
Message-ID: <DL5PV8KZSLAY.10R2KRTZ2YOBH@rcpassos.me> (raw)
In-Reply-To: <20260817213840.1053216-1-rafael@rcpassos.me>

Hi!

[Sorry for the dupplicated email, I sent this in the V3 by mistake ;( ]

I'm looking for feedback in this patchset.
I believe this is a good time,
since the merge window was just closed.
Maybe this could be ready for 7.4 ?

Thanks,
Rafael Passos

On Mon Aug 17, 2026 at 6:38 PM -03, Rafael Passos wrote:
> Hi,
> This patchset contains one feature change, and 3 patches appying 
> scoped cleanup to locking and to the initialization functions for
> the led probing and the main wiimote probe call.
>
> The feature is turning different LEDs for each of the first 4 wiimotes connected.
> From id 5 forward, the LED will cycle back to 1, and so on.
> This uses the ida struct, so its quite simple and lightweight.
> The hid_info log message prints out the controller id.
>
> While implementing this feature, I decided to cleanup the code using
> scoped_guard for the many spinlocks in the driver. There are two places
> where the original lock/unlock version fits best, and I left them
> untouched.
> I also used the __free scope cleanup in the wiimote_probe and LED probe.
> This was trivial for the LED probe.
> The wiimote_probe required a new state tracker bitmask, now the wiimote_destroy
> is used both on disconnect (hid_remove) and in the probe cleanup.
>
> It was really fun working with this driver.
> I tested it with 4 Wii Motion Plus remotes (gen2).
> Video recording of my tests (48s video).
> https://rcpassos.me/video/wiimote-led-linux-driver
>
> Thanks,
> Rafael Passos
>
> ---
> V1: https://lore.kernel.org/linux-input/20260710153456.2093889-1-rafael@rcpassos.me/
> Changes from v1:
>     (1/3):
>     - fix ida_alloc_min error handling to consider negative values
>     - remove fallback to 1 on ida_alloc_min failure
>     - move player_leds static array to hid-wiimote-core.c
>     - s/instance_id/player_id/g
>     - store player_id on an u8
>     (2/3):
>     - add header include for cleanup.h
>     - add identation to one-liner scoped_guards
>     (3/3):
>     - add scoped cleanup function to wiimote_probe, with a bitmask to track state
>       Patch used for testing this:
>       https://lore.kernel.org/linux-input/20260715213513.3929001-1-rafael@rcpassos.me/
>     (4/4) *new patch* :
>     - sashiko found a pre-existing uaf. Unlikely, but correct.
>       implemented using the playstation driver as an inspiration
>
> V2: https://lore.kernel.org/linux-input/20260710153456.2093889-1-rafael@rcpassos.me/
> Changes from v2:
>     (2/4):
>     - join the last two locks into a single scoped_guard lock in wiimote_modules_load
>
> V3: https://lore.rcpassos.me/wiimote/20260729164928.1138468-1-rafael@rcpassos.me/
> Changes from v3:
>     - dropped false uaf patch (previous 4/4). It was a false alarm.
>       Discussion in:
>       https://lore.kernel.org/linux-input/20260729164928.1138468-1-rafael@rcpassos.me/T/#t
>
>     (1/4):
>     - I tested how the changes looked if using ida from 0 instead of 1,
>       and I believe it ended up less clean. I decided to keep them as is,
>       with a few additional comments.
>     - explicit initialization of player_id to 0 before allocating an id
>     - avoid using a new int during ida_alloc (use ret instead)
>     - use u8 instead of __u8
>     - move ida_remove from wiimote_hid_remove to wiimote_destroy
>     - add debugfs entry for the player_id entry
>     (3/4):
>     - move changes to wiimote_probe from this patch to the next
>     - update patch title
>     (4/4): *new patch*
>     - scoped cleanup in the wiimote_probe call, using a bitmask to keep
>       track of state during initialization
>     - update wiimote_destroy so it can be the cleanup function
>     - add a debugfs entry for this new entry
>
> As we discussed in the v3, tell me if you like the changes in patch 4/4.
> If you prefer not to apply it, I can send a new patchset revision, or
> just drop it from the set if nothing else needs changes.
>
> Thanks!
>
>
> Rafael Passos (4):
>   HID: wiimote: turn on the LEDs indicating the controller id
>   HID: wiimote: replace spinlock pairs with scoped_guard
>   HID: wiimote: led_probe with scoped cleanup
>   HID: wiimote: wiimote_probe with scoped cleanup
>
>  drivers/hid/hid-wiimote-core.c    | 346 ++++++++++++++++--------------
>  drivers/hid/hid-wiimote-debug.c   |  71 +++---
>  drivers/hid/hid-wiimote-modules.c |  24 +--
>  drivers/hid/hid-wiimote.h         |  10 +
>  4 files changed, 240 insertions(+), 211 deletions(-)



  parent reply	other threads:[~2026-09-03 13:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17 21:38 [PATCH v4 0/4] HID: wiimote: new LED behavior on connect + scoped_guards Rafael Passos
2026-08-17 21:38 ` [PATCH v4 1/4] HID: wiimote: turn on the LEDs indicating the controller id Rafael Passos
2026-08-17 21:55   ` sashiko-bot
2026-08-17 21:38 ` [PATCH v4 2/4] HID: wiimote: replace spinlock pairs with scoped_guard Rafael Passos
2026-08-17 21:59   ` sashiko-bot
2026-08-17 21:38 ` [PATCH v4 3/4] HID: wiimote: led_probe with scoped cleanup Rafael Passos
2026-08-17 21:38 ` [PATCH v4 4/4] HID: wiimote: wiimote_probe " Rafael Passos
2026-08-17 21:54   ` sashiko-bot
2026-09-03 13:30 ` Rafael Passos [this message]
2026-09-11 16:44 ` [PATCH v4 0/4] HID: wiimote: new LED behavior on connect + scoped_guards Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DL5PV8KZSLAY.10R2KRTZ2YOBH@rcpassos.me \
    --to=rafael@rcpassos.me \
    --cc=bentiss@kernel.org \
    --cc=david@readahead.eu \
    --cc=jikos@kernel.org \
    --cc=jkoolstra@xs4all.nl \
    --cc=linux-input@vger.kernel.org \
    --cc=me@brighamcampbell.com \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.