linux-kernel - Re: [PATCH 1/2] HID: hid-lg4ff: Use Private Data

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]

Date:	Tue, 03 Apr 2012 10:02:46 +0200
From:	Michal Malý <madcatxster@...il.com>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Simon Wood <simon@...gewell.org>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, Michael Bauer <michael@...auer.org>
Subject: Re: [PATCH 1/2] HID: hid-lg4ff: Use Private Data

On Tuesday 03. of April 2012 4:13:37 you wrote:
> On Mon, 2 Apr 2012, Simon Wood wrote:
> > Use private data in hid-lg4ff to store device properties.
> 
> I'd like to have a more verbose changelog -- namely what advantage this
> brings compared to the previous state.
> 
> Thanks.
Hi,

the previous implementation used a linked list to store the device 
configuration (at this point it was just the operating range, but I have plans 
for further expansion, I guess Simon's LEDs patch could use that too). 
Searching through the list every time the user adjusted the range wasn't 
exactly fast, particularly because the list used kobj name as the ID. I 
originally opted for that solution because I didn't want to mess with the code 
of the whole hid-lg driver.
This patch takes advantage of the changes introduced in my patches from 
2011/04/02. lg4ff now calls hid_get/set_drvdata() to read or store device 
configuration. The way I understand it, this is how all HID drivers store their 
private data.

Since J. Slabý complained about unnecessary uninitialized_var() macros, I'll 
update the patch to remove them.

Michal M.
Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)