[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1vYZWr1k+APa1Xc-7x1L8p+oJU0_fdJU9YOyzF7czP=A@mail.gmail.com>
Date: Wed, 17 Jan 2018 20:44:07 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Daniel Vetter <daniel@...ll.ch>
Cc: Patrik Jakobsson <patrik.r.jakobsson@...il.com>,
David Airlie <airlied@...ux.ie>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [RESEND] drm/gma500: initialize gma_clock_t structures
On Wed, Jan 17, 2018 at 3:55 PM, Daniel Vetter <daniel@...ll.ch> wrote:
> On Wed, Jan 17, 2018 at 3:36 PM, Arnd Bergmann <arnd@...db.de> wrote:
>> On Wed, Jan 17, 2018 at 9:27 AM, Daniel Vetter <daniel@...ll.ch> wrote:
>>> On Tue, Jan 16, 2018 at 03:57:10PM +0100, Arnd Bergmann wrote:
>>>> The two functions pass a partially initialized structure back to the
>>>> caller after a memset() on the destination.
>>>>
>>>> This is not entirely well-defined, most compilers are sensible enough
>>>> to either keep the zero-initialization for the uninitialized members,
>>>> but gcc-4.4 does not, and it warns about this:
>>>>
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_sdvo_find_best_pll':
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.vco' may be used uninitialized in this function
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.dot' may be used uninitialized in this function
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.p2' may be used uninitialized in this function
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m2' may be used uninitialized in this function
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m1' may be used uninitialized in this function
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_lvds_find_best_pll':
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p' may be used uninitialized in this function
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.vco' may be used uninitialized in this function
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p2' may be used uninitialized in this function
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m2' may be used uninitialized in this function
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m1' may be used uninitialized in this function
>>>> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.n' may be used uninitialized in this function
>>>>
>>>> This adds an initialization at declaration time to avoid the warning
>>>> and make it well-defined on all compiler versions.
>>>>
>>>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>>>
>>> Applied to drm-misc-next-fixes for 4.16, thx for your patch.
>>
>> Thanks!
>>
>>> Aside: Still don't want commit rights? :-)
>>
>> I think I'm fine without. While I do tend to have a backlog on DRM
>> patches that I'd
>> like to get merged, they are generally of the kind that I should not
>> apply myself
>> without the maintainer being involved in some form, and then they can commit
>> it themselves.
>
> Commit rights isn't for pushing unreviewed stuff (our scripts will
> remind you of that if you try). But you could just volunteer someone
> to review the entire pile and then push it, instead of nagging every
> single slacking maintainer individually.
I understand, but I could also just nag someone to review and apply
the patches, right? Or do the committer and reviewer also need to
be separate people?
Arnd
Powered by blists - more mailing lists