RE: [PATCH 0/8] HID-Sensor: v2

[Jonathan Cameron <jic23@cam.ac.uk>]

"Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:

>Hi Jonath=
an and Jiri,
>
>I am in process of implementing as mfd device. In this case=
 I can keep
>the core HID stuff in driver/hid and move sensor implantation =
using IIO
>to drivers/iio/hid-sensors.
>In this way if some driver if just =
want to use HID sensor but want to
>use some other mechanism to communicate=
 with user mode, they can do in
>their respective drivers.
>
>What do you t=
hink about this approach?
Sounds like a sensible plan.  I would put the ind=
ividual drivers in iio/accel and similar though. 
>
>Thanks,
>Srinivas
>
>
=
>-----Original Message-----
>From: Jonathan Cameron [mailto:jic23@cam.ac.uk=
] 
>Sent: Thursday, June 14, 2012 6:40 AM
>To: Jiri Kosina
>Cc: Pandruvada,=
 Srinivas; linux-iio@vger.kernel.org; Jonathan Cameron
>Subject: Re: [PATCH=
 0/8] HID-Sensor: v2
>
>On 6/14/2012 2:25 PM, Jiri Kosina wrote:
>> On Thu,=
 14 Jun 2012, Jonathan Cameron wrote:
>>
>>>> As this is however a staging =
driver (and depends on IIO, which is a
>
>>>> staging infrastructure), I su=
ggest you resend the patch to staging 
>>>> maintainers so that it gets app=
lied and we can work on polishing
>the 
>>>> driver there.
>>>
>>>> Also, w=
hat are the plans regarding moving IIO out of staging,
>please?
>>> The cor=
e is out of staging as of the current cycle.
>>
>> Ah, you are right, I mis=
sed that this has already happened.
>>
>>> Drivers are moving out whenever =
someone has time to take a look at 
>>> each one and clean up any loose end=
s.  A couple went with the last 
>>> merge window, lots more a queued up fo=
r the next one.
>>>
>>> Generally any new drivers shouldn't go into staging=
 but directly
>into 
>>> drivers/iio.
>>
>> For hid sensors I'd probably pr=
efer drivers/hid though.
>There's some pretty strong moves to clasify drive=
rs by function not by
>'bus' (which is kind of what hid is I guess?)
>
>I d=
o wonder if this driver would work better as an mfd type device with
>the s=
ensor specific bits each having their own module?
>
>Honestly I've never be=
en much of a stickler for where things are as
>long as someone is happy to =
look after them.
>>
>>> Sorry for my lack of responses on this revised vers=
ion, been a busy 
>>> week and it's a fairly big review to do.
>>
>> Thanks=
,
>>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevit=
y.