Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support

["Hemanth V" <hemanthv@ti.com>]

----- Original Message ----- 
From: "Christoph Fritz" <chf.fritz@googlemail.com>
To: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Cc: "Jonathan Cameron" <jic23@cam.ac.uk>; "Datta, Shubhrajyoti" 
<shubhrajyoti@ti.com>; <linux-input@vger.kernel.org>; 
<linux-omap@vger.kernel.org>
Sent: Thursday, May 13, 2010 1:38 AM
Subject: Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support


> On Wed, 2010-05-12 at 11:29 -0700, Dmitry Torokhov wrote:
>> On Wed, May 12, 2010 at 07:15:22PM +0100, Jonathan Cameron wrote:
>> > Hi,
>> >
>> > I was wondering if you could provide a bit more detail on what this
>> > driver is actually doing?  My appologies if I have missed a
>> > previous explanation.  If so, please add a Documentation file
>> > to explain what is going on.
>> >
>> > The driver you have here does virtually nothing itself.  It takes
>> > both its source of interrupt and read function from platform
>> > data. Given the value is always 0 or 1, I'm guessing you are
>> > simply reading a gpio pin. That makes this effectively a button
>> > and doesn't require any specific code.  The fact it is a
>> > proximity sensor isn't relevant to anything other than perhaps
>> > the name.
>>
>> Excellent point. Maybe it should simply use gpio_keys driver with
>> SW_FRONT_PROXIMITY code.
>>
>
> I had a look into the datasheet, this SFH 7741 has one Schmitt trigger
> output: So yes, it's a "key" even without chatter.
>
Output being configured as GPIO  is specific to OMAP4 board, SFH7741 doesnot 
really
mandate this. The idea behind this driver is to provide a generic interface 
and
hooks for platform specific configuration.

Will using gpio_keys make this very specific to platform configuration.

Thanks
Hemanth

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>