I re-added your reviewers to the cc...
On Mon, 24 May 2010 16:34:25 +0530 (IST)
"Hemanth V" <[email protected]> wrote:
> This patch adds support for ROHM BH1780GLI Ambient light sensor.
>
> BH1780 supports I2C interface. Driver supports read/update of power state and
> read of lux value (through SYSFS). Writing value 3 to power_state enables the
> sensor and current lux value could be read.
There are at least two other ambient light sensor drivers:
drivers/misc/isl29003.c and drivers/misc/tsl2550.c.
Is there any standardisation of the ABIs whcih these drivers offer? If
so, does this new driver comply with that?
It would be most useful if the changelog were to fully describe the
proposed kernel<->userspace interface. That's the most important part
of the driver, because it's the only part we can never change.
There is a desultory effort to maintain sysfs API descriptions under
Documentation/ABI/. I'd have thought that it would be appropriate to
document this driver's ABI in there.
On Tue, Jun 01, 2010 at 01:12:44PM -0700, Andrew Morton wrote:
> On Mon, 24 May 2010 16:34:25 +0530 (IST)
> "Hemanth V" <[email protected]> wrote:
>
> > This patch adds support for ROHM BH1780GLI Ambient light sensor.
> >
> > BH1780 supports I2C interface. Driver supports read/update of power state and
> > read of lux value (through SYSFS). Writing value 3 to power_state enables the
> > sensor and current lux value could be read.
>
> There are at least two other ambient light sensor drivers:
> drivers/misc/isl29003.c and drivers/misc/tsl2550.c.
>
> Is there any standardisation of the ABIs whcih these drivers offer? If
> so, does this new driver comply with that?
Jonathan proposed the ALS framework for these type of devices, but it
was rejected (don't know about the reasons, I didn't follow the
discussions). The new idea is to put such drivers in the industrial IO
subsystem, but I don't know how mature that approach is currently.
For the time being, these drivers cook up whatever sysfs interface they
like, and their userspace ABIs are not standardized, unfortunately.
> It would be most useful if the changelog were to fully describe the
> proposed kernel<->userspace interface. That's the most important part
> of the driver, because it's the only part we can never change.
>
> There is a desultory effort to maintain sysfs API descriptions under
> Documentation/ABI/. I'd have thought that it would be appropriate to
> document this driver's ABI in there.
FWIW, I put some documentation about the isl29003 to
Documentation/misc-devices when I wrote the driver.
Daniel
On 06/01/10 21:12, Andrew Morton wrote:
>
> I re-added your reviewers to the cc...
>
> On Mon, 24 May 2010 16:34:25 +0530 (IST)
> "Hemanth V" <[email protected]> wrote:
>
>> This patch adds support for ROHM BH1780GLI Ambient light sensor.
>>
>> BH1780 supports I2C interface. Driver supports read/update of power state and
>> read of lux value (through SYSFS). Writing value 3 to power_state enables the
>> sensor and current lux value could be read.
>
> There are at least two other ambient light sensor drivers:
> drivers/misc/isl29003.c and drivers/misc/tsl2550.c.
for ref there is also drivers/staging/iio/light/tsl2563.c
and intent to pick up the other two soon (probably when, hopefully
IIO leaves staging, we could do it now if people prefer. Having two
drivers in the short term is also an option).
As for abi cleanup. We had all authors and contributors to all the
above agreeing to standardization changes for ALS (and probably
all the users ;) so we are probably in a position to change things
now before there are too many users!
>
> Is there any standardisation of the ABIs whcih these drivers offer? If
> so, does this new driver comply with that?
Sadly that was one of the things ALS was meant to clean up. I've proposed
one under IIO that is effectively the equivalent of hwmon (we have a lot
of overlap in supported device types with hwmon, so as Greg KH suggested
have matched their interface where it exists).
illuminance0_input (measured in lux)
The other exports of light sensors are remarkably inconsistent across different
devices. At the moment all the in kernel drivers only support polled reading
via sysfs. There are tsl2563 interrupt patches on linux-iio list (not that
it is particularly relevant here). I've also proposed some other naming
for the weird bits of tsl2563 in that patch series.
(http://marc.info/?l=linux-iio&m=127473503113241&w=2)
>
> It would be most useful if the changelog were to fully describe the
> proposed kernel<->userspace interface. That's the most important part
> of the driver, because it's the only part we can never change.
>
> There is a desultory effort to maintain sysfs API descriptions under
> Documentation/ABI/. I'd have thought that it would be appropriate to
> document this driver's ABI in there.
Agreed, but we get back to the debate of what we should standardise on.
The main point of ALS before it died was exactly putting this standardization
in place (admittedly the interface was slightly different from what we
are proposing in IIO, but that was before Greg pointed out that sharing
with hwmon would be a good idea!)
I have to admit I'm a little loath to spend too much time on this given
the amount of time wasted previously (ALS).
Jonathan
On Tue, 1 Jun 2010 22:27:15 +0200
Daniel Mack <[email protected]> wrote:
> On Tue, Jun 01, 2010 at 01:12:44PM -0700, Andrew Morton wrote:
> > On Mon, 24 May 2010 16:34:25 +0530 (IST)
> > "Hemanth V" <[email protected]> wrote:
> >
> > > This patch adds support for ROHM BH1780GLI Ambient light sensor.
> > >
> > > BH1780 supports I2C interface. Driver supports read/update of power state and
> > > read of lux value (through SYSFS). Writing value 3 to power_state enables the
> > > sensor and current lux value could be read.
> >
> > There are at least two other ambient light sensor drivers:
> > drivers/misc/isl29003.c and drivers/misc/tsl2550.c.
> >
> > Is there any standardisation of the ABIs whcih these drivers offer? If
> > so, does this new driver comply with that?
>
> Jonathan proposed the ALS framework for these type of devices, but it
> was rejected (don't know about the reasons, I didn't follow the
> discussions). The new idea is to put such drivers in the industrial IO
> subsystem, but I don't know how mature that approach is currently.
>
> For the time being, these drivers cook up whatever sysfs interface they
> like, and their userspace ABIs are not standardized, unfortunately.
Well can we fix that? Look at the existing drivers, pick one and make
this new driver provide the same interface?
It's not a grand plan - more of an incremental baby step, but it's
better than this random proliferation.
On 06/01/10 21:27, Daniel Mack wrote:
> On Tue, Jun 01, 2010 at 01:12:44PM -0700, Andrew Morton wrote:
>> On Mon, 24 May 2010 16:34:25 +0530 (IST)
>> "Hemanth V" <[email protected]> wrote:
>>
>>> This patch adds support for ROHM BH1780GLI Ambient light sensor.
>>>
>>> BH1780 supports I2C interface. Driver supports read/update of power state and
>>> read of lux value (through SYSFS). Writing value 3 to power_state enables the
>>> sensor and current lux value could be read.
>>
>> There are at least two other ambient light sensor drivers:
>> drivers/misc/isl29003.c and drivers/misc/tsl2550.c.
>>
>> Is there any standardisation of the ABIs whcih these drivers offer? If
>> so, does this new driver comply with that?
>
> Jonathan proposed the ALS framework for these type of devices, but it
> was rejected (don't know about the reasons, I didn't follow the
> discussions).
Ah the wonder of emails crossing ;)
For the interested... http://lkml.org/lkml/2010/3/1/367
(the main objections are Linus' email)
> The new idea is to put such drivers in the industrial IO
> subsystem, but I don't know how mature that approach is currently.
We haven't lifted any that didn't start there as moving things into staging
due to a dependency being there seemed a controversial thing to do.
>
> For the time being, these drivers cook up whatever sysfs interface they
> like, and their userspace ABIs are not standardized, unfortunately.
>
>> It would be most useful if the changelog were to fully describe the
>> proposed kernel<->userspace interface. That's the most important part
>> of the driver, because it's the only part we can never change.
>>
>> There is a desultory effort to maintain sysfs API descriptions under
>> Documentation/ABI/. I'd have thought that it would be appropriate to
>> document this driver's ABI in there.
>
> FWIW, I put some documentation about the isl29003 to
> Documentation/misc-devices when I wrote the driver.
>
> Daniel
>
On Tue, 01 Jun 2010 21:39:10 +0100
Jonathan Cameron <[email protected]> wrote:
> >
> > It would be most useful if the changelog were to fully describe the
> > proposed kernel<->userspace interface. That's the most important part
> > of the driver, because it's the only part we can never change.
> >
> > There is a desultory effort to maintain sysfs API descriptions under
> > Documentation/ABI/. I'd have thought that it would be appropriate to
> > document this driver's ABI in there.
> Agreed, but we get back to the debate of what we should standardise on.
I'd suggest standardising on one of the existing drivers. That way we
have two compliant drivers and only need to change (n-2) others. If we
pick some new standard then we need to change (n) drivers.
And we can't change the drivers, really. They'd all end up needing to
provide two interfaces: one for the shiny-new-standard and one legacy.
> The main point of ALS before it died was exactly putting this standardization
> in place (admittedly the interface was slightly different from what we
> are proposing in IIO, but that was before Greg pointed out that sharing
> with hwmon would be a good idea!)
>
> I have to admit I'm a little loath to spend too much time on this given
> the amount of time wasted previously (ALS).
Well, it's not a waste. This is very important! We appear to be
making a big mess which we can never fix up.
On 06/01/10 21:54, Andrew Morton wrote:
> On Tue, 01 Jun 2010 21:39:10 +0100
> Jonathan Cameron <[email protected]> wrote:
>
>>>
>>> It would be most useful if the changelog were to fully describe the
>>> proposed kernel<->userspace interface. That's the most important part
>>> of the driver, because it's the only part we can never change.
>>>
>>> There is a desultory effort to maintain sysfs API descriptions under
>>> Documentation/ABI/. I'd have thought that it would be appropriate to
>>> document this driver's ABI in there.
>> Agreed, but we get back to the debate of what we should standardise on.
>
> I'd suggest standardising on one of the existing drivers. That way we
> have two compliant drivers and only need to change (n-2) others. If we
> pick some new standard then we need to change (n) drivers.
I agree but take into account that we are getting a number of superficially
similar interfaces in kernel (hwmon, various sensors in misc and IIO)
and it makes sense to my mind to share interfaces across these where
possible (this is exactly the argument Greg made when we carried the
equivalent standardization out in IIO - for ref, the spec is in
staging/drivers/iio/Documentation/sysfs-class-iio)
(gah, the name needs a change to reflect our move to a sysfs bus - oops)
>
> And we can't change the drivers, really. They'd all end up needing to
> provide two interfaces: one for the shiny-new-standard and one legacy.
True enough. We argued we could do with out this before because we were
fairly sure that we knew everyone who was using the sensors (also 1 was in staging
and another extremely)
>
>> The main point of ALS before it died was exactly putting this standardization
>> in place (admittedly the interface was slightly different from what we
>> are proposing in IIO, but that was before Greg pointed out that sharing
>> with hwmon would be a good idea!)
>>
>> I have to admit I'm a little loath to spend too much time on this given
>> the amount of time wasted previously (ALS).
>
> Well, it's not a waste. This is very important! We appear to be
> making a big mess which we can never fix up.
I agree entirely, picking a driver to copy is the way to go.
(personally I'd argue for the tsl2563 for the reasons above)
I'm just moaning about the time wasted the previous time we tried to clean
this stuff up :)
Note that 'if' these drivers do end up in IIO we will have to add the abi
as per the tsl2563 (can keep the others around for a while). We have a consistent
abi over 6+ sensor types so far and we aren't going to want to break it for
this one. There are still unresolved corners in our abi but
they are all event related so this device is nowhere near them.
Either way, I agree entirely that matching any existing driver is a good thing
even if it isn't the one I'd personally prefer!
Jonathan
> Is there any standardisation of the ABIs whcih these drivers offer? If
> so, does this new driver comply with that?
There was an attempt to sort this out but Linux vetoed it because he is
under the delusion that light sensors are input devices. That doesn't
work in many use cases as you have to go ask them the light level and the
polling needed for input events keeps wrecks your idle behaviour when you
need to sample them when required instead. Instead therefore the API is
random and the devices appear in random ways and classes.
We have some intel drivers to submit as well as and when sanity prevails.
Alan