Re: [PATCH 13/17] HID: logitech-hidpp: make .probe usbhid capable

From: Jiri Kosina
Date: Thu Jan 19 2017 - 05:56:14 EST


On Wed, 18 Jan 2017, Benjamin Tissoires wrote:

> > The current custom solution for the G920 is not the best because
> > hid_hw_start() is not called at the end of the .probe().
> > It means that any configuration retrieved after the initial hid_hw_start
> > would not be exposed to user space without races.
> >
> > We can simply force hid_hw_start to just enable the transport layer by
> > not using a connect_mask. This way, we can have a common path between
> > USB, Unifying and Bluetooth devices.
> >
> > Tested with a G502 (plain USB), a T650 and many other unifying devices,
> > and the T651 over Bluetooth.
> >
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx>
> > ---
> > drivers/hid/hid-logitech-hidpp.c | 88 ++++++++++++++++++++++------------------
> > 1 file changed, 48 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> > index a5d37a4..f5889ff 100644
> > --- a/drivers/hid/hid-logitech-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -2813,6 +2813,17 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > if (!hidpp_validate_device(hdev))
> > return hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> >
> > + /*
> > + * HID++ needs to read incoming report while in .probe().
> > + * However, this doesn't work for plain USB devices until the hdev
> > + * status is set with HID_STAT_ADDED (device fully registered once
> > + * with HID).
> > + * So we ask for it to be reprobed later.
> > + */
> > + if (id->group != HID_GROUP_LOGITECH_DJ_DEVICE &&
> > + !(hdev->status & HID_STAT_ADDED))
>
> Looks like this test breaks the T651 (bluetooth) after all. I seem to
> have better success with:
> if (id->bus == BUS_USB && !(hdev->status & HID_STAT_ADDED))
>
> But that also means that the solution will not work if there is only
> one USB interface in the device :/

Benjamin,

do you want at least a subset of this patchset to be queued before you
figure this out, or should I put the whole thing on hold? (not gone
through it fully yet).

Thanks,

--
Jiri Kosina
SUSE Labs