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
