On Mon, Feb 18, 2013 at 12:37:52PM +0100, Alexander Holler wrote:

Am 18.02.2013 12:33, schrieb Mika Westerberg:

quoted

On Mon, Feb 18, 2013 at 12:22:58PM +0100, Alexander Holler wrote:

quoted

Am 18.02.2013 12:12, schrieb Mika Westerberg:

quoted

On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote:

quoted

Am 11.02.2013 11:31, schrieb Mika Westerberg:

quoted

We now have two transport mediums: USB and I2C, where sensor hubs can
exists. So instead of constraining the driver to only these two we let it
to match any HID bus as long as the group is HID_GROUP_SENSOR_HUB.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/hid/hid-sensor-hub.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 2643bce9..c01f10d 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c

@@ -603,7 +603,8 @@ static void sensor_hub_remove(struct hid_device *hdev)
 }

 static const struct hid_device_id sensor_hub_devices[] = {
-	{ HID_DEVICE(BUS_USB, HID_GROUP_SENSOR_HUB, HID_ANY_ID, HID_ANY_ID) },
+	{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, HID_ANY_ID,
+		     HID_ANY_ID) },
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, sensor_hub_devices);

Hmm, what happens with Bluetooth sensor-hubs? Is the driver now able
to handle them too?

It should, yes.

If so, I think patch 1/3 should be modified accordingly.

Do you know if such devices exists currently? If not, I'm not sure if it
makes sense to do that now.

The CC2541DK-SENSOR from TI looks like one. But I'm not sure as I
don't have one. Besides that, I think Bluetooth (especially with
BT4LE) will be by far the most used bus for sensors hubs.

OK, thanks.

In that case I think it's best to remove the explicit bus check from the
condition completely and rely on the fact that page == HID_UP_SENSOR.

Since Jiri already applied this patch, I can make an incremental patch
which removes the explicit bus check, if there are no objections.