-----Original Message-----
From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
Sent: Sunday, November 13, 2011 7:48 PM
To: Jiri Kosina
Cc: KY Srinivasan; gregkh@suse.de; linux-kernel@vger.kernel.org;
devel@linuxdriverproject.org; virtualization@lists.osdl.org; ohering@suse.com;
joe@perches.com
Subject: Re: [PATCH 1/1] Staging: hv: Move the mouse driver out of staging

On Sun, Nov 13, 2011 at 09:01:28PM +0100, Jiri Kosina wrote:

quoted

On Sun, 6 Nov 2011, Dmitry Torokhov wrote:

quoted

quoted

I am not a hid expert; but all  hid low level drivers appear to do this.
Initially, I was directly invoking hid_connect() directly and based on your
Input, I chose to use hid_hw_start() which all other drivers are using.

Note that the users of hid_hw_start() actually are not low level
drivers, such as usbhid or bluetooth hidp, but higher-level drivers,
such as hid-wacom, hid-a4tech, etc. Since your driver is a low-level
driver (a provider so to speak) it should not call hid_hw_start() on its
own but rather wait for the hid code to do it.

Still, I am not a HID expert either so I'll defer to Jiri here.

Hi,

my understanding is that hv driver is actually a bit special in this
respect -- it's actually all-in-one both low-level and high-level driver.
I take it that there is not ever going to be a different high-level driver
using low-level hv transport (is that correct, KY?), so this might indeed
be an acceptable layout of the driver.

I actually do not see anything of a high-level driver in hv-mouse. It is
a pure transport driver that channels everything through hid-input...

The split architecture (in my opinion) makes sense if there are multiple consumers
of that transport. In this case though, there is not going to be any other drivers
using this transport. As you have noted, there really is not any code in this driver that
would qualify as being the high level driver. 

Regards,

K. Y