[PATCH 1/2] drm/xe/hwmon: Fix kernel version documentation for temperature

[Lucas De Marchi]

On Tue, Apr 22, 2025 at 10:34:32AM +0300, Raag Jadav wrote:
>On Mon, Apr 21, 2025 at 02:53:00PM -0500, Lucas De Marchi wrote:
>> On Mon, Apr 21, 2025 at 08:13:13PM +0300, Raag Jadav wrote:
>> > On Mon, Apr 21, 2025 at 08:15:38AM -0700, Lucas De Marchi wrote:
>> > > Wrong copy and paste from other entries: these are starting to be
>> > > supported with 6.15.
>> >
>> > I had an impression that we follow the upstream drm tree, but it seems not?
>>
>> This is a simplified diagram on how it propagates to a X.Y kernel release:
>>
>>                                                (a)
>>         drm-xe/drm-xe-next  ->  drm/drm-next   ->  linus/master
>>                         |                      (b)      |
>>                         `---->  drm/drm-fixes  ->       `- <X.Y-rc1>
>>                         `---->  drm/drm-fixes  ->       `- <X.Y-rc2>
>>                                                         `- ...
>>                                                         `- <X.Y>
>>
>> 	(a) 2-weeks merge window
>> 	(b) weekly fixes propagation
>>
>> We always first merge it to drm-xe-next, but depending on when we merge
>> it, a **feature** may be targeting different kernel releases. As a rule of
>> thumb, a -next branch always target either the next kernel release or
>> next+1 in case current is already on ~ rc6. Fixes target the current or
>> next release (depending if the current has the bug or not).
>
>Yes, which makes targeting a release a bit fuzzy for the patches being
>merged around -rc6 (unless we have a hard cut-off rule that I'm not
>familiar with?).
>
>Side node: This is definitely worth being somewhere in
>https://dri.freedesktop.org/docs/drm/process/index.html

This page is not related to drm though: it's just the html-rendering of
the entire kernel docs. Also, I don't see any other subsystem/tree
detailing the "path to Linus".

>(atleast for the folks who are new to drm)
>
>> This sysfs documentation is for the end user and userspace developer: they
>> have now idea (and shouldn't have) of any branch propagation in the
>> kernel to get to a release. This propagation is not even stable across
>> the different subsystems in the kernel.
>
>Sure, so perhaps reflect this in the commit message?
>I know we do it for other cases but being accused of copy paste doesn't
>feel right :(

This is wrong for any subsystem and not only drm. If it was not a copy &
paste mistake as I assumed, I can write something else in the commit
message. Please don't view it as me accusing you of anything: it's just
the most common mistake and I assumed it was the case for missing it in
both instances. Would it be better like below?

	The version in the sysfs attribute should correspond to the version in
	which this is enabled and visible for end users. It usually doesn't
	correspond to the version in which the patch was developed, but rather
	a release that will contain it.

Lucas De Marchi