[PATCH v4] drm/i915/hwmon: expose fan speed

[Rodrigo Vivi]

On Tue, Aug 20, 2024 at 12:00:27PM +0300, Raag Jadav wrote:
> On Fri, Aug 09, 2024 at 12:57:54PM +0100, Andi Shyti wrote:
> > On Fri, Aug 09, 2024 at 02:48:08PM +0300, Andy Shevchenko wrote:
> > > On Fri, Aug 09, 2024 at 11:45:25AM +0530, Raag Jadav wrote:
> > > > Add hwmon support for fan1_input attribute, which will expose fan speed
> > > > in RPM. With this in place we can monitor fan speed using lm-sensors tool.
> > > > 
> > > > $ sensors
> > > > i915-pci-0300
> > > > Adapter: PCI adapter
> > > > in0:         653.00 mV
> > > > fan1:        3833 RPM
> > > > power1:           N/A  (max =  43.00 W)
> > > > energy1:      32.02 kJ
> > > 
> > > > v2:
> > > > - Add mutex protection
> > > > - Handle overflow
> > > > - Add ABI documentation
> > > > - Aesthetic adjustments (Riana)
> > > > 
> > > > v3:
> > > > - Declare rotations as "long" and drop redundant casting
> > > > - Change date and version in ABI documentation
> > > > - Add commenter name in changelog (Riana)
> > > > 
> > > > v4:
> > > > - Fix wakeref leak
> > > > - Drop switch case and simplify hwm_fan_xx() (Andi)
> > > 
> > > I do not understand why we pollute Git history with changelogs, but it's
> > > probably the ugly atavism in DRM workflow.
> > 
> > I never liked it! Besides it should even be against the
> > submitting patches recommendation.
> > 
> > I don't understand what interest might have someone in a couple
> > of years, reading this commit, knowing an unintellegible list of
> > differences between v2 and v3.
> > 
> > I consider it a random pollution of the commit log.

I agree it is ugly. But I don't agree it is just a 'random polution'.

I consider a valid and very useful information of the patch history.
Very useful for a later cross check to know what exactly version
of that patch got merged.
Useful for distros on backports as well.

> 
> Isn't it already documented?
> Documentation/process/submitting-patches.rst

I think it is:

"Be sure to tell the reviewers what changes you are making and to thank them
 for their time.  Code review is a tiring and time-consuming process, and
 reviewers sometimes get grumpy.  Even in that case, though, respond
 politely and address the problems they have pointed out.  When sending a next
 version, add a ``patch changelog`` to the cover letter or to individual patches
 explaining difference against previous submission
"

Then:

'''
Example of a patch submitted by the From: author::
'''

defines 'changelog' as the block above the signatures.

And

'The canonical patch format'

also tells that anything after '---' marker line is for
"Any additional comments not suitable for the changelog."

But well, the important part is to have the version information
available for reviewers. Let's try to focus on that instead on
visual preferences.

> 
> Please put this information **after** the ``---`` line which separates
> the changelog from the rest of the patch. The version information is
> not part of the changelog which gets committed to the git tree. It is
> additional information for the reviewers. If it's placed above the
> commit tags, it needs manual interaction to remove it. If it is below
> the separator line, it gets automatically stripped off when applying the
> patch::
> 
>   <commit message>
>   ...
>   Signed-off-by: Author <author at mail>
>   ---
>   V2 -> V3: Removed redundant helper function
>   V1 -> V2: Cleaned up coding style and addressed review comments
> 
>   path/to/file | 5+++--
>   ...
> 
> Raag
> > 
> > Andi