WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[gregkh]

The patch below was submitted to be applied to the 5.8-stable tree.

I fail to see how this patch meets the stable kernel rules as found at
Documentation/process/stable-kernel-rules.rst.

I could be totally wrong, and if so, please respond to 
<stable@vger.kernel.org> and let me know why this patch should be
applied.  Otherwise, it is now dropped from my patch queues, never to be
seen again.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 1d8d42ba365101fa68d210c0e2ed2bc9582fda6c Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Fri, 5 Jun 2020 15:57:50 +0200
Subject: [PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header
 file
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
removed the implementation of mgag200_mmap(). Also remove the declaration.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Fixes: 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Cc: Armijn Hemel <armijn@tjaldur.nl>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: <stable@vger.kernel.org> # v5.3+
Link: https://patchwork.freedesktop.org/patch/msgid/20200605135803.19811-2-tzimmermann@suse.de

diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 47df62b1ad29..92b6679029fe 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -198,6 +198,5 @@ void mgag200_i2c_destroy(struct mga_i2c_chan *i2c);
 
 int mgag200_mm_init(struct mga_device *mdev);
 void mgag200_mm_fini(struct mga_device *mdev);
-int mgag200_mmap(struct file *filp, struct vm_area_struct *vma);
 
 #endif				/* __MGAG200_DRV_H__ */

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[Vivi, Rodrigo]

> On Aug 10, 2020, at 5:49 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> On Sat, Aug 08, 2020 at 05:24:53PM +0200, Daniel Vetter wrote:
>> On Sat, Aug 8, 2020 at 1:28 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>>> 
>>> On Sat, Aug 08, 2020 at 01:02:34PM +0200, Daniel Vetter wrote:
>>>> On Sat, Aug 8, 2020 at 12:24 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>> 
>>>>> On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote:
>>>>>> On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>>>>> 
>>>>>>> Hi
>>>>>>> 
>>>>>>> Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org:
>>>>>>>> The patch below was submitted to be applied to the 5.8-stable tree.
>>>>>>>> 
>>>>>>>> I fail to see how this patch meets the stable kernel rules as found at
>>>>>>>> Documentation/process/stable-kernel-rules.rst.
>>>>>>>> 
>>>>>>>> I could be totally wrong, and if so, please respond to
>>>>>>>> <stable@vger.kernel.org> and let me know why this patch should be
>>>>>>>> applied.  Otherwise, it is now dropped from my patch queues, never to be
>>>>>>>> seen again.
>>>>>>> 
>>>>>>> Sorry for the noise. There's no reason this should go into stable.
>>>>>> 
>>>>>> We have a little script in our maintainer toolbox for bugfixes, which
>>>>>> generates the Fixes: line, adds everyone from the original commit to
>>>>>> the cc: list and also adds Cc: stable if that sha1 the patch fixes is
>>>>>> in a release already.
>>>>>> 
>>>>>> I guess we trained people a bit too much on using Fixes: tags like
>>>>>> that with the tooling, since they often do that for checkpatch stuff
>>>>>> and spelling fixes like this here too. I think the autoselect bot also
>>>>>> loves Fixes: tags a bit too much for its own good.
>>>>>> 
>>>>>> Not sure what to do, since telling people to "please sprinkle less
>>>>>> Fixes: tags" doesn't sound great either. I also don't want to tell
>>>>>> people to use the maintainer toolbox less, the autogenerated cc: list
>>>>>> is generally the right thing to do. Maybe best if the stable team
>>>>>> catches the obvious ones before adding them to the stable queue, if
>>>>>> you're ok with that Greg?
>>>>> 
>>>>> As I think this is the first time that I've had this problem for a DRM
>>>>> submission, I don't think it's a big issue yet at all, so whatever you
>>>>> are doing today is fine.
>>>>> 
>>>>> I do think that the number of patches submitted for stable for
>>>>> drm-related issues feels very very low given the rate of change and
>>>>> number of overall patches you all submit to the kernel, so if anything,
>>>>> you all should be increasing the number of times you tag stuff for
>>>>> stable, not reducing it :)
>>>> 
>>>> Ok, sounds like we should encourage people to use the Fixes: tag and
>>>> auto-cc tooling more, not less.
>>>> 
>>>> I also crunched some quick numbers:
>>>> commits with cc: stable in drm/amd: 2.6%
>>>> ... in drm/i915: 2.5%
>>>> ... drm overall: 2.3%
>>>> drivers/ overall: 3.1%
>>>> 
>>>> So from a quick look no big outliers at least, maybe not quite enough
>>>> cc: stable from smaller drivers (i915+amd is about 60% of everything
>>>> in drm). This is for the past year. Compared to drivers/ overall a bit
>>>> lower, but not drastically so. At least if I didn't screw up my
>>>> scripting.
>>> 
>>> Seems about right, so on those averages, you have missed about 40-50
>>> patches that should have been cc:ed stable.
>>> 
>>> However, you are comparing yourself against stuff like drivers/net/
>>> which shouldn't have cc: stable for most stuff (as per the networking
>>> workflow), and other subsystems that seem to never want to cc: stable
>>> for various reasons (offenders not mentioned to be nice...)
>>> 
>>> So let's bump that number up a bit, maybe you are missing 100 patches
>>> this past year that should have been backported?
>>> 
>>> Feels like you all could tag more, even if the number is only 40-50 :)
>>> 
>>> Oh wait, are you sure you don't count the horrid "double commits" where
>>> you backport something from your development branch to your "for linus"
>>> branch, and have cc: stable on both, so that during the -rc1 merge
>>> window I see a ton of commits that are already in the tree?  That would
>>> inflate your numbers a lot more so your real percentages might be a lot
>>> lower...
>>> 
>>> fun with math.
>> 
>> Even drivers/net has like 1.0% cc: stable or so, but yeah maybe a
>> third cc: stable might be missing overall in drm. The math aint more
>> accurate no matter what, but agrees with your "about 100 patches".
>> 
>> And yeah I didn't take out the cherry-picked ones. Trying to grep for
>> those (yay more fun with math) says there's 37 stable commits I
>> double-counted, leaving 1.4% left over for drm/i915. That seems indeed
>> a bit too low :-/
>> 
>> I guess time to add intel maintainers (kinda not my direct business anymore).
> 
> So for comparison I also looked at mesa3d, which at least compared to
> drivers/gpu is very similar:
> - 3 months release cycle, 1 month -rc
> - very low level C codebase dealing with gpu nonsense
> - same Cc: stable process, shamelessly copied from the kernel
> - roughly same review process, but recently switched from patch bombs on
>  m-l to gitlab merge requests (but still pretty similar flow with
>  detailed per-commit review)
> 
> It has a 0.9% stable ratio over the past year.
> 
> The really big difference is that mesa3d CI is really, really good. Like
> we run a ton of unit tests, sw rendering tests and then a bunch of hw
> platforms running validation suits. All pre-merge, i.e. before the patches
> are even reviewed in detail. And there's a bot used for merging, to make
> sure you're patches pass, or they don't go in.
> 
> tldr; roughly the same, except a CI that's a few orders of magnitude
> better than what drm/i915 has (especially wrt sporadic issues). Which I
> think is still lots better than what any other drm driver has (but it does
> help the subsytem overall with catching lots of issues in helpers an core
> code).
> 
> So maybe the lower cc: stable is because we catch more crap before it
> even lands ... no idea really, and no human can go and quickly review 10k
> patches for why there's fewer cc: stable.

