- 29 Nov, 2016 11 commits
-
-
Fan Yong authored
This is a feature for the client and server to use obd_connect_flags2 to communicate future feature flags. The client should set this flag whenever any flags in that field are requested, and the server should mask unsupported features from this field (assuming it understands OBD_CONNECT_FLAGS2). When checking if an OBD_CONNECT2_xxxx feature is supported, the client/server needs to firstly check if OBD_CONNECT_FLAGS2 is supported, since this field is also beyond the end of the old obd_connect_data. Land the connection flags to upstream client earlier for reserving the slot to avoid potential conflict with others. Signed-off-by:
Fan Yong <fan.yong@intel.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7543 Reviewed-on: http://review.whamcloud.com/17647Reviewed-by:
Andreas Dilger <andreas.dilger@intel.com> Reviewed-by:
Patrick Farrell <paf@cray.com> Signed-off-by:
James Simmons <jsimmons@infradead.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Fan Yong authored
The connection flag OBD_CONNECT_OBDOPACK will be used for the following the patch: LU-4215 optimize OUT protocol http://review.whamcloud.com/15336 Land the connection flags to upstream client earlier for reserving the slot to avoid potential conflict with others. Signed-off-by:
-
Fan Yong authored
The connection flag OBD_CONNECT_LOCK_AHEAD will be used for the following the patch: LU-6917 LDLM lock ahead http://review.whamcloud.com/13564 Land the connection flags to upstream client earlier for reserving the slot to avoid potential conflict with others. Signed-off-by:
-
Fan Yong authored
The connection flag OBD_CONNECT_SUBTREE will be used for the following the patch: LU-28 mounting of filesystem from MDS http://review.whamcloud.com/5007 Land the connection flags to master earlier for reserving the slot to avoid potential conflict with others. Signed-off-by:
-
Andreas Dilger authored
Fix users of flags that were using "int" instead of named enum. Rename some "flags" variables to distinguish between different flags. Signed-off-by:
James Simmons <uja.ornl@yahoo.com> Reviewed-by:
Bob Glossman <bob.glossman@intel.com> Reviewed-by:
frank zago <fzago@cray.com> Reviewed-by:
Dmitry Eremin <dmitry.eremin@intel.com> Reviewed-by:
John L. Hammond <john.hammond@intel.com> Reviewed-by:
Oleg Drokin <oleg.drokin@intel.com> Signed-off-by:
-
Andreas Dilger authored
Rename LDLM_CANCEL_* flags (used with enum ldlm_lru_flags) to LDLM_LRU_FLAGS_* to avoid confusion with enum ldlm_cancel_flags. Signed-off-by:
-
Andreas Dilger authored
Replace usage of ldlm_wire_policy_data_t with named enums to conform to upstream coding style. Signed-off-by:
-
Andreas Dilger authored
Replace usage of ldlm_side_t with named enums to conform to upstream coding style. Signed-off-by:
-
Andreas Dilger authored
Replace usage of ldlm_policy_data_t with named enums to conform to upstream coding style. Signed-off-by:
-
Dan Carpenter authored
We want sizeof(struct lstcon_node) but instead we're getting the sizeof a pointer. Fixes: 8d78f0f2 ("staging: lustre: lnet: cleanup some of the > 80 line issues") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Dan Carpenter authored
We should free "desc" before returning NULL. Signed-off-by:
-
- 28 Nov, 2016 1 commit
-
-
Greg Kroah-Hartman authored
Merge tag 'iio-for-4.10d' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: Fourth set of IIO new device support, features and cleaups for the 4.10 cycle. Probably the final set before the merge window unless things get significantly delayed. New device support * STM32 ADC core - new driver. Interesting device with up to 3 ADCs with complex triggering options that will follow later. Note split into an 'mfd like' core that handles the interrupt sharing etc between the various instances present and a per ADC section that is instantiated as many times as needed. - device tree bindings. Cleanups and minor fixes * st_accel - inline per sensor data as the defines don't add any meaning and make it much harder to check if a given sensor has the right values. * hid-magnetometer - sort out the associations of the associated attributes with the two types.
-
- 24 Nov, 2016 2 commits
-
-
Ooi, Joyce authored
iio: magnetometer: separate the values of attributes based on their usage type for HID compass sensor There are 2 usage types (Magnetic Flux and Heading data field) for HID compass sensor, thus the values of offset, scale, and sensitivity should be separated according to their respective usage type. The changes made are as below: 1. Hysteresis: A struct hid_sensor_common rot_attributes is created in struct magn_3d_state to contain the sensitivity for IIO_ROT. 2. Scale: scale_pre_decml and scale_post_decml are separated for IIO_MAGN and IIO_ROT. 3. Offset: Same as scale, value_offset is separated for IIO_MAGN and IIO_ROT. For sensitivity, HID_USAGE_SENSOR_ORIENT_MAGN_FLUX and HID_USAGE_SENSOR_ORIENT_MAGN_HEADING are used for sensivitity fields based on the HID Sensor Usages specifications. Hence, these changes are added on the sensitivity field. Signed-off-by:
Ooi, Joyce <joyce.ooi@intel.com> Acked-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org>
-
Dan Carpenter authored
This array is supposed to have 10 elements. Smatch complains that with the current code we can have n == max_ints and read beyond the end of the array. Fixes: ac4f6eee ("staging: iio: TAOS tsl258x: Device driver") Signed-off-by:
Brian Masney <masneyb@onstation.org> Signed-off-by:
-
- 23 Nov, 2016 26 commits
-
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: Alignment should match open parenthesis Signed-off-by:
Walt Feasel <waltfeasel@gmail.com> Signed-off-by:
-
Walt Feasel authored
Make modifications to comment style Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: Blank lines aren't necessary after an open brace '{' Signed-off-by: -
Walt Feasel authored
Make suggested checkpatch modification for CHECK: Please don't use multiple blank lines Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: Logical continuations should be on the previous line Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: spaces preferred around that '|' Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: spaces preferred around that '|' Signed-off-by:
-
Walt Feasel authored
Make modifications to comments Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: spaces preferred around that '|' Signed-off-by:
-
Walt Feasel authored
Make modifications to comments Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: spaces preferred around that '+' Signed-off-by:
-
Walt Feasel authored
Make modifications to align columns Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: Alignment should match open parenthesis Signed-off-by:
-
Walt Feasel authored
Make modifications to comment style Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: Alignment should match open parenthesis Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: spaces preferred around that '|' Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for WARNING: braces {} are not necessary for single statement blocks Signed-off-by: -
Walt Feasel authored
Make suggested checkpatch modification for CHECK: Logical continuations should be on the previous line Signed-off-by:
-
Walt Feasel authored
Make suggested checkpatch modification for CHECK: Blank lines aren't necessary after an open brace '{' Signed-off-by: -
David Kershner authored
Add proper error handling to bus_configure and have it propagate errors back up the stack. This helped to streamline the function as well. Signed-off-by:
David Kershner <david.kershner@unisys.com> Reported-by:
-
David Kershner authored
It really isn't an error when you call visorchannel_signalremove and there isn't anything in the queue. Just means that the IOSP didn't process anything since the last time you checked. Just inform the caller that it is empty by returning -EAGAIN. Signed-off-by:
-
David Kershner authored
The function controlvm_respond returns proper error handling, so now we can propagate the error up and handle it appropriately. Signed-off-by:
-
David Kershner authored
Pass the error returned from visorchannel_signalinsert up the stack instead of just ignoring it. Signed-off-by:
-
David Kershner authored
Controlvm_respond now returns an error. Add error handling to the bus_responder function. Signed-off-by:
-
David Kershner authored
Add proper error handling to the function save_crash_message. Signed-off-by:
-
David Kershner authored
Propagate the error up the stack instead of ignoring it. Signed-off-by:
-
