Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <CAK8P3a1vYZWr1k+APa1Xc-7x1L8p+oJU0_fdJU9YOyzF7czP=A@mail.gmail.com>
References: <20180116145720.2348043-1-arnd@arndb.de> <20180117082712.GF2759@phenom.ffwll.local>
 <CAK8P3a0U5P9xFTsFFxwY4xOFJZ4X1BVdk+1H4=f3eZpWRHjjAg@mail.gmail.com>
 <CAKMK7uFvMdqDuTmukbJFAAmFQDeYG-vYb-donJxicL4Cna5shw@mail.gmail.com> <CAK8P3a1vYZWr1k+APa1Xc-7x1L8p+oJU0_fdJU9YOyzF7czP=A@mail.gmail.com>
From:   Daniel Vetter <daniel@ffwll.ch>
Date:   Wed, 17 Jan 2018 22:19:12 +0100
Message-ID: <CAKMK7uFme4qPJsLUJaXwc+phak45REObfQEq742FF3isQTt41w@mail.gmail.com>
Subject: Re: [PATCH] [RESEND] drm/gma500: initialize gma_clock_t structures
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Patrik Jakobsson <patrik.r.jakobsson@gmail.com>,
        David Airlie <airlied@linux.ie>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Jan 17, 2018 at 8:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Jan 17, 2018 at 3:55 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Jan 17, 2018 at 3:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Wed, Jan 17, 2018 at 9:27 AM, Daniel Vetter <daniel@ffwll.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@arndb.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?

Among author, committer and ackers/reviewers we just insist on 2
different people. So nagging works too, if you don't find that
frustrating.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch