Re: [RFC 0/5] hid: Extending the device-driver matching mechanism

From: "Henrik Rydberg" <rydberg@euromail.se>
To: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Stephane Chatty <chatty@enac.fr>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/5] hid: Extending the device-driver matching mechanism
Date: Tue, 3 Apr 2012 12:55:54 +0200	[thread overview]
Message-ID: <20120403105554.GA14201@polaris.bitmath.org> (raw)
In-Reply-To: <CAN+gG=EvmTFKmKGaC6T-RKYhUy8U0NqWxqz-k_Gr_w5_rm57Bg@mail.gmail.com>

Hi Benjamin,

> So, I made a few tests yesterday, and I have now a clearer idea about
> this solution:
> 
> generally, I like it. Furthermore, it should help us build new classes
> of devices without involving hid-core, which is great.
> However, I have a few minors concerns, and a major one.
> 
> The major one comes with patch 3: introducing the hid_parse function
> in usbhid is great but it interferes with report_fixup mechanism. That
> means that several drivers won't work with this solution.

Yes, as noted in the commit message, that part is a work in
progress. Going through all the drivers using report_fixup, the
majority only uses device information, some use a driver-specific
quirk which again boils down to a specific device. All drivers are
present in the special_driver list in hid-core.

The simplest solution is probably to defer parsing for drivers known
from the device list. Even better would be if there was a mechanism to
avoid that list altogether... considering the USB/BT device as
separate from the HID device, it might even make sense to split the
drivers that way. Most drivers would drive the HID devices,
kickstarted by the generic usbhid driver. Some drivers would need to
intervene on the USB/BT level instead, for instance by fixing up the
reports.

> Now the minors:
> - as mentioned, the patches do not apply on Jiri's tree, which means
> that we are missing the detection of the serial protocol (see comment
> in patch 4).

Ok, thanks. In a couple of weeks I should rebase the patches to 3.4,
and will deal with it then.

> - shouldn't we introduce the same behavior for bluetooth (hidp)
> devices -> to be able to separate the handling of the magicmouse for
> instance)?

Yes, although I have not looked into the details yet.

> - as the hid_parse function is already called, shouldn't we remove the
> calls in the other drivers?

Maybe, maybe not - it depends on if there will be a deferral
mechanism. Hopefully it will become clear as we go along.

Thanks!
Henrik