Message ID | af211ec180d91a13862630e635019ebe03d4be31.1677080089.git.mazziesaccount@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp665994wrd; Wed, 22 Feb 2023 08:16:28 -0800 (PST) X-Google-Smtp-Source: AK7set+RNunLxdZ+LWcGaebvGjRNDTKLe3cJpnQktfqONKSpTL+u3K5XDNk/3CzSUIL1734IyaYl X-Received: by 2002:a05:6a21:329c:b0:c7:7248:4e42 with SMTP id yt28-20020a056a21329c00b000c772484e42mr11757679pzb.18.1677082587653; Wed, 22 Feb 2023 08:16:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677082587; cv=none; d=google.com; s=arc-20160816; b=0xIQ0zDtbZIgNgJzLXpbRRAeWgYmCA6Dk74s5SzR3k1Fft3qPUr+wCTW9Exz3/zt2S Mk/DjfohJdtMFz+9JbrtZ+SPRJRpODyPcPhPI/cE/x6bzFIv3vD6K68DGXDA70ZQtOVW K8IAfTcGi2dUqPuEvfI9miunQIpgf9UqPrLgf9INb4MZAUa6eI1wvWHLTcrQTorfXF4F 553tfdzUc2J9obflFyiVBvKjzQiE/MdP0tChO0tPrJIdpEqRa+lcPpVAssvIpmIgaw7g 1xb32niZEQgIneHnOvoTX04KFi8U10rOJFNnvF02g+d61QZORl71FILF2k9+lgDDc3Rs /qeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=l5JBDHjdN3MXwiI4IvjYTThifirf1TjzCClQnfsSE+U=; b=j2k0880uLdhO5PbXR4QixXNaqeA4AZfAoVij/78858GwO7aXPqUWpqvBQklP5sVumD rMWrVrUBEgeTID6WA1Z5yivDC1KfLqYhlhegYufJlEDc4ThsC6NGbdK3WjHzENbJlzp2 uI9iFz3b/pXIDZSrM4FGKs50kVo7r4mQcZmmgHR0SCwef1ODKD3hBZsp1YFnsLGeldbw 4CNVsz6f7q6RVLu/tBqi157SDs7XQks8vKueuWkNpSnqjFnHtd0iswxoCuDgyg/o1L78 FBD2DebQqE84NZ0bqeZS/Ny5nfs02pfggfunrwDRmT5hSsJB49hAyi0ke+bNDeywY2oy reAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=C4BKH4vz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kb14-20020a170903338e00b0019cb53969a5si534825plb.398.2023.02.22.08.16.15; Wed, 22 Feb 2023 08:16:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=C4BKH4vz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232681AbjBVQOk (ORCPT <rfc822;chinmaygameti@gmail.com> + 99 others); Wed, 22 Feb 2023 11:14:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230406AbjBVQOj (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 22 Feb 2023 11:14:39 -0500 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9B1415BBD; Wed, 22 Feb 2023 08:14:33 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id s22so10613433lfi.9; Wed, 22 Feb 2023 08:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=l5JBDHjdN3MXwiI4IvjYTThifirf1TjzCClQnfsSE+U=; b=C4BKH4vzq1IF/vkpPcXc7b3H47gB9h+zS9yBv4/O8gLdjbjqoFn8PQJZgXhgmqakTC BpE3h/J0uiTvINLApNIwOethrvNsMtNikrgXePg+2LV0PMy/KxV/iw8da8FKuyVYk6aJ HFkFjM3BsXMFkr860SpA1ExHxyADvZTiWipbB6nm8Gk6zjfekwOslY8jtRgjkMiBO8h1 2jOJ2bMMjrR4yXr6ecCqsElNCb2mI70NhUNCOpFJE/fEtlRP0ePAb/d2pWC7W50CLaPY 0iIN1G8mIYd2/QdOpjkHiQ5ShGaMDXXoN8f0hcWs1Ag93sIq7z+AAZWXtx6ONpU6mlqZ VxiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=l5JBDHjdN3MXwiI4IvjYTThifirf1TjzCClQnfsSE+U=; b=HoLQwuKUfEHNRzpljJUtYv/htr3/R/6RFIqRoI38pdbRyW/siMix+LPip7n6CiYYMU S9GLko0tWlcMMy5hgfwr8Fo1CV+pAzWIKgCZhQSvafy/uq6xjulYBV/uMtBoC35ltW8T CCfSZusqhvYa/NnUC3//iilrBZHel35V2rpCgCmyKQHSts10SFu2W5l2a6BNN4j4BM95 4pflj3/rt7idD6cELRNwP5l44dlRGF6xIGnjxbAiVAIYepH3ED4fnMeU5Km8/xaycez6 lFNQiojizIiDKXUeKAlzhAvRoxvcp7NUkC4PLmAKz82zduCsQkNF+TwjQl6yZQQDZugT BvGw== X-Gm-Message-State: AO0yUKW4VP+TT1RpKDXwkvJ8snhUJpn9EkKTdhQeun4Mxizo0H/K1qLH /MVW9As8oUOlyhXRJooOJFk= X-Received: by 2002:a19:c511:0:b0:4b5:90c5:281c with SMTP id w17-20020a19c511000000b004b590c5281cmr3400591lfe.19.1677082470939; Wed, 22 Feb 2023 08:14:30 -0800 (PST) Received: from dc75zzyyyyyyyyyyyyyyt-3.rev.dnainternet.fi (dc75zzyyyyyyyyyyyyyyt-3.rev.dnainternet.fi. [2001:14ba:16f3:4a00::1]) by smtp.gmail.com with ESMTPSA id y10-20020a19750a000000b004d885a44789sm2211833lfe.66.2023.02.22.08.14.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Feb 2023 08:14:30 -0800 (PST) Date: Wed, 22 Feb 2023 18:14:25 +0200 From: Matti Vaittinen <mazziesaccount@gmail.com> To: Matti Vaittinen <mazziesaccount@gmail.com>, Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Cc: Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Matti Vaittinen <mazziesaccount@gmail.com>, Shreeya Patel <shreeya.patel@collabora.com>, Zhigang Shi <Zhigang.Shi@liteon.com>, Paul Gazzillo <paul@pgazz.com>, Dmitry Osipenko <dmitry.osipenko@collabora.com>, Liam Beguin <liambeguin@gmail.com>, Peter Rosin <peda@axentia.se>, Randy Dunlap <rdunlap@infradead.org>, Masahiro Yamada <masahiroy@kernel.org>, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH 1/6] dt-bindings: iio: light: Support ROHM BU27034 Message-ID: <af211ec180d91a13862630e635019ebe03d4be31.1677080089.git.mazziesaccount@gmail.com> References: <cover.1677080089.git.mazziesaccount@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KlI1YUSxTXU2sZ4e" Content-Disposition: inline In-Reply-To: <cover.1677080089.git.mazziesaccount@gmail.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758548551134270983?= X-GMAIL-MSGID: =?utf-8?q?1758548551134270983?= |
Series |
Support ROHM BU27034 ALS sensor
|
|
Commit Message
Matti Vaittinen
Feb. 22, 2023, 4:14 p.m. UTC
ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes
capable of detecting a very wide range of illuminance. Typical application
is adjusting LCD and backlight power of TVs and mobile phones.
Add initial dt-bindings.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
.../bindings/iio/light/rohm-bu27034.yaml | 46 +++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml
Comments
On 22/02/2023 17:14, Matti Vaittinen wrote: > ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes > capable of detecting a very wide range of illuminance. Typical application > is adjusting LCD and backlight power of TVs and mobile phones. > > Add initial dt-bindings. Driver can be "initial", but bindings better to be closer to complete, even if not used by the driver currently. > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > --- > .../bindings/iio/light/rohm-bu27034.yaml | 46 +++++++++++++++++++ > 1 file changed, 46 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml > > diff --git a/Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml b/Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml > new file mode 100644 > index 000000000000..a3a642c259e8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml Comma as a separator, so: rohm,bu27034.yaml > @@ -0,0 +1,46 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/iio/light/rohm-bu27034.yaml# With filename and $id fix: Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
Hi dee Ho Krzysztof, Thanks for the review! It's nice you had the time to take a look on RFC :) On 2/22/23 20:57, Krzysztof Kozlowski wrote: > On 22/02/2023 17:14, Matti Vaittinen wrote: >> ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes >> capable of detecting a very wide range of illuminance. Typical application >> is adjusting LCD and backlight power of TVs and mobile phones. >> >> Add initial dt-bindings. > > Driver can be "initial", but bindings better to be closer to complete, > even if not used by the driver currently. Out of the curiosity - why is that? (Please, don't take me wrong, I am not trying to argue against this - just learn the reason behind). I can't immediately see the harm caused by adding new properties later when we learn more of hardware. (and no, I don't expect this simple IC to gain at least many properties). >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> >> --- >> .../bindings/iio/light/rohm-bu27034.yaml | 46 +++++++++++++++++++ >> 1 file changed, 46 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml >> >> diff --git a/Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml b/Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml >> new file mode 100644 >> index 000000000000..a3a642c259e8 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml > > > Comma as a separator, so: > rohm,bu27034.yaml Oh, yes. So it seems. Strange, I could have sworn I used hyphen in binding file names previously although the comma has been used in the compatible. I had to go back in time (lore,kernel.org) to check my earlier submissions. Well, my mind seems to be playing tricks on me @_@. I'll fix this before sending out non RFC series :) Good catch (as always)! Thanks! >> @@ -0,0 +1,46 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/iio/light/rohm-bu27034.yaml# > > With filename and $id fix: > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > Best regards, > Krzysztof > -- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~
On 23/02/2023 07:20, Vaittinen, Matti wrote: > Hi dee Ho Krzysztof, > > Thanks for the review! It's nice you had the time to take a look on RFC :) > > On 2/22/23 20:57, Krzysztof Kozlowski wrote: >> On 22/02/2023 17:14, Matti Vaittinen wrote: >>> ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes >>> capable of detecting a very wide range of illuminance. Typical application >>> is adjusting LCD and backlight power of TVs and mobile phones. >>> >>> Add initial dt-bindings. >> >> Driver can be "initial", but bindings better to be closer to complete, >> even if not used by the driver currently. > > Out of the curiosity - why is that? (Please, don't take me wrong, I am > not trying to argue against this - just learn the reason behind). I > can't immediately see the harm caused by adding new properties later > when we learn more of hardware. (and no, I don't expect this simple IC > to gain at least many properties). Linux drivers change, but the hardware does not, thus DTS, which describes the hardware, can be complete. It should be written based on the hardware, not based on Linux drivers. If you add incomplete bindings, this suggests you wrote them to match your driver, not to match hardware. This in turn (adjusting bindings to driver) makes them less portable, narrowed to one specific driver implementation and more ABI-break-prone later. Imagine you that clock inputs, which you skipped in the binding, were actually needed but on your board they were enabled by bootloader. The binding is then used on other systems or by out of tree users. On your new system the clocks are not enabled by bootloader anymore, thus you add them to the binding. They are actually required for device to work, so you make them required. But all these other users cannot be fixed... What's more, incomplete binding/DTS is then used together with other pieces - DTS and driver, e.g. via some graphs or other phandles/supplies/pinctrl. So some other DTS or driver code might rely on your particular binding. Imagine you had only vdd-supply regulator, but no reset pins, so the only way to power-cycle device was to turn off/on regulator supply. Then you figure out that you have reset pins and it would be useful to add and use it. But already drivers are written to power cycle via regulator... or even someone wrote new driver regulator-pwrseq to power cycle your device due to missing reset GPIOs... Best regards, Krzysztof
On 2/23/23 11:26, Krzysztof Kozlowski wrote: > On 23/02/2023 07:20, Vaittinen, Matti wrote: >> On 2/22/23 20:57, Krzysztof Kozlowski wrote: >>> On 22/02/2023 17:14, Matti Vaittinen wrote: >>>> ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes >>>> capable of detecting a very wide range of illuminance. Typical application >>>> is adjusting LCD and backlight power of TVs and mobile phones. >>>> >>>> Add initial dt-bindings. >>> >>> Driver can be "initial", but bindings better to be closer to complete, >>> even if not used by the driver currently. >> >> Out of the curiosity - why is that? (Please, don't take me wrong, I am >> not trying to argue against this - just learn the reason behind). I >> can't immediately see the harm caused by adding new properties later >> when we learn more of hardware. (and no, I don't expect this simple IC >> to gain at least many properties). > > Linux drivers change, but the hardware does not, thus DTS, which > describes the hardware, can be complete. It should be written based on > the hardware, not based on Linux drivers. If you add incomplete > bindings, this suggests you wrote them to match your driver, not to > match hardware. This in turn (adjusting bindings to driver) makes them > less portable, narrowed to one specific driver implementation and more > ABI-break-prone later. > > Imagine you that clock inputs, which you skipped in the binding, were > actually needed but on your board they were enabled by bootloader. The > binding is then used on other systems or by out of tree users. On your > new system the clocks are not enabled by bootloader anymore, thus you > add them to the binding. They are actually required for device to work, > so you make them required. But all these other users cannot be fixed... > > What's more, incomplete binding/DTS is then used together with other > pieces - DTS and driver, e.g. via some graphs or other > phandles/supplies/pinctrl. So some other DTS or driver code might rely > on your particular binding. Imagine you had only vdd-supply regulator, > but no reset pins, so the only way to power-cycle device was to turn > off/on regulator supply. Then you figure out that you have reset pins > and it would be useful to add and use it. But already drivers are > written to power cycle via regulator... or even someone wrote new driver > regulator-pwrseq to power cycle your device due to missing reset GPIOs... Thanks for explanation Krzysztof. I think that what you wrote here makes sense. Still, I don't think this "adding features only later can cause problems to others" is in any way fundamentally different for bindings and software. Sure this clock example is a valid thing, adding a clock later could cause kernel to suddenly be aware of it can disable it - but disabling the clock would still require a new piece of clk driver too... I think same problems can happen when lower layer SW does not implement all the features - upper layers may need to implement some odd quircks and workarounds to get things working, and all that can be useless or even incompatible with the new low-level SW which finally adds the missing implementation. I guess the 'fundamental' difference I was looking for is that the hardware itself should not change - so in theory we should know the HW from the day 1. Still, we (I) at times notice we need some information about the hardware only when we are (I am) writing the drivers ;) Unfortunately there are companies where all the information about the hardware is not immediately available ... Out of the curiosity 2 (an no need to respond if you're in hurry) - how should one treat hardware logic which is implemented on FPGA? I have in the past worked for a good while on a project where FPGA blocks were also described in dt - but this _really_ blurs the line between "immutable" hardware and "mutable" software. (And yes, we had a great deal of "fun" with updating the FPGA images, FPGA device-trees, linux images and board device-trees...) Anyways, I agree with you. It would be good to have as complete bindings as possible from the day 1. By the way - planning to attend ELCE next summer? It'd be great to have a lecture part II about writing the bindings ;) Yours, --Matti
On Thu, 23 Feb 2023 10:26:02 +0100 Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > On 23/02/2023 07:20, Vaittinen, Matti wrote: > > Hi dee Ho Krzysztof, > > > > Thanks for the review! It's nice you had the time to take a look on RFC :) > > > > On 2/22/23 20:57, Krzysztof Kozlowski wrote: > >> On 22/02/2023 17:14, Matti Vaittinen wrote: > >>> ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes > >>> capable of detecting a very wide range of illuminance. Typical application > >>> is adjusting LCD and backlight power of TVs and mobile phones. > >>> > >>> Add initial dt-bindings. > >> > >> Driver can be "initial", but bindings better to be closer to complete, > >> even if not used by the driver currently. > > > > Out of the curiosity - why is that? (Please, don't take me wrong, I am > > not trying to argue against this - just learn the reason behind). I > > can't immediately see the harm caused by adding new properties later > > when we learn more of hardware. (and no, I don't expect this simple IC > > to gain at least many properties). > > Linux drivers change, but the hardware does not, thus DTS, which > describes the hardware, can be complete. It should be written based on > the hardware, not based on Linux drivers. If you add incomplete > bindings, this suggests you wrote them to match your driver, not to > match hardware. This in turn (adjusting bindings to driver) makes them > less portable, narrowed to one specific driver implementation and more > ABI-break-prone later. > > Imagine you that clock inputs, which you skipped in the binding, were > actually needed but on your board they were enabled by bootloader. The > binding is then used on other systems or by out of tree users. On your > new system the clocks are not enabled by bootloader anymore, thus you > add them to the binding. They are actually required for device to work, > so you make them required. But all these other users cannot be fixed... > > What's more, incomplete binding/DTS is then used together with other > pieces - DTS and driver, e.g. via some graphs or other > phandles/supplies/pinctrl. So some other DTS or driver code might rely > on your particular binding. Imagine you had only vdd-supply regulator, > but no reset pins, so the only way to power-cycle device was to turn > off/on regulator supply. Then you figure out that you have reset pins > and it would be useful to add and use it. But already drivers are > written to power cycle via regulator... or even someone wrote new driver > regulator-pwrseq to power cycle your device due to missing reset GPIOs... To add one wrinkle here, board designers have an annoying habit of not wiring reset pins up so if there is any easy way to support an alternative (often there is a software reset command over a bus) then keep the reset pins as optional and implement that in the driver from day one. Same is true of interrupts, though that can be harder to deal with so the binding may say they are optional but the driver fail to load without them. Nice reply Krzyzstof, I'll try and remember to point people at this one as the question comes up pretty often. Thanks, Jonathan > > > Best regards, > Krzysztof >
diff --git a/Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml b/Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml new file mode 100644 index 000000000000..a3a642c259e8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/rohm-bu27034.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/rohm-bu27034.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BU27034 ambient light sensor + +maintainers: + - Matti Vaittinen <mazziesaccount@gmail.com> + +description: | + ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes + capable of detecting a very wide range of illuminance. Typical application + is adjusting LCD and backlight power of TVs and mobile phones. + https://fscdn.rohm.com/en/products/databook/datasheet/ic/sensor/light/bu27034nuc-e.pdf + +properties: + compatible: + const: rohm,bu27034 + + reg: + maxItems: 1 + + vdd-supply: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + light-sensor@38 { + compatible = "rohm,bu27034"; + reg = <0x38>; + vdd-supply = <&vdd>; + }; + }; + +...