From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f48.google.com (mail-yx1-f48.google.com [74.125.224.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B228382F32 for ; Tue, 28 Apr 2026 23:20:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777418433; cv=none; b=WaoRLwlJ+Nc6xvPM3YiGK81XLkp7EAYWB7+sQHiPZKpfbOl+orm0q9LisfkHG/rAjKGle/jckS8Yca+Ca2Fhyu36kI9bfr7uILQdC1D8o5ghaRhej439lqeQ96uf5Goon4NFCD/CWCGmeHCQcY0vcYQMvFLEAx4f4ImzAqdrQCU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777418433; c=relaxed/simple; bh=oUDQ3jnJGrJYrFgpyu3sGYqMOSRy6Pgc9nJZRJ0mtGw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jaXlXnyIziORm713Jb+cpuWlDhC2lxFl+4HNUK3Dy1AqohEJztaQgETVGDHIO4dNviK3EkBYZgWc0HrccXyyr3IaBXqHLP47YyP1LmwCVbUdBkWQgv1uT1Cn9HBDyM6JBhdNfPZDwpqB5TwSIYcBgWIvLvUTvGa8akhY+NEP3No= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OdWe3I2Z; arc=none smtp.client-ip=74.125.224.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OdWe3I2Z" Received: by mail-yx1-f48.google.com with SMTP id 956f58d0204a3-6501418152cso11570231d50.0 for ; Tue, 28 Apr 2026 16:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777418431; x=1778023231; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=40Dpw4JkDEEUOfPNjhQNegKsRaiUaTKt2OfBjTtudeM=; b=OdWe3I2ZCeFamDschvQdvDyt1UWm89XZID+4zt5oqn4fg6o3GkezgVDB4s9Y/EDfMI mcwblXSVmWqifnRg8Xd4YTCGUMkem13Heu5CT1k2oNRa4f1u9s9gv/nRAn6MFkn4CWyO ILK5Bs7Sxg9M9Utryu0UMcurOBDfTp1nXWGxOBYPR29dc+iyLJ+t4mtD5aSdTu7C/t1P 88YmjLfKI5FFjJTofCPhJh4lVbGhBbTUZpEpHcaSjWYkJgTcDrKeU4zUHdFnWaW5ZEwb rM7/x6bK+sGzep/qgit4P4erFo5c2XH7hshvJxvJ5ux81cxKWHUUKkegQdck2ck2Lg0y u/6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777418431; x=1778023231; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=40Dpw4JkDEEUOfPNjhQNegKsRaiUaTKt2OfBjTtudeM=; b=EcxgVonHjrV563/zdiA2fcgMSpc3OAwdSWAFbf4wv0x+XebhxCTX14pVAusY3cftC9 P4qVY8SBteX/s1bS5zx+dlRM3KJf3GF1j3KMQBWb9zYmKc2HFarIyuNcAkr+RJj4mcm3 ADqMMisGOkDlZnVyPkxH/DVswXo2/7c3L427ZXohpLjYR+VyW8OIXDGQDPgC0SLTQij9 Z8SlQYgwtYmXg9TNN3AkxsZ8Te3JCbdNXMsncd+YiztuvAN2/F3faLQvcqS0PJOjPdpc TBjkjucmyGEWrjSvTpAKLEPEwJTQp+JodsVIEn5pyTT3LdNa4VQf2vi7xoPvrjrd9fwY SYfA== X-Forwarded-Encrypted: i=1; AFNElJ90LBksDSK3TjL0ewMIJ0H94v93dr/3hddiBAi5+IS7G5dnLOBJEMta4qrYk6pBuoGVn2q1tgUR9kDEt6s=@vger.kernel.org X-Gm-Message-State: AOJu0Ywk7fJ4/ViC1R5wkH3pqu0I1M1lVIEnvIopq7uodkSBNCfeczJ5 lQM3+MB6ociA11mvKhUnRQPO0WaTUxEyx8RRf/y2SDohxzVm8qS/LzEm X-Gm-Gg: AeBDietvdg1DIaMUHEdhumULLX/MAbSUOHYvc3hJr0NUsrlpHM88K76ZwCx8s1w7Vrg /7791VE9kDbkyELmNKg8uHbvxqYR8/Y7QoYqEHlYEfzCUrj/PaMOg1ALuzWFqdwi2xK//H9QGfW M2A2weC0zzYKemPJpejifJ6IZ1UXc+vdSGYtR4cUKV8ruHffjov1TP+XhnctfO9RAAmMmqCYC8v yvLW6diqeLLmfpL8gDCZjqIuCmHTLNd01HTsMtBsP6ZOJ58IJPU2FcxLbrxvcgr7110ZU3IlS3B g9jnqfFI3z6G/+inPW3tecia25KJM7IxSrtJVgaXKW4RZc+qneLbIsbjgFQbg4N8Bds7w1tqyCz EHnqA93gd5QuebP2C53gqhtvxCVYcQZFgNM4laFKDX9+8A1J60iu979YsePXvc4w+noWcY4sEQL 8hZRtSWAcMYSREPwMZnizOTKnEOci6nYITP/sHMwznNIqcA/QZ X-Received: by 2002:a53:d9c8:0:b0:651:bb90:714d with SMTP id 956f58d0204a3-65beee8b403mr3536992d50.32.1777418431161; Tue, 28 Apr 2026 16:20:31 -0700 (PDT) Received: from localhost ([2804:14c:5bc6:8c1b:a2c7:e12b:2f63:a597]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-65bff6c4113sm371156d50.11.2026.04.28.16.20.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2026 16:20:30 -0700 (PDT) Date: Tue, 28 Apr 2026 20:20:28 -0300 From: =?iso-8859-1?Q?Jos=E9?= Guilherme de Castro Rodrigues To: Ilpo =?iso-8859-1?Q?J=E4rvinen?= Cc: Corentin Chary , "Luke D. Jones" , Denis Benato , Hans de Goede , platform-driver-x86@vger.kernel.org, LKML Subject: Re: [PATCH v2] platform/x86: asus-wmi: fix camera key led on Zenbook S14 Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Thanks for the comment, Ilpo. On Tue, Apr 28, 2026 at 11:22:20AM +0300, Ilpo Järvinen wrote: > While I believe you are "correct" that userspace won't see a thing, is > this really correct way to implement support for this device? At first, I created another sysfs attribute that basically duplicated the logic that is used for the "asus::camera" attribute, with the exception being the value that was written to it, of course. I noticed, however, that calling asus_wmi_set_devstate() had not effect on the LED state. The LED only toggled when I read the attribute, which then called asus_wmi_get_devstate(). I don't know if this is a quirk for this device, or if all devices that expose ASUS_WMI_DEVID_CAMERA_LED_NEG behave the same, but the LED is not toggled until I call asus_wmi_get_devstate() - be it when detecting a key press (hardware change) or after the sysfs attribute is written to (software change). Since in this case the LED state would not change after a write to the sysfs attribute, I went in the "do not make it visible to userspace at all" direction. > I mean the camera led init in asus_wmi_led_init() is gated by > asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_CAMERA_LED) but should that > be gated by either CAMERA_LED or CAMERA_LED_NEG and the related code in > *_camera_led_*() that now only uses ASUS_WMI_DEVID_CAMERA_LED > should use which ever of them is available? Yes, I think what you said makes sense as it would give userspace access to the resource without creating a new attribute. In this case, I feel like a good option would be to gate the camera led initialization by both IDs, and assume that the write and read works as they probably should for CAMERA_LED_NEG. Then, somehow add a quirk for this specific device that performs a read when the key is pressed, and right after the sysfs attribute is written to. If we can confirm that this behavior is expected when writing to CAMERA_LED_NEG, it might not need to be a quirk. Unfortunately, I am not able to try this on other devices. What do you think about it? Best regards, José Rodrigues