linux-kernel - Re: [PATCH v4] drm/i915/hwmon: expose fan speed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZsVkapETDCTtx2_F@black.fi.intel.com>
Date: Wed, 21 Aug 2024 06:52:10 +0300
From: Raag Jadav <raag.jadav@...el.com>
To: Rodrigo Vivi <rodrigo.vivi@...el.com>
Cc: Andi Shyti <andi.shyti@...ux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	jani.nikula@...ux.intel.com, joonas.lahtinen@...ux.intel.com,
	tursulin@...ulin.net, airlied@...il.com, daniel@...ll.ch,
	linux@...ck-us.net, intel-gfx@...ts.freedesktop.org,
	dri-devel@...ts.freedesktop.org, linux-hwmon@...r.kernel.org,
	linux-kernel@...r.kernel.org, anshuman.gupta@...el.com,
	badal.nilawar@...el.com, riana.tauro@...el.com,
	ashutosh.dixit@...el.com, karthik.poosa@...el.com
Subject: Re: [PATCH v4] drm/i915/hwmon: expose fan speed

On Tue, Aug 20, 2024 at 05:49:23PM -0400, Rodrigo Vivi wrote:
> 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 this why we have 'Link' as part of commit which points to
actual ML submission?

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

Can still be available below '---' marker.

Raag