On Thu, 24 Dec 2009 02:29:47 +0000
Marcin Tolysz <tolysz@xxxxxxxxx> wrote:
> Simple but effective way of changing HID device descriptors using
> firmware loading mechanism.
> Just place your new descriptor in a location specified by driver
> i.e. somewhere in /lib/firmware/hid/
> If it is there it will replace HID descriptor from the device.
> I do not do any parsing or checking, as it is done by hid driver.
>
> Signed-off-by: Marcin Tolysz <tolysz@xxxxxxxxx>
>
Only some style comments below, I haven't tested the patch. Plus, try
running the patch through scripts/checkpatch.pl to spot all the other
style issues.
> ---
> drivers/hid/hid-core.c | 26 +++++++++++++++++++++++++-
> 1 files changed, 25 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 80792d3..5d8d656 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -27,6 +27,7 @@
> #include <linux/wait.h>
> #include <linux/vmalloc.h>
> #include <linux/sched.h>
> +#include <linux/firmware.h>
>
> #include <linux/hid.h>
> #include <linux/hiddev.h>
> @@ -640,6 +641,10 @@ int hid_parse_report(struct hid_device *device,
> __u8 *start,
> struct hid_item item;
> __u8 *end;
> int ret;
> + const struct firmware *fw;
> + int succ;
success? Can't you init fw to NULL and derive this info checking
(fw != NULL) before releasing firmware?
> + char *file;
> +
> static int (*dispatch_type[])(struct hid_parser *parser,
> struct hid_item *item) = {
> hid_parser_main,
> @@ -650,10 +655,27 @@ int hid_parse_report(struct hid_device *device,
> __u8 *start,
>
> if (device->driver->report_fixup)
> device->driver->report_fixup(device, start, size);
> + /* Now load a hid descriptor from a file firmware
> + ignoring this fixup thing */
> + file=kmalloc(29, GFP_KERNEL);
> +
> sprintf(file,"hid/%04X:%04X:%04X:%04X.bin",device->bus,device->vendor,device->product,device->version);
> +
What about removing this 29?
#define NEW_HID_DESCRIPTOR_PATH_FMT "hid/%04X:%04X:%04X:%04X.bin"
and use it in kmalloc with strlen and in sprintf.
> + succ = request_firmware(&fw, file, &device->dev);
> +
> + if (succ)
> + printk(KERN_INFO "To relace HID descriptor place it in
> /lib/firmaware/%s\n", file);
pr_info() could be used or maybe even dev_info()
> + else{
> + start = fw->data;
> + size = fw->size;
> + printk(KERN_INFO "HID descriptor relaced with /lib/firmaware/%s\n",
> file);
> + }
> + kfree(file);
>
> device->rdesc = kmalloc(size, GFP_KERNEL);
> - if (device->rdesc == NULL)
> + if (device->rdesc == NULL){
> + if(!succ)release_firmware(fw);
> return -ENOMEM;
> + }
> memcpy(device->rdesc, start, size);
> device->rsize = size;
>
> @@ -690,6 +712,7 @@ int hid_parse_report(struct hid_device *device, __u8
> *start,
> dbg_hid("unbalanced delimiter at end of report description\n");
> goto err;
> }
> + if(!succ)release_firmware(fw);
> vfree(parser);
> return 0;
> }
> @@ -697,6 +720,7 @@ int hid_parse_report(struct hid_device *device, __u8
> *start,
>
> dbg_hid("item fetching failed at offset %d\n", (int)(end - start));
> err:
> + if(!succ)release_firmware(fw);
> vfree(parser);
> return ret;
> }
> -- 1.6.5.7
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Attachment:
pgpw5p8KS5QoG.pgp
Description: PGP signature
