linux-kernel - Re: [RFC ebeam PATCH v2 3/3] input: misc: New USB eBeam input driver.

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]

Message-ID: <501BEEA8.4060702@laposte.net>
Date:	Fri, 03 Aug 2012 17:30:48 +0200
From:	Yann Cantin <yann.cantin@...oste.net>
To:	Jiri Kosina <jkosina@...e.cz>
CC:	linux-input@...r.kernel.org, linux-usb@...r.kernel.org,
	gregkh@...uxfoundation.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC ebeam PATCH v2 3/3] input: misc: New USB eBeam input driver.

Hi,

>> +#include <linux/hid.h>
> 
> As this driver is not a HID bus driver, why do you need this include?

Cinder, removed

>> +#define DRIVER_VERSION	"v0.7"
> 
> I don't think we need to be tracking driver versions for newly submitted 
> drivers, git is much better at tracking changes.

Old habit, removed.

>> +	u16			 X, Y;		/* raw coordinates	     */
>> +	int			 x, y;		/* computed coordinates      */
> 
> X,x being different fields seems confusing to me. How about, let's say, x, 
> raw_x?

Done.
 
>> +DEVICE_H_ATTR(1);
>> +DEVICE_H_ATTR(2);
>> +DEVICE_H_ATTR(3);
>> +DEVICE_H_ATTR(4);
>> +DEVICE_H_ATTR(5);
>> +DEVICE_H_ATTR(6);
>> +DEVICE_H_ATTR(7);
>> +DEVICE_H_ATTR(8);
>> +DEVICE_H_ATTR(9);
> 
> You are adding a number of sysfs files. If they are really necessary, 
> you'll probably need to document those in Documentation/ABI.

Will do, in testing i suppose.

BTW : The driver need lot of parameters to be passed from user-space calibration
tool. The best way to do it isn't decided yet : one sysfs file per parameter, or
one sysfs file for all, with a big sscanf parsing. Any idea ?

>> +		strlcat(ebeam->name, ")", sizeof(ebeam->name));
> 
> I'd suggest checking the length, making sure that you don't overflow the 
> ->name buffer.

Something like this ? :

if (strlcat(ebeam->name, ")", sizeof(ebeam->name))>=sizeof(ebeam->name)) {
	// overflowed, closing ) anyway
	ebeam->name[sizeof(ebeam->name)-2] = ')';

Thanks.
-- 
Yann Cantin
A4FEB47F
--
--
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/