Or maybe because we have a higher rate of code refactor? :/

But yes, let's work to encourage more people of using Fixes; and cc-stable
properly. Luckily we already have some tools in place (dim fixes <has>) that
our developers are used to. This will dump the right "Fixes: <hash><commit-subject>"
line, and appropriated Ccs, including stable when needed.

> 
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[Daniel Vetter]

On Sat, Aug 08, 2020 at 05:24:53PM +0200, Daniel Vetter wrote:
> On Sat, Aug 8, 2020 at 1:28 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Sat, Aug 08, 2020 at 01:02:34PM +0200, Daniel Vetter wrote:
> > > On Sat, Aug 8, 2020 at 12:24 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote:
> > > > > On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org:
> > > > > > > The patch below was submitted to be applied to the 5.8-stable tree.
> > > > > > >
> > > > > > > I fail to see how this patch meets the stable kernel rules as found at
> > > > > > > Documentation/process/stable-kernel-rules.rst.
> > > > > > >
> > > > > > > I could be totally wrong, and if so, please respond to
> > > > > > > <stable@vger.kernel.org> and let me know why this patch should be
> > > > > > > applied.  Otherwise, it is now dropped from my patch queues, never to be
> > > > > > > seen again.
> > > > > >
> > > > > > Sorry for the noise. There's no reason this should go into stable.
> > > > >
> > > > > We have a little script in our maintainer toolbox for bugfixes, which
> > > > > generates the Fixes: line, adds everyone from the original commit to
> > > > > the cc: list and also adds Cc: stable if that sha1 the patch fixes is
> > > > > in a release already.
> > > > >
> > > > > I guess we trained people a bit too much on using Fixes: tags like
> > > > > that with the tooling, since they often do that for checkpatch stuff
> > > > > and spelling fixes like this here too. I think the autoselect bot also
> > > > > loves Fixes: tags a bit too much for its own good.
> > > > >
> > > > > Not sure what to do, since telling people to "please sprinkle less
> > > > > Fixes: tags" doesn't sound great either. I also don't want to tell
> > > > > people to use the maintainer toolbox less, the autogenerated cc: list
> > > > > is generally the right thing to do. Maybe best if the stable team
> > > > > catches the obvious ones before adding them to the stable queue, if
> > > > > you're ok with that Greg?
> > > >
> > > > As I think this is the first time that I've had this problem for a DRM
> > > > submission, I don't think it's a big issue yet at all, so whatever you
> > > > are doing today is fine.
> > > >
> > > > I do think that the number of patches submitted for stable for
> > > > drm-related issues feels very very low given the rate of change and
> > > > number of overall patches you all submit to the kernel, so if anything,
> > > > you all should be increasing the number of times you tag stuff for
> > > > stable, not reducing it :)
> > >
> > > Ok, sounds like we should encourage people to use the Fixes: tag and
> > > auto-cc tooling more, not less.
> > >
> > > I also crunched some quick numbers:
> > > commits with cc: stable in drm/amd: 2.6%
> > > ... in drm/i915: 2.5%
> > > ... drm overall: 2.3%
> > > drivers/ overall: 3.1%
> > >
> > > So from a quick look no big outliers at least, maybe not quite enough
> > > cc: stable from smaller drivers (i915+amd is about 60% of everything
> > > in drm). This is for the past year. Compared to drivers/ overall a bit
> > > lower, but not drastically so. At least if I didn't screw up my
> > > scripting.
> >
> > Seems about right, so on those averages, you have missed about 40-50
> > patches that should have been cc:ed stable.
> >
> > However, you are comparing yourself against stuff like drivers/net/
> > which shouldn't have cc: stable for most stuff (as per the networking
> > workflow), and other subsystems that seem to never want to cc: stable
> > for various reasons (offenders not mentioned to be nice...)
> >
> > So let's bump that number up a bit, maybe you are missing 100 patches
> > this past year that should have been backported?
> >
> > Feels like you all could tag more, even if the number is only 40-50 :)
> >
> > Oh wait, are you sure you don't count the horrid "double commits" where
> > you backport something from your development branch to your "for linus"
> > branch, and have cc: stable on both, so that during the -rc1 merge
> > window I see a ton of commits that are already in the tree?  That would
> > inflate your numbers a lot more so your real percentages might be a lot
> > lower...
> >
> > fun with math.
> 
> Even drivers/net has like 1.0% cc: stable or so, but yeah maybe a
> third cc: stable might be missing overall in drm. The math aint more
> accurate no matter what, but agrees with your "about 100 patches".
> 
> And yeah I didn't take out the cherry-picked ones. Trying to grep for
> those (yay more fun with math) says there's 37 stable commits I
> double-counted, leaving 1.4% left over for drm/i915. That seems indeed
> a bit too low :-/
> 
> I guess time to add intel maintainers (kinda not my direct business anymore).

