public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Denis Benato <denis.benato@linux.dev>
To: James Ye <jye836@gmail.com>,
	jikos@kernel.org, bentiss@kernel.org, lee@kernel.org,
	pavel@kernel.org
Cc: linux-input@vger.kernel.org, linux-leds@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/6] HID: asus: add microphone mute LED support for T3304
Date: Mon, 4 May 2026 00:45:01 +0200	[thread overview]
Message-ID: <769ce05a-3148-408f-b012-74a85c1a2343@linux.dev> (raw)
In-Reply-To: <20260503072643.2774762-6-jye836@gmail.com>


On 5/3/26 09:26, James Ye wrote:
> T3304 keyboard has a microphone mute LED indicator on the same key
> (Fn+F9). Look this up with a led_classdev.
>
> It does not have backlight LEDs, so return without failure from
> asus_kbd_register_leds if backlight support is not present.
>
> Signed-off-by: James Ye <jye836@gmail.com>
> ---
>  drivers/hid/hid-asus.c | 51 +++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index e4c97fddfaf1..4f68bc40b8bf 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -100,6 +100,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
>  #define QUIRK_ROG_ALLY_XPAD		BIT(13)
>  #define QUIRK_HID_FN_LOCK		BIT(14)
>  #define QUIRK_T3304_KEYBOARD		BIT(15)
> +#define QUIRK_HID_MICMUTE		BIT(16)
>  
Isn't QUIRK_T3304_KEYBOARD enough? Or are you saying you know there is more than one keyboard
model that requires this?
>  #define I2C_KEYBOARD_QUIRKS			(QUIRK_FIX_NOTEBOOK_REPORT | \
>  						 QUIRK_NO_INIT_REPORTS | \
> @@ -144,6 +145,7 @@ struct asus_drvdata {
>  	unsigned long battery_next_query;
>  	struct work_struct fn_lock_sync_work;
>  	bool fn_lock;
> +	struct led_classdev led_micmute;
>  };
>  
>  static int asus_report_battery(struct asus_drvdata *, u8 *, int);
> @@ -578,6 +580,26 @@ static int asus_kbd_disable_oobe(struct hid_device *hdev)
>  	return 0;
>  }
>  
> +static int asus_kbd_set_micmute_led(struct hid_device *hdev, bool enabled)
> +{
> +	u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xd0, 0x7c, enabled };
> +
> +	return asus_kbd_set_report(hdev, buf, sizeof(buf));
> +}
> +
> +static int asus_led_brightness_set(struct led_classdev *led_cdev,
> +		enum led_brightness value)
> +{
> +	struct device *dev = led_cdev->dev->parent;
> +	struct hid_device *hdev = to_hid_device(dev);
> +	struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
> +
> +	if (led_cdev == &drvdata->led_micmute)
> +		return asus_kbd_set_micmute_led(hdev, !!value);
> +
> +	return -ENODEV;
> +}
> +
>  static int asus_kbd_set_fn_lock(struct hid_device *hdev, bool enabled)
>  {
>  	u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xd0, 0x4e, !!enabled };
> @@ -752,9 +774,31 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
>  	if (ret < 0)
>  		return ret;
>  
> +	if (drvdata->quirks & QUIRK_HID_MICMUTE) {
> +		char *name_micmute;
> +		size_t name_sz = strlen(dev_name(&hdev->dev)) + 16;
> +
Do we really want to use strlen?

Do we really want to use strlen on the result of a function without additional checks?
> +		name_micmute = devm_kzalloc(&hdev->dev, name_sz, GFP_KERNEL);
> +		if (name_micmute == NULL)
> +			return -ENOMEM;
> +
> +		snprintf(name_micmute, name_sz, "%s::micmute", dev_name(&hdev->dev));
> +		drvdata->led_micmute.name = name_micmute;
> +		drvdata->led_micmute.default_trigger = "audio-micmute";
> +		drvdata->led_micmute.brightness_set_blocking = asus_led_brightness_set;
> +		drvdata->led_micmute.max_brightness = 1;
> +		drvdata->led_micmute.flags = LED_CORE_SUSPENDRESUME | LED_HW_PLUGGABLE;
> +		drvdata->led_micmute.dev = &hdev->dev;
> +		ret = devm_led_classdev_register(&hdev->dev, &drvdata->led_micmute);
> +		if (ret < 0) {
> +			hid_err(hdev, "Failed to register LED: %d.\n", ret);
> +			return ret;
> +		}
> +	}
> +
>  	/* Check for backlight support */
>  	if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
> -		return -ENODEV;
> +		return 0;
>  
This doesn't look like a good idea to change this for all laptops under the sun...


Perhaps might make sense to move this check before? Maybe not?

Denis
>  	if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
>  		ret = asus_kbd_disable_oobe(hdev);
> @@ -1315,7 +1359,8 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>  	}
>  
>  	/* Laptops keyboard backlight is always at 0x5a */
> -	if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
> +	if (is_vendor &&
> +	    (drvdata->quirks & (QUIRK_USE_KBD_BACKLIGHT | QUIRK_HID_MICMUTE)) &&
>  	    (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID)) &&
>  		(asus_kbd_register_leds(hdev)))
>  		hid_warn(hdev, "Failed to initialize backlight.\n");
> @@ -1587,7 +1632,7 @@ static const struct hid_device_id asus_devices[] = {
>  		USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD) },
>  	{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
>  		USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_T3304_KEYBOARD),
> -	  QUIRK_T3304_KEYBOARD },
> +	  QUIRK_T3304_KEYBOARD | QUIRK_HID_MICMUTE },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(hid, asus_devices);

  reply	other threads:[~2026-05-03 22:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-03  7:26 [PATCH 0/6] HID: asus: add support for T3304 keyboard James Ye
2026-05-03  7:26 ` [PATCH 1/6] HID: input: delete hid_battery on disconnect James Ye
2026-05-03  7:26 ` [PATCH 2/6] HID: asus: check feature reports when determining is_vendor James Ye
2026-05-03  7:26 ` [PATCH 3/6] HID: asus: add support for T3304 detachable keyboard James Ye
2026-05-03 22:23   ` Denis Benato
2026-05-03  7:26 ` [PATCH 4/6] HID: multitouch: add support for ASUS T3304 media keys James Ye
2026-05-03  7:26 ` [PATCH 5/6] HID: asus: add microphone mute LED support for T3304 James Ye
2026-05-03 22:45   ` Denis Benato [this message]
2026-05-04  1:27     ` James Ye
2026-05-03  7:26 ` [PATCH 6/6] leds: led-class: mark classdev as unregistering early James Ye
2026-05-04 21:49   ` kernel test robot
2026-05-05  2:24   ` kernel test robot
2026-05-05 14:16     ` James Ye

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=769ce05a-3148-408f-b012-74a85c1a2343@linux.dev \
    --to=denis.benato@linux.dev \
    --cc=bentiss@kernel.org \
    --cc=jikos@kernel.org \
    --cc=jye836@gmail.com \
    --cc=lee@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox