[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN+gG=FEHefW-4XrCTkDY2_Jfj+uWZ=g_uc-2BsgFdW2My=VvA@mail.gmail.com>
Date: Thu, 15 Aug 2013 19:36:57 +0200
From: Benjamin Tissoires <benjamin.tissoires@...il.com>
To: Alexander Holler <holler@...oftware.de>
Cc: Benjamin Tissoires <benjamin.tissoires@...hat.com>,
Henrik Rydberg <rydberg@...omail.se>,
Jiri Kosina <jkosina@...e.cz>,
Stephane Chatty <chatty@...c.fr>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
linux-input <linux-input@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] HID: Use existing parser for pre-scanning the report descriptors
On Wed, Aug 14, 2013 at 10:03 PM, Alexander Holler <holler@...oftware.de> wrote:
> Am 14.08.2013 17:38, schrieb Benjamin Tissoires:
>
>
>>>> {
>>>> if (usage == HID_DG_CONTACTID)
>>>> - hid->group = HID_GROUP_MULTITOUCH;
>>>> + parser->flags |= HID_FLAG_MULTITOUCH;
>>>
>>>
>>> Did you consider reusing the group flags, e.g., parser->groups |= (1
>>> << HID_GROUP_MULTITOUCH)? This change could be made regardless of the
>>> parser logic.
>>
>>
>> If nobody is against changing the values of the different groups across
>> kernel version (which should be harmless), then I fully agree, we can
>> use the group item as a bit field (but we would be able to only have 16
>> different device groups).
>
>
> Hmm, that might become a problem. E.g. all the HID sensors might be used
> stand alone (without a sensor-hub, if someone modifies the drivers). But I
> agree that currently the flags are just confusing and would introduce them
> only if the number of groups reaches the limit.
>
>
>
>>>> - hid->group = HID_GROUP_GENERIC;
>>>> + parser = vzalloc(sizeof(struct hid_parser));
>>>
>>>
>>> Argh, I realize it is inevitable for this patch, but it still makes my
>>> eyes bleed. The parser takes quite a bit of memory...
>>
>>
>> Yep, my first attempt was to remove it, then I re-added it with a small
>> tear...
>
>
> So you actually create a new parser and the subject (that existing) of this
> patch is misleading.
Hi Alexander,
I think you misread what Henrik and I were discussing about:
Henrik complained about using the heap for something which is just
used in this function, and using the stack would have been better.
However, the size of the parser is too big that the compiler complains
when we declare it on the stack.
So this line is just a copy/paste from the function hid_open_report(),
and thus, you can agree that I did not create a new parser.
Cheers,
Benjamin
--
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