2012-09-05 20:56:00 +08:00
|
|
|
/*
|
|
|
|
|
* HID Sensors Driver
|
|
|
|
|
* Copyright (c) 2012, Intel Corporation.
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License along with
|
|
|
|
|
* this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
|
* 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
|
|
|
|
|
*
|
|
|
|
|
*/
|
2016-08-07 17:25:38 +08:00
|
|
|
|
2012-09-05 20:56:00 +08:00
|
|
|
#include <linux/device.h>
|
|
|
|
|
#include <linux/hid.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/slab.h>
|
|
|
|
|
#include <linux/mfd/core.h>
|
|
|
|
|
#include <linux/list.h>
|
|
|
|
|
#include <linux/hid-sensor-ids.h>
|
|
|
|
|
#include <linux/hid-sensor-hub.h>
|
|
|
|
|
#include "hid-ids.h"
|
|
|
|
|
|
HID: hid-sensor-hub: Fix buggy report descriptors
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>
2014-01-15 01:30:20 +08:00
|
|
|
#define HID_SENSOR_HUB_ENUM_QUIRK 0x01
|
|
|
|
|
|
2012-09-05 20:56:00 +08:00
|
|
|
/**
|
|
|
|
|
* struct sensor_hub_data - Hold a instance data for a HID hub device
|
|
|
|
|
* @hsdev: Stored hid instance for current hub device.
|
|
|
|
|
* @mutex: Mutex to serialize synchronous request.
|
|
|
|
|
* @lock: Spin lock to protect pending request structure.
|
|
|
|
|
* @dyn_callback_list: Holds callback function
|
|
|
|
|
* @dyn_callback_lock: spin lock to protect callback list
|
|
|
|
|
* @hid_sensor_hub_client_devs: Stores all MFD cells for a hub instance.
|
|
|
|
|
* @hid_sensor_client_cnt: Number of MFD cells, (no of sensors attached).
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
* @ref_cnt: Number of MFD clients have opened this device
|
2012-09-05 20:56:00 +08:00
|
|
|
*/
|
|
|
|
|
struct sensor_hub_data {
|
|
|
|
|
struct mutex mutex;
|
|
|
|
|
spinlock_t lock;
|
|
|
|
|
struct list_head dyn_callback_list;
|
|
|
|
|
spinlock_t dyn_callback_lock;
|
|
|
|
|
struct mfd_cell *hid_sensor_hub_client_devs;
|
|
|
|
|
int hid_sensor_client_cnt;
|
HID: hid-sensor-hub: Fix buggy report descriptors
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>
2014-01-15 01:30:20 +08:00
|
|
|
unsigned long quirks;
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
int ref_cnt;
|
2012-09-05 20:56:00 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* struct hid_sensor_hub_callbacks_list - Stores callback list
|
|
|
|
|
* @list: list head.
|
|
|
|
|
* @usage_id: usage id for a physical device.
|
|
|
|
|
* @usage_callback: Stores registered callback functions.
|
|
|
|
|
* @priv: Private data for a physical device.
|
|
|
|
|
*/
|
|
|
|
|
struct hid_sensor_hub_callbacks_list {
|
|
|
|
|
struct list_head list;
|
|
|
|
|
u32 usage_id;
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
struct hid_sensor_hub_device *hsdev;
|
2012-09-05 20:56:00 +08:00
|
|
|
struct hid_sensor_hub_callbacks *usage_callback;
|
|
|
|
|
void *priv;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct hid_report *sensor_hub_report(int id, struct hid_device *hdev,
|
|
|
|
|
int dir)
|
|
|
|
|
{
|
|
|
|
|
struct hid_report *report;
|
|
|
|
|
|
|
|
|
|
list_for_each_entry(report, &hdev->report_enum[dir].report_list, list) {
|
|
|
|
|
if (report->id == id)
|
|
|
|
|
return report;
|
|
|
|
|
}
|
|
|
|
|
hid_warn(hdev, "No report with id 0x%x found\n", id);
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
static int sensor_hub_get_physical_device_count(struct hid_device *hdev)
|
2012-09-05 20:56:00 +08:00
|
|
|
{
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
int i;
|
|
|
|
|
int count = 0;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
for (i = 0; i < hdev->maxcollection; ++i) {
|
|
|
|
|
struct hid_collection *collection = &hdev->collection[i];
|
2015-02-20 07:31:26 +08:00
|
|
|
if (collection->type == HID_COLLECTION_PHYSICAL ||
|
|
|
|
|
collection->type == HID_COLLECTION_APPLICATION)
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
++count;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
|
|
|
|
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
return count;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void sensor_hub_fill_attr_info(
|
|
|
|
|
struct hid_sensor_hub_attribute_info *info,
|
2013-11-28 06:19:00 +08:00
|
|
|
s32 index, s32 report_id, struct hid_field *field)
|
2012-09-05 20:56:00 +08:00
|
|
|
{
|
|
|
|
|
info->index = index;
|
|
|
|
|
info->report_id = report_id;
|
2013-11-28 06:19:00 +08:00
|
|
|
info->units = field->unit;
|
|
|
|
|
info->unit_expo = field->unit_exponent;
|
|
|
|
|
info->size = (field->report_size * field->report_count)/8;
|
|
|
|
|
info->logical_minimum = field->logical_minimum;
|
|
|
|
|
info->logical_maximum = field->logical_maximum;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct hid_sensor_hub_callbacks *sensor_hub_get_callback(
|
|
|
|
|
struct hid_device *hdev,
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
u32 usage_id,
|
|
|
|
|
int collection_index,
|
|
|
|
|
struct hid_sensor_hub_device **hsdev,
|
|
|
|
|
void **priv)
|
2012-09-05 20:56:00 +08:00
|
|
|
{
|
|
|
|
|
struct hid_sensor_hub_callbacks_list *callback;
|
|
|
|
|
struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
|
2015-01-08 02:14:44 +08:00
|
|
|
unsigned long flags;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
2015-01-08 02:14:44 +08:00
|
|
|
spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
list_for_each_entry(callback, &pdata->dyn_callback_list, list)
|
2015-02-20 07:31:26 +08:00
|
|
|
if ((callback->usage_id == usage_id ||
|
|
|
|
|
callback->usage_id == HID_USAGE_SENSOR_COLLECTION) &&
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
(collection_index >=
|
|
|
|
|
callback->hsdev->start_collection_index) &&
|
|
|
|
|
(collection_index <
|
|
|
|
|
callback->hsdev->end_collection_index)) {
|
2012-09-05 20:56:00 +08:00
|
|
|
*priv = callback->priv;
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
*hsdev = callback->hsdev;
|
2015-01-08 02:14:44 +08:00
|
|
|
spin_unlock_irqrestore(&pdata->dyn_callback_lock,
|
|
|
|
|
flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
return callback->usage_callback;
|
|
|
|
|
}
|
2015-01-08 02:14:44 +08:00
|
|
|
spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int sensor_hub_register_callback(struct hid_sensor_hub_device *hsdev,
|
|
|
|
|
u32 usage_id,
|
|
|
|
|
struct hid_sensor_hub_callbacks *usage_callback)
|
|
|
|
|
{
|
|
|
|
|
struct hid_sensor_hub_callbacks_list *callback;
|
|
|
|
|
struct sensor_hub_data *pdata = hid_get_drvdata(hsdev->hdev);
|
2014-06-10 17:05:43 +08:00
|
|
|
unsigned long flags;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
2014-06-10 17:05:43 +08:00
|
|
|
spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
list_for_each_entry(callback, &pdata->dyn_callback_list, list)
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
if (callback->usage_id == usage_id &&
|
|
|
|
|
callback->hsdev == hsdev) {
|
2014-06-10 17:05:43 +08:00
|
|
|
spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2012-09-14 14:53:23 +08:00
|
|
|
callback = kzalloc(sizeof(*callback), GFP_ATOMIC);
|
2012-09-05 20:56:00 +08:00
|
|
|
if (!callback) {
|
2014-06-10 17:05:43 +08:00
|
|
|
spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
callback->hsdev = hsdev;
|
2012-09-05 20:56:00 +08:00
|
|
|
callback->usage_callback = usage_callback;
|
|
|
|
|
callback->usage_id = usage_id;
|
|
|
|
|
callback->priv = NULL;
|
2015-02-20 07:31:26 +08:00
|
|
|
/*
|
|
|
|
|
* If there is a handler registered for the collection type, then
|
|
|
|
|
* it will handle all reports for sensors in this collection. If
|
|
|
|
|
* there is also an individual sensor handler registration, then
|
|
|
|
|
* we want to make sure that the reports are directed to collection
|
|
|
|
|
* handler, as this may be a fusion sensor. So add collection handlers
|
|
|
|
|
* to the beginning of the list, so that they are matched first.
|
|
|
|
|
*/
|
|
|
|
|
if (usage_id == HID_USAGE_SENSOR_COLLECTION)
|
|
|
|
|
list_add(&callback->list, &pdata->dyn_callback_list);
|
|
|
|
|
else
|
|
|
|
|
list_add_tail(&callback->list, &pdata->dyn_callback_list);
|
2014-06-10 17:05:43 +08:00
|
|
|
spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(sensor_hub_register_callback);
|
|
|
|
|
|
|
|
|
|
int sensor_hub_remove_callback(struct hid_sensor_hub_device *hsdev,
|
|
|
|
|
u32 usage_id)
|
|
|
|
|
{
|
|
|
|
|
struct hid_sensor_hub_callbacks_list *callback;
|
|
|
|
|
struct sensor_hub_data *pdata = hid_get_drvdata(hsdev->hdev);
|
2014-06-10 17:05:43 +08:00
|
|
|
unsigned long flags;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
2014-06-10 17:05:43 +08:00
|
|
|
spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
list_for_each_entry(callback, &pdata->dyn_callback_list, list)
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
if (callback->usage_id == usage_id &&
|
|
|
|
|
callback->hsdev == hsdev) {
|
2012-09-05 20:56:00 +08:00
|
|
|
list_del(&callback->list);
|
|
|
|
|
kfree(callback);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2014-06-10 17:05:43 +08:00
|
|
|
spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(sensor_hub_remove_callback);
|
|
|
|
|
|
|
|
|
|
int sensor_hub_set_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,
|
2015-02-20 07:35:26 +08:00
|
|
|
u32 field_index, int buffer_size, void *buffer)
|
2012-09-05 20:56:00 +08:00
|
|
|
{
|
|
|
|
|
struct hid_report *report;
|
2013-08-14 16:07:09 +08:00
|
|
|
struct sensor_hub_data *data = hid_get_drvdata(hsdev->hdev);
|
2015-02-20 07:35:26 +08:00
|
|
|
__s32 *buf32 = buffer;
|
|
|
|
|
int i = 0;
|
|
|
|
|
int remaining_bytes;
|
|
|
|
|
__s32 value;
|
2012-09-05 20:56:00 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&data->mutex);
|
|
|
|
|
report = sensor_hub_report(report_id, hsdev->hdev, HID_FEATURE_REPORT);
|
2013-08-14 16:07:09 +08:00
|
|
|
if (!report || (field_index >= report->maxfield)) {
|
2012-09-05 20:56:00 +08:00
|
|
|
ret = -EINVAL;
|
|
|
|
|
goto done_proc;
|
|
|
|
|
}
|
2015-02-20 07:35:26 +08:00
|
|
|
|
2015-11-04 06:01:46 +08:00
|
|
|
remaining_bytes = buffer_size % sizeof(__s32);
|
|
|
|
|
buffer_size = buffer_size / sizeof(__s32);
|
2015-02-20 07:35:26 +08:00
|
|
|
if (buffer_size) {
|
|
|
|
|
for (i = 0; i < buffer_size; ++i) {
|
|
|
|
|
hid_set_field(report->field[field_index], i,
|
2015-02-27 03:04:44 +08:00
|
|
|
(__force __s32)cpu_to_le32(*buf32));
|
2015-02-20 07:35:26 +08:00
|
|
|
++buf32;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (remaining_bytes) {
|
|
|
|
|
value = 0;
|
|
|
|
|
memcpy(&value, (u8 *)buf32, remaining_bytes);
|
|
|
|
|
hid_set_field(report->field[field_index], i,
|
2015-02-27 03:04:44 +08:00
|
|
|
(__force __s32)cpu_to_le32(value));
|
2015-02-20 07:35:26 +08:00
|
|
|
}
|
2013-02-25 18:31:46 +08:00
|
|
|
hid_hw_request(hsdev->hdev, report, HID_REQ_SET_REPORT);
|
2013-02-25 18:31:47 +08:00
|
|
|
hid_hw_wait(hsdev->hdev);
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
done_proc:
|
|
|
|
|
mutex_unlock(&data->mutex);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(sensor_hub_set_feature);
|
|
|
|
|
|
|
|
|
|
int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,
|
2015-02-20 07:35:25 +08:00
|
|
|
u32 field_index, int buffer_size, void *buffer)
|
2012-09-05 20:56:00 +08:00
|
|
|
{
|
|
|
|
|
struct hid_report *report;
|
2013-08-14 16:07:09 +08:00
|
|
|
struct sensor_hub_data *data = hid_get_drvdata(hsdev->hdev);
|
2015-02-20 07:35:25 +08:00
|
|
|
int report_size;
|
2012-09-05 20:56:00 +08:00
|
|
|
int ret = 0;
|
HID: sensor-hub: Fix packing of result buffer for feature report
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>
2016-10-28 07:49:20 +08:00
|
|
|
u8 *val_ptr;
|
|
|
|
|
int buffer_index = 0;
|
|
|
|
|
int i;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
2016-12-28 00:57:59 +08:00
|
|
|
memset(buffer, 0, buffer_size);
|
|
|
|
|
|
2012-09-05 20:56:00 +08:00
|
|
|
mutex_lock(&data->mutex);
|
|
|
|
|
report = sensor_hub_report(report_id, hsdev->hdev, HID_FEATURE_REPORT);
|
2013-09-06 17:59:53 +08:00
|
|
|
if (!report || (field_index >= report->maxfield) ||
|
2013-08-29 04:31:44 +08:00
|
|
|
report->field[field_index]->report_count < 1) {
|
2012-09-05 20:56:00 +08:00
|
|
|
ret = -EINVAL;
|
|
|
|
|
goto done_proc;
|
|
|
|
|
}
|
2013-02-25 18:31:46 +08:00
|
|
|
hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT);
|
2013-02-25 18:31:47 +08:00
|
|
|
hid_hw_wait(hsdev->hdev);
|
2015-02-20 07:35:25 +08:00
|
|
|
|
|
|
|
|
/* calculate number of bytes required to read this field */
|
|
|
|
|
report_size = DIV_ROUND_UP(report->field[field_index]->report_size,
|
|
|
|
|
8) *
|
|
|
|
|
report->field[field_index]->report_count;
|
|
|
|
|
if (!report_size) {
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
goto done_proc;
|
|
|
|
|
}
|
|
|
|
|
ret = min(report_size, buffer_size);
|
HID: sensor-hub: Fix packing of result buffer for feature report
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>
2016-10-28 07:49:20 +08:00
|
|
|
|
|
|
|
|
val_ptr = (u8 *)report->field[field_index]->value;
|
|
|
|
|
for (i = 0; i < report->field[field_index]->report_count; ++i) {
|
|
|
|
|
if (buffer_index >= ret)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
memcpy(&((u8 *)buffer)[buffer_index], val_ptr,
|
|
|
|
|
report->field[field_index]->report_size / 8);
|
|
|
|
|
val_ptr += sizeof(__s32);
|
|
|
|
|
buffer_index += (report->field[field_index]->report_size / 8);
|
|
|
|
|
}
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
done_proc:
|
|
|
|
|
mutex_unlock(&data->mutex);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(sensor_hub_get_feature);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
int sensor_hub_input_attr_get_raw_value(struct hid_sensor_hub_device *hsdev,
|
|
|
|
|
u32 usage_id,
|
2015-02-20 07:33:56 +08:00
|
|
|
u32 attr_usage_id, u32 report_id,
|
|
|
|
|
enum sensor_hub_read_flags flag)
|
2012-09-05 20:56:00 +08:00
|
|
|
{
|
2013-08-14 16:07:09 +08:00
|
|
|
struct sensor_hub_data *data = hid_get_drvdata(hsdev->hdev);
|
2012-09-05 20:56:00 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
struct hid_report *report;
|
|
|
|
|
int ret_val = 0;
|
|
|
|
|
|
2015-02-20 07:33:56 +08:00
|
|
|
report = sensor_hub_report(report_id, hsdev->hdev,
|
|
|
|
|
HID_INPUT_REPORT);
|
2014-03-25 07:25:04 +08:00
|
|
|
if (!report)
|
2015-02-20 07:33:56 +08:00
|
|
|
return -EINVAL;
|
2014-03-25 07:25:04 +08:00
|
|
|
|
2015-05-08 05:26:34 +08:00
|
|
|
mutex_lock(hsdev->mutex_ptr);
|
2015-02-20 07:33:56 +08:00
|
|
|
if (flag == SENSOR_HUB_SYNC) {
|
|
|
|
|
memset(&hsdev->pending, 0, sizeof(hsdev->pending));
|
|
|
|
|
init_completion(&hsdev->pending.ready);
|
|
|
|
|
hsdev->pending.usage_id = usage_id;
|
|
|
|
|
hsdev->pending.attr_usage_id = attr_usage_id;
|
|
|
|
|
hsdev->pending.raw_size = 0;
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&data->lock, flags);
|
|
|
|
|
hsdev->pending.status = true;
|
|
|
|
|
spin_unlock_irqrestore(&data->lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
2015-02-20 07:31:25 +08:00
|
|
|
mutex_lock(&data->mutex);
|
2013-02-25 18:31:46 +08:00
|
|
|
hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT);
|
2012-09-05 20:56:00 +08:00
|
|
|
mutex_unlock(&data->mutex);
|
2015-02-20 07:33:56 +08:00
|
|
|
if (flag == SENSOR_HUB_SYNC) {
|
|
|
|
|
wait_for_completion_interruptible_timeout(
|
|
|
|
|
&hsdev->pending.ready, HZ*5);
|
|
|
|
|
switch (hsdev->pending.raw_size) {
|
|
|
|
|
case 1:
|
|
|
|
|
ret_val = *(u8 *)hsdev->pending.raw_data;
|
|
|
|
|
break;
|
|
|
|
|
case 2:
|
|
|
|
|
ret_val = *(u16 *)hsdev->pending.raw_data;
|
|
|
|
|
break;
|
|
|
|
|
case 4:
|
|
|
|
|
ret_val = *(u32 *)hsdev->pending.raw_data;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
ret_val = 0;
|
|
|
|
|
}
|
|
|
|
|
kfree(hsdev->pending.raw_data);
|
|
|
|
|
hsdev->pending.status = false;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
2015-05-08 05:26:34 +08:00
|
|
|
mutex_unlock(hsdev->mutex_ptr);
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
return ret_val;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(sensor_hub_input_attr_get_raw_value);
|
|
|
|
|
|
2014-01-24 10:50:21 +08:00
|
|
|
int hid_sensor_get_usage_index(struct hid_sensor_hub_device *hsdev,
|
|
|
|
|
u32 report_id, int field_index, u32 usage_id)
|
|
|
|
|
{
|
|
|
|
|
struct hid_report *report;
|
|
|
|
|
struct hid_field *field;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
report = sensor_hub_report(report_id, hsdev->hdev, HID_FEATURE_REPORT);
|
|
|
|
|
if (!report || (field_index >= report->maxfield))
|
|
|
|
|
goto done_proc;
|
|
|
|
|
|
|
|
|
|
field = report->field[field_index];
|
|
|
|
|
for (i = 0; i < field->maxusage; ++i) {
|
|
|
|
|
if (field->usage[i].hid == usage_id)
|
|
|
|
|
return field->usage[i].usage_index;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
done_proc:
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(hid_sensor_get_usage_index);
|
|
|
|
|
|
2012-09-05 20:56:00 +08:00
|
|
|
int sensor_hub_input_get_attribute_info(struct hid_sensor_hub_device *hsdev,
|
|
|
|
|
u8 type,
|
|
|
|
|
u32 usage_id,
|
|
|
|
|
u32 attr_usage_id,
|
|
|
|
|
struct hid_sensor_hub_attribute_info *info)
|
|
|
|
|
{
|
|
|
|
|
int ret = -1;
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
int i;
|
2012-09-05 20:56:00 +08:00
|
|
|
struct hid_report *report;
|
|
|
|
|
struct hid_field *field;
|
|
|
|
|
struct hid_report_enum *report_enum;
|
|
|
|
|
struct hid_device *hdev = hsdev->hdev;
|
|
|
|
|
|
|
|
|
|
/* Initialize with defaults */
|
|
|
|
|
info->usage_id = usage_id;
|
2013-08-14 16:07:09 +08:00
|
|
|
info->attrib_id = attr_usage_id;
|
2012-09-05 20:56:00 +08:00
|
|
|
info->report_id = -1;
|
|
|
|
|
info->index = -1;
|
|
|
|
|
info->units = -1;
|
|
|
|
|
info->unit_expo = -1;
|
|
|
|
|
|
|
|
|
|
report_enum = &hdev->report_enum[type];
|
|
|
|
|
list_for_each_entry(report, &report_enum->report_list, list) {
|
|
|
|
|
for (i = 0; i < report->maxfield; ++i) {
|
|
|
|
|
field = report->field[i];
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
if (field->maxusage) {
|
|
|
|
|
if (field->physical == usage_id &&
|
|
|
|
|
(field->logical == attr_usage_id ||
|
|
|
|
|
field->usage[0].hid ==
|
|
|
|
|
attr_usage_id) &&
|
|
|
|
|
(field->usage[0].collection_index >=
|
|
|
|
|
hsdev->start_collection_index) &&
|
|
|
|
|
(field->usage[0].collection_index <
|
|
|
|
|
hsdev->end_collection_index)) {
|
|
|
|
|
|
|
|
|
|
sensor_hub_fill_attr_info(info, i,
|
|
|
|
|
report->id,
|
|
|
|
|
field);
|
|
|
|
|
ret = 0;
|
|
|
|
|
break;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(sensor_hub_input_get_attribute_info);
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_PM
|
|
|
|
|
static int sensor_hub_suspend(struct hid_device *hdev, pm_message_t message)
|
|
|
|
|
{
|
2013-08-14 16:07:09 +08:00
|
|
|
struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
|
2012-09-05 20:56:00 +08:00
|
|
|
struct hid_sensor_hub_callbacks_list *callback;
|
2014-06-10 17:05:43 +08:00
|
|
|
unsigned long flags;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
hid_dbg(hdev, " sensor_hub_suspend\n");
|
2014-06-10 17:05:43 +08:00
|
|
|
spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
list_for_each_entry(callback, &pdata->dyn_callback_list, list) {
|
|
|
|
|
if (callback->usage_callback->suspend)
|
|
|
|
|
callback->usage_callback->suspend(
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
callback->hsdev, callback->priv);
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
2014-06-10 17:05:43 +08:00
|
|
|
spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int sensor_hub_resume(struct hid_device *hdev)
|
|
|
|
|
{
|
2013-08-14 16:07:09 +08:00
|
|
|
struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
|
2012-09-05 20:56:00 +08:00
|
|
|
struct hid_sensor_hub_callbacks_list *callback;
|
2014-06-10 17:05:43 +08:00
|
|
|
unsigned long flags;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
hid_dbg(hdev, " sensor_hub_resume\n");
|
2014-06-10 17:05:43 +08:00
|
|
|
spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
list_for_each_entry(callback, &pdata->dyn_callback_list, list) {
|
|
|
|
|
if (callback->usage_callback->resume)
|
|
|
|
|
callback->usage_callback->resume(
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
callback->hsdev, callback->priv);
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
2014-06-10 17:05:43 +08:00
|
|
|
spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int sensor_hub_reset_resume(struct hid_device *hdev)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2013-08-14 16:07:09 +08:00
|
|
|
|
2012-09-05 20:56:00 +08:00
|
|
|
/*
|
|
|
|
|
* Handle raw report as sent by device
|
|
|
|
|
*/
|
|
|
|
|
static int sensor_hub_raw_event(struct hid_device *hdev,
|
|
|
|
|
struct hid_report *report, u8 *raw_data, int size)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
u8 *ptr;
|
|
|
|
|
int sz;
|
|
|
|
|
struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
struct hid_sensor_hub_callbacks *callback = NULL;
|
|
|
|
|
struct hid_collection *collection = NULL;
|
|
|
|
|
void *priv = NULL;
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
struct hid_sensor_hub_device *hsdev = NULL;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
hid_dbg(hdev, "sensor_hub_raw_event report id:0x%x size:%d type:%d\n",
|
|
|
|
|
report->id, size, report->type);
|
|
|
|
|
hid_dbg(hdev, "maxfield:%d\n", report->maxfield);
|
|
|
|
|
if (report->type != HID_INPUT_REPORT)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
ptr = raw_data;
|
2013-08-14 16:07:08 +08:00
|
|
|
ptr++; /* Skip report id */
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
spin_lock_irqsave(&pdata->lock, flags);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < report->maxfield; ++i) {
|
|
|
|
|
hid_dbg(hdev, "%d collection_index:%x hid:%x sz:%x\n",
|
|
|
|
|
i, report->field[i]->usage->collection_index,
|
|
|
|
|
report->field[i]->usage->hid,
|
2013-10-27 01:04:09 +08:00
|
|
|
(report->field[i]->report_size *
|
|
|
|
|
report->field[i]->report_count)/8);
|
|
|
|
|
sz = (report->field[i]->report_size *
|
|
|
|
|
report->field[i]->report_count)/8;
|
2012-09-05 20:56:00 +08:00
|
|
|
collection = &hdev->collection[
|
|
|
|
|
report->field[i]->usage->collection_index];
|
|
|
|
|
hid_dbg(hdev, "collection->usage %x\n",
|
|
|
|
|
collection->usage);
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
|
|
|
|
|
callback = sensor_hub_get_callback(hdev,
|
|
|
|
|
report->field[i]->physical,
|
|
|
|
|
report->field[i]->usage[0].collection_index,
|
|
|
|
|
&hsdev, &priv);
|
2015-02-20 07:31:25 +08:00
|
|
|
if (!callback) {
|
|
|
|
|
ptr += sz;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2015-02-26 10:56:27 +08:00
|
|
|
if (hsdev->pending.status && (hsdev->pending.attr_usage_id ==
|
|
|
|
|
report->field[i]->usage->hid ||
|
|
|
|
|
hsdev->pending.attr_usage_id ==
|
|
|
|
|
report->field[i]->logical)) {
|
2015-02-20 07:31:25 +08:00
|
|
|
hid_dbg(hdev, "data was pending ...\n");
|
|
|
|
|
hsdev->pending.raw_data = kmemdup(ptr, sz, GFP_ATOMIC);
|
|
|
|
|
if (hsdev->pending.raw_data)
|
|
|
|
|
hsdev->pending.raw_size = sz;
|
|
|
|
|
else
|
|
|
|
|
hsdev->pending.raw_size = 0;
|
|
|
|
|
complete(&hsdev->pending.ready);
|
|
|
|
|
}
|
|
|
|
|
if (callback->capture_sample) {
|
2012-09-05 20:56:00 +08:00
|
|
|
if (report->field[i]->logical)
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
callback->capture_sample(hsdev,
|
2012-09-05 20:56:00 +08:00
|
|
|
report->field[i]->logical, sz, ptr,
|
|
|
|
|
callback->pdev);
|
|
|
|
|
else
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
callback->capture_sample(hsdev,
|
2012-09-05 20:56:00 +08:00
|
|
|
report->field[i]->usage->hid, sz, ptr,
|
|
|
|
|
callback->pdev);
|
|
|
|
|
}
|
|
|
|
|
ptr += sz;
|
|
|
|
|
}
|
|
|
|
|
if (callback && collection && callback->send_event)
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
callback->send_event(hsdev, collection->usage,
|
2012-09-05 20:56:00 +08:00
|
|
|
callback->pdev);
|
|
|
|
|
spin_unlock_irqrestore(&pdata->lock, flags);
|
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-19 01:13:00 +08:00
|
|
|
int sensor_hub_device_open(struct hid_sensor_hub_device *hsdev)
|
|
|
|
|
{
|
|
|
|
|
int ret = 0;
|
|
|
|
|
struct sensor_hub_data *data = hid_get_drvdata(hsdev->hdev);
|
|
|
|
|
|
|
|
|
|
mutex_lock(&data->mutex);
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
if (!data->ref_cnt) {
|
2013-09-19 01:13:00 +08:00
|
|
|
ret = hid_hw_open(hsdev->hdev);
|
|
|
|
|
if (ret) {
|
|
|
|
|
hid_err(hsdev->hdev, "failed to open hid device\n");
|
|
|
|
|
mutex_unlock(&data->mutex);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
}
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
data->ref_cnt++;
|
2013-09-19 01:13:00 +08:00
|
|
|
mutex_unlock(&data->mutex);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(sensor_hub_device_open);
|
|
|
|
|
|
|
|
|
|
void sensor_hub_device_close(struct hid_sensor_hub_device *hsdev)
|
|
|
|
|
{
|
|
|
|
|
struct sensor_hub_data *data = hid_get_drvdata(hsdev->hdev);
|
|
|
|
|
|
|
|
|
|
mutex_lock(&data->mutex);
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
data->ref_cnt--;
|
|
|
|
|
if (!data->ref_cnt)
|
2013-09-19 01:13:00 +08:00
|
|
|
hid_hw_close(hsdev->hdev);
|
|
|
|
|
mutex_unlock(&data->mutex);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(sensor_hub_device_close);
|
|
|
|
|
|
HID: hid-sensor-hub: Fix buggy report descriptors
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>
2014-01-15 01:30:20 +08:00
|
|
|
static __u8 *sensor_hub_report_fixup(struct hid_device *hdev, __u8 *rdesc,
|
|
|
|
|
unsigned int *rsize)
|
|
|
|
|
{
|
|
|
|
|
int index;
|
|
|
|
|
struct sensor_hub_data *sd = hid_get_drvdata(hdev);
|
|
|
|
|
unsigned char report_block[] = {
|
|
|
|
|
0x0a, 0x16, 0x03, 0x15, 0x00, 0x25, 0x05};
|
|
|
|
|
unsigned char power_block[] = {
|
|
|
|
|
0x0a, 0x19, 0x03, 0x15, 0x00, 0x25, 0x05};
|
|
|
|
|
|
|
|
|
|
if (!(sd->quirks & HID_SENSOR_HUB_ENUM_QUIRK)) {
|
|
|
|
|
hid_dbg(hdev, "No Enum quirks\n");
|
|
|
|
|
return rdesc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Looks for power and report state usage id and force to 1 */
|
|
|
|
|
for (index = 0; index < *rsize; ++index) {
|
|
|
|
|
if (((*rsize - index) > sizeof(report_block)) &&
|
|
|
|
|
!memcmp(&rdesc[index], report_block,
|
|
|
|
|
sizeof(report_block))) {
|
|
|
|
|
rdesc[index + 4] = 0x01;
|
|
|
|
|
index += sizeof(report_block);
|
|
|
|
|
}
|
|
|
|
|
if (((*rsize - index) > sizeof(power_block)) &&
|
|
|
|
|
!memcmp(&rdesc[index], power_block,
|
|
|
|
|
sizeof(power_block))) {
|
|
|
|
|
rdesc[index + 4] = 0x01;
|
|
|
|
|
index += sizeof(power_block);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-09-03 23:56:31 +08:00
|
|
|
/* Checks if the report descriptor of Thinkpad Helix 2 has a logical
|
|
|
|
|
* minimum for magnetic flux axis greater than the maximum */
|
|
|
|
|
if (hdev->product == USB_DEVICE_ID_TEXAS_INSTRUMENTS_LENOVO_YOGA &&
|
|
|
|
|
*rsize == 2558 && rdesc[913] == 0x17 && rdesc[914] == 0x40 &&
|
|
|
|
|
rdesc[915] == 0x81 && rdesc[916] == 0x08 &&
|
|
|
|
|
rdesc[917] == 0x00 && rdesc[918] == 0x27 &&
|
|
|
|
|
rdesc[921] == 0x07 && rdesc[922] == 0x00) {
|
|
|
|
|
/* Sets negative logical minimum for mag x, y and z */
|
|
|
|
|
rdesc[914] = rdesc[935] = rdesc[956] = 0xc0;
|
|
|
|
|
rdesc[915] = rdesc[936] = rdesc[957] = 0x7e;
|
|
|
|
|
rdesc[916] = rdesc[937] = rdesc[958] = 0xf7;
|
|
|
|
|
rdesc[917] = rdesc[938] = rdesc[959] = 0xff;
|
|
|
|
|
}
|
|
|
|
|
|
HID: hid-sensor-hub: Fix buggy report descriptors
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>
2014-01-15 01:30:20 +08:00
|
|
|
return rdesc;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-05 20:56:00 +08:00
|
|
|
static int sensor_hub_probe(struct hid_device *hdev,
|
|
|
|
|
const struct hid_device_id *id)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
struct sensor_hub_data *sd;
|
|
|
|
|
int i;
|
|
|
|
|
char *name;
|
|
|
|
|
int dev_cnt;
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
struct hid_sensor_hub_device *hsdev;
|
|
|
|
|
struct hid_sensor_hub_device *last_hsdev = NULL;
|
2015-02-20 07:31:26 +08:00
|
|
|
struct hid_sensor_hub_device *collection_hsdev = NULL;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
2013-08-14 16:07:10 +08:00
|
|
|
sd = devm_kzalloc(&hdev->dev, sizeof(*sd), GFP_KERNEL);
|
2012-09-05 20:56:00 +08:00
|
|
|
if (!sd) {
|
|
|
|
|
hid_err(hdev, "cannot allocate Sensor data\n");
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
|
2012-09-05 20:56:00 +08:00
|
|
|
hid_set_drvdata(hdev, sd);
|
HID: hid-sensor-hub: Fix buggy report descriptors
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>
2014-01-15 01:30:20 +08:00
|
|
|
sd->quirks = id->driver_data;
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
|
2012-09-05 20:56:00 +08:00
|
|
|
spin_lock_init(&sd->lock);
|
|
|
|
|
spin_lock_init(&sd->dyn_callback_lock);
|
|
|
|
|
mutex_init(&sd->mutex);
|
|
|
|
|
ret = hid_parse(hdev);
|
|
|
|
|
if (ret) {
|
|
|
|
|
hid_err(hdev, "parse failed\n");
|
2013-08-14 16:07:10 +08:00
|
|
|
return ret;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
|
|
|
|
INIT_LIST_HEAD(&hdev->inputs);
|
|
|
|
|
|
|
|
|
|
ret = hid_hw_start(hdev, 0);
|
|
|
|
|
if (ret) {
|
|
|
|
|
hid_err(hdev, "hw start failed\n");
|
2013-08-14 16:07:10 +08:00
|
|
|
return ret;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
|
|
|
|
INIT_LIST_HEAD(&sd->dyn_callback_list);
|
|
|
|
|
sd->hid_sensor_client_cnt = 0;
|
|
|
|
|
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
dev_cnt = sensor_hub_get_physical_device_count(hdev);
|
2012-09-05 20:56:00 +08:00
|
|
|
if (dev_cnt > HID_MAX_PHY_DEVICES) {
|
|
|
|
|
hid_err(hdev, "Invalid Physical device count\n");
|
|
|
|
|
ret = -EINVAL;
|
2013-09-19 01:13:00 +08:00
|
|
|
goto err_stop_hw;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
2014-08-03 06:11:35 +08:00
|
|
|
sd->hid_sensor_hub_client_devs = devm_kzalloc(&hdev->dev, dev_cnt *
|
|
|
|
|
sizeof(struct mfd_cell),
|
|
|
|
|
GFP_KERNEL);
|
2012-09-05 20:56:00 +08:00
|
|
|
if (sd->hid_sensor_hub_client_devs == NULL) {
|
2012-09-19 23:30:00 +08:00
|
|
|
hid_err(hdev, "Failed to allocate memory for mfd cells\n");
|
2015-10-11 22:18:22 +08:00
|
|
|
ret = -ENOMEM;
|
|
|
|
|
goto err_stop_hw;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
|
|
|
|
|
for (i = 0; i < hdev->maxcollection; ++i) {
|
|
|
|
|
struct hid_collection *collection = &hdev->collection[i];
|
|
|
|
|
|
2015-02-20 07:31:26 +08:00
|
|
|
if (collection->type == HID_COLLECTION_PHYSICAL ||
|
|
|
|
|
collection->type == HID_COLLECTION_APPLICATION) {
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
|
2014-08-03 06:11:35 +08:00
|
|
|
hsdev = devm_kzalloc(&hdev->dev, sizeof(*hsdev),
|
|
|
|
|
GFP_KERNEL);
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
if (!hsdev) {
|
|
|
|
|
hid_err(hdev, "cannot allocate hid_sensor_hub_device\n");
|
|
|
|
|
ret = -ENOMEM;
|
2014-08-03 06:11:35 +08:00
|
|
|
goto err_stop_hw;
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
}
|
|
|
|
|
hsdev->hdev = hdev;
|
|
|
|
|
hsdev->vendor_id = hdev->vendor;
|
|
|
|
|
hsdev->product_id = hdev->product;
|
2015-02-20 07:31:25 +08:00
|
|
|
hsdev->usage = collection->usage;
|
2015-05-08 05:26:34 +08:00
|
|
|
hsdev->mutex_ptr = devm_kzalloc(&hdev->dev,
|
|
|
|
|
sizeof(struct mutex),
|
|
|
|
|
GFP_KERNEL);
|
|
|
|
|
if (!hsdev->mutex_ptr) {
|
|
|
|
|
ret = -ENOMEM;
|
|
|
|
|
goto err_stop_hw;
|
|
|
|
|
}
|
|
|
|
|
mutex_init(hsdev->mutex_ptr);
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
hsdev->start_collection_index = i;
|
|
|
|
|
if (last_hsdev)
|
|
|
|
|
last_hsdev->end_collection_index = i;
|
|
|
|
|
last_hsdev = hsdev;
|
2014-08-03 06:11:35 +08:00
|
|
|
name = devm_kasprintf(&hdev->dev, GFP_KERNEL,
|
|
|
|
|
"HID-SENSOR-%x",
|
|
|
|
|
collection->usage);
|
2013-08-14 16:07:09 +08:00
|
|
|
if (name == NULL) {
|
2012-09-19 23:30:00 +08:00
|
|
|
hid_err(hdev, "Failed MFD device name\n");
|
2015-10-11 22:18:22 +08:00
|
|
|
ret = -ENOMEM;
|
|
|
|
|
goto err_stop_hw;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
2013-12-06 08:34:25 +08:00
|
|
|
sd->hid_sensor_hub_client_devs[
|
2012-09-05 20:56:00 +08:00
|
|
|
sd->hid_sensor_client_cnt].name = name;
|
|
|
|
|
sd->hid_sensor_hub_client_devs[
|
|
|
|
|
sd->hid_sensor_client_cnt].platform_data =
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
hsdev;
|
2012-09-05 20:56:00 +08:00
|
|
|
sd->hid_sensor_hub_client_devs[
|
|
|
|
|
sd->hid_sensor_client_cnt].pdata_size =
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
sizeof(*hsdev);
|
|
|
|
|
hid_dbg(hdev, "Adding %s:%d\n", name,
|
|
|
|
|
hsdev->start_collection_index);
|
2012-09-05 20:56:00 +08:00
|
|
|
sd->hid_sensor_client_cnt++;
|
2015-02-20 07:31:26 +08:00
|
|
|
if (collection_hsdev)
|
|
|
|
|
collection_hsdev->end_collection_index = i;
|
|
|
|
|
if (collection->type == HID_COLLECTION_APPLICATION &&
|
|
|
|
|
collection->usage == HID_USAGE_SENSOR_COLLECTION)
|
|
|
|
|
collection_hsdev = hsdev;
|
2012-09-05 20:56:00 +08:00
|
|
|
}
|
|
|
|
|
}
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
if (last_hsdev)
|
|
|
|
|
last_hsdev->end_collection_index = i;
|
2015-02-20 07:31:26 +08:00
|
|
|
if (collection_hsdev)
|
|
|
|
|
collection_hsdev->end_collection_index = i;
|
HID: hid-sensor-hub: Processing for duplicate physical ids
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>
2014-02-01 04:04:10 +08:00
|
|
|
|
2014-09-26 18:55:32 +08:00
|
|
|
ret = mfd_add_hotplug_devices(&hdev->dev,
|
|
|
|
|
sd->hid_sensor_hub_client_devs,
|
|
|
|
|
sd->hid_sensor_client_cnt);
|
2012-09-05 20:56:00 +08:00
|
|
|
if (ret < 0)
|
2014-08-03 06:11:35 +08:00
|
|
|
goto err_stop_hw;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
err_stop_hw:
|
|
|
|
|
hid_hw_stop(hdev);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void sensor_hub_remove(struct hid_device *hdev)
|
|
|
|
|
{
|
|
|
|
|
struct sensor_hub_data *data = hid_get_drvdata(hdev);
|
|
|
|
|
unsigned long flags;
|
2015-02-20 07:31:25 +08:00
|
|
|
int i;
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
hid_dbg(hdev, " hardware removed\n");
|
|
|
|
|
hid_hw_close(hdev);
|
2012-09-19 23:30:00 +08:00
|
|
|
hid_hw_stop(hdev);
|
2012-09-05 20:56:00 +08:00
|
|
|
spin_lock_irqsave(&data->lock, flags);
|
2015-02-20 07:31:25 +08:00
|
|
|
for (i = 0; i < data->hid_sensor_client_cnt; ++i) {
|
|
|
|
|
struct hid_sensor_hub_device *hsdev =
|
|
|
|
|
data->hid_sensor_hub_client_devs[i].platform_data;
|
|
|
|
|
if (hsdev->pending.status)
|
|
|
|
|
complete(&hsdev->pending.ready);
|
|
|
|
|
}
|
2012-09-05 20:56:00 +08:00
|
|
|
spin_unlock_irqrestore(&data->lock, flags);
|
|
|
|
|
mfd_remove_devices(&hdev->dev);
|
|
|
|
|
hid_set_drvdata(hdev, NULL);
|
|
|
|
|
mutex_destroy(&data->mutex);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct hid_device_id sensor_hub_devices[] = {
|
HID: hid-sensor-hub: Fix buggy report descriptors
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>
2014-01-15 01:30:20 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_INTEL_0,
|
2014-04-04 04:27:55 +08:00
|
|
|
USB_DEVICE_ID_INTEL_HID_SENSOR_0),
|
HID: hid-sensor-hub: Fix buggy report descriptors
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>
2014-01-15 01:30:20 +08:00
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
|
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_INTEL_1,
|
2014-04-04 04:27:55 +08:00
|
|
|
USB_DEVICE_ID_INTEL_HID_SENSOR_0),
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
|
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_INTEL_1,
|
|
|
|
|
USB_DEVICE_ID_INTEL_HID_SENSOR_1),
|
HID: hid-sensor-hub: Fix buggy report descriptors
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>
2014-01-15 01:30:20 +08:00
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2014-05-27 15:29:10 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
|
|
|
|
|
USB_DEVICE_ID_MS_SURFACE_PRO_2),
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
|
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
|
|
|
|
|
USB_DEVICE_ID_MS_TOUCH_COVER_2),
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
|
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
|
|
|
|
|
USB_DEVICE_ID_MS_TYPE_COVER_2),
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2016-11-25 18:03:43 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
|
|
|
|
|
0x07bd), /* Microsoft Surface 3 */
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2016-11-25 18:03:44 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROCHIP,
|
|
|
|
|
0x0f01), /* MM7150 */
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2014-09-04 07:00:54 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_STM_0,
|
|
|
|
|
USB_DEVICE_ID_STM_HID_SENSOR),
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2014-02-03 15:14:16 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_STM_0,
|
2014-06-02 19:40:49 +08:00
|
|
|
USB_DEVICE_ID_STM_HID_SENSOR_1),
|
2014-02-03 15:14:16 +08:00
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2014-05-06 06:55:32 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_TEXAS_INSTRUMENTS,
|
|
|
|
|
USB_DEVICE_ID_TEXAS_INSTRUMENTS_LENOVO_YOGA),
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2015-06-27 23:02:23 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_ITE,
|
|
|
|
|
USB_DEVICE_ID_ITE_LENOVO_YOGA),
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2015-10-06 00:32:18 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_ITE,
|
|
|
|
|
USB_DEVICE_ID_ITE_LENOVO_YOGA2),
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2015-12-28 23:01:31 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_ITE,
|
|
|
|
|
USB_DEVICE_ID_ITE_LENOVO_YOGA900),
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2016-08-07 17:25:38 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_INTEL_0,
|
|
|
|
|
0x22D8),
|
|
|
|
|
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
|
2013-02-11 18:31:19 +08:00
|
|
|
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, HID_ANY_ID,
|
|
|
|
|
HID_ANY_ID) },
|
2012-09-05 20:56:00 +08:00
|
|
|
{ }
|
|
|
|
|
};
|
|
|
|
|
MODULE_DEVICE_TABLE(hid, sensor_hub_devices);
|
|
|
|
|
|
|
|
|
|
static struct hid_driver sensor_hub_driver = {
|
|
|
|
|
.name = "hid-sensor-hub",
|
|
|
|
|
.id_table = sensor_hub_devices,
|
|
|
|
|
.probe = sensor_hub_probe,
|
|
|
|
|
.remove = sensor_hub_remove,
|
|
|
|
|
.raw_event = sensor_hub_raw_event,
|
HID: hid-sensor-hub: Fix buggy report descriptors
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>
2014-01-15 01:30:20 +08:00
|
|
|
.report_fixup = sensor_hub_report_fixup,
|
2012-09-05 20:56:00 +08:00
|
|
|
#ifdef CONFIG_PM
|
|
|
|
|
.suspend = sensor_hub_suspend,
|
2013-08-14 16:07:09 +08:00
|
|
|
.resume = sensor_hub_resume,
|
|
|
|
|
.reset_resume = sensor_hub_reset_resume,
|
2012-09-05 20:56:00 +08:00
|
|
|
#endif
|
|
|
|
|
};
|
2012-12-18 06:28:26 +08:00
|
|
|
module_hid_driver(sensor_hub_driver);
|
2012-09-05 20:56:00 +08:00
|
|
|
|
|
|
|
|
MODULE_DESCRIPTION("HID Sensor Hub driver");
|
|
|
|
|
MODULE_AUTHOR("Srinivas Pandruvada <srinivas.pandruvada@intel.com>");
|
|
|
|
|
MODULE_LICENSE("GPL");
|