So for comparison I also looked at mesa3d, which at least compared to
drivers/gpu is very similar:
- 3 months release cycle, 1 month -rc
- very low level C codebase dealing with gpu nonsense
- same Cc: stable process, shamelessly copied from the kernel
- roughly same review process, but recently switched from patch bombs on
  m-l to gitlab merge requests (but still pretty similar flow with
  detailed per-commit review)

It has a 0.9% stable ratio over the past year.

The really big difference is that mesa3d CI is really, really good. Like
we run a ton of unit tests, sw rendering tests and then a bunch of hw
platforms running validation suits. All pre-merge, i.e. before the patches
are even reviewed in detail. And there's a bot used for merging, to make
sure you're patches pass, or they don't go in.

tldr; roughly the same, except a CI that's a few orders of magnitude
better than what drm/i915 has (especially wrt sporadic issues). Which I
think is still lots better than what any other drm driver has (but it does
help the subsytem overall with catching lots of issues in helpers an core
code).

So maybe the lower cc: stable is because we catch more crap before it
even lands ... no idea really, and no human can go and quickly review 10k
patches for why there's fewer cc: stable.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[Jani Nikula]

On Sat, 08 Aug 2020, Sam Ravnborg <sam@ravnborg.org> wrote:
> Hi Daniel.
>
> On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote:
>> On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> >
>> > Hi
>> >
>> > Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org:
>> > > The patch below was submitted to be applied to the 5.8-stable tree.
>> > >
>> > > I fail to see how this patch meets the stable kernel rules as found at
>> > > Documentation/process/stable-kernel-rules.rst.
>> > >
>> > > I could be totally wrong, and if so, please respond to
>> > > <stable@vger.kernel.org> and let me know why this patch should be
>> > > applied.  Otherwise, it is now dropped from my patch queues, never to be
>> > > seen again.
>> >
>> > Sorry for the noise. There's no reason this should go into stable.
>> 
>> We have a little script in our maintainer toolbox for bugfixes, which
>> generates the Fixes: line, adds everyone from the original commit to
>> the cc: list and also adds Cc: stable if that sha1 the patch fixes is
>> in a release already.
>> 
>> I guess we trained people a bit too much on using Fixes: tags like
>> that with the tooling, since they often do that for checkpatch stuff
>> and spelling fixes like this here too. I think the autoselect bot also
>> loves Fixes: tags a bit too much for its own good.
>> 
>> Not sure what to do, since telling people to "please sprinkle less
>> Fixes: tags" doesn't sound great either.
>
> We know that at lot of the drm people uses "dim fixes".
> So maybe teach them a litte here?
>
> diff --git a/dim b/dim
> index e4f4d2e..d4fd310 100755
> --- a/dim
> +++ b/dim
> @@ -2428,6 +2428,10 @@ function dim_fixes
>  
>  	sha1=${1:?$usage}
>  
> +	echo ""
> +	echo "Note: Patch must meet the stable-kernel-rules criterias (Documentation/process/stable-kernel-rules.rst)"
> +	echo ""
> +

I don't think this is right, because we also use Fixes: to refer to
commits that haven't even been merged upstream yet, i.e. commits that
are in the -next feature branches, and the stable kernel rules do not
apply.

BR,
Jani.





