- 18 Apr, 2012 28 commits
-
-
Dan Carpenter authored
The original code had some confusion about the dimensions of the array. It should have been an array of 2 element arrays but it was declared as an array of 50 element arrays. The limitter on the outside array should have been ARRAY_SIZE(chan_freq_list) or 26 but instead 50 was used. It meant that we read past the end. It's probably harmless but it's obviously worth fixing. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Benedikt Bergenthal authored
Fixed a code style issue. Signed-off-by:
Benedikt Bergenthal <benedikt@kdrennert.de> Signed-off-by:
-
Larry Finger authored
It is possible to misconfigure a kernel by selecting the rtllib crypto routines without enabling the underlying support from the crypto library. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
Sean MacLennan <seanm@seanm.ca> Signed-off-by:
-
Dan Carpenter authored
We don't use the rxcmdpkt[] counters at all and we can remove them. Signed-off-by:
-
Dan Carpenter authored
When we received a command we incremented a stat counter depending on the type of message. The problem is there were 8 types of commands but there were only 4 counters allocated so it corrupted memory past the end of the rxcmdpkt[] array. The fix is just to remove the counters because they aren't used. Signed-off-by:
-
Justin P. Mattock authored
Signed-off-by:
Justin P. Mattock <justinmattock@gmail.com> Signed-off-by:
-
Randy Dunlap authored
Fix printk format warnings by using 't' modifier for ptrdiff_t. drivers/staging/android/alarm.c:344:2: warning: format '%ld' expects type 'long int', but argument 2 has type 'int' drivers/staging/android/alarm.c:367:3: warning: format '%ld' expects type 'long int', but argument 2 has type 'int' Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Cc: Brian Swetland <swetland@google.com> Signed-off-by:
-
Masanari Iida authored
Fix spelling typo in comments within android drivers. Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Signed-off-by:
-
Jonathan Cameron authored
There is no longer any need for this as we have separate info_mask elements for raw and processed value reads. Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Jonathan Cameron authored
Until now all channels have had read/write attributes. This patch allows for channels where we can't actually read the value (or for output devices, write it!) v2 introduces separate elements for processed and raw thus removing some special case code from the core. Thanks to Lars-Peter for an excellent suggestion! Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. This one stands along as it merged just before the series doing all the other drivers. Signed-off-by:
Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by:
-
Lars-Peter Clausen authored
Precursor to making value read / write attribute optional. No processed values in resolvers at the moment. Signed-off-by:
-
Lars-Peter Clausen authored
Precursor to making value read / write attribute optional. No processed values in resolvers at the moment. Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. No processed values in resolvers at the moment. Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. No processed values for magnetometers. Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. Note that minimal change route taken here. The read_raw callbacks in both drivers could do fewer checks to identify the channel than they now do. Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. No processed values in IMU. Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. No processed values in gyroscopes. Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. No processed versions in DACs. Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. No processed values for adc's. Updated to include the spear adc driver (hence introducing a dependency on the patch that adds that driver). Signed-off-by:
-
Jonathan Cameron authored
Precursor to making value read / write attribute optional. No processed values in accelerometers. Signed-off-by:
-
Jonathan Cameron authored
This will allow us to have drivers where the channel value may not be read or written but other information is available. Also adds the ability to have both processed and raw access to a given channel, though in most cases this doesn't make sense. Ultimately will lead to simpler code by allowing us to drop the special case handling for the value reading cases. Signed-off-by:
-
W. Trevor King authored
Update comments in comedi.h accordingly. Signed-off-by:
W. Trevor King <wking@drexel.edu> Acked-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Laxman Dewangan authored
The mask value in the read_raw/write_raw is absolute value, not the bit position value. Fixing this in the implemented function to check value, not with the bit position value. Signed-off-by:
Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by:
-
Jesper Juhl authored
release_firmware() deals gracefullt with NULL pointers - it's redundant to check for them before calling the function. Also remove a few pointless comments - it's rather obvious from the code that kfree() free's a buffer and that release_firmware() releases firmware - comments just stating that add no value. Signed-off-by:
Jesper Juhl <jj@chaosbits.net> Signed-off-by:
-
Jesper Juhl authored
Checking for a NULL pointer before calling release_firmware() is redundant since the function does that check itself. Signed-off-by:
-
- 13 Apr, 2012 12 commits
-
-
Ian Abbott authored
Allow the default values for the module parameters for the default initial buffer size and default maximum buffer size to be specified in the kernel configuration. I'm not sure what the defaults for the defaults for the defaults should be, but 64 KiB seems to small, so I used values suggested by Bernd Porr, which are 2048 KiB for the default initial buffer size and 20480 for the default maximum buffer size. Signed-off-by:
-
Ian Abbott authored
For comedi subdevices that support asynchronous transfer commands, the initial buffer size and maximum buffer size for the transfer are both set to 64 KiB when the comedi device is "attached" to the hardware device. For many applications with reasonable fast sample rates and slow user-space (e.g. Python) these sizes are a bit too small. A task with CAP_SYS_ADMIN privileges can change the maximum buffer size for a comedi subdevice with an ioctl call or by writing to a device attribute file in sysfs, but that's not very convenient. For comedi devices attached during system startup, this could be done by a start-up script, but for hot-plugged devices it would require scripts run by udev rules, etc. Rather than use hardwired values, this patch introduces a couple of module parameters to set the defaults for the initial buffer size (comedi_default_buf_size_kb) and maximum buffer size (comedi_default_buf_maxsize_kb). These values are applied in place of the previous hard-wired values when the comedi device is "attached". The module parameter values are in units of KiB for consistency with the existing device attribute files. Signed-off-by:
-
Stefan Roese authored
This patch implements the basic single data conversion support for the SPEAr600 SoC ADC. The register layout of SPEAr600 differs a bit from other SPEAr SoC variants (e.g. SPEAr3xx). These differences are handled via DT compatible testing. Resulting in a multi-arch binary. This driver is currently tested only on SPEAr600. Future patches may add support for other SoC variants (SPEAr3xx) and features like software buffer or DMA. Signed-off-by:
Stefan Roese <sr@denx.de> Acked-by:
Viresh Kumar <viresh.kumar@st.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Laxman Dewangan authored
Intersil's ISL29028 is concurrent Ambient Light and Proximity Sensor device. Add driver to access the light and IR intensity and proximity value via iio interface. Signed-off-by:
-
Laxman Dewangan authored
Adding channel info IIO_CHAN_INFO_SAMP_FREQ to select different sampling frequency per channel wise. Signed-off-by:
-
Jonathan Cameron authored
I was warned long ago that this macro would cause trouble but didn't heed the advice, hence I'm unwinding it now! Signed-off-by:
-
Jonathan Cameron authored
This macro is being removed to simplify ongoing maintenance so we need to unwind and remaining users. Signed-off-by:
-
Jonathan Cameron authored
This macro is being removed to simplify ongoing maintenance so we need to unwind and remaining users. Signed-off-by:
-
Jonathan Cameron authored
This macro is being removed to simplify ongoing maintenance so we need to unwind and remaining users. Signed-off-by:
-
Jonathan Cameron authored
This macro is being removed to simplify ongoing maintenance so we need to unwind and remaining users. Signed-off-by:
-
Jonathan Cameron authored
This macro is being removed to simplify ongoing maintenance so we need to unwind and remaining users. V2 has the cleanup Lars-Peter suggested. Signed-off-by:
-
Jonathan Cameron authored
This macro is being removed to simplify ongoing maintenance so we need to unwind and remaining users. Signed-off-by:
-
