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

[Raag Jadav]

On Tue, Apr 22, 2025 at 02:42:46PM -0500, Lucas De Marchi wrote:
> 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".

I meant it's worth being informed to be able to target a release correctly
and you don't have to go around explaining each time.

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

With that feel free to add to the series

Reviewed-by: Raag Jadav <raag.jadav at intel.com>