Re: [PATCH 0/7] staging: comedi: core: checkpatch.pl --strict cleanup
On 2014-07-18 22:28, H Hartley Sweeten wrote: comedi_fops.c also still has a couple: CHECK: if this code is redundant consider removing it Two of them deal with #if 0'ed code in do_lock_ioctl() and do_unlock_ioctl(). The disabled code would call the subdevice (*lock_f) and (*unlock) callbacks. I'm not sure why this code is disabled. Hopefully Ian can provide some info. It was added in comedi-0.7.6 back in June 1999 and has always been commented out. Should be safe to remove it! There is also some disabled code in do_chaninfo_ioctl() that does a copy_to_user(). Again, I'm not sure why this is disabled. It was replaced by the code above it in comedi-0.7.40, although the format of the rangelist[] values returned to the user changed in comedi-0.7.43. I need to check what uses the various bits of the rangelist[] elements. Putting the minor device number in there doesn't seem terribly useful, for example, especially as only 4 bits are provided to hold it. -- -=( Ian Abbott @ MEV Ltd.E-mail: abbo...@mev.co.uk)=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/7] staging: comedi: core: checkpatch.pl --strict cleanup
This series fixes most of the checkpatch.pl --strict issues in the comedi core files. comedidev.h still has a couple: CHECK: spinlock_t definition without comment CHECK: struct mutex definition without comment CHECK: Avoid CamelCase: RANGE_mA CHECK: Avoid CamelCase: UNIT_mA CHECK: Avoid CamelCase: range_0_20mA CHECK: Avoid CamelCase: range_4_20mA CHECK: Avoid CamelCase: range_0_32mA I'm hoping Ian Abbot can add some comments about the spinlock_t and mutex definitions. The CamelCase ones are easy to fix but I think 'mA' is easier to read than 'MA' or 'ma'. comedi_fops.c also still has a couple: CHECK: if this code is redundant consider removing it Two of them deal with #if 0'ed code in do_lock_ioctl() and do_unlock_ioctl(). The disabled code would call the subdevice (*lock_f) and (*unlock) callbacks. I'm not sure why this code is disabled. Hopefully Ian can provide some info. There is also some disabled code in do_chaninfo_ioctl() that does a copy_to_user(). Again, I'm not sure why this is disabled. H Hartley Sweeten (7): staging: comedi: comedi_compat32: checkpatch.pl --strict cleanup staging: comedi: drivers.c: checkpatch.pl --strict cleanup staging: comedi: comedi_internal.h: checkpatch.pl --strict cleanup staging: comedi: comedi.h: checkpatch.pl --strict cleanup staging: comedi: comedi_fops: checkpatch.pl --strict cleanup staging: comedi: comedidev.h: checkpatch.pl --strict cleanup staging: comedi: comedi_compat32.h: checkpatch.pl --strict cleanup drivers/staging/comedi/comedi.h | 116 +-- drivers/staging/comedi/comedi_compat32.c | 28 drivers/staging/comedi/comedi_compat32.h | 3 +- drivers/staging/comedi/comedi_fops.c | 12 ++-- drivers/staging/comedi/comedi_internal.h | 1 + drivers/staging/comedi/comedidev.h | 5 +- drivers/staging/comedi/drivers.c | 4 +- 7 files changed, 58 insertions(+), 111 deletions(-) -- 1.9.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: comedi: core: checkpatch.pl --strict cleanup
On Fri, Jul 18, 2014 at 02:28:09PM -0700, H Hartley Sweeten wrote: This series fixes most of the checkpatch.pl --strict issues in the comedi core files. comedidev.h still has a couple: CHECK: spinlock_t definition without comment CHECK: struct mutex definition without comment CHECK: Avoid CamelCase: RANGE_mA CHECK: Avoid CamelCase: UNIT_mA CHECK: Avoid CamelCase: range_0_20mA CHECK: Avoid CamelCase: range_4_20mA CHECK: Avoid CamelCase: range_0_32mA I'm hoping Ian Abbot can add some comments about the spinlock_t and mutex definitions. The CamelCase ones are easy to fix but I think 'mA' is easier to read than 'MA' or 'ma'. Yeah, don't worry about that, it's fine. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
