[PATCH v2 0/4] hwmon: Add support for Amphenol ChipCap 2

[PATCH v2 0/4] hwmon: Add support for Amphenol ChipCap 2

[Javier Carrasco]

This series adds support and documentation for the Amphenol ChipCap 2
humidity and temperature sensor in its digital version.

This I2C device provides 14-bit humidity and temperature measurements as
well as low (minimum) and high (maximum) humidity alarms. A ready signal
is also available to reduce delays while fetching data.

The proposed driver implements the logic to perform measurements with
and without the ready signal, EEPROM configuration and alarm signaling.

The features this driver does not support (I2C address and command
window length modification) have been documented in the "Known Issues"
section.

The complete supported functionality has been tested with a CC2D33S
sensor (a 'sleep' device) connected to a Raspberry Pi Zero 2 w.
Different device tree node definitions (with and without regulator,
ready and/or alarm signals) have been positively tested.

The non-sleep measurement mechanism has been inferred from the first
measurement, which is carried out automatically and it is common for all
part numbers. Any testing or improvements with a non-sleep device is
more than welcome.

The tests have also covered the properties added to the hwmon core to
account for minimum and maximum humidity alarms.

Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Changes in v2:
- vendor-prefixes: full company name in the vendor description (Krzystof
  Kozlowski)
- chipcap2.c: proper i2c_device_id table, coding style fixes, cleaner
  error path in the probe function (Krzystof Kozlowski)
- dt-bindings: per-item description and lowercase names (Krzystof
  Kozlowski)
- MAINTAINERS: fix manufacturer name (Krzystof Kozlowski)
- Link to v1: https://lore.kernel.org/r/20231020-topic-chipcap2-v1-0-087e21d4b1ed@gmail.com

---
Javier Carrasco (4):
      dt-bindings: vendor-prefixes: add Amphenol
      hwmon: (core) Add support for humidity min/max alarm
      hwmon: Add support for Amphenol ChipCap 2
      dt-bindings: hwmon: Add Amphenol ChipCap 2

 .../bindings/hwmon/amphenol,chipcap2.yaml          |   68 ++
 .../devicetree/bindings/vendor-prefixes.yaml       |    2 +
 Documentation/hwmon/chipcap2.rst                   |   73 ++
 Documentation/hwmon/index.rst                      |    1 +
 MAINTAINERS                                        |    8 +
 drivers/hwmon/Kconfig                              |   10 +
 drivers/hwmon/Makefile                             |    1 +
 drivers/hwmon/chipcap2.c                           | 1022 ++++++++++++++++++++
 drivers/hwmon/hwmon.c                              |    2 +
 include/linux/hwmon.h                              |    4 +
 10 files changed, 1191 insertions(+)
---
base-commit: ffc253263a1375a65fa6c9f62a893e9767fbebfa
change-id: 20231020-topic-chipcap2-e2d8985430c2

Best regards,
-- 
Javier Carrasco <javier.carrasco.cruz@gmail.com>

[PATCH v2 1/4] dt-bindings: vendor-prefixes: add Amphenol

[Javier Carrasco]

