summaryrefslogtreecommitdiff
path: root/drivers/hid/hid-sensor-custom.c
AgeCommit message (Collapse)AuthorFilesLines
2023-03-24HID: hid-sensor-custom: Fix buffer overrun in device nameTodd Brandt1-1/+1
On some platforms there are some platform devices created with invalid names. For example: "HID-SENSOR-INT-020b?.39.auto" instead of "HID-SENSOR-INT-020b.39.auto" This string include some invalid characters, hence it will fail to properly load the driver which will handle this custom sensor. Also it is a problem for some user space tools, which parses the device names from ftrace and dmesg. This is because the string, real_usage, is not NULL terminated and printed with %s to form device name. To address this, initialize the real_usage string with 0s. Reported-and-tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217169 Fixes: 98c062e82451 ("HID: hid-sensor-custom: Allow more custom iio sensors") Cc: stable@vger.kernel.org Suggested-by: Philipp Jungkamp <p.jungkamp@gmx.net> Signed-off-by: Philipp Jungkamp <p.jungkamp@gmx.net> Signed-off-by: Todd Brandt <todd.e.brandt@intel.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2023-01-06HID: hid-sensor-custom: Fix big on-stack allocation in ↵Jiri Kosina1-7/+14
hid_sensor_custom_get_known() struct hid_sensor_custom_properties is currently 384 bytes big, which consumes too much stack space for no good reason. Make it dynamically allocated. Fixes: 98c062e824519 ("HID: hid-sensor-custom: Allow more custom iio sensors") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-12-20HID: hid-sensor-custom: Add LISS custom sensorsPhilipp Jungkamp1-0/+23
Add the Lenovo Intelligent Sensing Solution (LISS) custom sensors to the known custom sensors. Signed-off-by: Philipp Jungkamp <p.jungkamp@gmx.net> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-12-20HID: hid-sensor-custom: Allow more custom iio sensorsPhilipp Jungkamp1-72/+138
The known LUID table for established/known custom HID sensors was limited to sensors with "INTEL" as manufacturer. But some vendors such as Lenovo also include fairly standard iio sensors (e.g. ambient light) in their custom sensors. Expand the known custom sensors table by a tag used for the platform device name and match sensors based on the LUID as well as optionally on model and manufacturer properties. Signed-off-by: Philipp Jungkamp <p.jungkamp@gmx.net> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-11-21HID: hid-sensor-custom: set fixed size for custom attributesMarcus Folkesson1-1/+1
This is no bugfix (so no Fixes: tag is necessary) as it is taken care of in hid_sensor_custom_add_attributes(). The motivation for this patch is that: hid_sensor_custom_field.attr_name and hid_sensor_custom_field.attrs has the size of HID_CUSTOM_TOTAL_ATTRS and used in same context. We compare against HID_CUSTOM_TOTAL_ATTRS when looping through hid_custom_attrs. We will silent the smatch error: hid_sensor_custom_add_attributes() error: buffer overflow 'hid_custom_attrs' 8 <= 10 Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-11-14HID: hid-sensor-custom: Allow more than one hinge angle sensorYauhen Kharuzhy1-1/+1
Some devices has two sets of accelerometers and the sensor hub exports two hinge angle 'sensors' based on accelerometer values. To allow more than one sensor of the same type, use PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE when registering platform device for it. Checked on the Lenovo Yoga Book YB1-X91L tablet. Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-05-26HID: hid-sensor-custom: Process failure of sensor_hub_set_feature()Srinivas Pandruvada1-3/+5
When user modifies a custom feature value and sensor_hub_set_feature() fails, return error. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-04-07HID: hid-sensor-custom: Remove unused variable 'ret'Lee Jones1-3/+2
Fixes the following W=1 kernel build warning(s): drivers/hid/hid-sensor-custom.c: In function ‘store_value’: drivers/hid/hid-sensor-custom.c:400:7: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Cc: Jiri Kosina <jikos@kernel.org> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Cc: linux-iio@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2021-01-22HID: hid-sensor-custom: Add custom sensor iio supportYe Xiang1-0/+143
Currently custom sensors properties are not decoded and it is up to user space to interpret. Some manufacturers already standardized the meaning of some custom sensors. They can be presented as a proper IIO sensor. We can identify these sensors based on manufacturer and serial number property in the report. This change is identifying hinge sensor when the manufacturer is "INTEL". This creates a platform device so that a sensor driver can be loaded to process these sensors. Signed-off-by: Ye Xiang <xiang.ye@intel.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Link: https://lore.kernel.org/r/20201215054444.9324-2-xiang.ye@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-03-11HID: hid-sensor-custom: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai1-3/+3
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-07-14*: convert stream-like files -> stream_open, even if they use noop_llseekKirill Smelkov1-1/+1
This patch continues 10dce8af3422 (fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock) and c5bf68fe0c86 (*: convert stream-like files from nonseekable_open -> stream_open) and teaches steam_open.cocci to consider files as being stream-like not only if they have .llseek=no_llseek, but also if they have .llseek=noop_llseek. This is safe to do: the comment about noop_llseek says This is an implementation of ->llseek useable for the rare special case when userspace expects the seek to succeed but the (device) file is actually not able to perform the seek. In this case you use noop_llseek() instead of falling back to the default implementation of ->llseek. and in general noop_llseek was massively added to drivers in 6038f373a3dc (llseek: automatically add .llseek fop) when changing default for NULL .llseek from NOP to no_llseek with the idea to avoid breaking compatibility, if maybe some user-space program was using lseek on a device without caring about the result, but caring if it was an error or not. Amended semantic patch produces two changes when applied tree-wide: drivers/hid/hid-sensor-custom.c:690:8-24: WARNING: hid_sensor_custom_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open. drivers/input/mousedev.c:564:1-17: ERROR: mousedev_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix. Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Jan Blunck <jblunck@suse.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jiri Kosina <jikos@kernel.org> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 288Thomas Gleixner1-9/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms and conditions of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 263 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.208660670@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-27HID: hid-sensor-custom: simplify getting .driver_dataWolfram Sang1-8/+4
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2018-11-16iio/hid-sensors: Fix IIO_CHAN_INFO_RAW returning wrong values for signed numbersHans de Goede1-1/+1
Before this commit sensor_hub_input_attr_get_raw_value() failed to take the signedness of 16 and 8 bit values into account, returning e.g. 65436 instead of -100 for the z-axis reading of an accelerometer. This commit adds a new is_signed parameter to the function and makes all callers pass the appropriate value for this. While at it, this commit also fixes up some neighboring lines where statements were needlessly split over 2 lines to improve readability. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-02-11vfs: do bulk POLL* -> EPOLL* replacementLinus Torvalds1-1/+1
This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-11-28the rest of drivers/*: annotate ->poll() instancesAl Viro1-2/+2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2017-09-05Merge branch 'for-4.14/ish' into for-linusJiri Kosina1-1/+1
- bring consistency into logical minimum numbering in sensor-hub driver, from Srinivas Pandruvada
2017-08-15HID: sensor: constify platform_device_idArvind Yadav1-1/+1
platform_device_id are not supposed to change at runtime. All functions working with platform_device_id provided by <linux/platform_device.h> work with const platform_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2017-08-03HID: sensor: constify attribute_group structures.Arvind Yadav1-1/+1
attribute_group are not supposed to change at runtime. All functions working with attribute_group provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-05HID: sensor: fix attributes in HID sensor interfaceOoi, Joyce1-3/+3
User is unable to access to input-X-yyy and feature-X-yyy where X is a hex value and more than 9 (e.g. input-a-yyy, feature-b-yyy) in HID sensor custom sysfs interface. This is because when creating the attribute, the attribute index is written to using %x (hex). However, when reading and writing values into the attribute, the attribute index is scanned using %d (decimal). Hence, user is unable to access to attributes with index in hex values (e.g. 'a', 'b', 'c') but able to access to attributes with index in decimal values (e.g. 1, 2, 3,..). This fix will change input-%d-%x-%s and feature-%d-%x-%s to input-%x-%x-%s and feature-%x-%x-%s in show_values() and store_values() accordingly. Signed-off-by: Ooi, Joyce <joyce.ooi@intel.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-04-10HID: sensor: Custom and Generic sensor supportSrinivas Pandruvada1-0/+849
HID Sensor Spec defines two usage ids for custom sensors HID_USAGE_SENSOR_TYPE_OTHER_CUSTOM (0x09, 0xE1) HID_USAGE_SENSOR_TYPE_OTHER_GENERIC(0x09, 0xE2) In addition the standard also defines usage ids for custom fields. The purpose of these sensors is to extend the functionality or provide a way to obfuscate the data being communicated by a sensor. Without knowing the mapping between the data and its encapsulated form, it is difficult for an driver to determine what data is being communicated by the sensor. This allows some differentiating use cases, where vendor can provide applications. Since these can't be represented by standard sensor interfaces like IIO, we present these as fields with - type (input/output) - units - min/max - get/set value In addition an dev interface to transfer report events. Details about this interface is described in /Documentation/hid/hid-sensor.txt. Manufacturers should not use these ids for any standard sensors, otherwise the the product/vendor id can be added to black list. 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>