The analog inputs are confgured with jumpers on the board to be:
* 16 single-ended inputs
* 8 differential inputs
* 16 pseudo-differential inputs (common ground)
Simplify the handling of this configuration option and properly set
the subdev_flags based on the selected input mode.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: dt2811: simplify analog output range options
The D/A ranges are not programmable. Currently this driver uses some
configuration options to select the comedi_lrange for each channel.
This is a bit messy and it requires the user to make sure the correct
option value is used.
The range information isn't used by the driver. The user space library
uses it to convert between raw data values and physical units. If the
user passed an incorrect option when attaching the driver the conversion
will be incorrect.
Simplify the analog output ranges by providing a range_table that
contains all the possible output ranges. The user can then select the
correct range when converting values.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: dt2811: tidy up Digital Input/Output register defines
The digital input and outputs are separate ports even though they share the
same register offset. For aesthetics, define then separately and remove the
redundant information in the comment.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Introduce a helper function to handle writing the channel/gain data to
the queue for single channel reads, (*insn_read), and multi-channel
scans, (*do_cmd).
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: das16m1: remove unnecessary ai 'cancel' operations
The comedi core will only call the (*insn_read) and (*do_cmd) functions
if the subdevice is not "busy". All async commands are terminated by
a (*cancel) operation which clears the INTE and PACER_MASK bits in the
interrupt control register. These bits are also cleared when the driver
first attaches. There is no need for the (*insn_read) or (*do_cmd) to
duplicate the cancel.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: das16m1: tidy up digital input/output register defines
The digtial inputs and outputs are read/written using the same register
offset but they are different logical registers. Physically they are the
same register with the hi 4 bits returning the inputs and the lo 4 bits
driving the outputs.
For aesthetics, use two different defines for the registers.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: das16m1: tidy up analog input data register defines
Convert the inline helper munge_sample() into a macro and rename the
defines for the analog input data register/bits. Use the register define
when accessing this register instead of just dev->iobase.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: das16m1: tidy up register map comment
The comment about all the registers is not neccessary. The defines
give the same information. This also fixes a checkpatch.pl issue:
WARNING: Block comments use * on subsequent lines
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Drokin [Wed, 15 Jun 2016 03:33:43 +0000 (23:33 -0400)]
staging/lustre/libcfs: Remove "Please contact Oracle" from header
The "Please contact Oracle Corporation" lines are removed since not
only Oracle has nothing to do with Lustre anymore, there's a pointer
to GPL already that's independent of any particular company.
Oleg Drokin [Wed, 15 Jun 2016 03:33:40 +0000 (23:33 -0400)]
staging/lustre: Replace sun.com GPLv2 URL with gnu.org one.
http://www.sun.com/software/products/lustre/docs/GPLv2.pdf is no
longer around, so replae it with (hopefully more permanent)
http://http://www.gnu.org/licenses/gpl-2.0.html
Oleg Drokin [Wed, 15 Jun 2016 03:33:39 +0000 (23:33 -0400)]
staging/lustre: Remove the "Please contact SUN for GPL" from headers
Since SUN is no longer around and there's no point in contacting them,
just remove that whole thing. Copy of GPL is available online anyway
(URLs to be updated in next patch).
This patch was generated with:
find drivers/staging/lustre -name "*.[ch]" -exec perl -0777 -i -pe 's/ \* Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,\n \* CA 95054 USA or visit www.sun.com if you need additional information or\n \* have any questions.\n \*\n//igs' {} \;
Arnd Bergmann [Mon, 13 Jun 2016 20:44:57 +0000 (22:44 +0200)]
staging: lustre: hide call to Posix ACL in ifdef
A call to forget_cached_acl() was recently added to the lustre file
system, but this is only available when CONFIG_FS_POSIX_ACL is
enabled, otherwise the build now fails with:
lustre/llite/file.c: In function 'll_get_acl':
lustre/llite/file.c:3134:2: error: implicit declaration of function 'forget_cached_acl' [-Werror=implicit-function-declaration]
forget_cached_acl(inode, type);
This adds one more #ifdef for this call, corresponding to the
other 22 such checks for ACL in lustre.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: b788dc51e425 ("staging: lustre: llite: drop acl from cache") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Simmons [Wed, 8 Jun 2016 22:50:12 +0000 (18:50 -0400)]
staging: lustre: llite: remove lloop device
The lloop device was original developed to work around
the lack of direct I/O for the default loop back device.
Also the lloop device greatly out performed the default
loop back device. The lloop hasn't been worked on for
some time and now it no longer out performs the loop
device and loop now supports direct I/O. Since this is
the case we can delete this device.
Signed-off-by: James Simmons <jsimmons@infradead.org> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'iio-for-4.8a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
First round of IIO new device support, features and cleanups for the 4.8 cycle.
New device support
* ads1015
- add ads1115 support
* bma220 accelerometer
- new driver
- triggered buffer support.
* bmc150
- add bmm150 support.
* bmp280
- bme280 support with addition of humidity channel.
* max5487 potentiometer
- new driver
* MMA7660FC accelerometer.
- New driver
* st-pressure
- support for the lps22hb
* loop trigger.
- This one is *nasty* but we have real applications (parrot drones) where
it is useful. The trigger basically spins as hard as it can firing off
a new trigger each time all triggered devices come back to say they are
done. It doesn't hang a machine even when doing it on a dummy driver.
A lot nicer than having this implemented within lots of device drivers
anyway.
Core stuff
* Add support to create IIO devices via configfs (similar to we did for
triggers a while back) + docs.
* New channel types
- IIO_ELECTRICAL_CONDUCTIVITY
* Couple of MAINTAINERS patches to list the device tree bindings.
* Make trigger ops structure non optional (comment fix). It hasn't been for
an awful long time, but that's not what the description said.
New features
* ak8975
- support adapters that are limited to byte data only by allowing the
emulated block read i2c function that was recently introduced.
* atlas-ph
- support atlas-ec (electrical conductivity sensor)
* bmi160
- add available frequency and scale attributes to make the driver
more user friendly (and avoid having to read the datasheet to know
what will work).
* dummy
- move creation to configfs interface. It's not real hardware so we
are not that worried about the ABI breakage ;)
* mma8452
- oversampling ration support
* nau7802
- expose available gains to make life easier for userspace.
* st-sensors
- allow use of emulation for SMBus block reads as all the st parts support
it.
* ti-ads1015
- list datasheet names to allow their use by inkernel consumers.
* Various module alias additions to help auto probing. Drop one redundant one
as well.
Cleanups
* ad7266, ad7476, ad7887, ad7923, ad799x
- use direct mode claim function rather than open coding it during sensor
read (prevents switching on buffers mid read).
* ad7793, ad7791
- use direct mode claim to prevent frequency changes when buffers running.
* afe440x - These are ABI breaking but the driver requires custom userspace
code to do anything useful anyway and that is still being written and under
control of TI. Ultimately we may have other libraries to do pulse
oximetry with these devices but we aren't aware of any yet.
- kernel-doc format fixes
- drop ifdef fun around of_match_ptr - it's not worth the mess to save
a tiny amount of space.
- drop some unnecessary register initializations.
- drop the weird locked gain modes as they gain us nothing (can just set
all gains separately).
- remove handling of offset attributes seeing as no channels actually have
them (oops)
- Drop the LED3 input channel as it's an alias for ALED2.
- *big one* remove channel names - an experiment that turned out to not
make sense - see patch for details.
- use regmap fields to clean up code.
- tie the tia gain stages to appropriate channels in the ABI as that is
what they really effect. Same with the LED currents.
- cleanout some unused defines and fix a missnamed one.
* atlas-ph
- reorganise to allow support of other similar parts.
* bmc150
- document supported chips in kconfig help.
* jsa1212
- drop an unneeded i2c functionality check for functionality the driver
doesn't use.
* mxs-lradc
- simply touch screen registration code.
- remove the touch screen unregister as all devm based now.
- disable only those channels that are masked in hardware stop (others
are already dealt with elsewhere)
* st-sensors
- unexport st_sensors_get_buffer_element as nothing outside the st-sensors
core driver uses it.
- fix handling of failure to start up regulators.
* tpl0102
- drop an i2c functionality test for features that aren't needed.
* ti-am335x
- use variable name rather than type in sizeof for clarity.
- use SIMPLE_DEV_PM_OPS helper macro to tidy up a bit.
Tools
* Add install / uninstall to makefile. Someone cares, so presumably
some people will find it useful!
* generic_buffer
- rename to iio_generic_buffer to line up with other tools.
- handle cleanup when receiving signals
- Add a --device-num option and a --trigger-num option rather than
relying on naming which doesn't work if you have two of the same part.
Changes return statements in visornic_rx() to use literals instead of a
variable. Also changes function description to reflect the correct return
type.
Signed-off-by: David Binder <david.binder@unisys.com> Signed-off-by: David Kershner <david.kershner@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch changes the vague -1 return values to -EPERM.
This operation is not supported is a good alternative
to -1 because the return is basically telling the caller
that the processor doesn't support vmcall operations.
Signed-off-by: Erik Arfvidson <erik.arfvidson@unisys.com> Signed-off-by: David Kershner <david.kershner@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Erik Arfvidson [Sat, 14 May 2016 03:17:19 +0000 (23:17 -0400)]
staging: unisys: visorbus change -1 return values
This patch changes the vague -1 return values to -EFAULT since
it would be the most appropriate, given that this error
would only occur in an unexpected bad offset field.
Resulting in a bad address.
Signed-off-by: Erik Arfvidson <erik.arfvidson@unisys.com> Signed-off-by: David Kershner <david.kershner@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Sell [Thu, 12 May 2016 13:14:44 +0000 (09:14 -0400)]
staging: unisys: visorhba: visorhbas_open[] no longer used, so deleted
The prior patch which simplified the visorhba debugfs interface made it so
visorhbas_open[] and VISORHBA_OPEN_MAX were no longer needed, so they have
now been deleted.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: David Kershner <david.kershner@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Sell [Thu, 12 May 2016 13:14:43 +0000 (09:14 -0400)]
staging: unisys: visorhba: simplify and enhance debugfs interface
debugfs info for each visorhba device is now presented by a file named of
the following form within the debugfs tree:
visorhba/vbus<x>:dev<y>/info
where <x> is the vbus number, and <y> is the relative device number.
Also, the debugfs presentation function was converted to use the seq_file
interface, so that it could access the device context without resorting to
a global array. This also simplified the function.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: David Kershner <david.kershner@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The handling of CMD_NOTIFYGUEST_TYPE messages from the IO partition appears
to be only partially implemented, but fortunately it is never used in our
current environment. This patch deletes the unused code.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: David Kershner <david.kershner@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is necessary to enable ANY task mgmt command to complete
successfully via visorhba.
When issuing a task mgmt command (CMD_SCSITASKMGMT_TYPE) to the IO
partition (back-end), forward_taskmgmt_command() includes pointers
within the command area that will be used to wake up the issuing
process and provide the result when the command completes:
'notify_handle' is a pointer to a 'wait_queue_head_t' variable, and
'notifyresult' is a pointer to an int. Both of these are just local
stack variables in the issuing process.
The way it's supposed to happen is that when the IO partition completes
the command, in our completion handling we get copies of those pointers
back from the IO partition, where we stash the result of the command at
'*notifyresult' (which should not be 0xffff, because that is the initial
value that the caller is looking to see a change in), and wake up the
wait queue at '*notify_handle'. There are several places we do that dance,
but prior to this patch, we always do it WRONG, like:
The wake_up_all() part is correct (albeit with the help of the sloppy
pointer casting, but that's irrelevant to the bug), but the assignment of
'notifyresult_handle' is WRONG, and SHOULD read:
Without this change, the caller is NEVER going to notice a change in his
local value of 'notifyresult' when he does the:
if (!wait_event_timeout(notifyevent, notifyresult != 0xffff,
msecs_to_jiffies(45000)))
and hence will be timing out EVERY taskmgmt command.
This patch also eliminates the need for sloppy casting of pointers
back-and-forth between u64 values, with the help of idr_alloc() to provide
handles for us. It is the generated int handles we pass to the IO
partition to denote our completion context, and these are validated and
converted back to the required pointers when the task mgmt commands are
returned back to us by the IO partition.
== Testing ==
You must enable dynamic debugging in visorhba (build kernel with
'CONFIG_DYNAMIC_DEBUG=y', provide kernel parameter 'visorhba.dyndbg=+p')
to see kernel messages involved with visorhba scsi task mgmt commands,
which were added in this patch in the form of a few dev_dbg() / pr_debug()
messages.
In order to inject faults necessary to get visorhba to actully issue scsi
task mgmt commands, you will need to compile a kernel with
CONFIG_FAIL_IO_TIMEOUT and friends, in the "Kernel hacking" section:
* Enable "Fault-injection framework"
* Enable "Fault-injection capability for disk IO"
* Enable "Fault-injection capability for faking disk interrupts"
* Enable "Debugfs entries for fault-injection capabilities"
When running a kernel with those options, you can manually inject a fault
that will force a scsi task mgmt command to be issued like this:
# mount -t debugfs nodev /sys/kernel/debug
# cd /sys/kernel/debug/fail_io_timeout
# cat interval
1
# cat probability
0
# cat times
1
# echo 100 >probability
# cd /sys/block/sda
# l | grep fail
-rw-r--r-- 1 root root 4096 May 5 10:53 io-timeout-fail
-rw-r--r-- 1 root root 4096 May 5 10:54 make-it-fail
# echo 1 >io-timeout-fail
# echo 1 >make-it-fail
To test this patch, after performing the above steps, I did something to
force a block device i/o, then shortly afterwards examined the kernel log.
There I found evidence that visorhba had successfully issued a task mgmt
command, and that it completed successfully:
Wolfram Sang [Tue, 31 May 2016 10:56:42 +0000 (12:56 +0200)]
staging: ks7010: drop counting sd errors
They were counted but never really used anywhere. Also change the printk
to a debug print, since it mostly shows on the expected -ENOMEDIUM on
card removal.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wolfram Sang [Tue, 31 May 2016 10:56:38 +0000 (12:56 +0200)]
staging: ks7010: remove supported card table with one element
There is only this card supported, no need to iterate over the table.
The resulting firmware filename wasn't used anyway, but came from the
config file or hardcoded default.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wolfram Sang [Tue, 31 May 2016 10:56:23 +0000 (12:56 +0200)]
staging: ks7010: make loading config file optional
We have sane defaults, so we don't need to bail out if there is no
config file. Note that the config file should go away completely in
favour of configuration mechanisms already upstream.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>