From: "Sergio Pérez" <sergio@pereznus.es>
To: Jonathan Cameron <jic23@kernel.org>
Cc: tduszyns@gmail.com, lars@metafoo.de, robh@kernel.org,
conor+dt@kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
krzk+dt@kernel.org
Subject: Re: [PATCH] iio: light: bh1750: Add hardware reset support via GPIO
Date: Tue, 18 Mar 2025 15:35:29 +0100 [thread overview]
Message-ID: <a1ee42f8-56c8-4a77-ab94-e0bb88476cbf@pereznus.es> (raw)
In-Reply-To: <20250317115815.2416c741@jic23-huawei>
[-- Attachment #1: Type: text/plain, Size: 5473 bytes --]
El 17/03/2025 a las 12:58, Jonathan Cameron escribió:
> On Sun, 16 Mar 2025 15:55:13 +0100
> Sergio Perez <sergio@pereznus.es> wrote:
>
>> Some BH1750 sensors require a hardware reset before they can be
>> detected on the I2C bus. This patch adds support for an optional
>> reset GPIO that can be specified in the device tree.
>>
>> The reset sequence pulls the GPIO low and then high before
>> initializing the sensor, which enables proper detection with
>> tools like i2cdetect.
>>
>> Update the devicetree binding documentation to include the new
>> reset-gpios property with examples.
>>
>> Signed-off-by: Sergio Perez <sergio@pereznus.es>
>> ---
>> .../devicetree/bindings/iio/light/bh1750.yaml | 20 +++-
>> drivers/iio/light/bh1750.c | 113 ++++++++++++------
>> 2 files changed, 95 insertions(+), 38 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/light/bh1750.yaml b/Documentation/devicetree/bindings/iio/light/bh1750.yaml
>> index 1a88b3c253d5..d53b221eb84b 100644
>> --- a/Documentation/devicetree/bindings/iio/light/bh1750.yaml
>> +++ b/Documentation/devicetree/bindings/iio/light/bh1750.yaml
>> @@ -11,6 +11,9 @@ maintainers:
>>
>> description: |
>> Ambient light sensor with an i2c interface.
>> +
>> + Some BH1750 sensors require a hardware reset before being properly detected
>> + on the I2C bus. This can be done using the optional reset-gpios property.
> I don't think this detail belongs here. In general we are going to reset
> them all if we have the GPIO.
>
>>
>> properties:
>> compatible:
>> @@ -23,6 +26,10 @@ properties:
>>
>> reg:
>> maxItems: 1
>> +
>> + reset-gpios:
>> + description: GPIO connected to the sensor's reset line (active low)
>> + maxItems: 1
>>
>> required:
>> - compatible
>> @@ -41,5 +48,16 @@ examples:
>> reg = <0x23>;
>> };
>> };
>> + - |
>> + i2c {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + light-sensor@23 {
>> + compatible = "rohm,bh1750";
>> + reg = <0x23>;
>> + reset-gpios = <&gpio2 17 GPIO_ACTIVE_HIGH>;
> Add the GPIO to the existing example rather than having a new one.
Yes, I am going to change it.
>> + };
>> + };
>>
>> -...
>> +...
>> \ No newline at end of file
>> diff --git a/drivers/iio/light/bh1750.c b/drivers/iio/light/bh1750.c
>> index 4b869fa9e5b1..53d64b70c03f 100644
>> --- a/drivers/iio/light/bh1750.c
>> +++ b/drivers/iio/light/bh1750.c
>> @@ -22,11 +22,16 @@
>> #include <linux/iio/iio.h>
>> #include <linux/iio/sysfs.h>
>> #include <linux/module.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/of.h>
> As already pointed out, there is a lot of accidental stuff in here.
>
> I'll review again once that is sorted out. For now I'll ignore it.
> If I weren't on a train and bored, I'd probably just have waited for v2.
>
>
>>
>> -#define BH1750_POWER_DOWN 0x00
>> -#define BH1750_ONE_TIME_H_RES_MODE 0x20 /* auto-mode for BH1721 */
>> -#define BH1750_CHANGE_INT_TIME_H_BIT 0x40
>> -#define BH1750_CHANGE_INT_TIME_L_BIT 0x60
>> +#define BH1750_POWER_DOWN 0x00
>> +#define BH1750_ONE_TIME_H_RES_MODE 0x20 /* auto-mode for BH1721 */
>> +#define BH1750_CHANGE_INT_TIME_H_BIT 0x40
>> +#define BH1750_CHANGE_INT_TIME_L_BIT 0x60
>> +
>> +/* Define the reset delay time in microseconds */
>> +#define BH1750_RESET_DELAY_US 10000 /* 10ms */
>>
>> enum {
>> BH1710,
>> @@ -40,6 +45,7 @@ struct bh1750_data {
>> struct mutex lock;
>> const struct bh1750_chip_info *chip_info;
>> u16 mtreg;
>> + struct gpio_desc *reset_gpio;
>> };
>>
>> struct bh1750_chip_info {
>> @@ -62,11 +68,26 @@ struct bh1750_chip_info {
>>
>> +static int bh1750_reset(struct bh1750_data *data)
>> +{
>> + if (!data->reset_gpio)
> No need to check outside and in here.
>
>> + return 0; /* No GPIO configured for reset, continue */
>> +
>> + /* Perform reset sequence: low-high */
>> + gpiod_set_value_cansleep(data->reset_gpio, 0);
>> + usleep_range(BH1750_RESET_DELAY_US, BH1750_RESET_DELAY_US + 1000);
> fsleep for cases like this where is approximately but greater than X usecs.
>
>> + gpiod_set_value_cansleep(data->reset_gpio, 1);
>> + usleep_range(BH1750_RESET_DELAY_US, BH1750_RESET_DELAY_US + 1000);
> fsleep
>> +
>> + dev_info(&data->client->dev, "BH1750 reset completed via GPIO\n");
> Too noisy. dev_dbg at most for something like this.
>
>> + return 0;
>> +}
>
>> @@ -248,6 +266,19 @@ static int bh1750_probe(struct i2c_client *client)
>> data->client = client;
>> data->chip_info = &bh1750_chip_info_tbl[id->driver_data];
>>
>> + data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
>> + if (IS_ERR(data->reset_gpio)) {
>> + ret = PTR_ERR(data->reset_gpio);
>> + dev_err(&client->dev, "Failed to get reset GPIO: %d\n", ret);
>> + return ret;
> Use return dev_err_probe(). In general good to have because of pretty printing
> errors messages etc, but in this case you might get a deferral request and
> that call adds a bunch of debug info for probe deferal.
>
>> + }
>> +
>> + if (data->reset_gpio) {
>> + ret = bh1750_reset(data);
> There isn't a lot going on in that function, so I'd pull all the code down
> here and not bother with a function at all.
>> + if (ret < 0)
>> + return ret;
>> + }
>> +
Thanks for the suggestions, I rewrote the code with all these points, I
passed the tests again and everything seems correct.
[-- Attachment #2: 0001-iio-light-bh1750-Add-hardware-reset-support-via-GPIO.patch --]
[-- Type: text/plain, Size: 3273 bytes --]
From 2493b60b924fad787098ab2e3f1b9ba9a9a649c1 Mon Sep 17 00:00:00 2001
From: Sergio Perez <sergio@pereznus.es>
Date: Tue, 18 Mar 2025 01:12:05 +0100
Subject: [PATCH] iio: light: bh1750: Add hardware reset support via GPIO
Some BH1750 sensors require a hardware reset before they can be
detected on the I2C bus. This patch adds support for an optional
reset GPIO that can be specified in the device tree.
The reset sequence pulls the GPIO low and then high before
initializing the sensor, which enables proper detection with
tools like i2cdetect.
Update the devicetree binding documentation to include the new
reset-gpios property with examples.
Signed-off-by: Sergio Perez <sergio@pereznus.es>
---
.../devicetree/bindings/iio/light/bh1750.yaml | 5 +++++
drivers/iio/light/bh1750.c | 22 +++++++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/light/bh1750.yaml b/Documentation/devicetree/bindings/iio/light/bh1750.yaml
index 1a88b3c253d5..f7a8dcd7d2a1 100644
--- a/Documentation/devicetree/bindings/iio/light/bh1750.yaml
+++ b/Documentation/devicetree/bindings/iio/light/bh1750.yaml
@@ -24,6 +24,10 @@ properties:
reg:
maxItems: 1
+ reset-gpios:
+ description: GPIO connected to the sensor's reset line (active low)
+ maxItems: 1
+
required:
- compatible
- reg
@@ -39,6 +43,7 @@ examples:
light-sensor@23 {
compatible = "rohm,bh1750";
reg = <0x23>;
+ reset-gpios = <&gpio2 17 0>;
};
};
diff --git a/drivers/iio/light/bh1750.c b/drivers/iio/light/bh1750.c
index 4b869fa9e5b1..b88ce92acbc6 100644
--- a/drivers/iio/light/bh1750.c
+++ b/drivers/iio/light/bh1750.c
@@ -22,12 +22,16 @@
#include <linux/iio/iio.h>
#include <linux/iio/sysfs.h>
#include <linux/module.h>
+#include <linux/gpio/consumer.h>
#define BH1750_POWER_DOWN 0x00
#define BH1750_ONE_TIME_H_RES_MODE 0x20 /* auto-mode for BH1721 */
#define BH1750_CHANGE_INT_TIME_H_BIT 0x40
#define BH1750_CHANGE_INT_TIME_L_BIT 0x60
+/* Define the reset delay time in microseconds */
+#define BH1750_RESET_DELAY_US 10000 /* 10ms */
+
enum {
BH1710,
BH1721,
@@ -40,6 +44,7 @@ struct bh1750_data {
struct mutex lock;
const struct bh1750_chip_info *chip_info;
u16 mtreg;
+ struct gpio_desc *reset_gpio;
};
struct bh1750_chip_info {
@@ -248,6 +253,23 @@ static int bh1750_probe(struct i2c_client *client)
data->client = client;
data->chip_info = &bh1750_chip_info_tbl[id->driver_data];
+ /* Get reset GPIO from device tree */
+ data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(data->reset_gpio))
+ return dev_err_probe(&client->dev, PTR_ERR(data->reset_gpio),
+ "Failed to get reset GPIO\n");
+
+ /* Perform hardware reset if GPIO is provided */
+ if (data->reset_gpio) {
+ /* Perform reset sequence: low-high */
+ gpiod_set_value_cansleep(data->reset_gpio, 0);
+ fsleep(BH1750_RESET_DELAY_US);
+ gpiod_set_value_cansleep(data->reset_gpio, 1);
+ fsleep(BH1750_RESET_DELAY_US);
+
+ dev_dbg(&client->dev, "BH1750 reset completed via GPIO\n");
+ }
+
usec = data->chip_info->mtreg_to_usec * data->chip_info->mtreg_default;
ret = bh1750_change_int_time(data, usec);
if (ret < 0)
--
2.43.0
prev parent reply other threads:[~2025-03-18 14:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250316145514.627-1-sergio@pereznus.es>
[not found] ` <01f48f6d-55a4-4dbe-b1ae-ef8c54dcc1ff@kernel.org>
[not found] ` <64182937-29e9-45dc-aa2f-5f2b739056a1@me.com>
2025-03-18 13:28 ` [PATCH] iio: light: bh1750: Add hardware reset support via GPIO Krzysztof Kozlowski
2025-03-18 14:16 ` Sergio Pérez
2025-03-18 15:16 ` Krzysztof Kozlowski
2025-03-18 16:06 ` Sergio Pérez
2025-03-18 16:21 ` Krzysztof Kozlowski
2025-03-18 16:23 ` Krzysztof Kozlowski
2025-03-18 17:26 ` Sergio Pérez
2025-03-18 17:37 ` Krzysztof Kozlowski
2025-03-18 19:51 ` Sergio Pérez
2025-03-20 7:15 ` Krzysztof Kozlowski
2025-03-19 8:46 ` Krzysztof Kozlowski
2025-03-19 16:26 ` Sergio Pérez
2025-03-20 7:18 ` Krzysztof Kozlowski
[not found] ` <20250317115815.2416c741@jic23-huawei>
2025-03-18 14:35 ` Sergio Pérez [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a1ee42f8-56c8-4a77-ab94-e0bb88476cbf@pereznus.es \
--to=sergio@pereznus.es \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=tduszyns@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox