Re: [PATCH 1/3] HID: Add HID_CLAIMED_OTHER for non-generic drivers

["Henrik Rydberg" <rydberg@euromail.se>]

On Mon, Jul 16, 2012 at 09:08:47PM +0200, David Herrmann wrote:
> Hi Henrik
> 
> On Mon, Jul 16, 2012 at 8:45 PM, Henrik Rydberg <rydberg@euromail.se> wrote:
> > Hi David,
> >
> > Perhaps one should make hid-core warn instead of bailing out instead?
> > Something may need to be done to make sure everything works smoothly,
> > but really, why would hid-core mind keeping a device on the bus with a
> > non-standard io driver?
> 
> No, I think bailing out is the correct thing to do. If we emit a
> warning but leave the device on the bus, the device will have no
> driver loaded and idling in background. Hence, dropping the device is
> the best solution for 99% of the devices.

If the driver that picks up the device (wiimote for instance) decides
it does not want to use any of the io drivers (HID_CONNECT*) by
calling hid_hw_start(hdev, 0), in what way is that different from
calling it with, say, hid_hw_start(hdev, HID_CONNECT_TO_OTHER)?  (The
latter would be an equivalent (but cleaner) way of setting your
HID_CLAIMED_OTHER flag).

To catch possible mistakes, one could check for the presence of
raw_event() instead, for instance.

What I am getting at is that we really do not need to create any more
backdoors into the hid core - on the contrary, we can most likely
easily remove some of them instead.

> However, devices that explicitly do not require the generic drivers
> (like picolcd and wiimote) should be able to stay on the bus. We could
> of course put them out of the HID subsystem as they have very little
> in common with the other HID drivers, but that wouldn't make the
> situation any better. It would mean writing transport-level drivers
> for picolcd and wiimote which are exactly the same as USBHID and HIDP.
> Hence, I think allowing non-standard drivers on the BUS is ok as long
> as they explicitly request it.

Yes, the question is only what that request looks like. The simpler
the better, don't you agree?

Thanks,
Henrik