Add vendor prefix for Amphenol (https://www.amphenol-sensors.com)

Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 573578db9509..f12590e88be6 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -103,6 +103,8 @@ patternProperties:
     description: Amlogic, Inc.
   "^ampere,.*":
     description: Ampere Computing LLC
+  "^amphenol,.*":
+    description: Amphenol Advanced Sensors
   "^ampire,.*":
     description: Ampire Co., Ltd.
   "^ams,.*":

-- 
2.39.2

Re: [PATCH v2 1/4] dt-bindings: vendor-prefixes: add Amphenol

[Krzysztof Kozlowski]

On 08/11/2023 16:37, Javier Carrasco wrote:
> Add vendor prefix for Amphenol (https://www.amphenol-sensors.com)
> 
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

[PATCH v2 2/4] hwmon: (core) Add support for humidity min/max alarm

[Javier Carrasco]

Add min_alarm and max_alarm attributes for humidityX to support devices
that can generate these alarms.
Such attributes already exist for other magnitudes such as tempX.

Tested with a ChipCap 2 temperature-humidity sensor.

Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
 drivers/hwmon/hwmon.c | 2 ++
 include/linux/hwmon.h | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index c7dd3f5b2bd5..7f92984c37d9 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -579,8 +579,10 @@ static const char * const hwmon_humidity_attr_templates[] = {
 	[hwmon_humidity_input] = "humidity%d_input",
 	[hwmon_humidity_label] = "humidity%d_label",
 	[hwmon_humidity_min] = "humidity%d_min",
+	[hwmon_humidity_min_alarm] = "humidity%d_min_alarm",
 	[hwmon_humidity_min_hyst] = "humidity%d_min_hyst",
 	[hwmon_humidity_max] = "humidity%d_max",
+	[hwmon_humidity_max_alarm] = "humidity%d_max_alarm",
 	[hwmon_humidity_max_hyst] = "humidity%d_max_hyst",
 	[hwmon_humidity_alarm] = "humidity%d_alarm",
 	[hwmon_humidity_fault] = "humidity%d_fault",
diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
index 8cd6a6b33593..154de35e34ac 100644
--- a/include/linux/hwmon.h
+++ b/include/linux/hwmon.h
@@ -286,8 +286,10 @@ enum hwmon_humidity_attributes {
 	hwmon_humidity_input,
 	hwmon_humidity_label,
 	hwmon_humidity_min,
+	hwmon_humidity_min_alarm,
 	hwmon_humidity_min_hyst,
 	hwmon_humidity_max,
+	hwmon_humidity_max_alarm,
 	hwmon_humidity_max_hyst,
 	hwmon_humidity_alarm,
 	hwmon_humidity_fault,
@@ -299,8 +301,10 @@ enum hwmon_humidity_attributes {
 #define HWMON_H_INPUT			BIT(hwmon_humidity_input)
 #define HWMON_H_LABEL			BIT(hwmon_humidity_label)
 #define HWMON_H_MIN			BIT(hwmon_humidity_min)
+#define HWMON_H_MIN_ALARM		BIT(hwmon_humidity_min_alarm)
 #define HWMON_H_MIN_HYST		BIT(hwmon_humidity_min_hyst)
 #define HWMON_H_MAX			BIT(hwmon_humidity_max)
+#define HWMON_H_MAX_ALARM		BIT(hwmon_humidity_max_alarm)
 #define HWMON_H_MAX_HYST		BIT(hwmon_humidity_max_hyst)
 #define HWMON_H_ALARM			BIT(hwmon_humidity_alarm)
 #define HWMON_H_FAULT			BIT(hwmon_humidity_fault)

-- 
2.39.2

Re: [PATCH v2 2/4] hwmon: (core) Add support for humidity min/max alarm

[Guenter Roeck]

On 11/8/23 07:37, Javier Carrasco wrote:
> Add min_alarm and max_alarm attributes for humidityX to support devices
> that can generate these alarms.
> Such attributes already exist for other magnitudes such as tempX.
> 
> Tested with a ChipCap 2 temperature-humidity sensor.
> 

No objection, but the new attributes also need to be added to the ABI
documentation at
Documentation/ABI/testing/sysfs-class-hwmon and
Documentation/hwmon/sysfs-interface.rst

Which made me notice that humidityX_alarm isn't documented either.
Please document that attribute as well while you are at it.

Thanks,
Guenter

> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
>   drivers/hwmon/hwmon.c | 2 ++
>   include/linux/hwmon.h | 4 ++++
>   2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
> index c7dd3f5b2bd5..7f92984c37d9 100644
> --- a/drivers/hwmon/hwmon.c
> +++ b/drivers/hwmon/hwmon.c
> @@ -579,8 +579,10 @@ static const char * const hwmon_humidity_attr_templates[] = {
>   	[hwmon_humidity_input] = "humidity%d_input",
>   	[hwmon_humidity_label] = "humidity%d_label",
>   	[hwmon_humidity_min] = "humidity%d_min",
> +	[hwmon_humidity_min_alarm] = "humidity%d_min_alarm",
>   	[hwmon_humidity_min_hyst] = "humidity%d_min_hyst",
>   	[hwmon_humidity_max] = "humidity%d_max",
> +	[hwmon_humidity_max_alarm] = "humidity%d_max_alarm",
>   	[hwmon_humidity_max_hyst] = "humidity%d_max_hyst",
>   	[hwmon_humidity_alarm] = "humidity%d_alarm",
>   	[hwmon_humidity_fault] = "humidity%d_fault",
> diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
> index 8cd6a6b33593..154de35e34ac 100644
> --- a/include/linux/hwmon.h
> +++ b/include/linux/hwmon.h
> @@ -286,8 +286,10 @@ enum hwmon_humidity_attributes {
>   	hwmon_humidity_input,
>   	hwmon_humidity_label,
>   	hwmon_humidity_min,
> +	hwmon_humidity_min_alarm,
>   	hwmon_humidity_min_hyst,
>   	hwmon_humidity_max,
> +	hwmon_humidity_max_alarm,
>   	hwmon_humidity_max_hyst,
>   	hwmon_humidity_alarm,
>   	hwmon_humidity_fault,
> @@ -299,8 +301,10 @@ enum hwmon_humidity_attributes {
>   #define HWMON_H_INPUT			BIT(hwmon_humidity_input)
>   #define HWMON_H_LABEL			BIT(hwmon_humidity_label)
>   #define HWMON_H_MIN			BIT(hwmon_humidity_min)
> +#define HWMON_H_MIN_ALARM		BIT(hwmon_humidity_min_alarm)
>   #define HWMON_H_MIN_HYST		BIT(hwmon_humidity_min_hyst)
>   #define HWMON_H_MAX			BIT(hwmon_humidity_max)
> +#define HWMON_H_MAX_ALARM		BIT(hwmon_humidity_max_alarm)
>   #define HWMON_H_MAX_HYST		BIT(hwmon_humidity_max_hyst)
>   #define HWMON_H_ALARM			BIT(hwmon_humidity_alarm)
>   #define HWMON_H_FAULT			BIT(hwmon_humidity_fault)
> 

Re: [PATCH v2 2/4] hwmon: (core) Add support for humidity min/max alarm

[Javier Carrasco]

Hello,

On 09.11.23 01:02, Guenter Roeck wrote:
> On 11/8/23 07:37, Javier Carrasco wrote:
>> Add min_alarm and max_alarm attributes for humidityX to support devices
>> that can generate these alarms.
>> Such attributes already exist for other magnitudes such as tempX.
>>
>> Tested with a ChipCap 2 temperature-humidity sensor.
>>
> 
> No objection, but the new attributes also need to be added to the ABI
> documentation at
> Documentation/ABI/testing/sysfs-class-hwmon and
> Documentation/hwmon/sysfs-interface.rst
> 
> Which made me notice that humidityX_alarm isn't documented either.
> Please document that attribute as well while you are at it.
> 
> Thanks,
> Guenter
> 
Actually there are several attributes without ABI documentation or at
least the attributes enum is much larger than the objects in the ABI
documentation (in testing/sysfs-class-hwmon).
For humidity there is only input, enable, rated_min and rated_max. Are
some attributes not described for a good reason or should all be
documented? the current humidity_attributes contains:

hwmon_humidity_enable -> documented in sysfs-class-hwmon
hwmon_humidity_input -> documented in sysfs-class-hwmon
hwmon_humidity_label
hwmon_humidity_min
hwmon_humidity_min_hyst
hwmon_humidity_max
hwmon_humidity_max_hyst
hwmon_humidity_alarm
hwmon_humidity_fault
hwmon_humidity_rated_min -> documented in sysfs-class-hwmon
hwmon_humidity_rated_max -> documented in sysfs-class-hwmon

I could not find the temperature counterparts of my new additions
(temp_min_alarm and temp_max_alarm).

Should all be added to sysfs-class-hwmon or am I missing some other
document? I am alright adding the ones I mentioned.

>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>> ---
>>   drivers/hwmon/hwmon.c | 2 ++
>>   include/linux/hwmon.h | 4 ++++
>>   2 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
>> index c7dd3f5b2bd5..7f92984c37d9 100644
>> --- a/drivers/hwmon/hwmon.c
>> +++ b/drivers/hwmon/hwmon.c
>> @@ -579,8 +579,10 @@ static const char * const
>> hwmon_humidity_attr_templates[] = {
>>       [hwmon_humidity_input] = "humidity%d_input",
>>       [hwmon_humidity_label] = "humidity%d_label",
>>       [hwmon_humidity_min] = "humidity%d_min",
>> +    [hwmon_humidity_min_alarm] = "humidity%d_min_alarm",
>>       [hwmon_humidity_min_hyst] = "humidity%d_min_hyst",
>>       [hwmon_humidity_max] = "humidity%d_max",
>> +    [hwmon_humidity_max_alarm] = "humidity%d_max_alarm",
>>       [hwmon_humidity_max_hyst] = "humidity%d_max_hyst",
>>       [hwmon_humidity_alarm] = "humidity%d_alarm",
>>       [hwmon_humidity_fault] = "humidity%d_fault",
>> diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
>> index 8cd6a6b33593..154de35e34ac 100644
>> --- a/include/linux/hwmon.h
>> +++ b/include/linux/hwmon.h
>> @@ -286,8 +286,10 @@ enum hwmon_humidity_attributes {
>>       hwmon_humidity_input,
>>       hwmon_humidity_label,
>>       hwmon_humidity_min,
>> +    hwmon_humidity_min_alarm,
>>       hwmon_humidity_min_hyst,
>>       hwmon_humidity_max,
>> +    hwmon_humidity_max_alarm,
>>       hwmon_humidity_max_hyst,
>>       hwmon_humidity_alarm,
>>       hwmon_humidity_fault,
>> @@ -299,8 +301,10 @@ enum hwmon_humidity_attributes {
>>   #define HWMON_H_INPUT            BIT(hwmon_humidity_input)
>>   #define HWMON_H_LABEL            BIT(hwmon_humidity_label)
>>   #define HWMON_H_MIN            BIT(hwmon_humidity_min)
>> +#define HWMON_H_MIN_ALARM        BIT(hwmon_humidity_min_alarm)
>>   #define HWMON_H_MIN_HYST        BIT(hwmon_humidity_min_hyst)
>>   #define HWMON_H_MAX            BIT(hwmon_humidity_max)
>> +#define HWMON_H_MAX_ALARM        BIT(hwmon_humidity_max_alarm)
>>   #define HWMON_H_MAX_HYST        BIT(hwmon_humidity_max_hyst)
>>   #define HWMON_H_ALARM            BIT(hwmon_humidity_alarm)
>>   #define HWMON_H_FAULT            BIT(hwmon_humidity_fault)
>>
> 
Best regards,
Javier Carrasco

Re: [PATCH v2 2/4] hwmon: (core) Add support for humidity min/max alarm

[Guenter Roeck]

On Thu, Nov 09, 2023 at 07:24:00AM +0100, Javier Carrasco wrote:
> Hello,
> 
> On 09.11.23 01:02, Guenter Roeck wrote:
> > On 11/8/23 07:37, Javier Carrasco wrote:
> >> Add min_alarm and max_alarm attributes for humidityX to support devices
> >> that can generate these alarms.
> >> Such attributes already exist for other magnitudes such as tempX.
> >>
> >> Tested with a ChipCap 2 temperature-humidity sensor.
> >>
> > 
> > No objection, but the new attributes also need to be added to the ABI
> > documentation at
> > Documentation/ABI/testing/sysfs-class-hwmon and
> > Documentation/hwmon/sysfs-interface.rst
> > 
> > Which made me notice that humidityX_alarm isn't documented either.
> > Please document that attribute as well while you are at it.
> > 
> > Thanks,
> > Guenter
> > 
> Actually there are several attributes without ABI documentation or at
> least the attributes enum is much larger than the objects in the ABI
> documentation (in testing/sysfs-class-hwmon).
> For humidity there is only input, enable, rated_min and rated_max. Are
> some attributes not described for a good reason or should all be
> documented? the current humidity_attributes contains:
> 
> hwmon_humidity_enable -> documented in sysfs-class-hwmon
> hwmon_humidity_input -> documented in sysfs-class-hwmon
> hwmon_humidity_label
> hwmon_humidity_min
> hwmon_humidity_min_hyst
> hwmon_humidity_max
> hwmon_humidity_max_hyst
> hwmon_humidity_alarm
> hwmon_humidity_fault
> hwmon_humidity_rated_min -> documented in sysfs-class-hwmon
> hwmon_humidity_rated_max -> documented in sysfs-class-hwmon
> 
> I could not find the temperature counterparts of my new additions
> (temp_min_alarm and temp_max_alarm).
> 
> Should all be added to sysfs-class-hwmon or am I missing some other
> document? I am alright adding the ones I mentioned.
> 

They should all be documented. It would be great if you volunteer
to add the missing ones, but that won't be a mandate. I just don't want
the situation to get worse.

Thanks,
Guenter

Re: [PATCH v2 2/4] hwmon: (core) Add support for humidity min/max alarm

[Javier Carrasco]

On 15.11.23 14:25, Guenter Roeck wrote:
> On Thu, Nov 09, 2023 at 07:24:00AM +0100, Javier Carrasco wrote:
>> Hello,
>>
>> On 09.11.23 01:02, Guenter Roeck wrote:
>>> On 11/8/23 07:37, Javier Carrasco wrote:
>>>> Add min_alarm and max_alarm attributes for humidityX to support devices
>>>> that can generate these alarms.
>>>> Such attributes already exist for other magnitudes such as tempX.
>>>>
>>>> Tested with a ChipCap 2 temperature-humidity sensor.
>>>>
>>>
>>> No objection, but the new attributes also need to be added to the ABI
>>> documentation at
>>> Documentation/ABI/testing/sysfs-class-hwmon and
>>> Documentation/hwmon/sysfs-interface.rst
>>>
>>> Which made me notice that humidityX_alarm isn't documented either.
>>> Please document that attribute as well while you are at it.
>>>
>>> Thanks,
>>> Guenter
>>>
>> Actually there are several attributes without ABI documentation or at
>> least the attributes enum is much larger than the objects in the ABI
>> documentation (in testing/sysfs-class-hwmon).
>> For humidity there is only input, enable, rated_min and rated_max. Are
>> some attributes not described for a good reason or should all be
>> documented? the current humidity_attributes contains:
>>
>> hwmon_humidity_enable -> documented in sysfs-class-hwmon
>> hwmon_humidity_input -> documented in sysfs-class-hwmon
>> hwmon_humidity_label
>> hwmon_humidity_min
>> hwmon_humidity_min_hyst
>> hwmon_humidity_max
>> hwmon_humidity_max_hyst
>> hwmon_humidity_alarm
>> hwmon_humidity_fault
>> hwmon_humidity_rated_min -> documented in sysfs-class-hwmon
>> hwmon_humidity_rated_max -> documented in sysfs-class-hwmon
>>
>> I could not find the temperature counterparts of my new additions
>> (temp_min_alarm and temp_max_alarm).
>>
>> Should all be added to sysfs-class-hwmon or am I missing some other
>> document? I am alright adding the ones I mentioned.
>>
> 
> They should all be documented. It would be great if you volunteer
> to add the missing ones, but that won't be a mandate. I just don't want
> the situation to get worse.
> 
> Thanks,
> Guenter

I will document them in a separate series, so the (probably) long review
of the original device driver will not have any effect on this task,
which has nothing to do with the ChipCap 2 anyways.
I will start asap.

Best regards,
Javier Carrasco

[PATCH v2 3/4] hwmon: Add support for Amphenol ChipCap 2

[Javier Carrasco]

The Amphenol 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

This driver adds support for the digital variant (CC2D part numbers),
which is also divided into two subfamilies [1]:
- CC2DXX: non-sleep measurement mode
- CC2DXXS: sleep measurement mode

The only difference between them is that the non-sleep parts carry out
measurements periodically, whereas the sleep counterparts require the
user to trigger each measurement, staying in sleep mode otherwise to
increase power savings.

The Chipcap 2 EEPROM can be accessed to configure a series of parameters
like the minimum/maximum humidity alarm threshold and hysteresis. The
EEPROM is only accessible in the command window after a power-on reset.
The default window lasts 10 ms if no Start_CM command is sent. After the
command window is finished (either after the mentioned timeout of after
a Start_NOM command is sent), the device enters the normal operation
mode and makes a first measurement automatically.

Unfortunately, the device does not provide any hardware or software
reset and therefore the driver must trigger power cycles to enter the
command mode. An external regulator is required for that and if it is
not available, the driver cannot configure the alarms and it must limit
the device operation to humidity and temperature measurements.

Given the high cost of accessing the command mode, an EEPROM read is
made in the probe function and the alarm parameters are stored for
further readings, only accessing the command mode again to overwrite
those parameters.

The measurement process makes use of the ready signal if available,
using maximum delay values from the datasheet otherwise. In non-sleep
mode, a single "data fetch" command is required to read the measurements
and no trigger is required. Sleep devices require an additional
"measurement request" command to trigger the measurement, followed by a
data fetch to retrieve the measured values. In both cases the ready
signal goes high when valid data can be fetched. The ready signal stays
high until the data is retrieved even if further measurements are made.

The minimum and maximum humidity alarms can be configured with two
registers per alarm: one stores the alarm threshold and the other one
keeps the value that turns off the alarm. Note that the second register
stores an absolute value and not the hysteresis. The hysteresis is
therefore obtained as a subtraction of the two registers.
The alarm signals are only updated when a measurement is carried out.
Sleep mode devices will not trigger their alarms until a measurement
is requested.

This driver has been tested with a sleep device and the non-sleep
mechanism has been inferred from the common behavior after power-on
reset explained above, where a first measurement is made without user
intervention. Therefore there is no guarantee that no adjustments in
the measurement function will be required if the driver ever controls
a non-sleep device.

[1] Note that the measurement mode is programmed in the manufacturing
process. The datasheet mentions the name of the register and exact bit
to set the measurement mode, but no addresses are provided and according
to the manufacturer, it is not modifiable by the user.

Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
 Documentation/hwmon/chipcap2.rst |   73 +++
 Documentation/hwmon/index.rst    |    1 +
 MAINTAINERS                      |    8 +
 drivers/hwmon/Kconfig            |   10 +
 drivers/hwmon/Makefile           |    1 +
 drivers/hwmon/chipcap2.c         | 1022 ++++++++++++++++++++++++++++++++++++++
 6 files changed, 1115 insertions(+)

diff --git a/Documentation/hwmon/chipcap2.rst b/Documentation/hwmon/chipcap2.rst
new file mode 100644
index 000000000000..35a968aaac4e
--- /dev/null
+++ b/Documentation/hwmon/chipcap2.rst
@@ -0,0 +1,73 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver ChipCap2
+======================
+
+Supported chips:
+
+  * Amphenol CC2D23, CC2D23S, CC2D25, CC2D25S, CC2D33, CC2D33S, CC2D35, CC2D35S
+
+    Prefix: 'chipcap2'
+
+    Addresses scanned: -
+
+    Datasheet: https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
+
+Author:
+
+  - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+Description
+-----------
+
+This driver implements support for the Amphenol ChipCap 2 chips, a humidity
+and temperature family. Temperature is measured in milli degrees celsius,
+relative humidity is expressed as a per cent mille. The measurement ranges
+are the following:
+
+  - Relative humidity: 0 to 100000 pcm (14-bit resolution)
+  - Temperature: -40000 to +125000 m°C (14-bit resolution)
+
+The device communicates with the I2C protocol and uses the I2C address 0x28
+by default.
+
+Depending on the hardware configuration, up to two humidity alarms to control
+minimum and maximum values are provided. Their thresholds and hystersis can be
+configured via sysfs.
+
+Thresholds and hysteris must be provided as a per cent mille. These values
+might be truncated to match the 14-bit device resolution (6.1 pcm/LSB)
+
+Known Issues
+------------
+
+The driver does not support I2C address and command window length modification.
+
+sysfs-Interface
+---------------
+
+The following list includes the sysfs attributes that the driver always provides,
+their permissions and a short description:
+
+=============================== ======= ========================================
+Name                            Perm    Description
+=============================== ======= ========================================
+temp1_input:                    RO      temperature input
+humidity1_input:                RO      humidity input
+=============================== ======= ========================================
+
+The following list includes the sysfs attributes that the driver may provide
+depending on the hardware configuration:
+
+=============================== ======= ========================================
+Name                            Perm    Description
+=============================== ======= ========================================
+humidity1_min:                  RW      humidity low limit. Measurements under
+                                        this limit trigger a humidity low alarm
+humidity1_max:                  RW      humidity high limit. Measurements above
+                                        this limit trigger a humidity high alarm
+humidity1_min_hyst:             RW      humidity low hystersis
+humidity1_max_hyst:             RW      humidity high hystersis
+humidity1_min_alarm:            RO      humidity low alarm indicator
+humidity1_max_alarm:            RO      humidity high alarm indicator
+=============================== ======= ========================================
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 88dadea85cfc..ddc2d4579f24 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -51,6 +51,7 @@ Hardware Monitoring Kernel Drivers
    bel-pfe
    bpa-rs600
    bt1-pvt
+   chipcap2
    coretemp
    corsair-cpro
    corsair-psu
diff --git a/MAINTAINERS b/MAINTAINERS
index dd5de540ec0b..bf4a066d3628 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1084,6 +1084,14 @@ F:	Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml
 F:	drivers/perf/amlogic/
 F:	include/soc/amlogic/
 
+AMPHENOL CHIPCAP 2 HUMIDITY-TEMPERATURE IIO DRIVER
+M:	Javier Carrasco <javier.carrasco.cruz@gmail.com>
+L:	linux-hwmon@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
+F:	Documentation/hwmon/chipcap2.rst
+F:	drivers/hwmon/chipcap2.c
+
 AMPHION VPU CODEC V4L2 DRIVER
 M:	Ming Qian <ming.qian@nxp.com>
 M:	Zhou Peng <eagle.zhou@nxp.com>
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ec38c8892158..75f67d58e649 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -452,6 +452,16 @@ config SENSORS_BT1_PVT_ALARMS
 	  the data conversion will be periodically performed and the data will be
 	  saved in the internal driver cache.
 
+config SENSORS_CHIPCAP2
+	tristate "Amphenol ChipCap 2 relative humidity and temperature sensor"
+	depends on I2C
+	help
+	  Say yes here to build support for the Amphenol ChipCap 2
+	  relative humidity and temperature sensor.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called chipcap2.
+
 config SENSORS_CORSAIR_CPRO
 	tristate "Corsair Commander Pro controller"
 	depends on HID
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 4ac9452b5430..450ce8fa1d4f 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_SENSORS_ASPEED)	+= aspeed-pwm-tacho.o
 obj-$(CONFIG_SENSORS_ATXP1)	+= atxp1.o
 obj-$(CONFIG_SENSORS_AXI_FAN_CONTROL) += axi-fan-control.o
 obj-$(CONFIG_SENSORS_BT1_PVT)	+= bt1-pvt.o
+obj-$(CONFIG_SENSORS_CHIPCAP2) += chipcap2.o
 obj-$(CONFIG_SENSORS_CORETEMP)	+= coretemp.o
 obj-$(CONFIG_SENSORS_CORSAIR_CPRO) += corsair-cpro.o
 obj-$(CONFIG_SENSORS_CORSAIR_PSU) += corsair-psu.o
diff --git a/drivers/hwmon/chipcap2.c b/drivers/hwmon/chipcap2.c
new file mode 100644
index 000000000000..740e3dcb1352
--- /dev/null
+++ b/drivers/hwmon/chipcap2.c
@@ -0,0 +1,1022 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * cc2.c - Support for the Amphenol ChipCap 2 relative humidity, temperature sensor
+ *
+ * Part numbers supported:
+ * - CC2DXX: digital, non-sleep mode (CC2D23, CC2D25, CC2D33, CC2D35)
+ * - CC2DXXS: digital, sleep mode (CC2D23S, CC2D25S, CC2D33S, CC2D35S)
+ *
+ * Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+ *
+ * Datasheet and application notes:
+ * https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/hwmon.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/regulator/consumer.h>
+
+#define CC2_DEV_NAME "chipcap2"
+
+#define CC2_START_CM			0xA0
+#define CC2_START_NOM			0x80
+#define CC2_R_ALARM_HIGH_ON		0x18
+#define CC2_R_ALARM_HIGH_OFF		0x19
+#define CC2_R_ALARM_LOW_ON		0x1A
+#define CC2_R_ALARM_LOW_OFF		0x1B
+#define CC2_RW_OFFSET			0x40
+#define CC2_W_ALARM_HIGH_ON		(CC2_R_ALARM_HIGH_ON + CC2_RW_OFFSET)
+#define CC2_W_ALARM_HIGH_OFF		(CC2_R_ALARM_HIGH_OFF + CC2_RW_OFFSET)
+#define CC2_W_ALARM_LOW_ON		(CC2_R_ALARM_LOW_ON + CC2_RW_OFFSET)
+#define CC2_W_ALARM_LOW_OFF		(CC2_R_ALARM_LOW_OFF + CC2_RW_OFFSET)
+
+#define CC2_STATUS_FIELD		GENMASK(7, 6)
+#define CC2_STATUS_VALID_DATA		0x00
+#define CC2_STATUS_STALE_DATA		0x01
+#define CC2_STATUS_CMD_MODE		0x02
+
+#define CC2_RESPONSE_FIELD		GENMASK(1, 0)
+#define CC2_RESPONSE_BUSY		0x00
+#define CC2_RESPONSE_ACK		0x01
+#define CC2_RESPONSE_NACK		0x02
+
+#define CC2_ERR_CORR_EEPROM		BIT(2)
+#define CC2_ERR_UNCORR_EEPROM		BIT(3)
+#define CC2_ERR_RAM_PARITY		BIT(4)
+#define CC2_ERR_CONFIG_LOAD		BIT(5)
+
+#define CC2_EEPROM_SIZE			10
+#define CC2_EEPROM_DATA_LEN		3
+#define CC2_MEAS_DATA_LEN		4
+
+#define CC2_RH_DATA_FIELD		GENMASK(13, 0)
+
+#define CC2_POWER_CYCLE_MS		150
+#define CC2_RESP_SLEEP_MS		45
+#define CC2_RESP_START_CM_US		100
+#define CC2_RESP_EEPROM_R_US		100
+#define CC2_RESP_EEPROM_W_MS		12
+#define CC2_STARTUP_TIME_US		1250
+#define CC2_UPDATE_RATE_MS		165
+
+#define CC2_RH_MIN			0
+#define CC2_RH_MAX			(100 * 1000U)
+
+struct cc2_data;
+
+enum cc2_ids {cc2dxx, cc2dxxs};
+
+struct cc2_config {
+	int (*measurement)(struct cc2_data *data,
+			   enum hwmon_sensor_types type,
+			   long *val);
+};
+
+struct cc2_alarm_info {
+	long min;
+	long min_hyst;
+	long max;
+	long max_hyst;
+	bool rh_low;
+	bool rh_high;
+	bool rh_low_visible;
+	bool rh_high_visible;
+};
+
+struct cc2_data {
+	const struct cc2_config *config;
+	struct cc2_alarm_info alarm;
+	struct mutex alarm_lock; /* alarm status lock */
+	struct completion complete;
+	struct device *hwmon;
+	struct i2c_client *client;
+	struct mutex i2c_lock; /* i2c communication lock */
+	struct regulator *regulator;
+	const char *name;
+	int irq_ready;
+	int irq_low;
+	int irq_high;
+	bool ignore_irqs;
+};
+
+enum cc2_chan_addr {
+	CC2_CHAN_TEMP = 0,
+	CC2_CHAN_HUMIDITY,
+};
+
+static long cc2_rh_convert(u16 data)
+{
+	unsigned long tmp = (data & CC2_RH_DATA_FIELD) * CC2_RH_MAX;
+
+	return tmp / ((1 << 14) - 1);
+}
+
+static u16 cc2_rh_to_reg(long data)
+{
+	return data * ((1 << 14) - 1) / CC2_RH_MAX;
+}
+
+static long cc2_rh_in_device_resolution(long data)
+{
+	u16 reg_val;
+
+	reg_val = cc2_rh_to_reg(data);
+
+	return cc2_rh_convert(reg_val);
+}
+
+static long cc2_temp_convert(u16 data)
+{
+	unsigned long tmp = ((data >> 2) * 165 * 1000U) / ((1 << 14) - 1);
+
+	return tmp - 40 * 1000U;
+}
+
+static int cc2_analyze_cmd_response(struct device *dev, u8 status)
+{
+	int resp;
+	int ret;
+
+	if (FIELD_GET(CC2_STATUS_FIELD, status) != CC2_STATUS_CMD_MODE) {
+		dev_dbg(dev, "Command sent out of command window\n");
+		return -ETIMEDOUT;
+	}
+
+	resp = FIELD_GET(CC2_RESPONSE_FIELD, status);
+	switch (resp) {
+	case CC2_RESPONSE_ACK:
+		ret = 0;
+		break;
+	case CC2_RESPONSE_BUSY:
+		ret = -EBUSY;
+		break;
+	case CC2_RESPONSE_NACK:
+		if (resp & CC2_ERR_CORR_EEPROM)
+			dev_dbg(dev, "Command failed: corrected EEPROM\n");
+		if (resp & CC2_ERR_UNCORR_EEPROM)
+			dev_dbg(dev, "Command failed: uncorrected EEPROM\n");
+		if (resp & CC2_ERR_RAM_PARITY)
+			dev_dbg(dev, "Command failed: RAM parity\n");
+		if (resp & CC2_ERR_RAM_PARITY)
+			dev_dbg(dev, "Command failed: configuration error\n");
+		ret = -ENODATA;
+		break;
+	default:
+		dev_dbg(dev, "Unknown command reply\n");
+		ret = -ENODATA;
+		break;
+	}
+
+	return ret;
+}
+
+static int cc2_read_command_status(struct i2c_client *client)
+{
+	u8 status;
+	int ret;
+
+	ret = i2c_master_recv(client, &status, 1);
+	if (ret != 1) {
+		ret = ret < 0 ? ret : -EIO;
+		return ret;
+	}
+
+	return cc2_analyze_cmd_response(&client->dev, status);
+}
+
+static int cc2_clear_data_ready(struct i2c_client *client)
+{
+	u8 data[CC2_MEAS_DATA_LEN];
+	u8 status;
+	int ret;
+
+	ret = i2c_master_recv(client, data, CC2_MEAS_DATA_LEN);
+	if (ret != CC2_MEAS_DATA_LEN) {
+		ret = ret < 0 ? ret : -EIO;
+		return ret;
+	}
+	status = FIELD_GET(CC2_STATUS_FIELD, data[0]);
+	if (status == CC2_STATUS_STALE_DATA)
+		return -EBUSY;
+
+	if (status != CC2_STATUS_VALID_DATA)
+		return -EIO;
+
+	return 0;
+}
+
+/*
+ * The command mode is only accessible after sending the START_CM command in the
+ * first 10 ms after power-up.
+ */
+static int cc2_command_mode_start(struct cc2_data *data)
+{
+	unsigned long timeout;
+	int ret;
+
+	ret = i2c_smbus_write_word_data(data->client, CC2_START_CM, 0);
+	if (ret < 0)
+		return ret;
+
+	if (data->irq_ready > 0) {
+		timeout = usecs_to_jiffies(2 * CC2_RESP_START_CM_US);
+		ret = wait_for_completion_timeout(&data->complete, timeout);
+		if (!ret)
+			return -ETIMEDOUT;
+	} else {
+		usleep_range(CC2_RESP_START_CM_US, 2 * CC2_RESP_START_CM_US);
+	}
+
+	return cc2_read_command_status(data->client);
+}
+
+/* Sending a Start_NOM command finishes the command mode immediately with no
+ * reply and the device enters normal operation mode
+ */
+static int cc2_command_mode_finish(struct cc2_data *data)
+{
+	int ret;
+
+	ret = i2c_smbus_write_word_data(data->client, CC2_START_NOM, 0);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+/* EEPROM registers can only be read in command mode */
+static int cc2_read_eeprom_reg(struct cc2_data *data, u8 cmd, u16 *val)
+{
+	u8 buf[CC2_EEPROM_DATA_LEN];
+	unsigned long timeout;
+	int ret;
+
+	ret = i2c_smbus_write_word_data(data->client, cmd, 0);
+	if (ret < 0)
+		return ret;
+
+	if (data->irq_ready > 0) {
+		timeout = usecs_to_jiffies(2 * CC2_RESP_EEPROM_R_US);
+		ret = wait_for_completion_timeout(&data->complete, timeout);
+		if (!ret)
+			return -ETIMEDOUT;
+	} else {
+		usleep_range(CC2_RESP_EEPROM_R_US, CC2_RESP_EEPROM_R_US + 10);
+	}
+	ret = i2c_master_recv(data->client, buf, CC2_EEPROM_DATA_LEN);
+	if (ret != CC2_EEPROM_DATA_LEN) {
+		ret = ret < 0 ? ret : -EIO;
+		return ret;
+	}
+
+	*val = be16_to_cpup((__be16 *)&buf[1]);
+
+	return cc2_read_command_status(data->client);
+}
+
+static int cc2_write_eeprom_reg(struct cc2_data *data, u8 cmd, u16 val)
+{
+	unsigned long timeout;
+	int ret;
+
+	cpu_to_be16s(&val);
+	ret = i2c_smbus_write_word_data(data->client, cmd, val);
+	if (ret < 0)
+		return ret;
+
+	if (data->irq_ready > 0) {
+		timeout = msecs_to_jiffies(2 * CC2_RESP_EEPROM_W_MS);
+		ret = wait_for_completion_timeout(&data->complete, timeout);
+		if (!ret)
+			return -ETIMEDOUT;
+	} else {
+		msleep(CC2_RESP_EEPROM_W_MS);
+	}
+
+	return cc2_read_command_status(data->client);
+}
+
+/* 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.
+ */
+static int cc2_start_command_window(struct cc2_data *data)
+{
+	int ret;
+
+	/* ignore alarms triggered by voltage toggling during the power cycle */
+	mutex_lock(&data->alarm_lock);
+	data->ignore_irqs = true;
+	mutex_unlock(&data->alarm_lock);
+
+	/* clear any pending completion */
+	try_wait_for_completion(&data->complete);
+
+	if (regulator_is_enabled(data->regulator)) {
+		ret = regulator_disable(data->regulator);
+		if (ret < 0)
+			return ret;
+
+		msleep(CC2_POWER_CYCLE_MS); /* ensure a clean power cycle */
+	}
+
+	ret = regulator_enable(data->regulator);
+	if (ret < 0)
+		return ret;
+
+	/*
+	 * TODO: the startup-delay-us property of the regulator might be
+	 * added to the delay (if provided).
+	 * Currently there is no interface to read its value apart from
+	 * a direct access to regulator->rdev->constraints->enable_time,
+	 * which is discouraged like any direct access to the regulator_dev
+	 * structure. This would be relevant in cases where the startup delay
+	 * is in the range of milliseconds.
+	 */
+	usleep_range(CC2_STARTUP_TIME_US, CC2_STARTUP_TIME_US + 125);
+
+	mutex_lock(&data->alarm_lock);
+	data->ignore_irqs = false;
+	mutex_unlock(&data->alarm_lock);
+
+	return 0;
+}
+
+/*
+ * An EEPROM update requires the following steps:
+ * 1. Power cycle to accept the START_CM command.
+ * 2. STARTM_CM command to enter command mode.
+ * 3. Command(s) to update register(s).
+ * 4. START_NOM command to exit command mode.
+ * After that, the device switches to normal mode and a measurement is
+ * triggered automatically. In order to obtain a recent measurement on demand,
+ * the automatic measurement is dropped.
+ */
+static int cc2_update_eeprom(struct cc2_data *data, u8 *cmd, u16 *val, int len)
+{
+	int i, ret;
+
+	if (!cmd || !val || len > CC2_EEPROM_SIZE)
+		return -EINVAL;
+
+	ret = cc2_start_command_window(data);
+	if (ret < 0)
+		return ret;
+
+	mutex_lock(&data->i2c_lock);
+	ret = cc2_command_mode_start(data);
+	if (ret < 0)
+		goto unlock;
+
+	for (i = 0; i < len; i++) {
+		ret = cc2_write_eeprom_reg(data, *cmd, *val);
+		if (ret < 0) {
+			dev_dbg(&data->client->dev,
+				"Failed to write register %#02x\n", *cmd);
+			goto cmd_finish;
+		}
+		cmd++;
+		val++;
+	}
+
+cmd_finish:
+	ret = cc2_command_mode_finish(data);
+unlock:
+	mutex_unlock(&data->i2c_lock);
+
+	return ret;
+}
+
+/*
+ * EEPROM access is a highly time-consuming task that involves a power cycle.
+ * The alarm-related registers are read once and their values are stored and
+ * updated without further EEPROM accesses.
+ * Probe deferring is used to minimize the risk of missing the command window
+ * if the task is waiting to be executed for too long.
+ */
+static int cc2_read_eeprom_alarm_registers(struct cc2_data *data)
+{
+	u16 val;
+	int ret;
+
+	mutex_lock(&data->i2c_lock);
+	ret = cc2_command_mode_start(data);
+	if (ret < 0) {
+		ret = (ret == -ETIMEDOUT) ? -EPROBE_DEFER : ret;
+		goto unlock;
+	}
+
+	ret = cc2_read_eeprom_reg(data, CC2_R_ALARM_LOW_ON, &val);
+	if (ret < 0)
+		goto unlock;
+
+	data->alarm.min = cc2_rh_convert(val);
+
+	ret = cc2_read_eeprom_reg(data, CC2_R_ALARM_LOW_OFF, &val);
+	if (ret < 0)
+		goto unlock;
+
+	data->alarm.min_hyst = cc2_rh_convert(val) - data->alarm.min;
+
+	ret = cc2_read_eeprom_reg(data, CC2_R_ALARM_HIGH_ON, &val);
+	if (ret < 0)
+		goto unlock;
+
+	data->alarm.max = cc2_rh_convert(val);
+
+	ret = cc2_read_eeprom_reg(data, CC2_R_ALARM_HIGH_OFF, &val);
+	if (ret < 0)
+		goto unlock;
+
+	data->alarm.max_hyst = data->alarm.max - cc2_rh_convert(val);
+
+	ret = cc2_command_mode_finish(data);
+
+unlock:
+	mutex_unlock(&data->i2c_lock);
+
+	return ret;
+}
+
+static int cc2_retrive_alarm_config(struct cc2_data *data)
+{
+	int ret;
+
+	ret = cc2_start_command_window(data);
+	if (ret)
+		return ret;
+
+	return cc2_read_eeprom_alarm_registers(data);
+}
+
+/*
+ * A measurement request must be sent in sleep mode to wake up the device and
+ * start measuring. This request only contains the slave address and the write
+ * bit.
+ */
+static int cc2_measurement_request(struct i2c_client *client)
+{
+	int ret;
+
+	ret = i2c_master_send(client, NULL, 0);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+};
+
+static int cc2_data_fetch(struct i2c_client *client,
+			  enum hwmon_sensor_types type, long *val)
+{
+	u8 data[CC2_MEAS_DATA_LEN];
+	u8 status;
+	int ret;
+
+	ret = i2c_master_recv(client, data, CC2_MEAS_DATA_LEN);
+	if (ret != CC2_MEAS_DATA_LEN) {
+		ret = ret < 0 ? ret : -EIO;
+		return ret;
+	}
+	status = FIELD_GET(CC2_STATUS_FIELD, data[0]);
+	if (status == CC2_STATUS_STALE_DATA)
+		return -EBUSY;
+
+	if (status != CC2_STATUS_VALID_DATA)
+		return -EIO;
+
+	switch (type) {
+	case hwmon_humidity:
+		*val = cc2_rh_convert(be16_to_cpup((__be16 *)&data[0]));
+		break;
+	case hwmon_temp:
+		*val = cc2_temp_convert(be16_to_cpup((__be16 *)&data[2]));
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/*
+ * non sleep-mode devies (cc2dxx variants) make measurements periodically and
+ * indicate valid data with the ready signal, whose level stays high until data
+ * is fetched even if new measurements are made.
+ */
+static int cc2dxx_meas(struct cc2_data *data, enum hwmon_sensor_types type,
+		       long *val)
+{
+	unsigned long timeout;
+	int ret;
+
+	if (data->irq_ready > 0) {
+		if (try_wait_for_completion(&data->complete))
+			goto data_fetch;
+
+		timeout = msecs_to_jiffies(CC2_UPDATE_RATE_MS);
+		ret = wait_for_completion_timeout(&data->complete, timeout);
+		if (!ret)
+			return -ETIMEDOUT;
+	} else {
+		/* check if data is ready and retry for stale data */
+		ret = cc2_data_fetch(data->client, type, val);
+		if (ret != -EBUSY)
+			return ret;
+
+		msleep(CC2_UPDATE_RATE_MS);
+	}
+
+data_fetch:
+	return cc2_data_fetch(data->client, type, val);
+}
+
+/*
+ * sleep-mode devies (cc2dxxs variants) require a measurement request command to
+ * wake up the device and trigger a measurement. Then a data fetch command is
+ * sent to retrieve the measured values.
+ */
+static int cc2dxxs_meas(struct cc2_data *data, enum hwmon_sensor_types type,
+			long *val)
+{
+	unsigned long timeout;
+	int ret;
+
+	if (data->irq_ready > 0) {
+		/*
+		 * the device carries out a first measurement after entering
+		 * measurement mode automatically. To avoid outdated values,
+		 * a new request is made
+		 */
+		if (try_wait_for_completion(&data->complete)) {
+			ret = cc2_clear_data_ready(data->client);
+			if (ret < 0)
+				return ret;
+		}
+
+		ret = cc2_measurement_request(data->client);
+		if (ret < 0)
+			return ret;
+
+		timeout = msecs_to_jiffies(2 * CC2_RESP_SLEEP_MS);
+		ret = wait_for_completion_timeout(&data->complete, timeout);
+		if (!ret)
+			return -ETIMEDOUT;
+	} else {
+		ret = cc2_measurement_request(data->client);
+		if (ret < 0)
+			return ret;
+
+		msleep(CC2_RESP_SLEEP_MS);
+	}
+
+	return cc2_data_fetch(data->client, type, val);
+}
+
+static umode_t cc2_is_visible(const void *data, enum hwmon_sensor_types type,
+			      u32 attr, int channel)
+{
+	const struct cc2_data *cc2 = data;
+
+	switch (type) {
+	case hwmon_humidity:
+		switch (attr) {
+		case hwmon_humidity_input:
+			return 0444;
+		case hwmon_humidity_min_alarm:
+			return cc2->alarm.rh_low_visible ? 0444 : 0;
+		case hwmon_humidity_max_alarm:
+			return cc2->alarm.rh_high_visible ? 0444 : 0;
+		case hwmon_humidity_min:
+		case hwmon_humidity_min_hyst:
+			return cc2->alarm.rh_low_visible ? 0644 : 0;
+		case hwmon_humidity_max:
+		case hwmon_humidity_max_hyst:
+			return cc2->alarm.rh_high_visible ? 0644 : 0;
+		default:
+			return 0;
+		}
+	case hwmon_temp:
+		switch (attr) {
+		case hwmon_temp_input:
+			return 0444;
+		default:
+			return 0;
+		}
+	default:
+		break;
+	}
+
+	return 0;
+}
+
+static irqreturn_t cc2_ready_interrupt(int irq, void *data)
+{
+	struct cc2_data *cc2 = data;
+
+	mutex_lock(&cc2->alarm_lock);
+	if (!cc2->ignore_irqs)
+		complete(&cc2->complete);
+	mutex_unlock(&cc2->alarm_lock);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t cc2_low_interrupt(int irq, void *data)
+{
+	struct cc2_data *cc2 = data;
+
+	mutex_lock(&cc2->alarm_lock);
+	if (!cc2->ignore_irqs) {
+		hwmon_notify_event(cc2->hwmon, hwmon_humidity,
+				   hwmon_humidity_min_alarm, CC2_CHAN_HUMIDITY);
+		cc2->alarm.rh_low = true;
+	}
+	mutex_unlock(&cc2->alarm_lock);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t cc2_high_interrupt(int irq, void *data)
+{
+	struct cc2_data *cc2 = data;
+
+	mutex_lock(&cc2->alarm_lock);
+	if (!cc2->ignore_irqs) {
+		hwmon_notify_event(cc2->hwmon, hwmon_humidity,
+				   hwmon_humidity_max_alarm, CC2_CHAN_HUMIDITY);
+		cc2->alarm.rh_high = true;
+	}
+	mutex_unlock(&cc2->alarm_lock);
+
+	return IRQ_HANDLED;
+}
+
+static int cc2_humidity_min_alarm_status(struct cc2_data *data, long *val)
+{
+	long meas;
+	int ret;
+
+	mutex_lock(&data->i2c_lock);
+	ret = data->config->measurement(data, hwmon_humidity, &meas);
+	mutex_unlock(&data->i2c_lock);
+	if (ret < 0)
+		return ret;
+
+	mutex_lock(&data->alarm_lock);
+	if (data->alarm.rh_low) {
+		*val = (meas < data->alarm.min + data->alarm.min_hyst) ? 1 : 0;
+		data->alarm.rh_low = *val;
+	} else {
+		*val = 0;
+	}
+	mutex_unlock(&data->alarm_lock);
+
+	return 0;
+}
+
+static int cc2_humidity_max_alarm_status(struct cc2_data *data, long *val)
+{
+	long meas;
+	int ret;
+
+	mutex_lock(&data->i2c_lock);
+	ret = data->config->measurement(data, hwmon_humidity, &meas);
+	mutex_unlock(&data->i2c_lock);
+	if (ret < 0)
+		return ret;
+
+	mutex_lock(&data->alarm_lock);
+	if (data->alarm.rh_high) {
+		*val = (meas > data->alarm.max - data->alarm.max_hyst) ? 1 : 0;
+		data->alarm.rh_high = *val;
+	} else {
+		*val = 0;
+	}
+	mutex_unlock(&data->alarm_lock);
+
+	return 0;
+}
+
+static int cc2_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+		    int channel, long *val)
+{
+	struct cc2_data *data = dev_get_drvdata(dev);
+	int ret;
+
+	switch (type) {
+	case hwmon_temp:
+		mutex_lock(&data->i2c_lock);
+		ret = data->config->measurement(data, type, val);
+		mutex_unlock(&data->i2c_lock);
+		break;
+	case hwmon_humidity:
+		switch (attr) {
+		case hwmon_humidity_input:
+			mutex_lock(&data->i2c_lock);
+			ret = data->config->measurement(data, type, val);
+			mutex_unlock(&data->i2c_lock);
+			break;
+		case hwmon_humidity_min:
+			*val = data->alarm.min;
+			break;
+		case hwmon_humidity_min_hyst:
+			*val = data->alarm.min_hyst;
+			break;
+		case hwmon_humidity_max:
+			*val = data->alarm.max;
+			break;
+		case hwmon_humidity_max_hyst:
+			*val = data->alarm.max_hyst;
+			break;
+		case hwmon_humidity_min_alarm:
+			ret = cc2_humidity_min_alarm_status(data, val);
+			if (ret < 0)
+				return -EIO;
+			break;
+		case hwmon_humidity_max_alarm:
+			ret = cc2_humidity_max_alarm_status(data, val);
+			if (ret < 0)
+				return -EIO;
+			break;
+		default:
+			return -EOPNOTSUPP;
+		}
+		break;
+	default:
+		return -EOPNOTSUPP;
+	}
+
+	return ret;
+}
+
+static int cc2_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+		     int channel, long val)
+{
+	struct cc2_data *data = dev_get_drvdata(dev);
+	u8 cmd[CC2_EEPROM_SIZE];
+	u16 arg[CC2_EEPROM_SIZE];
+	int ret;
+
+	if (type != hwmon_humidity)
+		return -EOPNOTSUPP;
+
+	switch (attr) {
+	case hwmon_humidity_min:
+		if (val < CC2_RH_MIN || val > CC2_RH_MAX)
+			return -EINVAL;
+
+		cmd[0] = CC2_W_ALARM_LOW_ON;
+		arg[0] = cc2_rh_to_reg(val);
+		/* alarm low off must be updated to keep the hysteresis */
+		cmd[1] = CC2_W_ALARM_LOW_OFF;
+		arg[1] = cc2_rh_to_reg(val + data->alarm.min_hyst);
+		ret = cc2_update_eeprom(data, cmd, arg, 2);
+		if (ret < 0)
+			return ret;
+
+		data->alarm.min = cc2_rh_in_device_resolution(val);
+		break;
+	case hwmon_humidity_min_hyst:
+		if (val < CC2_RH_MIN || val + data->alarm.min > CC2_RH_MAX)
+			return -EINVAL;
+
+		cmd[0] = CC2_W_ALARM_LOW_OFF;
+		arg[0] = cc2_rh_to_reg(data->alarm.min + val);
+		ret = cc2_update_eeprom(data, cmd, arg, 1);
+		if (ret < 0)
+			return ret;
+
+		data->alarm.min_hyst = cc2_rh_in_device_resolution(val);
+		break;
+	case hwmon_humidity_max:
+		if (val < CC2_RH_MIN || val > CC2_RH_MAX)
+			return -EINVAL;
+
+		cmd[0] = CC2_W_ALARM_HIGH_ON;
+		arg[0] = cc2_rh_to_reg(val);
+		/* alarm high off must be updated to keep the hysteresis */
+		cmd[1] = CC2_W_ALARM_HIGH_OFF;
+		arg[1] = cc2_rh_to_reg(val - data->alarm.max_hyst);
+		ret = cc2_update_eeprom(data, cmd, arg, 2);
+		if (ret < 0)
+			return ret;
+
+		data->alarm.max = cc2_rh_in_device_resolution(val);
+		break;
+	case hwmon_humidity_max_hyst:
+		if (val < CC2_RH_MIN || data->alarm.max - val < CC2_RH_MIN)
+			return -EINVAL;
+
+		cmd[0] = CC2_W_ALARM_HIGH_OFF;
+		arg[0] = cc2_rh_to_reg(data->alarm.max - val);
+		ret = cc2_update_eeprom(data, cmd, arg, 1);
+		if (ret < 0)
+			return ret;
+
+		data->alarm.max_hyst = cc2_rh_in_device_resolution(val);
+		break;
+	default:
+		return -EOPNOTSUPP;
+	}
+
+	return 0;
+}
+
+static int cc2_disable(struct cc2_data *data)
+{
+	int ret = 0;
+
+	if (data->regulator && regulator_is_enabled(data->regulator))
+		ret = regulator_disable(data->regulator);
+
+	return ret;
+}
+
+static int cc2_request_ready_irq(struct cc2_data *data, struct device *dev)
+{
+	int ret = 0;
+
+	data->irq_ready = fwnode_irq_get_byname(dev_fwnode(dev), "ready");
+	if (data->irq_ready > 0) {
+		init_completion(&data->complete);
+		ret = devm_request_threaded_irq(dev, data->irq_ready, NULL,
+						cc2_ready_interrupt,
+						IRQF_ONESHOT |
+						IRQF_TRIGGER_RISING,
+						dev_name(dev), data);
+	}
+
+	return ret;
+}
+
+static int cc2_request_alarm_irqs(struct cc2_data *data, struct device *dev)
+{
+	int ret;
+
+	data->irq_low = fwnode_irq_get_byname(dev_fwnode(dev), "low");
+	if (data->irq_low > 0) {
+		ret = devm_request_threaded_irq(dev, data->irq_low, NULL,
+						cc2_low_interrupt,
+						IRQF_ONESHOT |
+						IRQF_TRIGGER_RISING,
+						dev_name(dev), data);
+		if (!ret)
+			data->alarm.rh_low_visible = true;
+	}
+
+	data->irq_high = fwnode_irq_get_byname(dev_fwnode(dev), "high");
+	if (data->irq_high > 0) {
+		ret = devm_request_threaded_irq(dev, data->irq_high, NULL,
+						cc2_high_interrupt,
+						IRQF_ONESHOT |
+						IRQF_TRIGGER_RISING,
+						dev_name(dev), data);
+		if (!ret)
+			data->alarm.rh_high_visible = true;
+	}
+
+	return ret;
+}
+
+static const struct hwmon_channel_info *cc2_info[] = {
+	HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
+	HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT | HWMON_H_MIN | HWMON_H_MAX |
+			   HWMON_H_MIN_HYST | HWMON_H_MAX_HYST |
+			   HWMON_H_MIN_ALARM | HWMON_H_MAX_ALARM),
+	NULL
+};
+
+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 cc2_config[] = {
+	[cc2dxx] = {
+		.measurement = cc2dxx_meas,
+	},
+	[cc2dxxs] = {
+		.measurement = cc2dxxs_meas,
+	},
+};
+
+static const struct i2c_device_id cc2_id[] = {
+	{ "cc2dxx", cc2dxx },
+	{ "cc2dxxs", cc2dxxs },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, cc2_id);
+
+static const struct of_device_id cc2_of_match[] = {
+	{
+		.compatible = "amphenol,cc2dxx",
+		.data = (void *)cc2dxx,
+	},
+	{
+		.compatible = "amphenol,cc2dxxs",
+		.data = (void *)cc2dxxs,
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, cc2_of_match);
+
+static int cc2_probe(struct i2c_client *client)
+{
+	struct cc2_data *data;
+	struct device *dev = &client->dev;
+	enum cc2_ids chip;
+	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;
+
+	if (client->dev.of_node)
+		chip = (uintptr_t)of_device_get_match_data(&client->dev);
+	else
+		chip = i2c_match_id(cc2_id, client)->driver_data;
+
+	data->config = &cc2_config[chip];
+
+	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 */
+		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)) {
+		ret = PTR_ERR(data->hwmon);
+		goto cleanup;
+	}
+
+	return 0;
+
+cleanup:
+	if (cc2_disable(data))
+		dev_dbg(dev, "Failed to disable device");
+
+	return dev_err_probe(dev, ret,
+			     "Unable to register hwmon device\n");
+}
+
+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 struct i2c_driver cc2_driver = {
+	.driver = {
+		.name	= CC2_DEV_NAME,
+		.of_match_table = cc2_of_match,
+	},
+	.probe		= cc2_probe,
+	.remove		= cc2_remove,
+};
+module_i2c_driver(cc2_driver);
+
+MODULE_AUTHOR("Javier Carrasco <javier.carrasco.cruz@gamil.com>");
+MODULE_DESCRIPTION("Amphenol ChipCap 2 humidity and temperature sensor driver");
+MODULE_LICENSE("GPL");

-- 
2.39.2

Re: [PATCH v2 3/4] hwmon: Add support for Amphenol ChipCap 2

[Krzysztof Kozlowski]

On 08/11/2023 16:37, Javier Carrasco wrote:
> The Amphenol 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
> 
> This driver adds support for the digital variant (CC2D part numbers),
> which is also divided into two subfamilies [1]:
> - CC2DXX: non-sleep measurement mode
> - CC2DXXS: sleep measurement mode

...

> +
> +static int cc2_probe(struct i2c_client *client)
> +{
> +	struct cc2_data *data;
> +	struct device *dev = &client->dev;
> +	enum cc2_ids chip;
> +	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;
> +
> +	if (client->dev.of_node)
> +		chip = (uintptr_t)of_device_get_match_data(&client->dev);
> +	else
> +		chip = i2c_match_id(cc2_id, client)->driver_data;
> +
> +	data->config = &cc2_config[chip];
> +
> +	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 */
> +		goto dev_register;

Nothing improved here.

Do not send new version of patchset before discussion finishes.

> +	}
> +
> +	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)) {
> +		ret = PTR_ERR(data->hwmon);
> +		goto cleanup;
> +	}
> +
> +	return 0;
> +
> +cleanup:
> +	if (cc2_disable(data))
> +		dev_dbg(dev, "Failed to disable device");
> +
> +	return dev_err_probe(dev, ret,
> +			     "Unable to register hwmon device\n");

Drop or move to each error path.



Best regards,
Krzysztof

Re: [PATCH v2 3/4] hwmon: Add support for Amphenol ChipCap 2

[Guenter Roeck]

On 11/9/23 00:52, Krzysztof Kozlowski wrote:
> On 08/11/2023 16:37, Javier Carrasco wrote:
>> The Amphenol 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
>>
>> This driver adds support for the digital variant (CC2D part numbers),
>> which is also divided into two subfamilies [1]:
>> - CC2DXX: non-sleep measurement mode
>> - CC2DXXS: sleep measurement mode
> 
> ...
> 
>> +
>> +static int cc2_probe(struct i2c_client *client)
>> +{
>> +	struct cc2_data *data;
>> +	struct device *dev = &client->dev;
>> +	enum cc2_ids chip;
>> +	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;
>> +
>> +	if (client->dev.of_node)
>> +		chip = (uintptr_t)of_device_get_match_data(&client->dev);
>> +	else
>> +		chip = i2c_match_id(cc2_id, client)->driver_data;
>> +
>> +	data->config = &cc2_config[chip];
>> +
>> +	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);

fwiw, s/retrive/retrieve/g

>> +		if (ret)
>> +			goto cleanup;
>> +	} else {
>> +		/* No access to EEPROM without regulator: no alarm control */
>> +		goto dev_register;
> 
> Nothing improved here.
> 
> Do not send new version of patchset before discussion finishes.
> 

This driver will take a while to review due to its complexity.

As for the code above: Error handling goes first. Something like
the above, where the error case is just a goto, is unacceptable and
just increases indentation level for the other code and makes it
more difficult to read. Also, the above code _will_ have to handle
error cases other than -ENODEV. Besides deferred probe, it is
completely inappropriate to ignore -EINVAL or -ENOMEM or any other
error codes other than -ENODEV.

>> +	}
>> +
>> +	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)) {
>> +		ret = PTR_ERR(data->hwmon);
>> +		goto cleanup;
>> +	}
>> +
>> +	return 0;
>> +
>> +cleanup:
>> +	if (cc2_disable(data))
>> +		dev_dbg(dev, "Failed to disable device");
>> +
>> +	return dev_err_probe(dev, ret,
>> +			     "Unable to register hwmon device\n");
> 
> Drop or move to each error path.
> 
This actually follows Documentation/process/coding-style.rst, chapter 7
(Centralized exiting of functions).

Guenter

Re: [PATCH v2 3/4] hwmon: Add support for Amphenol ChipCap 2

[Javier Carrasco]

On 09.11.23 15:55, Guenter Roeck wrote:
> On 11/9/23 00:52, Krzysztof Kozlowski wrote:
>> On 08/11/2023 16:37, Javier Carrasco wrote:
>>> The Amphenol 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
>>>
>>> This driver adds support for the digital variant (CC2D part numbers),
>>> which is also divided into two subfamilies [1]:
>>> - CC2DXX: non-sleep measurement mode
>>> - CC2DXXS: sleep measurement mode
>>
>> ...
>>
>>> +
>>> +static int cc2_probe(struct i2c_client *client)
>>> +{
>>> +    struct cc2_data *data;
>>> +    struct device *dev = &client->dev;
>>> +    enum cc2_ids chip;
>>> +    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;
>>> +
>>> +    if (client->dev.of_node)
>>> +        chip = (uintptr_t)of_device_get_match_data(&client->dev);
>>> +    else
>>> +        chip = i2c_match_id(cc2_id, client)->driver_data;
>>> +
>>> +    data->config = &cc2_config[chip];
>>> +
>>> +    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);
> 
> fwiw, s/retrive/retrieve/g
ack.
> 
>>> +        if (ret)
>>> +            goto cleanup;
>>> +    } else {
>>> +        /* No access to EEPROM without regulator: no alarm control */
>>> +        goto dev_register;
>>
>> Nothing improved here.
>>
>> Do not send new version of patchset before discussion finishes.
>>
> 
> This driver will take a while to review due to its complexity.
That is absolutely ok. I will wait for a few days to gather more
feedback and hopefully send less versions.
> 
> As for the code above: Error handling goes first. Something like
> the above, where the error case is just a goto, is unacceptable and
> just increases indentation level for the other code and makes it
> more difficult to read. Also, the above code _will_ have to handle
> error cases other than -ENODEV. Besides deferred probe, it is
> completely inappropriate to ignore -EINVAL or -ENOMEM or any other
> error codes other than -ENODEV.
> 
The probe function will return from errors other than -ENODEV directly
with no goto and checking them first.
I just need to skip the alarm registration for -ENODEV and do the
cleanup if an error occurs after enabling the regulator to keep
enable/disable parity.
>>> +    }
>>> +
>>> +    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)) {
>>> +        ret = PTR_ERR(data->hwmon);
>>> +        goto cleanup;
>>> +    }
>>> +
>>> +    return 0;
>>> +
>>> +cleanup:
>>> +    if (cc2_disable(data))
>>> +        dev_dbg(dev, "Failed to disable device");
>>> +
>>> +    return dev_err_probe(dev, ret,
>>> +                 "Unable to register hwmon device\n");
>>
>> Drop or move to each error path.
>>
> This actually follows Documentation/process/coding-style.rst, chapter 7
> (Centralized exiting of functions).
> 
> Guenter
> 
Thanks for your comments.

Best regards,
Javier Carrasco

Re: [PATCH v2 3/4] hwmon: Add support for Amphenol ChipCap 2

[Krzysztof Kozlowski]

On 09/11/2023 15:55, Guenter Roeck wrote:
>>> +	if (IS_ERR(data->hwmon)) {
>>> +		ret = PTR_ERR(data->hwmon);
>>> +		goto cleanup;
>>> +	}
>>> +
>>> +	return 0;
>>> +
>>> +cleanup:
>>> +	if (cc2_disable(data))
>>> +		dev_dbg(dev, "Failed to disable device");
>>> +
>>> +	return dev_err_probe(dev, ret,
>>> +			     "Unable to register hwmon device\n");
>>
>> Drop or move to each error path.
>>
> This actually follows Documentation/process/coding-style.rst, chapter 7
> (Centralized exiting of functions).

The point is that centralized message of error is useless. Probe failure
is already handled by core, thus another message doing the same is
redundant. What is needed to explain the true reason of failure, thus
the error message should be next to each type of failure. Missing
regulator? Say it. Missing clock? Say something else.

Best regards,
Krzysztof

Re: [PATCH v2 3/4] hwmon: Add support for Amphenol ChipCap 2

[Guenter Roeck]

On 11/9/23 08:18, Krzysztof Kozlowski wrote:
> On 09/11/2023 15:55, Guenter Roeck wrote:
>>>> +	if (IS_ERR(data->hwmon)) {
>>>> +		ret = PTR_ERR(data->hwmon);
>>>> +		goto cleanup;
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +
>>>> +cleanup:
>>>> +	if (cc2_disable(data))
>>>> +		dev_dbg(dev, "Failed to disable device");
>>>> +
>>>> +	return dev_err_probe(dev, ret,
>>>> +			     "Unable to register hwmon device\n");
>>>
>>> Drop or move to each error path.
>>>
>> This actually follows Documentation/process/coding-style.rst, chapter 7
>> (Centralized exiting of functions).
> 
> The point is that centralized message of error is useless. Probe failure
> is already handled by core, thus another message doing the same is
> redundant. What is needed to explain the true reason of failure, thus
> the error message should be next to each type of failure. Missing
> regulator? Say it. Missing clock? Say something else.
> 

Agreed, you have a point.

Thanks,
Guenter

[PATCH v2 4/4] dt-bindings: hwmon: Add Amphenol ChipCap 2

[Javier Carrasco]

Add device tree bindings and an example for the ChipCap 2 humidity
and temperature sensor.

Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
 .../bindings/hwmon/amphenol,chipcap2.yaml          | 68 ++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
new file mode 100644
index 000000000000..8bb6daa293d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/amphenol,chipcap2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChipCap 2 humidity and temperature iio sensor
+
+maintainers:
+  - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+description: |
+  Relative humidity and temperature sensor on I2C bus.
+
+  Datasheets:
+    https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
+
+properties:
+  compatible:
+    enum:
+      - amphenol,cc2dxx
+      - amphenol,cc2dxxs
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    items:
+      - description: measurement ready indicator
+      - description: low humidity alarm
+      - description: high humidity alarm
+
+  interrupt-names:
+    items:
+      - const: ready
+      - const: low
+      - const: high
+
+  vdd-supply:
+    description:
+      Dedicated, controllable supply-regulator to reset the device and
+      enter in command mode.
+      If not defined, no alarms will be available.
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        humidity@28 {
+            compatible = "amphenol,cc2dxxs";
+            reg = <0x28>;
+            interrupt-parent = <&gpio>;
+            interrupts = <4 IRQ_TYPE_EDGE_RISING>,
+                         <5 IRQ_TYPE_EDGE_RISING>,
+                         <6 IRQ_TYPE_EDGE_RISING>;
+            interrupt-names = "ready", "low", "high";
+            vdd-supply = <&reg_vdd>;
+        };
+    };

-- 
2.39.2

Re: [PATCH v2 4/4] dt-bindings: hwmon: Add Amphenol ChipCap 2

[Krzysztof Kozlowski]

On 08/11/2023 16:37, Javier Carrasco wrote:
> Add device tree bindings and an example for the ChipCap 2 humidity
> and temperature sensor.
> 
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
>  .../bindings/hwmon/amphenol,chipcap2.yaml          | 68 ++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> new file mode 100644
> index 000000000000..8bb6daa293d3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> @@ -0,0 +1,68 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/amphenol,chipcap2.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ChipCap 2 humidity and temperature iio sensor
> +
> +maintainers:
> +  - Javier Carrasco <javier.carrasco.cruz@gmail.com>
> +
> +description: |
> +  Relative humidity and temperature sensor on I2C bus.
> +
> +  Datasheets:
> +    https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
> +
> +properties:
> +  compatible:
> +    enum:
> +      - amphenol,cc2dxx
> +      - amphenol,cc2dxxs
> +

Nothing improved.

Really, you just ignored the review.

Best regards,
Krzysztof

Re: [PATCH v2 4/4] dt-bindings: hwmon: Add Amphenol ChipCap 2

[Javier Carrasco]

On 09.11.23 09:53, Krzysztof Kozlowski wrote:
> On 08/11/2023 16:37, Javier Carrasco wrote:
>> Add device tree bindings and an example for the ChipCap 2 humidity
>> and temperature sensor.
>>
>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>> ---
>>  .../bindings/hwmon/amphenol,chipcap2.yaml          | 68 ++++++++++++++++++++++
>>  1 file changed, 68 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
>> new file mode 100644
>> index 000000000000..8bb6daa293d3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
>> @@ -0,0 +1,68 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/hwmon/amphenol,chipcap2.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: ChipCap 2 humidity and temperature iio sensor
>> +
>> +maintainers:
>> +  - Javier Carrasco <javier.carrasco.cruz@gmail.com>
>> +
>> +description: |
>> +  Relative humidity and temperature sensor on I2C bus.
>> +
>> +  Datasheets:
>> +    https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - amphenol,cc2dxx
>> +      - amphenol,cc2dxxs
>> +
> 
> Nothing improved.
> 
> Really, you just ignored the review.
> 
> Best regards,
> Krzysztof
> 
I am sorry if I missed something from your first review. I changed the
interrupt description to have one per item as you suggested and removed
the empty line. I did not change the compatible enum to add all part
numbers because it was still under discussion, but now that I know that
I have to add all of them, I will change for the next version.

Best regards,
Javier Carrasco

Re: [PATCH v2 4/4] dt-bindings: hwmon: Add Amphenol ChipCap 2

[Krzysztof Kozlowski]

On 09/11/2023 10:02, Javier Carrasco wrote:
> 
> 
> On 09.11.23 09:53, Krzysztof Kozlowski wrote:
>> On 08/11/2023 16:37, Javier Carrasco wrote:
>>> Add device tree bindings and an example for the ChipCap 2 humidity
>>> and temperature sensor.
>>>
>>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>>> ---
>>>  .../bindings/hwmon/amphenol,chipcap2.yaml          | 68 ++++++++++++++++++++++
>>>  1 file changed, 68 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
>>> new file mode 100644
>>> index 000000000000..8bb6daa293d3
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
>>> @@ -0,0 +1,68 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/hwmon/amphenol,chipcap2.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: ChipCap 2 humidity and temperature iio sensor
>>> +
>>> +maintainers:
>>> +  - Javier Carrasco <javier.carrasco.cruz@gmail.com>
>>> +
>>> +description: |
>>> +  Relative humidity and temperature sensor on I2C bus.
>>> +
>>> +  Datasheets:
>>> +    https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - amphenol,cc2dxx
>>> +      - amphenol,cc2dxxs
>>> +
>>
>> Nothing improved.
>>
>> Really, you just ignored the review.
>>
>> Best regards,
>> Krzysztof
>>
> I am sorry if I missed something from your first review. I changed the
> interrupt description to have one per item as you suggested and removed
> the empty line. I did not change the compatible enum to add all part
> numbers because it was still under discussion, but now that I know that
> I have to add all of them, I will change for the next version.

And a new patch should not be sent while discussion happens. Literally I
had no chances to respond to your comment and v2 appears.

Best regards,
Krzysztof

Re: [PATCH v2 4/4] dt-bindings: hwmon: Add Amphenol ChipCap 2

[Javier Carrasco]

On 09.11.23 10:20, Krzysztof Kozlowski wrote:
> On 09/11/2023 10:02, Javier Carrasco wrote:
>>
>>
>> On 09.11.23 09:53, Krzysztof Kozlowski wrote:
>>> On 08/11/2023 16:37, Javier Carrasco wrote:
>>>> Add device tree bindings and an example for the ChipCap 2 humidity
>>>> and temperature sensor.
>>>>
>>>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>>>> ---
>>>>  .../bindings/hwmon/amphenol,chipcap2.yaml          | 68 ++++++++++++++++++++++
>>>>  1 file changed, 68 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
>>>> new file mode 100644
>>>> index 000000000000..8bb6daa293d3
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
>>>> @@ -0,0 +1,68 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/hwmon/amphenol,chipcap2.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: ChipCap 2 humidity and temperature iio sensor
>>>> +
>>>> +maintainers:
>>>> +  - Javier Carrasco <javier.carrasco.cruz@gmail.com>
>>>> +
>>>> +description: |
>>>> +  Relative humidity and temperature sensor on I2C bus.
>>>> +
>>>> +  Datasheets:
>>>> +    https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - amphenol,cc2dxx
>>>> +      - amphenol,cc2dxxs
>>>> +
>>>
>>> Nothing improved.
>>>
>>> Really, you just ignored the review.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>> I am sorry if I missed something from your first review. I changed the
>> interrupt description to have one per item as you suggested and removed
>> the empty line. I did not change the compatible enum to add all part
>> numbers because it was still under discussion, but now that I know that
>> I have to add all of them, I will change for the next version.
> 
> And a new patch should not be sent while discussion happens. Literally I
> had no chances to respond to your comment and v2 appears.
> 
> Best regards,
> Krzysztof
> 
You are right, there is a lot to review and I should have gathered more
feedback. I will wait a few days to receive more input and in the
meantime I will add all part numbers (there is eight of them, which is
manageable) to the documentation and the device tables. Wildcards and
families will be dropped.

Thank for your feedback and best regards,
Javier Carrasco

Re: [PATCH v2 4/4] dt-bindings: hwmon: Add Amphenol ChipCap 2

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3085 bytes --]

On Thu, Nov 09, 2023 at 10:25:39AM +0100, Javier Carrasco wrote:
> 
> 
> On 09.11.23 10:20, Krzysztof Kozlowski wrote:
> > On 09/11/2023 10:02, Javier Carrasco wrote:
> >>
> >>
> >> On 09.11.23 09:53, Krzysztof Kozlowski wrote:
> >>> On 08/11/2023 16:37, Javier Carrasco wrote:
> >>>> Add device tree bindings and an example for the ChipCap 2 humidity
> >>>> and temperature sensor.
> >>>>
> >>>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> >>>> ---
> >>>>  .../bindings/hwmon/amphenol,chipcap2.yaml          | 68 ++++++++++++++++++++++
> >>>>  1 file changed, 68 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> >>>> new file mode 100644
> >>>> index 000000000000..8bb6daa293d3
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> >>>> @@ -0,0 +1,68 @@
> >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>>> +%YAML 1.2
> >>>> +---
> >>>> +$id: http://devicetree.org/schemas/hwmon/amphenol,chipcap2.yaml#
> >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>> +
> >>>> +title: ChipCap 2 humidity and temperature iio sensor
> >>>> +
> >>>> +maintainers:
> >>>> +  - Javier Carrasco <javier.carrasco.cruz@gmail.com>
> >>>> +
> >>>> +description: |
> >>>> +  Relative humidity and temperature sensor on I2C bus.
> >>>> +
> >>>> +  Datasheets:
> >>>> +    https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
> >>>> +
> >>>> +properties:
> >>>> +  compatible:
> >>>> +    enum:
> >>>> +      - amphenol,cc2dxx
> >>>> +      - amphenol,cc2dxxs
> >>>> +
> >>>
> >>> Nothing improved.
> >>>
> >>> Really, you just ignored the review.
> >>>
> >>> Best regards,
> >>> Krzysztof
> >>>
> >> I am sorry if I missed something from your first review. I changed the
> >> interrupt description to have one per item as you suggested and removed
> >> the empty line. I did not change the compatible enum to add all part
> >> numbers because it was still under discussion, but now that I know that
> >> I have to add all of them, I will change for the next version.
> > 
> > And a new patch should not be sent while discussion happens. Literally I
> > had no chances to respond to your comment and v2 appears.
> > 
> > Best regards,
> > Krzysztof
> > 
> You are right, there is a lot to review and I should have gathered more
> feedback. I will wait a few days to receive more input and in the
> meantime I will add all part numbers (there is eight of them, which is
> manageable) to the documentation and the device tables. Wildcards and
> families will be dropped.

I'm not sure what was said in the prior feedback, but it would be
possible, if any of these devices have an identical programming model,
is allow one of their compatibles in isolation and use that compatible
as a fallback for all other devices that have an identical or compatible
programming model.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]