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] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 20 May 2011 12:32:23 +0200
From:	Benjamin Tissoires <benjamin.tissoires@...c.fr>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Henrik Rydberg <rydberg@...omail.se>,
	Stephane Chatty <chatty@...-enac.fr>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/6] hid-multitouch: class MT_CLS_STANTUM is redundant
 with MT_CLS_CONFIDENCE

On Fri, May 20, 2011 at 10:35, Jiri Kosina <jkosina@...e.cz> wrote:
> On Thu, 19 May 2011, Benjamin Tissoires wrote:
>
>> Stantum devices used to work with MT_CLS_STANTUM but MT_CLS_CONFIDENCE
>> is exactly the same. This patch switches them to this generic class,
>> and remove the unused MT_CLS_STANTUM.
>>
>> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@...c.fr>
>> ---
>>  drivers/hid/hid-multitouch.c |    9 +++------
>>  1 files changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>> index feeb0b7..65b92d2 100644
>> --- a/drivers/hid/hid-multitouch.c
>> +++ b/drivers/hid/hid-multitouch.c
>> @@ -88,7 +88,6 @@ struct mt_class {
>>  #define MT_CLS_DUAL_INRANGE_CONTACTNUMBER    3
>>  #define MT_CLS_CYPRESS                               4
>>  #define MT_CLS_EGALAX                                5
>> -#define MT_CLS_STANTUM                               6
>>  #define MT_CLS_3M                            7
>>  #define MT_CLS_CONFIDENCE                    8
>>  #define MT_CLS_CONFIDENCE_MINUS_ONE          9
>
> Benjamin,
>
> is it intentional that you are leaving the hole in the numbering here?
>
> I don't think there would be any issue with re-numbering 7-10, would it?

Well, the first time I tried to renumber those classes (to keep them
alphabetically sorted), I've been told not to do it. That's why I let
the hole in this case.
There won't be any issue in renumbering those classes (and we could sort them).
Maybe I can just send a new patch on top of this to sort them.

Cheers,
Benjamin

PS: and thank you very much for applying so quickly the last patches I sent.

>
> --
> Jiri Kosina
> SUSE Labs
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