From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Jean Delvare <jdelvare@suse.com>,
Guenter Roeck <linux@roeck-us.net>,
Jonathan Corbet <corbet@lwn.net>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH 3/4] hwmon: Add support for Amphenol ChipCap 2
Date: Wed, 8 Nov 2023 17:35:36 +0100 [thread overview]
Message-ID: <285ec1d8-d277-403c-961f-3de523fc799f@gmail.com> (raw)
In-Reply-To: <e58cdedb-1825-4713-9d3f-5239bb182230@linaro.org>
On 08.11.23 13:41, Krzysztof Kozlowski wrote:
> On 08/11/2023 13:29, Javier Carrasco wrote:
>> The Telaire ChipCap 2 is a capacitive polymer humidity and temperature
>> sensor with an integrated EEPROM and minimum/maximum humidity alarms.
>>
>> All device variants offer an I2C interface and depending on the part
>> number, two different output modes:
>> - CC2D: digital output
>> - CC2A: analog (PDM) output
>
> Thank you for your patch. There is something to discuss/improve.
>
>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index dd5de540ec0b..63361104469f 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -21572,6 +21572,14 @@ F: Documentation/devicetree/bindings/media/i2c/ti,ds90*
>> F: drivers/media/i2c/ds90*
>> F: include/media/i2c/ds90*
>>
>> +TI CHIPCAP 2 HUMIDITY-TEMPERATURE IIO DRIVER
>
> Why this is TI?
>
> Bindings say Amphenol. Subject as well. Commit msg says Telaire. Here
> you write Texas Instruments.
>
> Three different companies used. How possibly we could understand this?
>
>
>> +M: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>> +L: linux-hwmon@vger.kernel.org
>> +S: Maintained
>
> ...
>
>> +
>> +/* Command mode is only accessible in the first 10 ms after power-up, but the
>> + * device does not provide any kind of reset. In order to access the command
>> + * mode during normal operation, a power cycle must be triggered.
>> + */
>
>
> Please use full comment style, as described in Coding Style document.
>
> ...
>
>> +
>> +static const struct hwmon_ops cc2_hwmon_ops = {
>> + .is_visible = cc2_is_visible,
>> + .read = cc2_read,
>> + .write = cc2_write,
>> +};
>> +
>> +static const struct hwmon_chip_info cc2_chip_info = {
>> + .ops = &cc2_hwmon_ops,
>> + .info = cc2_info,
>> +};
>> +
>> +static const struct cc2_config cc2dxx_config = {
>> + .measurement = cc2dxx_meas,
>> +};
>> +
>> +static const struct cc2_config cc2dxxs_config = {
>> + .measurement = cc2dxxs_meas,
>> +};
>> +
>> +static const struct of_device_id cc2_of_match[] = {
>> + { .compatible = "amphenol,cc2dxx",
>> + .data = &cc2dxx_config,
>> + },
>> + { .compatible = "amphenol,cc2dxxs",
>
> Format it as in other sources. Don't introduce your own codings style.
>
>> + .data = &cc2dxxs_config,
>> + },
>> + {}
>> +};
>> +MODULE_DEVICE_TABLE(of, cc2_of_match);
>
> Keep ID tables together.
>
>> +
>> +static int cc2_probe(struct i2c_client *client)
>> +{
>> + struct cc2_data *data;
>> + struct device *dev = &client->dev;
>> + const struct of_device_id *match;
>> + int ret;
>> +
>> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
>> + return -EOPNOTSUPP;
>> +
>> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>> + if (!data)
>> + return -ENOMEM;
>> +
>> + i2c_set_clientdata(client, data);
>> +
>> + mutex_init(&data->i2c_lock);
>> + mutex_init(&data->alarm_lock);
>> +
>> + data->client = client;
>> +
>> + match = i2c_of_match_device(cc2_of_match, client);
>> + if (!match)
>> + return -ENODEV;
>> +
>> + data->config = match->data;
>> +
>> + ret = cc2_request_ready_irq(data, dev);
>> + if (ret)
>> + return ret;
>> +
>> + data->regulator = devm_regulator_get_optional(dev, "vdd");
>> + if (!IS_ERR(data->regulator)) {
>> + ret = cc2_retrive_alarm_config(data);
>> + if (ret)
>> + goto cleanup;
>> + } else {
>> + /* No access to EEPROM without regulator: no alarm control */
>
> Test your code with deferred probe. Are you sure you handle it
> correctly? To me, it looks like you handle deferred probe the same as
> any error.
>
The -EPROBE_DEFER is propagated to the probe function and it is the
returned value. I clarified the error path in v2 so no error messages
are displayed in that case, going directly to the dev_err_probe in the
probe cleanup.
When the EPROBE_DEFER error is returned, the probe function is deferred
and called again later on, which is the desired behavior.
>> + goto dev_register;
>> + }
>> +
>> + ret = cc2_request_alarm_irqs(data, dev);
>> + if (ret)
>> + goto cleanup;
>> +
>> +dev_register:
>> + data->hwmon = devm_hwmon_device_register_with_info(dev, client->name,
>> + data, &cc2_chip_info,
>> + NULL);
>> + if (IS_ERR(data->hwmon))
>> + return dev_err_probe(dev, PTR_ERR(data->hwmon),
>> + "Unable to register hwmon device\n");
>> +
>> + return 0;
>> +
>> +cleanup:
>> + if (cc2_disable(data))
>> + dev_dbg(dev, "Failed to disable device");
>> +
>> + return ret;
>> +}
>> +
>> +static void cc2_remove(struct i2c_client *client)
>> +{
>> + struct cc2_data *data = i2c_get_clientdata(client);
>> + int ret = cc2_disable(data);
>> +
>> + if (ret)
>> + dev_dbg(&client->dev, "Failed to disable device");
>> +}
>> +
>> +static const struct i2c_device_id cc2_id[] = { { "chipcap2", 0 }, {} };
>
> Use style like in other files.
> git grep i2c_device_id
>
> BTW, having mismatched entries looks error-prone. Why do you even need
> i2c_device_id if it is not matching of_device_id?
>
> Best regards,
> Krzysztof
>
next prev parent reply other threads:[~2023-11-08 16:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 12:29 [PATCH 0/4] hwmon: Add support for Amphenol ChipCap 2 Javier Carrasco
2023-11-08 12:29 ` [PATCH 1/4] dt-bindings: vendor-prefixes: add Amphenol Javier Carrasco
2023-11-08 12:31 ` Krzysztof Kozlowski
2023-11-08 12:29 ` [PATCH 2/4] hwmon: (core) Add support for humidity min/max alarm Javier Carrasco
2023-11-08 12:29 ` [PATCH 3/4] hwmon: Add support for Amphenol ChipCap 2 Javier Carrasco
2023-11-08 12:41 ` Krzysztof Kozlowski
2023-11-08 16:35 ` Javier Carrasco [this message]
2023-11-09 8:40 ` Krzysztof Kozlowski
2023-11-09 8:59 ` Javier Carrasco
2023-11-09 9:35 ` Krzysztof Kozlowski
2023-11-09 9:52 ` Javier Carrasco
2023-11-09 10:23 ` Krzysztof Kozlowski
2023-11-08 12:29 ` [PATCH 4/4] dt-bindings: hwmon: Add " Javier Carrasco
2023-11-08 12:34 ` Krzysztof Kozlowski
2023-11-08 12:44 ` Javier Carrasco
2023-11-09 8:41 ` Krzysztof Kozlowski
2023-11-09 14:47 ` Guenter Roeck
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=285ec1d8-d277-403c-961f-3de523fc799f@gmail.com \
--to=javier.carrasco.cruz@gmail.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=jdelvare@suse.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).