linux-kernel - Re: [PATCH] iio: light: add driver for bh1730fvc chips

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 21 Feb 2018 20:32:45 +0200
From:   Daniel Baluta <daniel.baluta@...il.com>
To:     "Pierre Bourdon (delroth)" <delroth@...gle.com>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        linux-iio@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iio: light: add driver for bh1730fvc chips

On Wed, Feb 21, 2018 at 6:15 PM, Pierre Bourdon (delroth)
<delroth@...gle.com> wrote:
> Hi Daniel,
>
> On Wed, Feb 21, 2018 at 4:31 PM, Daniel Baluta <daniel.baluta@...il.com> wrote:
>> On Wed, Feb 21, 2018 at 2:55 PM, Pierre Bourdon <delroth@...gle.com> wrote:
>>> Ambient light sensor that supports visible light and IR measurements and
>>> configurable gain/integration time.
>>>
>>
>> Can you have a quick look to existing ROHM light sensor support.
>> Perhaps your sensor
>> is similar enough with existing code.
>>
>> I'm talking about:
>>
>> drivers/iio/light/{bh1750.c  bh1780.c }
>
> bh1750 does things sufficiently different in its protocol that the
> amount of common code would be fairly small. Unlike bh1730/bh1780 it's
> not fully SMBus compatible for example.
>
> bh1780 could probably be implemented as a subset of bh1730. It's
> basically a simplified bh1730 with less knobs. But there is still a
> significant amount of differences that make common code difficult to
> extract. For example, bh1780 reads lux values directly from the chip,
> whereas bh1730 has two raw channels that need to be combined in
> software to get a processed lux value. It could be done, but my gut
> feeling is that writing a "HAL" for this is going to make things more
> complicated, not simpler.
>

I only had a very quick look at existing ROHM sensors drivers. So, sure
if it doesn't makes sense then we can have bh1730 as a standalone driver.

<snip>

>>
>> Usually the devicetree binding part should be sent as a separate patch
>>  with device-tree mailing list and maintainer at CC.
>>
>> Use ./scripts/get_maintainer.pl to find the exact emails.
>>
>> Mind that you should sent a patchseries:
>>
>> 1/2 - driver code
>> 2/2 - documentation
>
> Will do. Should the of_match_table in the driver code be part of 1/2
> (driver) or 2/2 (dt-bindings)?
>

Should be part of 1/2. 2/2 should only containt the patch for Documentation.


> I'll send a v2 with this + the other changes you've suggested.

Great thanks!

Any idea how to make my gmail not to wrap the lines in plain text mode? :D
It drives me crazy when I reread my emails.

thanks,
Daniel.