Message-ID: <24ee4bf3-aa91-483d-a9be-5c47e5c37ed7@roeck-us.net>
Date: Wed, 28 Feb 2024 08:03:22 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Paul Menzel <pmenzel@...gen.mpg.de>
Cc: Ban Feng <baneric926@...il.com>, jdelvare@...e.com, robh+dt@...nel.org,
 krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, corbet@....net,
 linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
 kcfeng0@...oton.com, kwliu@...oton.com, openbmc@...ts.ozlabs.org,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 DELPHINE_CHIU@...ynn.com, naresh.solanki@...ements.com,
 billy_tsai@...eedtech.com
Subject: Re: [PATCH v4 3/3] hwmon: Driver for Nuvoton NCT7363Y

On 2/28/24 03:03, Paul Menzel wrote:
> Dear Guenter,
> 
> 
> Am 28.02.24 um 10:03 schrieb Guenter Roeck:
>> On 2/27/24 23:57, Paul Menzel wrote:
> 
>>> Am 27.02.24 um 01:56 schrieb baneric926@...il.com:
>>>> From: Ban Feng <kcfeng0@...oton.com>
>>>>
>>>> NCT7363Y is an I2C based hardware monitoring chip from Nuvoton.
>>>
>>> Please reference the datasheet.
>>
>> Note that something like
>>
>> Datasheet: Available from Nuvoton upon request
>>
>> is quite common for hardware monitoring chips and acceptable.
> 
> Yes, it would be nice to document it though. (And finally for vendors to just make them available for download.)
> 

Nuvoton is nice enough and commonly makes datasheets available on request.
The only exception I have seen so far is where they were forced into an NDA
by a large chip and board vendor, which prevented them from publishing a
specific datasheet.

Others are much worse. Many PMIC vendors don't publish their datasheets at
all, and sometimes chips don't even officially exist (notorious for chips
intended for the automotive market). Just look at the whole discussion
around MAX31335.

Anyway, there are lots of examples in Documentation/hwmon/. I don't see
the need to add further documentation, and I specifically don't want to
make it official that "Datasheet not public" is acceptable as well.
We really don't have a choice unless we want to exclude a whole class
of chips from the kernel, but that doesn't make it better.

>>> Could you please give a high level description of the driver design?
>>
>> Can you be more specific ? I didn't have time yet to look into details,
>> but at first glance this looks like a standard hardware monitoring driver.
>> One could argue that the high level design of such drivers is described
>> in Documentation/hwmon/hwmon-kernel-api.rst.
>>
>> I don't usually ask for a additional design information for hwmon drivers
>> unless some chip interaction is unusual and needs to be explained,
>> and then I prefer to have it explained in the code. Given that, I am
>> quite curious and would like to understand what you are looking for.
> For a 10+ lines commit, in my opinion the commit message should say something about the implementation. Even it is just, as you wrote, a note, that it follows the standard design.
> 

Again, I have not looked into the submission, but usually we ask for that
to be documented in Documentation/hwmon/. I find that much better than
a soon-to-be-forgotten commit message. I don't mind something like
"The NCT7363Y is a fan controller with up to 16 independent fan input
  monitors and up to 16 independent PWM outputs. It also supports up
  to 16 GPIO pins"
or in other words a description of the chip, not the implementation.
That a driver hwmon driver uses the hardware monitoring API seems to be
obvious to me, so I don't see the value of adding it to the commit
description. I would not mind having something there, but I don't
see it as mandatory.

On the  other side, granted, that is just _my_ personal opinion.
Do we have a common guideline for what exactly should be in commit
descriptions for driver submissions ? I guess I should look that up.

Thanks,
Guenter

Powered by blists - more mailing lists