linux-kernel - Re: [PATCH 02/30] include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201117100509.GJ401619@phenom.ffwll.local>
Date:   Tue, 17 Nov 2020 11:05:09 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Daniel Vetter <daniel@...ll.ch>, Sam Ravnborg <sam@...nborg.org>,
        David Airlie <airlied@...ux.ie>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH 02/30] include: drm: drm_atomic: Artificially use 'crtc'
 to avoid 'not used' warning

On Fri, Nov 13, 2020 at 10:01:57PM +0000, Lee Jones wrote:
> On Fri, 13 Nov 2020, 21:31 Daniel Vetter, <daniel@...ll.ch> wrote:
> 
> > On Fri, Nov 13, 2020 at 9:53 PM Lee Jones <lee.jones@...aro.org> wrote:
> > >
> > >
> > >
> > > On Fri, 13 Nov 2020, 20:50 Daniel Vetter, <daniel@...ll.ch> wrote:
> > >>
> > >> On Thu, Nov 12, 2020 at 09:25:16PM +0100, Sam Ravnborg wrote:
> > >> > Hi Lee,
> > >> >
> > >> > On Thu, Nov 12, 2020 at 07:00:11PM +0000, Lee Jones wrote:
> > >> > > The precedent has already been set by other macros in the same file.
> > >> > >
> > >> > > Fixes the following W=1 kernel build warning(s):
> > >> > >
> > >> > >  drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’
> > set but not used [-Wunused-but-set-variable]
> > >> > >  55 | struct drm_crtc *crtc;
> > >> > >  | ^~~~
> > >> > >
> > >> > > Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
> > >> > > Cc: Maxime Ripard <mripard@...nel.org>
> > >> > > Cc: Thomas Zimmermann <tzimmermann@...e.de>
> > >> > > Cc: David Airlie <airlied@...ux.ie>
> > >> > > Cc: Daniel Vetter <daniel@...ll.ch>
> > >> > > Cc: Rob Clark <robdclark@...il.com>
> > >> > > Cc: dri-devel@...ts.freedesktop.org
> > >> > > Signed-off-by: Lee Jones <lee.jones@...aro.org>
> > >> >
> > >> > Also applied to drm-misc-next.
> > >> > This was the last patch from this batch I will process.
> > >> > The others are left for the maintainers to pick up.
> > >>
> > >> btw for patches that maintainers don't pick up, the usual process is
> > that
> > >> we give them 2 weeks, then just mass apply. Now you're producing a lot
> > of
> > >> patches, too much for me to keep track, so please just ping me with a
> > >> resend for those that expired and I'll go through and pick them all up.
> > >
> > >
> > > That's great Daniel. Thanks for your support.
> > >
> > > I can do one better than that.
> > >
> > > Would a pull-request suit you?
> >
> > We have a few trees going on, and your patches are landing through all
> > kinds of them. So this might be more coordination pain. If you can
> > exclude patches for the separately and usually fairly well maintained
> > drivers out of the pull it should work (drm/amd, drm/radeon, drm/i915,
> > drm/nouveau, drm/msm and drm/omapdrm probably the usual ones).
> >
> > Or you just send the next pile and we'll see.
> >
> > Also I guess I can't really interest you in commit rights so this
> > patch bombs get off my back again? :-)
> >
> 
> What does that mean? Merge my own patches?
> 
> Not sure how that works with your group maintenance setup.
> 
> Is it just a `git push`?

It's a bunch of scripting and setup, might not be worth it for just one
of. Plus we still take pull requests from submaintainers so it's all just
if you feel like it. Some docs if you're curious:

https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html

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