>  	cd $DIM_PREFIX/$DIM_REPO
>  	echo "Fixes: $(dim_cite $sha1)"
>  
>
> Output would then look like this:
>
> $ dim fixes 1d8d42ba365101fa68d210c0e2ed2bc9582fda6c
>
> Note: Patch must meet the stable-kernel-rules criterias (Documentation/process/stable-kernel-rules.rst)
>
> Fixes: 1d8d42ba3651 ("drm/mgag200: Remove declaration of mgag200_mmap() from header file")
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "Noralf Trønnes" <noralf@tronnes.org>
> Cc: Armijn Hemel <armijn@tjaldur.nl>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Emil Velikov <emil.velikov@collabora.com>
> Cc: <stable@vger.kernel.org> # v5.3+
> Cc: Lyude Paul <lyude@redhat.com>
>
> No guarantee that people will look up the rules outlined in
> stable-kernel-rules.rst - but at least a reminder.
>
> 	Sam
>
>> I also don't want to tell
>> people to use the maintainer toolbox less, the autogenerated cc: list
>> is generally the right thing to do. Maybe best if the stable team
>> catches the obvious ones before adding them to the stable queue, if
>> you're ok with that Greg?
>> 
>> Also adding dri-devel here in case this becomes a bigger discussion.
>> 
>> Cheers, Daniel
>> 
>> >
>> > Best regards
>> > Thomas
>> >
>> > >
>> > > thanks,
>> > >
>> > > greg k-h
>> > >
>> > > ------------------ original commit in Linus's tree ------------------
>> > >
>> > > From 1d8d42ba365101fa68d210c0e2ed2bc9582fda6c Mon Sep 17 00:00:00 2001
>> > > From: Thomas Zimmermann <tzimmermann@suse.de>
>> > > Date: Fri, 5 Jun 2020 15:57:50 +0200
>> > > Subject: [PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header
>> > >  file
>> > > MIME-Version: 1.0
>> > > Content-Type: text/plain; charset=UTF-8
>> > > Content-Transfer-Encoding: 8bit
>> > >
>> > > Commit 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
>> > > removed the implementation of mgag200_mmap(). Also remove the declaration.
>> > >
>> > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> > > Acked-by: Sam Ravnborg <sam@ravnborg.org>
>> > > Fixes: 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
>> > > Cc: Gerd Hoffmann <kraxel@redhat.com>
>> > > Cc: Dave Airlie <airlied@redhat.com>
>> > > Cc: Krzysztof Kozlowski <krzk@kernel.org>
>> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > > Cc: Sam Ravnborg <sam@ravnborg.org>
>> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> > > Cc: Thomas Gleixner <tglx@linutronix.de>
>> > > Cc: "Noralf Trønnes" <noralf@tronnes.org>
>> > > Cc: Armijn Hemel <armijn@tjaldur.nl>
>> > > Cc: Alex Deucher <alexander.deucher@amd.com>
>> > > Cc: Emil Velikov <emil.velikov@collabora.com>
>> > > Cc: <stable@vger.kernel.org> # v5.3+
>> > > Link: https://patchwork.freedesktop.org/patch/msgid/20200605135803.19811-2-tzimmermann@suse.de
>> > >
>> > > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h
>> > > index 47df62b1ad29..92b6679029fe 100644
>> > > --- a/drivers/gpu/drm/mgag200/mgag200_drv.h
>> > > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
>> > > @@ -198,6 +198,5 @@ void mgag200_i2c_destroy(struct mga_i2c_chan *i2c);
>> > >
>> > >  int mgag200_mm_init(struct mga_device *mdev);
>> > >  void mgag200_mm_fini(struct mga_device *mdev);
>> > > -int mgag200_mmap(struct file *filp, struct vm_area_struct *vma);
>> > >
>> > >  #endif                               /* __MGAG200_DRV_H__ */
>> > >
>> >
>> > --
>> > Thomas Zimmermann
>> > Graphics Driver Developer
>> > SUSE Software Solutions Germany GmbH
>> > Maxfeldstr. 5, 90409 Nürnberg, Germany
>> > (HRB 36809, AG Nürnberg)
>> > Geschäftsführer: Felix Imendörffer
>> >
>> 
>> 
>> -- 
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[Daniel Vetter]

On Sat, Aug 8, 2020 at 1:28 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sat, Aug 08, 2020 at 01:02:34PM +0200, Daniel Vetter wrote:
> > On Sat, Aug 8, 2020 at 12:24 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote:
> > > > On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > > > >
> > > > > Hi
> > > > >
> > > > > Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org:
> > > > > > The patch below was submitted to be applied to the 5.8-stable tree.
> > > > > >
> > > > > > I fail to see how this patch meets the stable kernel rules as found at
> > > > > > Documentation/process/stable-kernel-rules.rst.
> > > > > >
> > > > > > I could be totally wrong, and if so, please respond to
> > > > > > <stable@vger.kernel.org> and let me know why this patch should be
> > > > > > applied.  Otherwise, it is now dropped from my patch queues, never to be
> > > > > > seen again.
> > > > >
> > > > > Sorry for the noise. There's no reason this should go into stable.
> > > >
> > > > We have a little script in our maintainer toolbox for bugfixes, which
> > > > generates the Fixes: line, adds everyone from the original commit to
> > > > the cc: list and also adds Cc: stable if that sha1 the patch fixes is
> > > > in a release already.
> > > >
> > > > I guess we trained people a bit too much on using Fixes: tags like
> > > > that with the tooling, since they often do that for checkpatch stuff
> > > > and spelling fixes like this here too. I think the autoselect bot also
> > > > loves Fixes: tags a bit too much for its own good.
> > > >
> > > > Not sure what to do, since telling people to "please sprinkle less
> > > > Fixes: tags" doesn't sound great either. I also don't want to tell
> > > > people to use the maintainer toolbox less, the autogenerated cc: list
> > > > is generally the right thing to do. Maybe best if the stable team
> > > > catches the obvious ones before adding them to the stable queue, if
> > > > you're ok with that Greg?
> > >
> > > As I think this is the first time that I've had this problem for a DRM
> > > submission, I don't think it's a big issue yet at all, so whatever you
> > > are doing today is fine.
> > >
> > > I do think that the number of patches submitted for stable for
> > > drm-related issues feels very very low given the rate of change and
> > > number of overall patches you all submit to the kernel, so if anything,
> > > you all should be increasing the number of times you tag stuff for
> > > stable, not reducing it :)
> >
> > Ok, sounds like we should encourage people to use the Fixes: tag and
> > auto-cc tooling more, not less.
> >
> > I also crunched some quick numbers:
> > commits with cc: stable in drm/amd: 2.6%
> > ... in drm/i915: 2.5%
> > ... drm overall: 2.3%
> > drivers/ overall: 3.1%
> >
> > So from a quick look no big outliers at least, maybe not quite enough
> > cc: stable from smaller drivers (i915+amd is about 60% of everything
> > in drm). This is for the past year. Compared to drivers/ overall a bit
> > lower, but not drastically so. At least if I didn't screw up my
> > scripting.
>
> Seems about right, so on those averages, you have missed about 40-50
> patches that should have been cc:ed stable.
>
> However, you are comparing yourself against stuff like drivers/net/
> which shouldn't have cc: stable for most stuff (as per the networking
> workflow), and other subsystems that seem to never want to cc: stable
> for various reasons (offenders not mentioned to be nice...)
>
> So let's bump that number up a bit, maybe you are missing 100 patches
> this past year that should have been backported?
>
> Feels like you all could tag more, even if the number is only 40-50 :)
>
> Oh wait, are you sure you don't count the horrid "double commits" where
> you backport something from your development branch to your "for linus"
> branch, and have cc: stable on both, so that during the -rc1 merge
> window I see a ton of commits that are already in the tree?  That would
> inflate your numbers a lot more so your real percentages might be a lot
> lower...
>
> fun with math.

