From: Vincent Jardin <vjardin@free.fr>

Both properties are missing, so a board that supplies either fails with
dtbs_check:

  fan-controller@2c (microchip,emc2305): '#cooling-cells', 'vcc-supply'
  do not match any of the regexes: '^fan@[0-4]$', '^pinctrl-[0-9]+$'

The #cooling-cells property belongs to the controller node, which is
where the driver actually registers.

Two cells is what that registration needs: a cooling-maps entry
references the fan as <&emc2305 min max>.

Two cells also documents what the driver supports today. The
pwm-separate path registers one cooling device per PWM against the same
node, and they all get cdev_id 0, so no cell count can tell them apart.
That is a driver issue, noted here but not addressed.

The examples in this binding put that property on the fan@N subnodes
instead, which does not match what the driver does: they are left alone
here rather than changed blind.

vcc-supply describes the chip's own rail, which matters on boards where
the sensor sits behind a switched supply.

Signed-off-by: Vincent Jardin <vjardin@free.fr>
---
 Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
index 8c2548539d7fd..47640214de100 100644
--- a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
+++ b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
@@ -44,6 +44,11 @@ properties:
            - 0 (Open-Drain)
            - 1 (Push-Pull)
 
+  vcc-supply: true
+
+  "#cooling-cells":
+    const: 2
+
 patternProperties:
   '^fan@[0-4]$':
     $ref: fan-common.yaml#

---
base-commit: 0a0d1d55dad570724bf8c7ea83409639cfb4be9b
change-id: 20260824-for-upstream-dt-emc2305-vcc-cooling-251655c99ef8

Best regards,
-- 
Vincent Jardin <vjardin@free.fr>

On Mon, Aug 24, 2026 at 05:42:59PM +0200, Vincent Jardin via B4 Relay wrote:
> From: Vincent Jardin <vjardin@free.fr>
> 
> Both properties are missing, so a board that supplies either fails with
> dtbs_check:
> 
>   fan-controller@2c (microchip,emc2305): '#cooling-cells', 'vcc-supply'
>   do not match any of the regexes: '^fan@[0-4]$', '^pinctrl-[0-9]+$'
> 
> The #cooling-cells property belongs to the controller node, which is
> where the driver actually registers.
> 
> Two cells is what that registration needs: a cooling-maps entry
> references the fan as <&emc2305 min max>.
> 
> Two cells also documents what the driver supports today. The
> pwm-separate path registers one cooling device per PWM against the same
> node, and they all get cdev_id 0, so no cell count can tell them apart.
> That is a driver issue, noted here but not addressed.
> 
> The examples in this binding put that property on the fan@N subnodes
> instead, which does not match what the driver does: they are left alone
> here rather than changed blind.

That seems correct though and putting it in the device node when there's 4
fans that could interact with different zones seems wrong. Shouldn't the
driver be fixed instead?

> vcc-supply describes the chip's own rail, which matters on boards where
> the sensor sits behind a switched supply.
> 
> Signed-off-by: Vincent Jardin <vjardin@free.fr>
> ---
>  Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
> index 8c2548539d7fd..47640214de100 100644
> --- a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
> @@ -44,6 +44,11 @@ properties:
>             - 0 (Open-Drain)
>             - 1 (Push-Pull)
>  
> +  vcc-supply: true
> +
> +  "#cooling-cells":
> +    const: 2
> +
>  patternProperties:
>    '^fan@[0-4]$':
>      $ref: fan-common.yaml#
> 
> ---
> base-commit: 0a0d1d55dad570724bf8c7ea83409639cfb4be9b
> change-id: 20260824-for-upstream-dt-emc2305-vcc-cooling-251655c99ef8
> 
> Best regards,
> -- 
> Vincent Jardin <vjardin@free.fr>
> 
> 

Hi Conor,

> That seems correct though and putting it in the device node when there's 4
> fans that could interact with different zones seems wrong. Shouldn't the
> driver be fixed instead?

Hmm, I did re-read again the code and I am wrong.

I withdraw the patch instead of sending a v2.

Sorry for the noise,
  Vincent

On 8/24/26 10:00, Conor Dooley wrote:
> On Mon, Aug 24, 2026 at 05:42:59PM +0200, Vincent Jardin via B4 Relay wrote:
>> From: Vincent Jardin <vjardin@free.fr>
>>
>> Both properties are missing, so a board that supplies either fails with
>> dtbs_check:
>>
>>    fan-controller@2c (microchip,emc2305): '#cooling-cells', 'vcc-supply'
>>    do not match any of the regexes: '^fan@[0-4]$', '^pinctrl-[0-9]+$'
>>
>> The #cooling-cells property belongs to the controller node, which is
>> where the driver actually registers.
>>
>> Two cells is what that registration needs: a cooling-maps entry
>> references the fan as <&emc2305 min max>.
>>
>> Two cells also documents what the driver supports today. The
>> pwm-separate path registers one cooling device per PWM against the same
>> node, and they all get cdev_id 0, so no cell count can tell them apart.
>> That is a driver issue, noted here but not addressed.
>>
>> The examples in this binding put that property on the fan@N subnodes
>> instead, which does not match what the driver does: they are left alone
>> here rather than changed blind.
> 
> That seems correct though and putting it in the device node when there's 4
> fans that could interact with different zones seems wrong. Shouldn't the
> driver be fixed instead?
> 

I am a bit (or, rather, more than a bit) concerned about Sashiko's feedback:

New issues:
- [Medium] The commit message makes materially false claims about the driver's
   device tree parsing logic to justify leaving the binding examples unchanged.

Guenter

>> vcc-supply describes the chip's own rail, which matters on boards where
>> the sensor sits behind a switched supply.
>>
>> Signed-off-by: Vincent Jardin <vjardin@free.fr>
>> ---
>>   Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
>> index 8c2548539d7fd..47640214de100 100644
>> --- a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
>> +++ b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
>> @@ -44,6 +44,11 @@ properties:
>>              - 0 (Open-Drain)
>>              - 1 (Push-Pull)
>>   
>> +  vcc-supply: true
>> +
>> +  "#cooling-cells":
>> +    const: 2
>> +
>>   patternProperties:
>>     '^fan@[0-4]$':
>>       $ref: fan-common.yaml#
>>
>> ---
>> base-commit: 0a0d1d55dad570724bf8c7ea83409639cfb4be9b
>> change-id: 20260824-for-upstream-dt-emc2305-vcc-cooling-251655c99ef8
>>
>> Best regards,
>> -- 
>> Vincent Jardin <vjardin@free.fr>
>>
>>

Hi Guenter,

> I am a bit (or, rather, more than a bit) concerned about Sashiko's feedback:
> 
> New issues:
> - [Medium] The commit message makes materially false claims about the driver's
>   device tree parsing logic to justify leaving the binding examples unchanged.

Sashiko is right on it ! I did miss read the code.

Best regards,
  Vincent