linux-kernel - Re: [PATCH v5 0/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z53f7VNIgUWWFn9l@duo.ucw.cz>
Date: Sat, 1 Feb 2025 09:48:45 +0100
From: Pavel Machek <pavel@....cz>
To: Armin Wolf <W_Armin@....de>
Cc: Werner Sembach <wse@...edocomputers.com>, hdegoede@...hat.com,
	ilpo.jarvinen@...ux.intel.com, bentiss@...nel.org,
	dri-devel@...ts.freedesktop.org, jelle@...aa.nl, jikos@...nel.org,
	lee@...nel.org, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org,
	miguel.ojeda.sandonis@...il.com, ojeda@...nel.org,
	onitake@...il.com, cs@...edo.de,
	platform-driver-x86@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH v5 0/1] platform/x86/tuxedo: Add virtual LampArray for
 TUXEDO NB04 devices

Hi!

> > I now got my feet a little wet with hid-bpf regarding something else, and
> > with that knowledge I would leave the long arrays in the beginning in the
> > kernel code for the time being:
> > 
> > sirius_16_ansii_kbl_mapping and sirius_16_iso_kbl_mapping are required
> > during initialization so they have to exist in the kernel code anyway.
> > 
> > report_descriptor will most likly not change even for future models and
> > afaik having report_descriptors in kernel drivers is not unheard of.
> > 
> > So the only things that could be meaningfully moved to a hid-bpf program
> > are the sirius_16_*_kbl_mapping_pos_* arrays. But for these is have to give
> > out some fallback value anyway for the case where a hid-bpf file is missing
> > or fails to load. So why not use real world values from my test device for
> > these values?
> > 
> > As soon as there is a future device that can use the same driver with just
> > these pos arrays different, then I would implement that change via a bpf
> > program instead of a change to the kernel driver.
> > 
> > Let me know if you too think this is a sensefull approach?
> > 
> > 
> > Another question: Would this patch need to wait for a userspace
> > implementation of lamp array before it can get accepted?
> 
> It would be nice if you could test the LampArray implementation. But other than that
> userspace can catch up later.
> 
> Still, i am interested in the opinion of the LED maintainers
> regarding the fake HID interface.

Comments from previous review were not addressed.

Most importantly, this is not a way to do kernel interface. We want
reasonable interface that can be documented and modified as needed. We
want to pass /dev/input to userspace, not raw HID. This is not ok.

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)