Even drivers/net has like 1.0% cc: stable or so, but yeah maybe a
third cc: stable might be missing overall in drm. The math aint more
accurate no matter what, but agrees with your "about 100 patches".

And yeah I didn't take out the cherry-picked ones. Trying to grep for
those (yay more fun with math) says there's 37 stable commits I
double-counted, leaving 1.4% left over for drm/i915. That seems indeed
a bit too low :-/

I guess time to add intel maintainers (kinda not my direct business anymore).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[Greg KH]

On Sat, Aug 08, 2020 at 01:02:34PM +0200, Daniel Vetter wrote:
> On Sat, Aug 8, 2020 at 12:24 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote:
> > > On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > > >
> > > > Hi
> > > >
> > > > Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org:
> > > > > The patch below was submitted to be applied to the 5.8-stable tree.
> > > > >
> > > > > I fail to see how this patch meets the stable kernel rules as found at
> > > > > Documentation/process/stable-kernel-rules.rst.
> > > > >
> > > > > I could be totally wrong, and if so, please respond to
> > > > > <stable@vger.kernel.org> and let me know why this patch should be
> > > > > applied.  Otherwise, it is now dropped from my patch queues, never to be
> > > > > seen again.
> > > >
> > > > Sorry for the noise. There's no reason this should go into stable.
> > >
> > > We have a little script in our maintainer toolbox for bugfixes, which
> > > generates the Fixes: line, adds everyone from the original commit to
> > > the cc: list and also adds Cc: stable if that sha1 the patch fixes is
> > > in a release already.
> > >
> > > I guess we trained people a bit too much on using Fixes: tags like
> > > that with the tooling, since they often do that for checkpatch stuff
> > > and spelling fixes like this here too. I think the autoselect bot also
> > > loves Fixes: tags a bit too much for its own good.
> > >
> > > Not sure what to do, since telling people to "please sprinkle less
> > > Fixes: tags" doesn't sound great either. I also don't want to tell
> > > people to use the maintainer toolbox less, the autogenerated cc: list
> > > is generally the right thing to do. Maybe best if the stable team
> > > catches the obvious ones before adding them to the stable queue, if
> > > you're ok with that Greg?
> >
> > As I think this is the first time that I've had this problem for a DRM
> > submission, I don't think it's a big issue yet at all, so whatever you
> > are doing today is fine.
> >
> > I do think that the number of patches submitted for stable for
> > drm-related issues feels very very low given the rate of change and
> > number of overall patches you all submit to the kernel, so if anything,
> > you all should be increasing the number of times you tag stuff for
> > stable, not reducing it :)
> 
> Ok, sounds like we should encourage people to use the Fixes: tag and
> auto-cc tooling more, not less.
> 
> I also crunched some quick numbers:
> commits with cc: stable in drm/amd: 2.6%
> ... in drm/i915: 2.5%
> ... drm overall: 2.3%
> drivers/ overall: 3.1%
> 
> So from a quick look no big outliers at least, maybe not quite enough
> cc: stable from smaller drivers (i915+amd is about 60% of everything
> in drm). This is for the past year. Compared to drivers/ overall a bit
> lower, but not drastically so. At least if I didn't screw up my
> scripting.

