devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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).