When report count is more than one and report size is not 4 bytes, then we
need some packing into result buffer from the caller of function
sensor_hub_get_feature.
By default the value extracted from a field is 4 bytes from hid core
(using hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT)), even
if report size if less than 4 byte. So when we copy data to user buffer in
sensor_hub_get_feature, we need to only copy report size bytes even
when report count is more than 1. This is
not an issue for most of the sensor hub fields as report count will be 1
where we already copy only report size bytes, but some string fields
like description, it is a problem as the report count will be more than 1.
For example:
Field(6)
Physical(Sensor.OtherCustom)
Application(Sensor.Sensor)
Usage(11)
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Report Size(16)
Report Count(11)
Here since the report size is 2 bytes, we will have 2 additional bytes of
0s copied into user buffer, if we directly copy to user buffer from
report->field[]->value
This change will copy report size bytes into the buffer of caller for each
usage report->field[]->value. So for example without this change, the
data displayed for a custom sensor field "sensor-model":
76 00 101 00 110 00 111 00 118 00 111
(truncated to report count of 11)
With change
76 101 110 111 118 111 32 89 111 103 97
("Lenovo Yoga" in ASCII )
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Need enum quirk to change the base of enums to 1 for
power and report descriptors.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The asm-generic tree this time contains one series from Nicolas Pitre
that makes the optimized do_div() implementation from the ARM
architecture available to all architectures. This also adds stricter
type checking for callers of do_div, which has uncovered a number
of bugs in existing code, and fixes up the ones we have found.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAVqARKWCrR//JCVInAQJrBhAAlwZL0IiVGFfDXWtvQGOm+yC5j4vdIhMf
1scsvRbk3ln1xUk5+NM61NpxbQotro78K5HxFZFhaVGUTbbFXM9w2VZSyI8ZaGAJ
Od6lBUUyLQmzlbHDJ3v/zrZn8Up7qZlRApmXcbUVDtssfnEfKk4xA2RG9JwIMS1c
uZMvnD7N3P9vxDPl+CsYlB2osi6Yks3VQ1tXYe2z6siO+H67zHaF08+ls7fbsd3d
oyKjZqlaQ02MIOr+AdR0h9iKyJJ6SXT0DQlsMyzB6aBWmeBCNLNALNIiukDk9Qc1
VV3sF1MOS3LtfU2TeOx4Na7hcd2iC6WYLb271iApO2Ww7t16n+de3i6AipZxLUJ0
08jiRlisTzUhXDobRSqI3mcQlxrB5UGfyblab2z/MqGGmIGJSPPRdTPRQUgi0ZKg
jksSmsaPwOQp64FhTgECLJthlYX7h6ULjkvJ9h60gZHa4jhGZbGPeMwHPf1uSm95
EvQE971Ssgm4jwhvxZ/kt1ruuZI/fxxG1Qfw+C25QkXZGKye2nB+icLWeMwz+FXG
HLqkmaAjasf5MAV1GiK8U6zoC6bCOLU0Lea83hOwRPZ999v3Nym1giSatNv4/pB+
QmkXRvFi93cdQ643l7xcUEDT2zpk4pogF3xREiBhyaXtqLlT7pPMKsBQOgdWvFuu
Ou0ZbEAwIVo=
=4psa
-----END PGP SIGNATURE-----
Merge tag 'asm-generic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic
Pull asm-generic updates from Arnd Bergmann:
"The asm-generic tree this time contains one series from Nicolas Pitre
that makes the optimized do_div() implementation from the ARM
architecture available to all architectures.
This also adds stricter type checking for callers of do_div, which has
uncovered a number of bugs in existing code, and fixes up the ones we
have found"
* tag 'asm-generic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
ARM: asm/div64.h: adjust to generic codde
__div64_32(): make it overridable at compile time
__div64_const32(): abstract out the actual 128-bit cross product code
do_div(): generic optimization for constant divisor on 32-bit machines
div64.h: optimize do_div() for power-of-two constant divisors
mtd/sm_ftl.c: fix wrong do_div() usage
drm/mgag200/mgag200_mode.c: fix wrong do_div() usage
hid-sensor-hub.c: fix wrong do_div() usage
ti/fapll: fix wrong do_div() usage
ti/clkt_dpll: fix wrong do_div() usage
tegra/clk-divider: fix wrong do_div() usage
imx/clk-pllv2: fix wrong do_div() usage
imx/clk-pllv1: fix wrong do_div() usage
nouveau/nvkm/subdev/clk/gk20a.c: fix wrong do_div() usage
This needs same quirk as applied to other YOGA sensor hubs. Refer to commit
21589ebda6 ("HID: sensor-hub: Add in quirk for Lenovo Yogas with ITE")
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some drivers indent some lines in a very weird manner. Fix that.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch is a follow-up to 47eeca8a48 (" HID: sensor-hub: Add in quirk
for Lenovo Yogas with ITE")
The Lenovo Yoga 2 13 seems to be sold in multiple variants with minor
difference3s. IN my case, the USB ID for ITE chip is different than the
Yoga 2 11 and Yoga 3 14.
Without the quirk, no data is received from the accelerometer. I have
verified the patch, testing this on 4.3-rc4 (and 4.2 stable). With this
patch, proper orientation data is received.
rrs@learner:~/Community/UpstreamSources/linux-upstream_GIT (stable-42)$
monitor-sensor
** Message: Accelerometer orientation changed: bottom-up
** Message: Light changed: 0.000000 (lux)
±** Message: Accelerometer orientation changed: left-up
** Message: Accelerometer orientation changed: bottom-up
** Message: Accelerometer orientation changed: left-up
** Message: Accelerometer orientation changed: normal
** Message: Light changed: 29.999999 (lux)
monitor-sensor can be found in the iio-sensor-proxy tool.
Signed-off-by: Ritesh Raj Sarraf <rrs@debian.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is an error in the report descriptor of the Thinkpad Helix 2 where
logical minimum value (557376) is greater than logical maximum (491200)
for all of the magnetic flux axis data fields. This error results in a
report descriptor parsing failure that causes the sensors attached to the
hub not to be detected.
dmesg excerpt:
[ 19.866905] drivers/hid/hid-core.c: logical range invalid 0x88140 0x77ec0
[ 19.866914] hid-sensor-hub 0018:2047:0855.0007: item 0 1 0 8 parsing failed
[ 19.866926] hid-sensor-hub 0018:2047:0855.0007: parse failed
[ 19.866933] hid-sensor-hub: probe of 0018:2047:0855.0007 failed with error -22
Add a report fixup to change magnetic flux logical minimums to -557376
for the parsing to succeed and the sensors to get detected.
After applying the fix the sensors get detected, with corresponding drivers
(hid-accel-3d,hid-gyro-3d,etc) loaded, and its possible to read their values.
Signed-off-by: Fernando D S Lima <fernandodsl@gmail.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When CONFIG_DEBUG_LOCK_ALLOC is defined, mutex magic is compared and
warned for (l->magic != l), here l is the address of mutex pointer.
In hid-sensor-hub as part of hsdev creation, a per hsdev mutex is
initialized during MFD cell creation. This hsdev, which contains, mutex
is part of platform data for the a cell. But platform_data is copied
in platform_device_add_data() in platform.c. This copy will copy the
whole hsdev structure including mutex. But once copied the magic
will no longer match. So when client driver call
sensor_hub_input_attr_get_raw_value, this will trigger mutex warning.
So to avoid this allocate mutex dynamically. This will be same even
after copy.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Since I can't change the type of hid_set_field argument 3, using __force __s32 to remove
this warning.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
For defining enumeration values like report or power status events, the
enumeration usage ids are enclosed in a logical collection. In this case we
need to match logical usage id for pending read on this usage id. For example,
in the below field, when read is requested for 0319, the report will
contain one of the status usages like 850, 851 etc. In this case the raw
event will not match 0319. So when logical collection matches, then wake
up the pending thread.
Physical(Sensor.OtherCustom)
Logical(Sensor.0319)
Application(Sensor.Sensor)
Usage(6)
Sensor.0850
Sensor.0851
Sensor.0852
Sensor.0853
Sensor.0854
Sensor.0855
Logical Minimum(1)
Logical Maximum(5)
Report Size(8)
Report Count(1)
Report Offset(24)
Flags( Array Absolute )
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Current API only allows setting one offset in the field. This API
is extended to set multiple offsets in the field report.
Also update parameters in the users of this API.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some hid sensor feature report can contain more than one reports.
This API can now support receiving multiple values from the feature
report.
Also update the parameters in the users of this API.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add additional flag to read in async mode. In this mode the caller will get
reply via registered callback for capture_sample. Callbacks can be registered
using sensor_hub_register_callback function. The usage id parameter of the
capture_sample can be matched with the usage id of the requested attribute.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Section 4.2.5 of HID Sensor hub specification allows two methods
defining sensor devices.
- Each sensor device by its own collection
- A top level application collection object, including multiple
sensors.
In the first method, each sensor can be in its own sensor application
collection without a physical collection.
In the second method there is a usage id for collection type, which
is defined as an application collection, with multiple physical
collections in it. It is possible to define fusion sensor with this
and may have its own handler. If there is a callback registered
for the collection type, then forward all reports for sensors in
its collection to this handler.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Current implementation only allows one outstanding synchronous read.
This is a performance hit when user mode is requesting raw reads
of sensor attributes on multiple sensors together.
This change changes the mutex lock to per hid sensor hub device instead
of global lock. Although request to hid sensor hub is serialized, there
can be multiple outstanding read requests pending for responses via
hid reports.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 0ccf091d1f ("HID: sensor-hub:
make dyn_callback_lock IRQ-safe) was supposed to change locks
in sensor_hub_get_callback(), but missed.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Use mfd_add_hotplug_devices() helper to register the subdevices.
Compile-only tested.
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Adding USB_DEVICE_ID_STM_HID_SENSOR again in the quirk table. During 3.16 merge
cycle somehow quirk for device id USB_DEVICE_ID_STM_HID_SENSOR is missing.
I see commit dde3b45cd7 ("HID: hid-sensor-hub: new device id and quirk
for STM Sensor hub") added new id USB_DEVICE_ID_STM_HID_SENSOR_1,
but didn't really delete the old device id.
Anyway we need to add this back, otherwise it breaks ST sensor hubs.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Use devm_kzalloc for all calls to kzalloc and not just the first. Use
devm functions for other allocations as well. The calls to free the
allocated memory in the probe and remove functions are done away with
and a label is removed in the probe function.
The semantic match that finds the inconsistency is as follows:
// <smpl>
@@
@@
*devm_kzalloc(...)
...
*kzalloc(...)
// </smpl>
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hsdev is not freed in sensor_hub_probe when kasprintf inside the for
loop fails. This is because hsdev is not set to platform_data yet (to
be freed by the code in the err_no_mem label). So free the memory
explicitly in the 'if' branch, as this is the only place where this is
(and will) be needed.
Reported-by: coverity
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: srinivas pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
dyn_callback_lock is being taken from IRQ context through hid_irq_in() ->
hid_input_report() -> sensor_hub_raw_event() -> sensor_hub_get_callback(),
therefore anyone else acquiring it needs to disable IRQs to disable deadlocks.
Reported-by: Alexander Holler <holler@ahsoftware.de>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Reported-by: Reyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Added STM sensor hub new device id. Also added this new device
in HID_SENSOR_HUB_ENUM_QUIRK to fix report descriptors.
These devices uses old FW which uses logical 0 as minimum.
In these, HID reports are not using proper collection classes.
So we need to fix report descriptors,for such devices. This
will not have any impact, if the FW uses logical 1 as minimum.
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add the Microsoft Surface Pro 2 Type/Touch and default device hardware ID's
Set report quirk for the device in hid-sensor-hub
Signed-off-by: Reyad Attiyat <reyad.attiyat@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The sensor hub in Lenovo Yogas needs the enumeration quirk. I've been running
the patch for over a month with no problems, whereas the unpatched drivers
reliably mis-initialized the sensors.
Signed-off-by: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Just like some of the other laptops/tablets on the market with ultrabook
sensors, the ThinkPad Helix's sensor hub requires a special quirk in
order for it to power on properly. Without it the sensors are detected
by the kernel and set up as usual, but they won't output any data. This
will also fix the sensors on any other laptops with the same model of
sensor hub.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix issue with the sleeping calling hid_hw_request under spinlock.
When i2c is used as HID transport, this is calling kmalloc, which
can sleep. So remove call to this function while under spinlock.
[ 1067.021961] Call Trace:
[ 1067.021970] [<ffffffff8192f5f2>] dump_stack+0x4d/0x6f
[ 1067.021976] [<ffffffff811109f2>] __might_sleep+0xd2/0xf0
[ 1067.021981] [<ffffffff811ea15b>] __kmalloc+0xeb/0x200
[ 1067.021989] [<ffffffff816e0cb3>] ? hid_alloc_report_buf+0x23/0x30
[ 1067.021993] [<ffffffff816e0cb3>] hid_alloc_report_buf+0x23/0x30
[ 1067.021997] [<ffffffff816f4cb7>] i2c_hid_request+0x57/0x110
[ 1067.022006] [<ffffffffa02bc61c>] sensor_hub_input_attr_get_raw_value+0xbc/0x100 [hid_sensor_hub]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In HID sensor hub, HID physical ids are used to represent different sensors.
For example physical id of 0x73 in usage page = 0x20, represents an
accelerometer. The HID sensor hub driver uses this physical ids to create
platform devices using MFD. There is 1:1 correspondence between an phy id and a
client driver.
But in some cases these physical ids are reused. There is a phy id 0xe1, which
specifies a custom sensor, which can exist multiple times to represent various
custom sensors. In this case there can be multiple instances of client MFD
drivers, processing specific custom sensor. In this case when client driver
looks for report id or a field index, it should still get the report id
specific to its own type. This is also true for reports, they should be
directed towards correct instance. This change introduce a way to parse and
tie physical devices to their correct instance.
Summary of changes:
- To get physical ids, use collections. If a collection of type=physical
exist then use usage id as in the name of platform device name
- As part of the platform data, we assign a hdsev instance, which has
start and end of collection indexes. Using these indexes attributes
can be tied to correct MFD client instances
- When a report is received, call callback with correct hsdev instance.
In this way using its private data stored as part of its registry, it
can distinguish different sensors even when they have same physical and
logical ids.
This patch is co-authored with Archana Patni <archna.patni@intel.com>.
Reported-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In some report descriptors, they leave holes in the selectors. In
this case if we use hardcoded selector values, this will result
in invalid values. For example, if there is selectors defined for
Power State from OFF to D0 to D3. We can't use indexes of these states
if some states are not implemented or not present in the report decriptors.
In this case, we need to get the indexes from report descriptors.
One API is added to get the index of a selector. This API will
search for usage id in the field usage list and return the index.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Added STM sensor hub vendor id in HID_SENSOR_HUB_ENUM_QUIRK to
fix report descriptors. These devices uses old FW which uses
logical 0 as minimum. In these, HID reports are not using proper
collection classes. So we need to fix report descriptors,for
such devices. This will not have any impact, if the FW uses
logical 1 as minimum.
We look for usage id for "power and report state", and modify
logical minimum value to 1.
This is a follow-up patch to commit id 875e36f8.
Signed-off-by: Archana Patni <archana.patni@linux.intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This addresses regression caused by commit id "751d17e23a9f7"
iio: hid-sensors: Fix power and report state.
This commit removed a quirk, to change the enumeration base
to 1 from 0 based on an CONFIG paramter. There was objection to
add more changes under this quirk, instead suggested to add an
HID quirk. But there is no easy way to add HID qurik as the
reports are not properly using collection class.
The solution was to use logical minimum, which is a correct way.
There were changes done in firmware to address this.
Unfortunately some devices, still use old FW and can't be upgraded
to newer version on Linux devices as there is no FW upgrade tool
available for Linux devices. So we need to fix report descriptors,
for such devices. This will not have any impact, if the FW uses
logical 1 as minimum.
In this patch we look for usage id for "power and report state", and
modify logical minimum value to 1.
Background on enum:
In the original HID sensor hub firmwares all Named array enums were
to 0-based. But the most recent hub implemented as 1-based,
because of the implementation by one of the major OS vendor.
Using logical minimum for the field as the base of enum. So we add
logical minimum to the selector values before setting those fields.
Some sensor hub FWs already changed logical minimum from 0 to 1
to reflect this and hope every other vendor will follow.
There is no easy way to add a common HID quirk for NAry elements,
even if the standard specifies these field as NAry, the collection
used to describe selectors is still just "logical".
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix kernel warning and failure to register sensor hub devices with MFD. Now
many devices has in-built sensor hubs. So by default this HID hub, is properly
parsed and register individual sensors as platform device using MFD framework.
But if a second sensor hub is attached via USB, which has same sensors, it will
result in kernel warning and failure to register MFD cell as the platform
device sysfs file name will be same as created by in-built sensor hubs. This
patch sets MFD cell id to PLATFORM_DEVID_AUTO. In this way there will never be
duplicate sysfs file names.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Exporting logical minimum and maximum of HID fields as part of the
hid sensor attribute info. This can be used for range checking and
to calculate enumeration base for NAry fields of HID sensor hub.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Pull HID updates from Jiri Kosina:
- i2c-hid is not querying init reports any more, as it's not mandated
by the spec, and annoys quite a few devices during enumeration, by
Bibek Basu
- a lot of fixes for Logitech devices, by Simon Wood
- hid-apple now has an option to switch between Option and Command
mode, by Nanno Langstraat
- Some more workarounds for severely broken ELO devices, by Oliver
Neukum
- more devm conversions, by Benjamin Tissoires
- wiimote correctness fixes, by David Herrmann
- a lot of added support for various new device IDs and random small
fixes here and there"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (34 commits)
HID: enable Mayflash USB Gamecube Adapter
HID: sony: Add force feedback support for Dualshock3 USB
Input: usbtouchscreen: ignore eGalax/D-Wav/EETI HIDs
HID: don't ignore eGalax/D-Wav/EETI HIDs
HID: roccat: add missing special driver declarations
HID:hid-lg4ff: Correct Auto-center strength for wheels other than MOMO and MOMO2
HID:hid-lg4ff: Initialize device properties before we touch autocentering.
HID:hid-lg4ff: ensure ConstantForce is disabled when set to 0
HID:hid-lg4ff: Switch autocentering off when strength is set to zero.
HID:hid-lg4ff: Scale autocentering force properly on Logitech wheel
HID: roccat: fix Coverity CID 141438
HID: multitouch: add manufacturer to Kconfig help text
HID: logitech-dj: small cleanup in rdcat()
HID: remove self-assignment from hid_input_report
HID: hid-sensor-hub: fix report size
HID: i2c-hid: Stop querying for init reports
HID: roccat: add support for Ryos MK keyboards
HID: roccat: generalize some common code
HID: roccat: add new device return value
HID: wiimote: add pro-controller analog stick calibration
...
Most of the hid sensor field size is reported in report_size field
in the report descriptor. For rotation fusion sensor the quaternion
data is 16 byte field, the report size was set to 4 and report
count field is set to 4. So the total size is 16 bytes. But the current
driver has a bug and not taking account for report count field. This
causes user space to see only 4 bytes of data sent via IIO interface.
The number of bytes in a field needs to take account of report_count
field. Need to multiply report_size and report_count to get total
number of bytes.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Don't call hid_open_device till there is actually an user. This saves
power by not opening underlying transport for HID. Also close device
if there are no active mfd client using HID sensor hub.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The patch substitutes kmemdup for kmalloc followed by memcpy.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
devm_kzalloc() will manage resources freeing and allows to make error path
smaller and nicer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Patch just rearranges lines to be more compact and/or readable. Additionally it
converts double space to one in several places.
There is no functional change.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
A HID device could send a malicious feature report that would cause the
sensor-hub HID driver to read past the end of heap allocation, leaking
kernel memory contents to the caller.
CVE-2013-2898
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@kernel.org
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch fixes the style of the comments to be like following
/* The commentary */
There is no functional change.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This removes most of the dependencies between hid drivers and usbhid.
The patch was constructed by replacing all occurences of
usbhid_wait_io() by its hid_hw_wait() counterpart.
Then, drivers not requiring USB_HID anymore have their USB_HID
dependency cleaned in the Kconfig file.
As of today, few drivers are still requiring an explicit USB layer
dependency:
* ntrig (a patch is on its way)
* multitouch (one patch following and another on its way)
* lenovo tpkbd
* roccat
* sony
The last three are two deeply using direct calls to the usb subsystem
to be able to be cleaned right now.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This allows the hid drivers to be independent from the transport layer.
The patch was constructed by replacing all occurences of
usbhid_submit_report() by its hid_hw_request() counterpart.
Then, drivers not requiring USB_HID anymore have their USB_HID
dependency cleaned in the Kconfig file.
Finally, few drivers still depends on USB_HID. Many of them
are requiring the io wait callback. They are found in the next patch.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
For the sensor-hub part:
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
