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

[Raag Jadav <raag.jadav@intel.com>]

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

> > > Fixes: dac328dea701 ("drm/xe/hwmon: expose package and vram temperature")
> > > Reported-by: Ulisses Furquim <ulisses.furquim@intel.com>
> > > Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4840
> > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > ---
> > >  Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon
> > > index adbb9bce15a5d..6fbab98fb639d 100644
> > > --- a/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon
> > > +++ b/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon
> > > @@ -111,7 +111,7 @@ Description:	RO. Package current voltage in millivolt.
> > > 
> > >  What:		/sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/temp2_input
> > >  Date:		March 2025
> > > -KernelVersion:	6.14
> > > +KernelVersion:	6.15
> > 
> > Perhaps the date should match the release?
> > https://hansen.beer/~dave/phb/
> 
> from Documentation/ABI/README:
> 
> 	Date:           Date created
> 	KernelVersion:  Kernel version this feature first showed up in.
> 
> I don't think we need to try to predict the exact month a kernel release
> will happen. There would certainly be mistakes. "Date created" can
> simply be interpreted as when the feature merged in our branch and
> doesn't matter much. The more important part is the kernel version.

Perhaps the rules are different across subsystems but sure, makes sense.

Raag