Seems about right, so on those averages, you have missed about 40-50
patches that should have been cc:ed stable.

However, you are comparing yourself against stuff like drivers/net/
which shouldn't have cc: stable for most stuff (as per the networking
workflow), and other subsystems that seem to never want to cc: stable
for various reasons (offenders not mentioned to be nice...)

So let's bump that number up a bit, maybe you are missing 100 patches
this past year that should have been backported?

Feels like you all could tag more, even if the number is only 40-50 :)

Oh wait, are you sure you don't count the horrid "double commits" where
you backport something from your development branch to your "for linus"
branch, and have cc: stable on both, so that during the -rc1 merge
window I see a ton of commits that are already in the tree?  That would
inflate your numbers a lot more so your real percentages might be a lot
lower...

fun with math.

greg k-h

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[Daniel Vetter]

On Sat, Aug 8, 2020 at 12:24 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > >
> > > Hi
> > >
> > > Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org:
> > > > The patch below was submitted to be applied to the 5.8-stable tree.
> > > >
> > > > I fail to see how this patch meets the stable kernel rules as found at
> > > > Documentation/process/stable-kernel-rules.rst.
> > > >
> > > > I could be totally wrong, and if so, please respond to
> > > > <stable@vger.kernel.org> and let me know why this patch should be
> > > > applied.  Otherwise, it is now dropped from my patch queues, never to be
> > > > seen again.
> > >
> > > Sorry for the noise. There's no reason this should go into stable.
> >
> > We have a little script in our maintainer toolbox for bugfixes, which
> > generates the Fixes: line, adds everyone from the original commit to
> > the cc: list and also adds Cc: stable if that sha1 the patch fixes is
> > in a release already.
> >
> > I guess we trained people a bit too much on using Fixes: tags like
> > that with the tooling, since they often do that for checkpatch stuff
> > and spelling fixes like this here too. I think the autoselect bot also
> > loves Fixes: tags a bit too much for its own good.
> >
> > Not sure what to do, since telling people to "please sprinkle less
> > Fixes: tags" doesn't sound great either. I also don't want to tell
> > people to use the maintainer toolbox less, the autogenerated cc: list
> > is generally the right thing to do. Maybe best if the stable team
> > catches the obvious ones before adding them to the stable queue, if
> > you're ok with that Greg?
>
> As I think this is the first time that I've had this problem for a DRM
> submission, I don't think it's a big issue yet at all, so whatever you
> are doing today is fine.
>
> I do think that the number of patches submitted for stable for
> drm-related issues feels very very low given the rate of change and
> number of overall patches you all submit to the kernel, so if anything,
> you all should be increasing the number of times you tag stuff for
> stable, not reducing it :)

Ok, sounds like we should encourage people to use the Fixes: tag and
auto-cc tooling more, not less.

I also crunched some quick numbers:
commits with cc: stable in drm/amd: 2.6%
... in drm/i915: 2.5%
... drm overall: 2.3%
drivers/ overall: 3.1%

So from a quick look no big outliers at least, maybe not quite enough
cc: stable from smaller drivers (i915+amd is about 60% of everything
in drm). This is for the past year. Compared to drivers/ overall a bit
lower, but not drastically so. At least if I didn't screw up my
scripting.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[Greg KH]

On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote:
> On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >
> > Hi
> >
> > Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org:
> > > The patch below was submitted to be applied to the 5.8-stable tree.
> > >
> > > I fail to see how this patch meets the stable kernel rules as found at
> > > Documentation/process/stable-kernel-rules.rst.
> > >
> > > I could be totally wrong, and if so, please respond to
> > > <stable@vger.kernel.org> and let me know why this patch should be
> > > applied.  Otherwise, it is now dropped from my patch queues, never to be
> > > seen again.
> >
> > Sorry for the noise. There's no reason this should go into stable.
> 
> We have a little script in our maintainer toolbox for bugfixes, which
> generates the Fixes: line, adds everyone from the original commit to
> the cc: list and also adds Cc: stable if that sha1 the patch fixes is
> in a release already.
> 
> I guess we trained people a bit too much on using Fixes: tags like
> that with the tooling, since they often do that for checkpatch stuff
> and spelling fixes like this here too. I think the autoselect bot also
> loves Fixes: tags a bit too much for its own good.
> 
> Not sure what to do, since telling people to "please sprinkle less
> Fixes: tags" doesn't sound great either. I also don't want to tell
> people to use the maintainer toolbox less, the autogenerated cc: list
> is generally the right thing to do. Maybe best if the stable team
> catches the obvious ones before adding them to the stable queue, if
> you're ok with that Greg?

As I think this is the first time that I've had this problem for a DRM
submission, I don't think it's a big issue yet at all, so whatever you
are doing today is fine.

I do think that the number of patches submitted for stable for
drm-related issues feels very very low given the rate of change and
number of overall patches you all submit to the kernel, so if anything,
you all should be increasing the number of times you tag stuff for
stable, not reducing it :)

thanks,

greg k-h

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[Sam Ravnborg]

Hi Daniel.

On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote:
> On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >
> > Hi
> >
> > Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org:
> > > The patch below was submitted to be applied to the 5.8-stable tree.
> > >
> > > I fail to see how this patch meets the stable kernel rules as found at
> > > Documentation/process/stable-kernel-rules.rst.
> > >
> > > I could be totally wrong, and if so, please respond to
> > > <stable@vger.kernel.org> and let me know why this patch should be
> > > applied.  Otherwise, it is now dropped from my patch queues, never to be
> > > seen again.
> >
> > Sorry for the noise. There's no reason this should go into stable.
> 
> We have a little script in our maintainer toolbox for bugfixes, which
> generates the Fixes: line, adds everyone from the original commit to
> the cc: list and also adds Cc: stable if that sha1 the patch fixes is
> in a release already.
> 
> I guess we trained people a bit too much on using Fixes: tags like
> that with the tooling, since they often do that for checkpatch stuff
> and spelling fixes like this here too. I think the autoselect bot also
> loves Fixes: tags a bit too much for its own good.
> 
> Not sure what to do, since telling people to "please sprinkle less
> Fixes: tags" doesn't sound great either.

We know that at lot of the drm people uses "dim fixes".
So maybe teach them a litte here?

diff --git a/dim b/dim
index e4f4d2e..d4fd310 100755
--- a/dim
+++ b/dim
@@ -2428,6 +2428,10 @@ function dim_fixes
 
 	sha1=${1:?$usage}
 
+	echo ""
+	echo "Note: Patch must meet the stable-kernel-rules criterias (Documentation/process/stable-kernel-rules.rst)"
+	echo ""
+
 	cd $DIM_PREFIX/$DIM_REPO
 	echo "Fixes: $(dim_cite $sha1)"
 

Output would then look like this:

$ dim fixes 1d8d42ba365101fa68d210c0e2ed2bc9582fda6c

Note: Patch must meet the stable-kernel-rules criterias (Documentation/process/stable-kernel-rules.rst)

Fixes: 1d8d42ba3651 ("drm/mgag200: Remove declaration of mgag200_mmap() from header file")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Cc: Armijn Hemel <armijn@tjaldur.nl>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: <stable@vger.kernel.org> # v5.3+
Cc: Lyude Paul <lyude@redhat.com>

No guarantee that people will look up the rules outlined in
stable-kernel-rules.rst - but at least a reminder.

	Sam

