* [PATCH 7/7] HID: logitech-dj: validate output report details
From: Kees Cook @ 2013-09-04 16:37 UTC (permalink / raw)
To: linux-input
Cc: Benjamin Tissoires, Jiri Kosina, Henrik Rydberg, Kees Cook,
stable
In-Reply-To: <1378312645-27736-1-git-send-email-keescook@chromium.org>
A HID device could send a malicious output report that would cause the
logitech-dj HID driver to leak kernel memory contents to the device, or
trigger a NULL dereference during initialization:
[ 304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b
...
[ 304.780467] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
[ 304.781409] IP: [<ffffffff815d50aa>] logi_dj_recv_send_report.isra.11+0x1a/0x90
CVE-2013-2895
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@kernel.org
---
drivers/hid/hid-logitech-dj.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index cd33084..404f2d0 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -461,7 +461,7 @@ static int logi_dj_recv_send_report(struct dj_receiver_dev *djrcv_dev,
struct hid_report *report;
struct hid_report_enum *output_report_enum;
u8 *data = (u8 *)(&dj_report->device_index);
- int i;
+ unsigned int i, length;
output_report_enum = &hdev->report_enum[HID_OUTPUT_REPORT];
report = output_report_enum->report_id_hash[REPORT_ID_DJ_SHORT];
@@ -471,7 +471,9 @@ static int logi_dj_recv_send_report(struct dj_receiver_dev *djrcv_dev,
return -ENODEV;
}
- for (i = 0; i < report->field[0]->report_count; i++)
+ length = min_t(size_t, sizeof(*dj_report) - 1,
+ report->field[0]->report_count);
+ for (i = 0; i < length; i++)
report->field[0]->value[i] = data[i];
hid_hw_request(hdev, report, HID_REQ_SET_REPORT);
@@ -783,6 +785,12 @@ static int logi_dj_probe(struct hid_device *hdev,
goto hid_parse_fail;
}
+ if (!hid_validate_values(hdev, HID_OUTPUT_REPORT, REPORT_ID_DJ_SHORT,
+ 0, 3)) {
+ retval = -ENODEV;
+ goto hid_parse_fail;
+ }
+
/* Starts the usb device and connects to upper interfaces hiddev and
* hidraw */
retval = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/7] HID: steelseries: validate output report details
From: Kees Cook @ 2013-09-04 16:37 UTC (permalink / raw)
To: linux-input
Cc: Benjamin Tissoires, Jiri Kosina, Henrik Rydberg, Kees Cook,
stable
In-Reply-To: <1378312645-27736-1-git-send-email-keescook@chromium.org>
A HID device could send a malicious output report that would cause the
steelseries HID driver to write beyond the output report allocation
during initialization, causing a heap overflow:
[ 167.981534] usb 1-1: New USB device found, idVendor=1038, idProduct=1410
...
[ 182.050547] BUG kmalloc-256 (Tainted: G W ): Redzone overwritten
CVE-2013-2891
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@kernel.org
---
drivers/hid/hid-steelseries.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-steelseries.c b/drivers/hid/hid-steelseries.c
index d164911..29f328f 100644
--- a/drivers/hid/hid-steelseries.c
+++ b/drivers/hid/hid-steelseries.c
@@ -249,6 +249,11 @@ static int steelseries_srws1_probe(struct hid_device *hdev,
goto err_free;
}
+ if (!hid_validate_values(hdev, HID_OUTPUT_REPORT, 0, 0, 16)) {
+ ret = -ENODEV;
+ goto err_free;
+ }
+
ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
if (ret) {
hid_err(hdev, "hw start failed\n");
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/7] HID: zeroplus: validate output report details
From: Kees Cook @ 2013-09-04 16:37 UTC (permalink / raw)
To: linux-input
Cc: Benjamin Tissoires, Jiri Kosina, Henrik Rydberg, Kees Cook,
stable
In-Reply-To: <1378312645-27736-1-git-send-email-keescook@chromium.org>
The zeroplus HID driver was not checking the size of allocated values
in fields it used. A HID device could send a malicious output report
that would cause the driver to write beyond the output report allocation
during initialization, causing a heap overflow:
[ 1442.728680] usb 1-1: New USB device found, idVendor=0c12, idProduct=0005
...
[ 1466.243173] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten
CVE-2013-2889
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@kernel.org
---
drivers/hid/hid-zpff.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/hid/hid-zpff.c b/drivers/hid/hid-zpff.c
index 6ec28a3..a29756c 100644
--- a/drivers/hid/hid-zpff.c
+++ b/drivers/hid/hid-zpff.c
@@ -68,21 +68,13 @@ static int zpff_init(struct hid_device *hid)
struct hid_report *report;
struct hid_input *hidinput = list_entry(hid->inputs.next,
struct hid_input, list);
- struct list_head *report_list =
- &hid->report_enum[HID_OUTPUT_REPORT].report_list;
struct input_dev *dev = hidinput->input;
- int error;
+ int i, error;
- if (list_empty(report_list)) {
- hid_err(hid, "no output report found\n");
- return -ENODEV;
- }
-
- report = list_entry(report_list->next, struct hid_report, list);
-
- if (report->maxfield < 4) {
- hid_err(hid, "not enough fields in report\n");
- return -ENODEV;
+ for (i = 0; i < 4; i++) {
+ report = hid_validate_values(hid, HID_OUTPUT_REPORT, 0, i, 1);
+ if (!report)
+ return -ENODEV;
}
zpff = kzalloc(sizeof(struct zpff_device), GFP_KERNEL);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 6/7] HID: lenovo-tpkbd: validate output report details
From: Kees Cook @ 2013-09-04 16:37 UTC (permalink / raw)
To: linux-input
Cc: Benjamin Tissoires, Jiri Kosina, Henrik Rydberg, Kees Cook,
stable
In-Reply-To: <1378312645-27736-1-git-send-email-keescook@chromium.org>
A HID device could send a malicious output report that would cause the
lenovo-tpkbd HID driver to write just beyond the output report allocation
during initialization, causing a heap overflow:
[ 76.109807] usb 1-1: New USB device found, idVendor=17ef, idProduct=6009
...
[ 80.462540] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten
CVE-2013-2894
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@kernel.org
---
drivers/hid/hid-lenovo-tpkbd.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-lenovo-tpkbd.c b/drivers/hid/hid-lenovo-tpkbd.c
index 07837f5..f458e76 100644
--- a/drivers/hid/hid-lenovo-tpkbd.c
+++ b/drivers/hid/hid-lenovo-tpkbd.c
@@ -339,7 +339,15 @@ static int tpkbd_probe_tp(struct hid_device *hdev)
struct tpkbd_data_pointer *data_pointer;
size_t name_sz = strlen(dev_name(dev)) + 16;
char *name_mute, *name_micmute;
- int ret;
+ int i, ret;
+
+ /* Validate required reports. */
+ for (i = 0; i < 4; i++) {
+ if (!hid_validate_values(hdev, HID_OUTPUT_REPORT, 4, i, 1))
+ return -ENODEV;
+ }
+ if (!hid_validate_values(hdev, HID_OUTPUT_REPORT, 3, 0, 2))
+ return -ENODEV;
if (sysfs_create_group(&hdev->dev.kobj,
&tpkbd_attr_group_pointer)) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/7] HID: validate report details
From: Kees Cook @ 2013-09-04 16:37 UTC (permalink / raw)
To: linux-input; +Cc: Benjamin Tissoires, Jiri Kosina, Henrik Rydberg
These patches introduce a validation function for HID devices that do
direct report value accesses, solving a number of heap smashing flaws.
This version changes to using an field-index-based checker for the new
"hid_validate_values()" which requires callers to loop across fields if
they use more than one field.
-Kees
^ permalink raw reply
* [PATCH 3/7] HID: sony: validate HID output report details
From: Kees Cook @ 2013-09-04 16:37 UTC (permalink / raw)
To: linux-input
Cc: Benjamin Tissoires, Jiri Kosina, Henrik Rydberg, Kees Cook,
stable
In-Reply-To: <1378312645-27736-1-git-send-email-keescook@chromium.org>
This driver must validate the availability of the HID output report and
its size before it can write LED states via buzz_set_leds(). This stops
a heap overflow that is possible if a device provides a malicious HID
output report:
[ 108.171280] usb 1-1: New USB device found, idVendor=054c, idProduct=0002
...
[ 117.507877] BUG kmalloc-192 (Not tainted): Redzone overwritten
CVE-2013-2890
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@kernel.org
---
drivers/hid/hid-sony.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 87fbe29..334a4b5 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -537,6 +537,10 @@ static int buzz_init(struct hid_device *hdev)
drv_data = hid_get_drvdata(hdev);
BUG_ON(!(drv_data->quirks & BUZZ_CONTROLLER));
+ /* Validate expected report characteristics. */
+ if (!hid_validate_values(hdev, HID_OUTPUT_REPORT, 0, 0, 7))
+ return -ENODEV;
+
buzz = kzalloc(sizeof(*buzz), GFP_KERNEL);
if (!buzz) {
hid_err(hdev, "Insufficient memory, cannot allocate driver data\n");
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 11/14] HID: multitouch: validate feature report details
From: Kees Cook @ 2013-09-04 16:31 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Benjamin Tissoires, Jiri Kosina, linux-input, Henrik Rydberg
In-Reply-To: <CAGXu5jKAob5s1vs5s974QsJWdje2rQgyz=PVACxW3aWiJWiEEA@mail.gmail.com>
On Fri, Aug 30, 2013 at 11:27 AM, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Aug 30, 2013 at 8:27 AM, Benjamin Tissoires
> <benjamin.tissoires@gmail.com> wrote:
>> On Thu, Aug 29, 2013 at 9:41 PM, Kees Cook <keescook@chromium.org> wrote:
>>> On Thu, Aug 29, 2013 at 1:59 AM, Benjamin Tissoires
>>> <benjamin.tissoires@redhat.com> wrote:
>>>> Hi Kees,
>>>>
>>>> I would be curious to have the HID report descriptors (maybe off list)
>>>> to understand how things can be that bad.
>>>
>>> Certainly! I'll send them your way. I did have to get pretty creative
>>> to tickle these conditions.
>>>
>>>> On overall, I'd prefer all those checks to be in hid-core so that we
>>>> have the guarantee that we don't have to open a new CVE each time a
>>>> specific hid driver do not check for these ranges.
>>>
>>> I pondered doing this, but it seemed like something that needed wider
>>> discussion, so I thought I'd start with just the dump of fixes. It
>>> seems like the entire HID report interface should use access functions
>>> to enforce range checking -- perhaps further enforced by making the
>>> structure opaque to the drivers.
>>
>> The problem with access functions with range checking is when they are
>> used at each input report. This will overload the kernel processing
>> for static checks.
>>
>>>
>>>> More specific comments inlined:
>>>>
>>>> On 28/08/13 22:31, Jiri Kosina wrote:
>>>>> From: Kees Cook <keescook@chromium.org>
>>>>>
>>>>> When working on report indexes, always validate that they are in bounds.
>>>>> Without this, a HID device could report a malicious feature report that
>>>>> could trick the driver into a heap overflow:
>>>>>
>>>>> [ 634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500
>>>>> ...
>>>>> [ 676.469629] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten
>>>>>
>>>>> CVE-2013-2897
>>>>>
>>>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>>>> Cc: stable@kernel.org
>>>>> ---
>>>>> drivers/hid/hid-multitouch.c | 25 ++++++++++++++++++++-----
>>>>> 1 file changed, 20 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>>>>> index cb0e361..2aa275e 100644
>>>>> --- a/drivers/hid/hid-multitouch.c
>>>>> +++ b/drivers/hid/hid-multitouch.c
>>>>> @@ -330,9 +330,18 @@ static void mt_feature_mapping(struct hid_device *hdev,
>>>>> break;
>>>>> }
>>>>> }
>>>>> + /* Ignore if value index is out of bounds. */
>>>>> + if (td->inputmode_index < 0 ||
>>>>
>>>> td->inputmode_index can not be less than 0
>>>
>>> Well, it certainly _shouldn't_ be less than zero. :) However, it is
>>> defined as s8, and gets set from an int:
>>>
>>> for (i=0; i < field->maxusage; i++) {
>>> if (field->usage[i].hid == usage->hid) {
>>> td->inputmode_index = i;
>>> break;
>>> }
>>> }
>>>
>>> Both "i" and "maxusage" are int, and I can generate a large maxusage
>>> and usage array where the first matching hid equality happens when i
>>> is >127, causing inputmode_index to wrap.
>>
>> ouch. Sorry. This piece of code (the current code) is junk. We should
>> switch to usage->usage_index and change from __s8 to __s16 the
>> declaration ASAP.
>>
>>>
>>>>> + td->inputmode_index >= field->report_count) {
>>>>
>>>> if this is really required, we could just change the for loop above to
>>>> go from 0 to field->report_count instead.
>>>
>>> That's certainly true, but since usage count and report count are not
>>> directly associated, I don't know if there are devices that will freak
>>> out with this restriction.
>>
>> Actually, I just again another long time understanding all the mess of
>> having usage count and report count different in hid-core.
>>
>> I think it is a bug at some point (but it looks like I tend to be
>> wrong on a lot of things recently :-P ), because when you look at the
>> actual code of hid_input_field() in hid-core.c, we never go further
>> than field->report_count when dealing with input report.
>> So my guess is that we are declaring extra usages that are never used
>> to parse incoming data.
>>
>>>
>>>> However, I think we could just rely on usage->usage_index to get the
>>>> actual index.
>>>> I'll do more tests today and tell you later.
>>>>
>>>>> + dev_err(&hdev->dev, "HID_DG_INPUTMODE out of range\n");
>>>>> + td->inputmode = -1;
>>>>> + }
>>>>>
>>>>> break;
>>>>> case HID_DG_CONTACTMAX:
>>>>> + /* Ignore if value count is out of bounds. */
>>>>> + if (field->report_count < 1)
>>>>> + break;
>>>>
>>>> If you can trigger this, I would say that the fix should be in hid-core,
>>>> not in every driver. A null report_count should not be allowed by the
>>>> HID protocol.
>>>
>>> Again, I have no problem with that idea, but there seem to be lots of
>>> general cases where this may not be possible (i.e. a HID with 0 OUTPUT
>>> or FEATURE reports). I didn't see a sensible way to approach this in
>>> core without declaring a "I require $foo many OUTPUT reports, $bar
>>> many INPUT, and $baz many FEATURE" for each driver. I instead opted
>>> for the report validation function instead.
>>>
>>
>> I think we can just add this check in both hidinput_configure_usage()
>> and report_features() (both in hid-input.c) so that we don't call the
>> *_mapping() callbacks with non sense fields.
Can you suggest a patch for this? (And please include reference to
CVE-2013-2897 in the commit.)
I'll send a v2 of the rest of the series.
Thanks!
-Kees
>> This way, the specific hid drivers will know only the correct fields,
>> and don't need to check this. So patches 9, 11 and 13 can be amended.
>>
>> It looks to me that you mismatched field->report_count and the actual
>> report_count in your answer: field->report_count is the number of
>> consecutive fields of field->report_size that are present for the
>> parsing of the report. It has nothing to do with the total report
>> count.
>>
>>>>> td->maxcontact_report_id = field->report->id;
>>>>> td->maxcontacts = field->value[0];
>>>>> if (!td->maxcontacts &&
>>>>> @@ -743,15 +752,21 @@ static void mt_touch_report(struct hid_device *hid, struct hid_report *report)
>>>>> unsigned count;
>>>>> int r, n;
>>>>>
>>>>> + if (report->maxfield == 0)
>>>>> + return;
>>>>> +
>>>>> /*
>>>>> * Includes multi-packet support where subsequent
>>>>> * packets are sent with zero contactcount.
>>>>> */
>>>>> - if (td->cc_index >= 0) {
>>>>> - struct hid_field *field = report->field[td->cc_index];
>>>>> - int value = field->value[td->cc_value_index];
>>>>> - if (value)
>>>>> - td->num_expected = value;
>>>>> + if (td->cc_index >= 0 && td->cc_index < report->maxfield) {
>>>>> + field = report->field[td->cc_index];
>>>>
>>>> looks like we previously overwrote the definition of field :(
>>>>
>>>>> + if (td->cc_value_index >= 0 &&
>>>>> + td->cc_value_index < field->report_count) {
>>>>> + int value = field->value[td->cc_value_index];
>>>>> + if (value)
>>>>> + td->num_expected = value;
>>>>> + }
>>>>
>>>> I can not see why td->cc_index and td->cc_value_index could have bad
>>>> values. They are initially created by hid-core, and are not provided by
>>>> the device.
>>>> Anyway, if you are able to produce bad values with them, I'd rather have
>>>> those checks during the assignment of td->cc_index (in
>>>> mt_touch_input_mapping()), instead of checking them for each report.
>>>
>>> Well, the problem comes again from there not being a hard link between
>>> the usage array and the value array:
>>>
>>> td->cc_value_index = usage->usage_index;
>>> ...
>>> int value = field->value[td->cc_value_index];
>>>
>>> And all of this would be irrelevant if there was an access function
>>> for field->value[].
>>
>> True, with the current implementation, td->cc_value_index can be
>> greater than field->report_count. Still, moving this check in
>> mt_touch_input_mapping() will allow us to make it only once.
>>
>>>
>>> Thanks for the review!
>>
>> you are welcome :)
>
> Okay, so, where does the whole patch series stand? It seems like the
> checks are all worth adding; and my fixes are, I think, "minimal" so
> having them go into the tree (so that they land in stable) seems like
> a good idea. The work beyond that could be done on top of the existing
> patches? There seems to be a lot of redesign ideas, but those probably
> aren't so great for stable, and I'm probably not the best person to
> write them, since everything I know about HID code I learned two weeks
> ago. :)
>
> Given the 12 flaws, what do you see as the best way forward?
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* Re: [PATCH 12/14] HID: sensor-hub: validate feature report details
From: Kees Cook @ 2013-09-04 16:05 UTC (permalink / raw)
To: Mika Westerberg; +Cc: Jiri Kosina, linux-input, srinivas pandruvada
In-Reply-To: <20130829100313.GG7393@intel.com>
Jiri,
Should this one have been part of the batch you applied? It doesn't
use hid_validate_report().
-Kees
On Thu, Aug 29, 2013 at 3:03 AM, Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
> On Wed, Aug 28, 2013 at 10:31:44PM +0200, Jiri Kosina wrote:
>> From: Kees Cook <keescook@chromium.org>
>>
>> A HID device could send a malicious feature report that would cause the
>> sensor-hub HID driver to read past the end of heap allocation, leaking
>> kernel memory contents to the caller.
>>
>> CVE-2013-2898
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> Cc: stable@kernel.org
>
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* Re: [PATCH 11/14] HID: multitouch: validate feature report details
From: Josh Boyer @ 2013-09-04 15:41 UTC (permalink / raw)
To: linux-input
In-Reply-To: <loom.20130904T165553-365@post.gmane.org>
Josh Boyer <jwboyer <at> fedoraproject.org> writes:
> So we actually did pick up the entire 14 patch series in Fedora on top of
> 3.10.10 and 3.11 to fix the CVEs. It's broken things for at least two
> users. One person's touchpad is now detected as a mouse with the error:
>
> Sep 04 16:25:14 HP6930p kernel: psmouse serio4: synaptics:
> Unable to query device.
Ignore this part. The synaptics issue was found to be unrelated.
> The other person reported
> https://bugzilla.redhat.com/show_bug.cgi?id=1003998 wherein they say these
> patches cause an ODEBUG backtrace and that the trackpoint on a USB keyboard
> doesn't work.
This is still an issue as far as we can tell.
josh
^ permalink raw reply
* Re: [PATCH 11/14] HID: multitouch: validate feature report details
From: Josh Boyer @ 2013-09-04 14:59 UTC (permalink / raw)
To: linux-input
In-Reply-To: <alpine.LNX.2.00.1309041155460.3684@pobox.suse.cz>
Jiri Kosina <jkosina <at> suse.cz> writes:
>
> On Mon, 2 Sep 2013, Benjamin Tissoires wrote:
>
> > > Given the 12 flaws, what do you see as the best way forward?
> >
> > If Jiri thinks we can wait one more week for some of these patches (I
> > know that the most critical one, 1/14 is already on its way to Linus),
> > then I can handle the v2, but not before Friday. Again, I think the
> > current patch series is perfectly fine for distributions as they can
> > add/remove things more easily than we can do in master.
>
> I agree.
>
> 1/14 will go to Linus shortly. The rest is public, and distributions are
> taking it depending on their requirements, but I'd like to have the
> patchset polished before pushing it to Linus.
So we actually did pick up the entire 14 patch series in Fedora on top of
3.10.10 and 3.11 to fix the CVEs. It's broken things for at least two
users. One person's touchpad is now detected as a mouse with the error:
Sep 04 16:25:14 HP6930p kernel: psmouse serio4: synaptics:
Unable to query device.
The other person reported
https://bugzilla.redhat.com/show_bug.cgi?id=1003998 wherein they say these
patches cause an ODEBUG backtrace and that the trackpoint on a USB keyboard
doesn't work.
> Therefore putting the rest on hold now, and waiting for v2.
Ideas on exactly what might cause these issues would be good to know.
josh
^ permalink raw reply
* [RFC PATCH] amba: Ensure drvdata is NULL
From: Michal Simek @ 2013-09-04 14:44 UTC (permalink / raw)
To: linux-kernel, monstr
Cc: Russell King, Vinod Koul, Dan Williams, Dmitry Torokhov,
Chris Ball, Alessandro Zummo, Linus Walleij, Mark Brown,
Greg Kroah-Hartman, Jiri Slaby, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Wim Van Sebroeck, Andrew Morton, zhangwei(Jovi),
Randy Dunlap, linux-arm-kernel, linux-input, linux-mmc, rtc-linux,
linux-spi, linux-serial, linux-fbdev, linux-watchdog
[-- Attachment #1: Type: text/plain, Size: 7224 bytes --]
This patch is inpired by the patch for drvdata
"device-core: Ensure drvdata = NULL when no driver is bound"
(sha1: 0998d0631001288a5974afc0b2a5f568bcdecb4d)
Also it fixes all occurences in drivers.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
arch/arm/kernel/etm.c | 6 ------
drivers/amba/bus.c | 2 ++
drivers/dma/pl330.c | 3 ---
drivers/input/serio/ambakmi.c | 2 --
drivers/mmc/host/mmci.c | 2 --
drivers/rtc/rtc-pl030.c | 2 --
drivers/rtc/rtc-pl031.c | 2 --
drivers/spi/spi-pl022.c | 1 -
drivers/tty/serial/amba-pl010.c | 3 ---
drivers/tty/serial/amba-pl011.c | 3 ---
drivers/video/amba-clcd.c | 2 --
drivers/watchdog/sp805_wdt.c | 1 -
12 files changed, 2 insertions(+), 27 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 8ff0ecd..131a6ab 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -385,7 +385,6 @@ out:
return ret;
out_unmap:
- amba_set_drvdata(dev, NULL);
iounmap(t->etb_regs);
out_release:
@@ -398,8 +397,6 @@ static int etb_remove(struct amba_device *dev)
{
struct tracectx *t = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
iounmap(t->etb_regs);
t->etb_regs = NULL;
@@ -588,7 +585,6 @@ out:
return ret;
out_unmap:
- amba_set_drvdata(dev, NULL);
iounmap(t->etm_regs);
out_release:
@@ -601,8 +597,6 @@ static int etm_remove(struct amba_device *dev)
{
struct tracectx *t = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
iounmap(t->etm_regs);
t->etm_regs = NULL;
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index c670727..9762090 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -373,6 +373,7 @@ static int amba_probe(struct device *dev)
if (ret == 0)
break;
+ amba_set_drvdata(pcdev, NULL);
pm_runtime_disable(dev);
pm_runtime_set_suspended(dev);
pm_runtime_put_noidle(dev);
@@ -391,6 +392,7 @@ static int amba_remove(struct device *dev)
pm_runtime_get_sync(dev);
ret = drv->remove(pcdev);
+ amba_set_drvdata(pcdev, NULL);
pm_runtime_put_noidle(dev);
/* Undo the runtime PM settings in amba_probe() */
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index fa645d8..626f99e 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -3026,8 +3026,6 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
return 0;
probe_err3:
- amba_set_drvdata(adev, NULL);
-
/* Idle the DMAC */
list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
chan.device_node) {
@@ -3061,7 +3059,6 @@ static int pl330_remove(struct amba_device *adev)
of_dma_controller_free(adev->dev.of_node);
dma_async_device_unregister(&pdmac->ddma);
- amba_set_drvdata(adev, NULL);
/* Idle the DMAC */
list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
diff --git a/drivers/input/serio/ambakmi.c b/drivers/input/serio/ambakmi.c
index 4e2fd44..b7c206d 100644
--- a/drivers/input/serio/ambakmi.c
+++ b/drivers/input/serio/ambakmi.c
@@ -167,8 +167,6 @@ static int amba_kmi_remove(struct amba_device *dev)
{
struct amba_kmi_port *kmi = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
serio_unregister_port(kmi->io);
clk_put(kmi->clk);
iounmap(kmi->base);
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index c3785ed..07e17f1 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1678,8 +1678,6 @@ static int mmci_remove(struct amba_device *dev)
{
struct mmc_host *mmc = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
if (mmc) {
struct mmci_host *host = mmc_priv(mmc);
diff --git a/drivers/rtc/rtc-pl030.c b/drivers/rtc/rtc-pl030.c
index 22bacdb..a804f75 100644
--- a/drivers/rtc/rtc-pl030.c
+++ b/drivers/rtc/rtc-pl030.c
@@ -153,8 +153,6 @@ static int pl030_remove(struct amba_device *dev)
{
struct pl030_rtc *rtc = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
writel(0, rtc->base + RTC_CR);
free_irq(dev->irq[0], rtc);
diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 0f0609b..c9ca86e 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -305,7 +305,6 @@ static int pl031_remove(struct amba_device *adev)
{
struct pl031_local *ldata = dev_get_drvdata(&adev->dev);
- amba_set_drvdata(adev, NULL);
free_irq(adev->irq[0], ldata);
rtc_device_unregister(ldata->rtc);
iounmap(ldata->base);
@@ -392,7 +391,6 @@ out_no_irq:
rtc_device_unregister(ldata->rtc);
out_no_rtc:
iounmap(ldata->base);
- amba_set_drvdata(adev, NULL);
out_no_remap:
kfree(ldata);
out:
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index abef061..e12813e 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2306,7 +2306,6 @@ pl022_remove(struct amba_device *adev)
amba_release_regions(adev);
tasklet_disable(&pl022->pump_transfers);
spi_unregister_master(pl022->master);
- amba_set_drvdata(adev, NULL);
return 0;
}
diff --git a/drivers/tty/serial/amba-pl010.c b/drivers/tty/serial/amba-pl010.c
index c368405..f630b78 100644
--- a/drivers/tty/serial/amba-pl010.c
+++ b/drivers/tty/serial/amba-pl010.c
@@ -728,7 +728,6 @@ static int pl010_probe(struct amba_device *dev, const struct amba_id *id)
amba_set_drvdata(dev, uap);
ret = uart_add_one_port(&amba_reg, &uap->port);
if (ret) {
- amba_set_drvdata(dev, NULL);
amba_ports[i] = NULL;
clk_put(uap->clk);
unmap:
@@ -745,8 +744,6 @@ static int pl010_remove(struct amba_device *dev)
struct uart_amba_port *uap = amba_get_drvdata(dev);
int i;
- amba_set_drvdata(dev, NULL);
-
uart_remove_one_port(&amba_reg, &uap->port);
for (i = 0; i < ARRAY_SIZE(amba_ports); i++)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 28b35ad..2a1efe0 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2143,7 +2143,6 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
amba_set_drvdata(dev, uap);
ret = uart_add_one_port(&amba_reg, &uap->port);
if (ret) {
- amba_set_drvdata(dev, NULL);
amba_ports[i] = NULL;
pl011_dma_remove(uap);
}
@@ -2156,8 +2155,6 @@ static int pl011_remove(struct amba_device *dev)
struct uart_amba_port *uap = amba_get_drvdata(dev);
int i;
- amba_set_drvdata(dev, NULL);
-
uart_remove_one_port(&amba_reg, &uap->port);
for (i = 0; i < ARRAY_SIZE(amba_ports); i++)
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..0bab6ab 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -594,8 +594,6 @@ static int clcdfb_remove(struct amba_device *dev)
{
struct clcd_fb *fb = amba_get_drvdata(dev);
- amba_set_drvdata(dev, NULL);
-
clcdfb_disable(fb);
unregister_framebuffer(&fb->fb);
if (fb->fb.cmap.len)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 58df98a..3f786ce 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -268,7 +268,6 @@ static int sp805_wdt_remove(struct amba_device *adev)
struct sp805_wdt *wdt = amba_get_drvdata(adev);
watchdog_unregister_device(&wdt->wdd);
- amba_set_drvdata(adev, NULL);
watchdog_set_drvdata(&wdt->wdd, NULL);
return 0;
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH] i2c-hid: explicitly cast parametrs to follow specifiers
From: Andy Shevchenko @ 2013-09-04 11:51 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input
In-Reply-To: <alpine.LNX.2.00.1309041317030.3684@pobox.suse.cz>
On Wed, 2013-09-04 at 13:17 +0200, Jiri Kosina wrote:
> On Tue, 25 Jun 2013, Andy Shevchenko wrote:
>
> > The vendor and product parameters are defined as __u32, but used as short int.
> > Let's do an explicit casting for them.
>
> Is this fixing any compiler warning you have seen?
It was found by static analyzer.
>
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> > drivers/hid/i2c-hid/i2c-hid.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> > index 879b0ed..d595f2a 100644
> > --- a/drivers/hid/i2c-hid/i2c-hid.c
> > +++ b/drivers/hid/i2c-hid/i2c-hid.c
> > @@ -1009,7 +1009,7 @@ static int i2c_hid_probe(struct i2c_client *client,
> > hid->product = le16_to_cpu(ihid->hdesc.wProductID);
> >
> > snprintf(hid->name, sizeof(hid->name), "%s %04hX:%04hX",
> > - client->name, hid->vendor, hid->product);
> > + client->name, (short int)hid->vendor, (short int)hid->product);
...and it's probably better to use (unsigned short int) if this patch is
going anywhere.
> >
> > ret = hid_add_device(hid);
> > if (ret) {
> > --
> > 1.8.3.1
> >
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH] i2c-hid: explicitly cast parametrs to follow specifiers
From: Jiri Kosina @ 2013-09-04 11:17 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-input
In-Reply-To: <1372163081-11394-1-git-send-email-andriy.shevchenko@linux.intel.com>
On Tue, 25 Jun 2013, Andy Shevchenko wrote:
> The vendor and product parameters are defined as __u32, but used as short int.
> Let's do an explicit casting for them.
Is this fixing any compiler warning you have seen?
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/hid/i2c-hid/i2c-hid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index 879b0ed..d595f2a 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -1009,7 +1009,7 @@ static int i2c_hid_probe(struct i2c_client *client,
> hid->product = le16_to_cpu(ihid->hdesc.wProductID);
>
> snprintf(hid->name, sizeof(hid->name), "%s %04hX:%04hX",
> - client->name, hid->vendor, hid->product);
> + client->name, (short int)hid->vendor, (short int)hid->product);
>
> ret = hid_add_device(hid);
> if (ret) {
> --
> 1.8.3.1
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] Input: don't push static constants on stack for %*ph
From: Andy Shevchenko @ 2013-09-04 10:41 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: Andy Shevchenko
There is no need to pass constants via stack. The width may be explicitly
specified in the format.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/input/mouse/hgpk.c | 7 +++----
drivers/input/touchscreen/atmel_mxt_ts.c | 4 ++--
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/input/mouse/hgpk.c b/drivers/input/mouse/hgpk.c
index 62be888..27909a1 100644
--- a/drivers/input/mouse/hgpk.c
+++ b/drivers/input/mouse/hgpk.c
@@ -333,9 +333,8 @@ static bool hgpk_is_byte_valid(struct psmouse *psmouse, unsigned char *packet)
}
if (!valid)
- psmouse_dbg(psmouse,
- "bad data, mode %d (%d) %*ph\n",
- priv->mode, pktcnt, 6, psmouse->packet);
+ psmouse_dbg(psmouse, "bad data, mode %d (%d) %6ph\n",
+ priv->mode, pktcnt, psmouse->packet);
return valid;
}
@@ -1027,7 +1026,7 @@ static enum hgpk_model_t hgpk_get_model(struct psmouse *psmouse)
return -EIO;
}
- psmouse_dbg(psmouse, "ID: %*ph\n", 3, param);
+ psmouse_dbg(psmouse, "ID: %3ph\n", param);
/* HGPK signature: 0x67, 0x00, 0x<model> */
if (param[0] != 0x67 || param[1] != 0x00)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 59aa240..dd44ebf 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -331,8 +331,8 @@ static bool mxt_object_writable(unsigned int type)
static void mxt_dump_message(struct device *dev,
struct mxt_message *message)
{
- dev_dbg(dev, "reportid: %u\tmessage: %*ph\n",
- message->reportid, 7, message->message);
+ dev_dbg(dev, "reportid: %u\tmessage: %7ph\n",
+ message->reportid, message->message);
}
static int mxt_check_bootloader(struct i2c_client *client,
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH 2/4] hid-sensor-hub: fix indentation accross the code
From: Jiri Kosina @ 2013-09-04 10:21 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Srinivas Pandruvada, linux-input, Srinivas Pandruvada
In-Reply-To: <1377787988.22798.1.camel@smile>
On Thu, 29 Aug 2013, Andy Shevchenko wrote:
> On Mon, 2013-08-19 at 08:28 -0700, Srinivas Pandruvada wrote:
> > On 08/14/2013 01:07 AM, Andy Shevchenko wrote:
> > > Patch just rearranges lines to be more compact and/or readable. Additionally it
> > > converts double space to one in several places.
> > >
> > > There is no functional change.
>
> Jiri, anything about this patch and the rest of the series?
> It seems you applied only patch 1/4. Do you have comments?
The whole series is now applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: move HID_REPORT_TYPES closer to the report-definitions
From: Jiri Kosina @ 2013-09-04 10:13 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-input
In-Reply-To: <1378123205-4032-1-git-send-email-dh.herrmann@gmail.com>
On Mon, 2 Sep 2013, David Herrmann wrote:
> HID_REPORT_TYPES defines the number of available report-types. Move it
> closer to the actualy definition of the report-types so we can see the
> relation more clearly (and hopefully will never forget to update it).
Makes sense. Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 01/14] HID: validate HID report id size
From: Jiri Kosina @ 2013-09-04 10:11 UTC (permalink / raw)
To: linux-input; +Cc: Kees Cook, Benjamin Tissoires
In-Reply-To: <alpine.LNX.2.00.1308282158220.22181@pobox.suse.cz>
So I have now queued subset of the patches that don't deal with
hid_validate_report(); waiting for v2 based on Benjamin's comments with
the rest.
The patches are public for distributions to apply them if they feel urgent
need, but for upstream I'd rather do things properly, and Benjamin had
quite some valuable feedback.
Thanks again,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 14/14] HID: check for NULL field when setting values
From: Jiri Kosina @ 2013-09-04 10:05 UTC (permalink / raw)
To: linux-input; +Cc: Kees Cook
In-Reply-To: <alpine.LNX.2.00.1308282223090.22181@pobox.suse.cz>
On Wed, 28 Aug 2013, Jiri Kosina wrote:
> From: Kees Cook <keescook@chromium.org>
>
> Defensively check that the field to be worked on is not NULL.
Applied.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Cc: stable@kernel.org
> ---
> drivers/hid/hid-core.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 55798b2..192be6b 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1206,7 +1206,12 @@ EXPORT_SYMBOL_GPL(hid_output_report);
>
> int hid_set_field(struct hid_field *field, unsigned offset, __s32 value)
> {
> - unsigned size = field->report_size;
> + unsigned size;
> +
> + if (!field)
> + return -1;
> +
> + size = field->report_size;
>
> hid_dump_input(field->report->device, field->usage + offset, value);
>
> --
> Jiri Kosina
> SUSE Labs
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 13/14] HID: picolcd_core: validate output report details
From: Jiri Kosina @ 2013-09-04 10:04 UTC (permalink / raw)
To: Bruno Prémont; +Cc: linux-input, Kees Cook
In-Reply-To: <20130831140415.7837c1c9@neptune.home>
On Sat, 31 Aug 2013, Bruno Prémont wrote:
> Hi Kees, Jiri,
>
> On Wed, 28 August 2013 Jiri Kosina <jkosina@suse.cz> wrote:
> > From: Kees Cook <keescook@chromium.org>
> >
> > A HID device could send a malicious output report that would cause the
> > picolcd HID driver to trigger a NULL dereference during attr file writing.
> >
> > CVE-2013-2899
> >
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > Cc: stable@kernel.org
> > ---
> > drivers/hid/hid-picolcd_core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
> > index b48092d..72bba1e 100644
> > --- a/drivers/hid/hid-picolcd_core.c
> > +++ b/drivers/hid/hid-picolcd_core.c
> > @@ -290,7 +290,7 @@ static ssize_t picolcd_operation_mode_store(struct device *dev,
> > buf += 10;
> > cnt -= 10;
> > }
> > - if (!report)
> > + if (!report || report->maxfield < 1)
>
> Please do
> + if (!report || report->maxfield != 1)
>
> That way we are consistent with whole picolcd driver and a device
> deciding to change its HID-ABI will be properly detected.
>
> With that adjustment, Acked-by/Reviewed-by me
Applied with that adjustment. Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 10/14] HID: ntrig: validate feature report details
From: Jiri Kosina @ 2013-09-04 10:00 UTC (permalink / raw)
To: Rafi Rubin; +Cc: linux-input, Kees Cook
In-Reply-To: <521F64C3.8000201@seas.upenn.edu>
On Thu, 29 Aug 2013, Rafi Rubin wrote:
> Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
Applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 06/14] HID: pantherlord: validate output report details
From: Jiri Kosina @ 2013-09-04 9:58 UTC (permalink / raw)
To: linux-input; +Cc: Kees Cook
In-Reply-To: <alpine.LNX.2.00.1308282218580.22181@pobox.suse.cz>
On Wed, 28 Aug 2013, Jiri Kosina wrote:
> From: Kees Cook <keescook@chromium.org>
>
> A HID device could send a malicious output report that would cause the
> pantherlord HID driver to write beyond the output report allocation
> during initialization, causing a heap overflow:
>
> [ 310.939483] usb 1-1: New USB device found, idVendor=0e8f, idProduct=0003
> ...
> [ 315.980774] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten
>
> CVE-2013-2892
Applying this one, thanks.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Cc: stable@kernel.org
> ---
> drivers/hid/hid-pl.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-pl.c b/drivers/hid/hid-pl.c
> index d29112f..2dcd7d9 100644
> --- a/drivers/hid/hid-pl.c
> +++ b/drivers/hid/hid-pl.c
> @@ -132,8 +132,14 @@ static int plff_init(struct hid_device *hid)
> strong = &report->field[0]->value[2];
> weak = &report->field[0]->value[3];
> debug("detected single-field device");
> - } else if (report->maxfield >= 4 && report->field[0]->maxusage == 1 &&
> - report->field[0]->usage[0].hid == (HID_UP_LED | 0x43)) {
> + } else if (report->field[0]->maxusage == 1 &&
> + report->field[0]->usage[0].hid ==
> + (HID_UP_LED | 0x43) &&
> + report->maxfield >= 4 &&
> + report->field[0]->report_count >= 1 &&
> + report->field[1]->report_count >= 1 &&
> + report->field[2]->report_count >= 1 &&
> + report->field[3]->report_count >= 1) {
> report->field[0]->value[0] = 0x00;
> report->field[1]->value[0] = 0x00;
> strong = &report->field[2]->value[0];
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 11/14] HID: multitouch: validate feature report details
From: Jiri Kosina @ 2013-09-04 9:57 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Kees Cook, Benjamin Tissoires, linux-input, Henrik Rydberg
In-Reply-To: <CAN+gG=Fx5bjcPndRSBBJTvZFC2GOegigkzL3De8iK7vauiPq1g@mail.gmail.com>
On Mon, 2 Sep 2013, Benjamin Tissoires wrote:
> > Given the 12 flaws, what do you see as the best way forward?
>
> If Jiri thinks we can wait one more week for some of these patches (I
> know that the most critical one, 1/14 is already on its way to Linus),
> then I can handle the v2, but not before Friday. Again, I think the
> current patch series is perfectly fine for distributions as they can
> add/remove things more easily than we can do in master.
I agree.
1/14 will go to Linus shortly. The rest is public, and distributions are
taking it depending on their requirements, but I'd like to have the
patchset polished before pushing it to Linus.
Therefore putting the rest on hold now, and waiting for v2.
Thanks a lot to both of you,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] hid-wiimote: print small buffers via %*ph
From: Jiri Kosina @ 2013-09-04 9:43 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: David Herrmann, linux-input
In-Reply-To: <alpine.LNX.2.00.1309041140080.3684@pobox.suse.cz>
On Wed, 4 Sep 2013, Jiri Kosina wrote:
> > Instead of passing each byte through stack let's use %*ph specifier to dump
> > buffer as a hex string.
>
> Applied, thanks.
I acutally applied the phC one, but replied to wrong thread, sorry for the
noise.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] hid-wiimote: print small buffers via %*ph
From: Jiri Kosina @ 2013-09-04 9:40 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: David Herrmann, linux-input
In-Reply-To: <1378211544-16594-1-git-send-email-andriy.shevchenko@linux.intel.com>
On Tue, 3 Sep 2013, Andy Shevchenko wrote:
> Instead of passing each byte through stack let's use %*ph specifier to dump
> buffer as a hex string.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] hid: uhid: improve uhid example client
From: Jiri Kosina @ 2013-09-04 9:37 UTC (permalink / raw)
To: David Herrmann; +Cc: Benjamin Tissoires, linux-input, Anderson Lizardo
In-Reply-To: <CANq1E4QwPRgCkROyLWNU7KtVDU6DAoLG+pD2_6brD90gSiJ9pg@mail.gmail.com>
On Mon, 2 Sep 2013, David Herrmann wrote:
> But thanks for the usb-spec hint, haven't looked there, yet.
There is also HID report descriptor tool available at
http://www.usb.org/developers/hidpage/
The tool itself isn't that earth-shaking (and you have to run it in wine
:) ), but it contains a load of pre-defined example descriptors for
various devices.
> No intention to modify it. Looks all good to me now.
Now applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox