| Message ID | 1360578679-7029-3-git-send-email-mika.westerberg@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Jiri Kosina |
| Headers | show |
On Mon, Feb 11, 2013 at 11:31 AM, Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > 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> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Thanks Mika for this series! Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 11 Feb 2013, Benjamin Tissoires wrote: > > 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> > > Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Thanks a lot Mika, I have now applied the series for 3.9
Am 11.02.2013 11:31, schrieb Mika Westerberg: > 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? Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote: > Am 11.02.2013 11:31, schrieb Mika Westerberg: > >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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 18.02.2013 12:12, schrieb Mika Westerberg: > On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote: >> Am 11.02.2013 11:31, schrieb Mika Westerberg: >>> 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. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 18, 2013 at 12:22:58PM +0100, Alexander Holler wrote: > Am 18.02.2013 12:12, schrieb Mika Westerberg: > >On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote: > >>Am 11.02.2013 11:31, schrieb Mika Westerberg: > >>>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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 18.02.2013 12:33, schrieb Mika Westerberg: > On Mon, Feb 18, 2013 at 12:22:58PM +0100, Alexander Holler wrote: >> Am 18.02.2013 12:12, schrieb Mika Westerberg: >>> On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote: >>>> Am 11.02.2013 11:31, schrieb Mika Westerberg: >>>>> 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. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 18, 2013 at 12:37:52PM +0100, Alexander Holler wrote: > Am 18.02.2013 12:33, schrieb Mika Westerberg: > >On Mon, Feb 18, 2013 at 12:22:58PM +0100, Alexander Holler wrote: > >>Am 18.02.2013 12:12, schrieb Mika Westerberg: > >>>On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote: > >>>>Am 11.02.2013 11:31, schrieb Mika Westerberg: > >>>>>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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 18.02.2013 12:54, schrieb Mika Westerberg: > On Mon, Feb 18, 2013 at 12:37:52PM +0100, Alexander Holler wrote: >> Am 18.02.2013 12:33, schrieb Mika Westerberg: >>> On Mon, Feb 18, 2013 at 12:22:58PM +0100, Alexander Holler wrote: >>>> Am 18.02.2013 12:12, schrieb Mika Westerberg: >>>>> On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote: >>>>>> Am 11.02.2013 11:31, schrieb Mika Westerberg: >>>>>>> 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. > I just had a deeper look at the spec for that TI device. Looks like the default firmware uses GATT and not HID. But nevertheless, if the driver does support Bluetooth too, I think enabling it makes sense. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Sorry for coming this late in the discussion (I was sick at the beginning of the week, preventing me to answer mails). On Mon, Feb 18, 2013 at 1:13 PM, Alexander Holler <holler@ahsoftware.de> wrote: >>>>>>> Hmm, what happens with Bluetooth sensor-hubs? Is the driver now able >>>>>>> to handle them too? >>>>>> >>>>>> >>>>>> It should, yes. >>>>> It should, but the full features are not enabled. We also need to patch hidp so that it can handle .request() too. Otherwise, when the sensor hub will request a "get feature" or a "set feature", then nothing will be triggered. However, I don't think it will prevent us from removing the test against USB/I2C. It's just something we need to work on too. Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 21.02.2013 11:34, schrieb Benjamin Tissoires: > Hi, > > Sorry for coming this late in the discussion (I was sick at the > beginning of the week, preventing me to answer mails). > > On Mon, Feb 18, 2013 at 1:13 PM, Alexander Holler <holler@ahsoftware.de> wrote: >>>>>>>> Hmm, what happens with Bluetooth sensor-hubs? Is the driver now able >>>>>>>> to handle them too? >>>>>>> >>>>>>> >>>>>>> It should, yes. >>>>>> > > It should, but the full features are not enabled. We also need to > patch hidp so that it can handle .request() too. Otherwise, when the > sensor hub will request a "get feature" or a "set feature", then > nothing will be triggered. > > However, I don't think it will prevent us from removing the test > against USB/I2C. It's just something we need to work on too. Thanks. I've just ordered me one of those bt-sensors from TI, maybe I will be able to make it HID over GATT aware to play a bit with it. The BT spec for HID over GATT doesn't talk about sensors, but if I will find a way to program the device without buying more hw, I will have a look if it is possible. ;) Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);
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(-)