> I also don't want to tell
> people to use the maintainer toolbox less, the autogenerated cc: list
> is generally the right thing to do. Maybe best if the stable team
> catches the obvious ones before adding them to the stable queue, if
> you're ok with that Greg?
> 
> Also adding dri-devel here in case this becomes a bigger discussion.
> 
> Cheers, Daniel
> 
> >
> > Best regards
> > Thomas
> >
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> > > ------------------ original commit in Linus's tree ------------------
> > >
> > > From 1d8d42ba365101fa68d210c0e2ed2bc9582fda6c Mon Sep 17 00:00:00 2001
> > > From: Thomas Zimmermann <tzimmermann@suse.de>
> > > Date: Fri, 5 Jun 2020 15:57:50 +0200
> > > Subject: [PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header
> > >  file
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset=UTF-8
> > > Content-Transfer-Encoding: 8bit
> > >
> > > Commit 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
> > > removed the implementation of mgag200_mmap(). Also remove the declaration.
> > >
> > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > Acked-by: Sam Ravnborg <sam@ravnborg.org>
> > > Fixes: 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
> > > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > > Cc: Dave Airlie <airlied@redhat.com>
> > > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Cc: Sam Ravnborg <sam@ravnborg.org>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: "Noralf Trønnes" <noralf@tronnes.org>
> > > Cc: Armijn Hemel <armijn@tjaldur.nl>
> > > Cc: Alex Deucher <alexander.deucher@amd.com>
> > > Cc: Emil Velikov <emil.velikov@collabora.com>
> > > Cc: <stable@vger.kernel.org> # v5.3+
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20200605135803.19811-2-tzimmermann@suse.de
> > >
> > > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h
> > > index 47df62b1ad29..92b6679029fe 100644
> > > --- a/drivers/gpu/drm/mgag200/mgag200_drv.h
> > > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
> > > @@ -198,6 +198,5 @@ void mgag200_i2c_destroy(struct mga_i2c_chan *i2c);
> > >
> > >  int mgag200_mm_init(struct mga_device *mdev);
> > >  void mgag200_mm_fini(struct mga_device *mdev);
> > > -int mgag200_mmap(struct file *filp, struct vm_area_struct *vma);
> > >
> > >  #endif                               /* __MGAG200_DRV_H__ */
> > >
> >
> > --
> > Thomas Zimmermann
> > Graphics Driver Developer
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > (HRB 36809, AG Nürnberg)
> > Geschäftsführer: Felix Imendörffer
> >
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[Daniel Vetter]

On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org:
> > The patch below was submitted to be applied to the 5.8-stable tree.
> >
> > I fail to see how this patch meets the stable kernel rules as found at
> > Documentation/process/stable-kernel-rules.rst.
> >
> > I could be totally wrong, and if so, please respond to
> > <stable@vger.kernel.org> and let me know why this patch should be
> > applied.  Otherwise, it is now dropped from my patch queues, never to be
> > seen again.
>
> Sorry for the noise. There's no reason this should go into stable.

We have a little script in our maintainer toolbox for bugfixes, which
generates the Fixes: line, adds everyone from the original commit to
the cc: list and also adds Cc: stable if that sha1 the patch fixes is
in a release already.

I guess we trained people a bit too much on using Fixes: tags like
that with the tooling, since they often do that for checkpatch stuff
and spelling fixes like this here too. I think the autoselect bot also
loves Fixes: tags a bit too much for its own good.

Not sure what to do, since telling people to "please sprinkle less
Fixes: tags" doesn't sound great either. I also don't want to tell
people to use the maintainer toolbox less, the autogenerated cc: list
is generally the right thing to do. Maybe best if the stable team
catches the obvious ones before adding them to the stable queue, if
you're ok with that Greg?

Also adding dri-devel here in case this becomes a bigger discussion.

Cheers, Daniel

>
> Best regards
> Thomas
>
> >
> > thanks,
> >
> > greg k-h
> >
> > ------------------ original commit in Linus's tree ------------------
> >
> > From 1d8d42ba365101fa68d210c0e2ed2bc9582fda6c Mon Sep 17 00:00:00 2001
> > From: Thomas Zimmermann <tzimmermann@suse.de>
> > Date: Fri, 5 Jun 2020 15:57:50 +0200
> > Subject: [PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header
> >  file
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Commit 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
> > removed the implementation of mgag200_mmap(). Also remove the declaration.
> >
> > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> > Acked-by: Sam Ravnborg <sam@ravnborg.org>
> > Fixes: 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: "Noralf Trønnes" <noralf@tronnes.org>
> > Cc: Armijn Hemel <armijn@tjaldur.nl>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Emil Velikov <emil.velikov@collabora.com>
> > Cc: <stable@vger.kernel.org> # v5.3+
> > Link: https://patchwork.freedesktop.org/patch/msgid/20200605135803.19811-2-tzimmermann@suse.de
> >
> > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h
> > index 47df62b1ad29..92b6679029fe 100644
> > --- a/drivers/gpu/drm/mgag200/mgag200_drv.h
> > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
> > @@ -198,6 +198,5 @@ void mgag200_i2c_destroy(struct mga_i2c_chan *i2c);
> >
> >  int mgag200_mm_init(struct mga_device *mdev);
> >  void mgag200_mm_fini(struct mga_device *mdev);
> > -int mgag200_mmap(struct file *filp, struct vm_area_struct *vma);
> >
> >  #endif                               /* __MGAG200_DRV_H__ */
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2747 bytes --]

Hi

Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org:
> The patch below was submitted to be applied to the 5.8-stable tree.
> 
> I fail to see how this patch meets the stable kernel rules as found at
> Documentation/process/stable-kernel-rules.rst.
> 
> I could be totally wrong, and if so, please respond to 
> <stable@vger.kernel.org> and let me know why this patch should be
> applied.  Otherwise, it is now dropped from my patch queues, never to be
> seen again.

Sorry for the noise. There's no reason this should go into stable.

Best regards
Thomas

> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
> From 1d8d42ba365101fa68d210c0e2ed2bc9582fda6c Mon Sep 17 00:00:00 2001
> From: Thomas Zimmermann <tzimmermann@suse.de>
> Date: Fri, 5 Jun 2020 15:57:50 +0200
> Subject: [PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header
>  file
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Commit 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
> removed the implementation of mgag200_mmap(). Also remove the declaration.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> Fixes: 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "Noralf Trønnes" <noralf@tronnes.org>
> Cc: Armijn Hemel <armijn@tjaldur.nl>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Emil Velikov <emil.velikov@collabora.com>
> Cc: <stable@vger.kernel.org> # v5.3+
> Link: https://patchwork.freedesktop.org/patch/msgid/20200605135803.19811-2-tzimmermann@suse.de
> 
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h
> index 47df62b1ad29..92b6679029fe 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.h
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
> @@ -198,6 +198,5 @@ void mgag200_i2c_destroy(struct mga_i2c_chan *i2c);
>  
>  int mgag200_mm_init(struct mga_device *mdev);
>  void mgag200_mm_fini(struct mga_device *mdev);
> -int mgag200_mmap(struct file *filp, struct vm_area_struct *vma);
>  
>  #endif				/* __MGAG200_DRV_H__ */
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

[gregkh]

The patch below was submitted to be applied to the 5.8-stable tree.

I fail to see how this patch meets the stable kernel rules as found at
Documentation/process/stable-kernel-rules.rst.

I could be totally wrong, and if so, please respond to 
<stable@vger.kernel.org> and let me know why this patch should be
applied.  Otherwise, it is now dropped from my patch queues, never to be
seen again.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 1d8d42ba365101fa68d210c0e2ed2bc9582fda6c Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Fri, 5 Jun 2020 15:57:50 +0200
Subject: [PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header
 file
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
removed the implementation of mgag200_mmap(). Also remove the declaration.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Fixes: 94668ac796a5 ("drm/mgag200: Convert mgag200 driver to VRAM MM")
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Cc: Armijn Hemel <armijn@tjaldur.nl>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: <stable@vger.kernel.org> # v5.3+
Link: https://patchwork.freedesktop.org/patch/msgid/20200605135803.19811-2-tzimmermann@suse.de

diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 47df62b1ad29..92b6679029fe 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -198,6 +198,5 @@ void mgag200_i2c_destroy(struct mga_i2c_chan *i2c);
 
 int mgag200_mm_init(struct mga_device *mdev);
 void mgag200_mm_fini(struct mga_device *mdev);
-int mgag200_mmap(struct file *filp, struct vm_area_struct *vma);
 
 #endif				/* __MGAG200_DRV_H__ */