Message ID | 20231020225338.1686974-1-javierm@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce89:0:b0:403:3b70:6f57 with SMTP id p9csp18206vqx; Fri, 20 Oct 2023 15:55:09 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGARktFdKG5CsDgY2OQWxKjmLQ/A3aLFLRS639aDcpzPn2BaIZI0fsX6lsE6Be1tQFToF2c X-Received: by 2002:a05:6358:4324:b0:132:d333:4a5c with SMTP id r36-20020a056358432400b00132d3334a5cmr3483990rwc.10.1697842508860; Fri, 20 Oct 2023 15:55:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697842508; cv=none; d=google.com; s=arc-20160816; b=ADygW9lh62rsmyAP9zhrXbtdCOaXNQ8XrWpyfdDlq6UwIkT5QiTQZbOfIIqwIXp0Ka u+SSuju7vHclHc6hwGqZWN1vdIltzSIs1P5SZoDL/TgyJu95eU1orZJPvLyQDFm7sXyz PCC9sS5ZBaob34PjGXjny79tApmqiq4g/XrfLnV4WikmrqVsRUskB0NeUCv1/GfsBsGI Pa3FLlCtvVxjvnGiY+yDCoxjHRvNPl0PKpRN39KljrEkagX37mq0UXMXBZsOEBAz67vs hahtROfoLFZjjcOg56SgNusXnoRfcdD1c1f5ow/EQ4iQ6ZTGGPiQke/cGmr0HNlyVjxo n0EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=qFRLhmS2CQCqNG3Gndm1rIdWDDyvH+OTofhMbIHOAf0=; fh=Nlwr9gfafUBeUgiMW4h9Si49OMO65mtO1h4sOC/yEzE=; b=VxDgdPfbyx8piGyD6uezNIqmA3do8D0bSfbNm8NMXkXUfGr7c8rmpJZg6hofZ1rNXx OhInMVgcM1podGPz8nSmpjFC2aVew2Qj0TV16wy++/p4SNfwmV7jud4juuVku56TlLby Mtfdzr3ZMargSMVcZVkP+ZpWCh9bZxvvVgPZ2fzw/uZbGQADogbOewFMWEekipOxVp6W 11bXme+gTUdIRQPhm+9k1u19c74iXbqsrPJwt+iIxZ2oGWc4KudO3WiKtUZnGL/SA3Ii Fj7V7gpWPHgHCpbwAYZPwtEd/4TaphhbaBdcAzLJHx1CtI916omCbEh03GqZWFTkcu+p ByUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QAfKHyDr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id bx23-20020a056a02051700b005aba9cdf091si2996823pgb.579.2023.10.20.15.55.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Oct 2023 15:55:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QAfKHyDr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id BF5FC8434AF1; Fri, 20 Oct 2023 15:55:06 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230142AbjJTWyv (ORCPT <rfc822;a1648639935@gmail.com> + 26 others); Fri, 20 Oct 2023 18:54:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbjJTWyu (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 20 Oct 2023 18:54:50 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7AFD8D68 for <linux-kernel@vger.kernel.org>; Fri, 20 Oct 2023 15:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697842443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=qFRLhmS2CQCqNG3Gndm1rIdWDDyvH+OTofhMbIHOAf0=; b=QAfKHyDrAfN7Y5Qccy+DYy707PCW6ZuGHWAb9FQ9gVPFGTl3kaonhmsfi6uUvUykrLW6s9 S3Dnaf1e+bdTHHTtA1SyntMoDBbMcM4T4GqeJvRf3QbuHMcQ/+/cWguV6uAxjX5V99ElCz kdKfjJnlLbRLKVjepnk8mC57AEbwyEY= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-257-Dp0jy4rKMSiZ67rfzU6qWw-1; Fri, 20 Oct 2023 18:54:02 -0400 X-MC-Unique: Dp0jy4rKMSiZ67rfzU6qWw-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-40768556444so7821885e9.3 for <linux-kernel@vger.kernel.org>; Fri, 20 Oct 2023 15:54:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697842440; x=1698447240; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qFRLhmS2CQCqNG3Gndm1rIdWDDyvH+OTofhMbIHOAf0=; b=FEyMfjRth98es+CzSpvwKEfwPZUuFFrcHvT0yHFpDTEAMILa++dSYhuDr0rfunAB0j H7YRgoTp+tYibU4aS59XSMnbJzOB+dG6YWQVGqalgYxB7Z4CrJttJgRc/h6hRmjqWm7T 8i338UNFnzZEskAJIOGH0fMY6/rzNlVTWBdplM+/YKytG/sAahVdTMqNun5WO+EFbMIi vLdl59d3pbkbsU+OZ5OMDOzKomjoPg4qdlmXwr/dIdsRroikrD0MDLh4bAoGEc9uJcoU Q425vFEm5NIvt5T+OYBidbGJfZkJpnO+8CW1ZMkp3gFBVNQ/3dMMxHltj0YYohGQpjGY bdag== X-Gm-Message-State: AOJu0YyJiVLZETFwNuSgODBuxIBgEB3bS8oSOiPC2Gft6wzBJ5+5ydK4 Z/RRNo9DeUeMioJ/R8EcpKzU4Q6csxFPk/GwpZkNh8so38fKVagIm7TICQDwmmBobrUsfX4lm1u ycfp/1sRC10Xph7NNmTtgTkqNmK4ED3FZ3bbPt6jkKS+1kcgzRNR5JJwG8qNlVcds85a5mxd6HQ c0zRWoJwI= X-Received: by 2002:a5d:58ea:0:b0:32d:819d:ec75 with SMTP id f10-20020a5d58ea000000b0032d819dec75mr2386189wrd.60.1697842440557; Fri, 20 Oct 2023 15:54:00 -0700 (PDT) X-Received: by 2002:a5d:58ea:0:b0:32d:819d:ec75 with SMTP id f10-20020a5d58ea000000b0032d819dec75mr2386176wrd.60.1697842440162; Fri, 20 Oct 2023 15:54:00 -0700 (PDT) Received: from localhost (205.pool92-176-231.dynamic.orange.es. [92.176.231.205]) by smtp.gmail.com with ESMTPSA id b16-20020a5d5510000000b0032d2489a399sm2530010wrv.49.2023.10.20.15.53.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Oct 2023 15:53:59 -0700 (PDT) From: Javier Martinez Canillas <javierm@redhat.com> To: linux-kernel@vger.kernel.org Cc: Javier Martinez Canillas <javierm@redhat.com>, Dan Carpenter <dan.carpenter@linaro.org>, Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@gmail.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, dri-devel@lists.freedesktop.org Subject: [PATCH] drm/ssd130x: Fix possible uninitialized usage of crtc_state variable Date: Sat, 21 Oct 2023 00:52:57 +0200 Message-ID: <20231020225338.1686974-1-javierm@redhat.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Fri, 20 Oct 2023 15:55:06 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780316906734259154 X-GMAIL-MSGID: 1780316906734259154 |
Series |
drm/ssd130x: Fix possible uninitialized usage of crtc_state variable
|
|
Commit Message
Javier Martinez Canillas
Oct. 20, 2023, 10:52 p.m. UTC
Avoid a possible uninitialized use of the crtc_state variable in function
ssd132x_primary_plane_atomic_check() and avoid the following Smatch warn:
drivers/gpu/drm/solomon/ssd130x.c:921 ssd132x_primary_plane_atomic_check()
error: uninitialized symbol 'crtc_state'.
Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/dri-devel/7dd6ca45-8263-44fe-a318-2fd9d761425d@moroto.mountain/
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---
drivers/gpu/drm/solomon/ssd130x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Hi, On 21/10/2023 00:52, Javier Martinez Canillas wrote: > Avoid a possible uninitialized use of the crtc_state variable in function > ssd132x_primary_plane_atomic_check() and avoid the following Smatch warn: > > drivers/gpu/drm/solomon/ssd130x.c:921 ssd132x_primary_plane_atomic_check() > error: uninitialized symbol 'crtc_state'. That looks trivial, so you can add: Acked-by: Jocelyn Falempe <jfalempe@redhat.com> > > Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") > Reported-by: Dan Carpenter <dan.carpenter@linaro.org> > Closes: https://lore.kernel.org/dri-devel/7dd6ca45-8263-44fe-a318-2fd9d761425d@moroto.mountain/ > Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> > --- > > drivers/gpu/drm/solomon/ssd130x.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c > index 32f0857aec9f..e0174f82e353 100644 > --- a/drivers/gpu/drm/solomon/ssd130x.c > +++ b/drivers/gpu/drm/solomon/ssd130x.c > @@ -910,7 +910,7 @@ static int ssd132x_primary_plane_atomic_check(struct drm_plane *plane, > struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(state, plane); > struct ssd130x_plane_state *ssd130x_state = to_ssd130x_plane_state(plane_state); > struct drm_crtc *crtc = plane_state->crtc; > - struct drm_crtc_state *crtc_state; > + struct drm_crtc_state *crtc_state = NULL; > const struct drm_format_info *fi; > unsigned int pitch; > int ret;
Jocelyn Falempe <jfalempe@redhat.com> writes: > Hi, > > On 21/10/2023 00:52, Javier Martinez Canillas wrote: >> Avoid a possible uninitialized use of the crtc_state variable in function >> ssd132x_primary_plane_atomic_check() and avoid the following Smatch warn: >> >> drivers/gpu/drm/solomon/ssd130x.c:921 ssd132x_primary_plane_atomic_check() >> error: uninitialized symbol 'crtc_state'. > > That looks trivial, so you can add: > > Acked-by: Jocelyn Falempe <jfalempe@redhat.com> > Pushed to drm-misc (drm-misc-next). Thanks!
Hi Javier, On Fri, Oct 27, 2023 at 11:33 AM Javier Martinez Canillas <javierm@redhat.com> wrote: > Jocelyn Falempe <jfalempe@redhat.com> writes: > > On 21/10/2023 00:52, Javier Martinez Canillas wrote: > >> Avoid a possible uninitialized use of the crtc_state variable in function > >> ssd132x_primary_plane_atomic_check() and avoid the following Smatch warn: > >> > >> drivers/gpu/drm/solomon/ssd130x.c:921 ssd132x_primary_plane_atomic_check() > >> error: uninitialized symbol 'crtc_state'. > > > > That looks trivial, so you can add: > > > > Acked-by: Jocelyn Falempe <jfalempe@redhat.com> > > > > Pushed to drm-misc (drm-misc-next). Thanks! Looks like you introduced an unintended (cherry picked from commit 9e4db199e66d427c50458f4d72734cc4f0b92948) ? Gr{oetje,eeting}s, Geert
Geert Uytterhoeven <geert@linux-m68k.org> writes: Hello Geert, > Hi Javier, > > On Fri, Oct 27, 2023 at 11:33 AM Javier Martinez Canillas > <javierm@redhat.com> wrote: >> Jocelyn Falempe <jfalempe@redhat.com> writes: >> > On 21/10/2023 00:52, Javier Martinez Canillas wrote: >> >> Avoid a possible uninitialized use of the crtc_state variable in function >> >> ssd132x_primary_plane_atomic_check() and avoid the following Smatch warn: >> >> >> >> drivers/gpu/drm/solomon/ssd130x.c:921 ssd132x_primary_plane_atomic_check() >> >> error: uninitialized symbol 'crtc_state'. >> > >> > That looks trivial, so you can add: >> > >> > Acked-by: Jocelyn Falempe <jfalempe@redhat.com> >> > >> >> Pushed to drm-misc (drm-misc-next). Thanks! > > Looks like you introduced an unintended > > (cherry picked from commit 9e4db199e66d427c50458f4d72734cc4f0b92948) > > ? > No, that's intended. It's added by the `dim cherry-pick` command, since I had to cherry-pick to drm-misc-next-fixes the commit that was already in the drm-misc-next branch. You will find that message in many drm commits, i.e: $ git log --oneline --grep="(cherry picked from commit" drivers/gpu/drm/ | wc -l 1708 > Gr{oetje,eeting}s, >
Hi Javier, On Tue, Oct 31, 2023 at 11:11 AM Javier Martinez Canillas <javierm@redhat.com> wrote: > Geert Uytterhoeven <geert@linux-m68k.org> writes: > > On Fri, Oct 27, 2023 at 11:33 AM Javier Martinez Canillas > > <javierm@redhat.com> wrote: > >> Jocelyn Falempe <jfalempe@redhat.com> writes: > >> > On 21/10/2023 00:52, Javier Martinez Canillas wrote: > >> >> Avoid a possible uninitialized use of the crtc_state variable in function > >> >> ssd132x_primary_plane_atomic_check() and avoid the following Smatch warn: > >> >> > >> >> drivers/gpu/drm/solomon/ssd130x.c:921 ssd132x_primary_plane_atomic_check() > >> >> error: uninitialized symbol 'crtc_state'. > >> > > >> > That looks trivial, so you can add: > >> > > >> > Acked-by: Jocelyn Falempe <jfalempe@redhat.com> > >> > > >> > >> Pushed to drm-misc (drm-misc-next). Thanks! > > > > Looks like you introduced an unintended > > > > (cherry picked from commit 9e4db199e66d427c50458f4d72734cc4f0b92948) > > > > ? > > > > No, that's intended. It's added by the `dim cherry-pick` command, since I > had to cherry-pick to drm-misc-next-fixes the commit that was already in > the drm-misc-next branch. > > You will find that message in many drm commits, i.e: > > $ git log --oneline --grep="(cherry picked from commit" drivers/gpu/drm/ | wc -l > 1708 Ah, so that's why it's (way too) common to have merge conflicts between the fixes and non-fixes drm branches :-( Gr{oetje,eeting}s, Geert
Geert Uytterhoeven <geert@linux-m68k.org> writes: > Hi Javier, [...] >> >> Pushed to drm-misc (drm-misc-next). Thanks! >> > >> > Looks like you introduced an unintended >> > >> > (cherry picked from commit 9e4db199e66d427c50458f4d72734cc4f0b92948) >> > >> > ? >> > >> >> No, that's intended. It's added by the `dim cherry-pick` command, since I >> had to cherry-pick to drm-misc-next-fixes the commit that was already in >> the drm-misc-next branch. >> >> You will find that message in many drm commits, i.e: >> >> $ git log --oneline --grep="(cherry picked from commit" drivers/gpu/drm/ | wc -l >> 1708 > > Ah, so that's why it's (way too) common to have merge conflicts between > the fixes and non-fixes drm branches :-( > I guess so. In this particular case it was my fault because I pushed to drm-misc-next with the expectation that there would be a last PR before the drm-next tree was sent to Torvalds but I missed for a few hours... So then I had the option for the fixes to miss 6.7 and wait to land in 6.8, or cherry-pick them to the drm-misc-next-fixes branch and pollute the git history log :( > Gr{oetje,eeting}s, > > Geert >
On Tue, Oct 31, 2023 at 12:27:05PM +0100, Javier Martinez Canillas wrote: > Geert Uytterhoeven <geert@linux-m68k.org> writes: > > > Hi Javier, > > [...] > > >> >> Pushed to drm-misc (drm-misc-next). Thanks! > >> > > >> > Looks like you introduced an unintended > >> > > >> > (cherry picked from commit 9e4db199e66d427c50458f4d72734cc4f0b92948) > >> > > >> > ? > >> > > >> > >> No, that's intended. It's added by the `dim cherry-pick` command, since I > >> had to cherry-pick to drm-misc-next-fixes the commit that was already in > >> the drm-misc-next branch. > >> > >> You will find that message in many drm commits, i.e: > >> > >> $ git log --oneline --grep="(cherry picked from commit" drivers/gpu/drm/ | wc -l > >> 1708 > > > > Ah, so that's why it's (way too) common to have merge conflicts between > > the fixes and non-fixes drm branches :-( > > > > I guess so. In this particular case it was my fault because I pushed to > drm-misc-next with the expectation that there would be a last PR before > the drm-next tree was sent to Torvalds but I missed for a few hours... > > So then I had the option for the fixes to miss 6.7 and wait to land in > 6.8, or cherry-pick them to the drm-misc-next-fixes branch and pollute > the git history log :( Yeah, it's the downside of having so many committers, we have to expect that people are going to make small mistakes every now and then and that's ok. That's also not as bad as Geert put it: merging two branches with the exact same commit applied won't create conflict. If the two commits aren't exactly the same then we can indeed create conflicts, but that would have been the case anyway with or without the "double-commits" Maxime
Hi Maxime, On Tue, Oct 31, 2023 at 12:53 PM Maxime Ripard <mripard@kernel.org> wrote: > On Tue, Oct 31, 2023 at 12:27:05PM +0100, Javier Martinez Canillas wrote: > > Geert Uytterhoeven <geert@linux-m68k.org> writes: > > >> >> Pushed to drm-misc (drm-misc-next). Thanks! > > >> > > > >> > Looks like you introduced an unintended > > >> > > > >> > (cherry picked from commit 9e4db199e66d427c50458f4d72734cc4f0b92948) > > >> > > > >> > ? > > >> > > >> No, that's intended. It's added by the `dim cherry-pick` command, since I > > >> had to cherry-pick to drm-misc-next-fixes the commit that was already in > > >> the drm-misc-next branch. > > >> > > >> You will find that message in many drm commits, i.e: > > >> > > >> $ git log --oneline --grep="(cherry picked from commit" drivers/gpu/drm/ | wc -l > > >> 1708 > > > > > > Ah, so that's why it's (way too) common to have merge conflicts between > > > the fixes and non-fixes drm branches :-( > That's also not as bad as Geert put it: merging two branches with the > exact same commit applied won't create conflict. If the two commits > aren't exactly the same then we can indeed create conflicts, but that > would have been the case anyway with or without the "double-commits" Oh it is, as soon as one branch receives more commits that make changes to the same location. Which is fairly common, too, to the point that I am surprised when merging a drm for-next branch does not trigger a conflict... Cfr. the conflict I had to resolve this morning between commit 64ffd2f1d00c6235 ("drm/amd: Disable ASPM for VI w/ all Intel systems") already upstream, and commits e5f52a84bf0a8170 ("drm/amd: Disable ASPM for VI w/ all Intel systems") and follow-up 2757a848cb0f1848 ("drm/amd: Explicitly disable ASPM when dynamic switching disabled") in drm/drm-next. Note that none of 64ffd2f1d00c6235 and 2757a848cb0f1848 has a "cherry picked from commit" line in the commit description. Gr{oetje,eeting}s, Geert
On Tue, Oct 31, 2023 at 02:00:06PM +0100, Geert Uytterhoeven wrote: > Hi Maxime, > > On Tue, Oct 31, 2023 at 12:53 PM Maxime Ripard <mripard@kernel.org> wrote: > > On Tue, Oct 31, 2023 at 12:27:05PM +0100, Javier Martinez Canillas wrote: > > > Geert Uytterhoeven <geert@linux-m68k.org> writes: > > > >> >> Pushed to drm-misc (drm-misc-next). Thanks! > > > >> > > > > >> > Looks like you introduced an unintended > > > >> > > > > >> > (cherry picked from commit 9e4db199e66d427c50458f4d72734cc4f0b92948) > > > >> > > > > >> > ? > > > >> > > > >> No, that's intended. It's added by the `dim cherry-pick` command, since I > > > >> had to cherry-pick to drm-misc-next-fixes the commit that was already in > > > >> the drm-misc-next branch. > > > >> > > > >> You will find that message in many drm commits, i.e: > > > >> > > > >> $ git log --oneline --grep="(cherry picked from commit" drivers/gpu/drm/ | wc -l > > > >> 1708 > > > > > > > > Ah, so that's why it's (way too) common to have merge conflicts between > > > > the fixes and non-fixes drm branches :-( > > > That's also not as bad as Geert put it: merging two branches with the > > exact same commit applied won't create conflict. If the two commits > > aren't exactly the same then we can indeed create conflicts, but that > > would have been the case anyway with or without the "double-commits" > > Oh it is, as soon as one branch receives more commits that make changes > to the same location. Which is fairly common, too, to the point > that I am surprised when merging a drm for-next branch does not trigger > a conflict... > > Cfr. the conflict I had to resolve this morning between commit > 64ffd2f1d00c6235 ("drm/amd: Disable ASPM for VI w/ all Intel systems") > already upstream, and commits e5f52a84bf0a8170 ("drm/amd: Disable ASPM > for VI w/ all Intel systems") and follow-up 2757a848cb0f1848 > ("drm/amd: Explicitly disable ASPM when dynamic switching disabled") > in drm/drm-next. I probably don't get what you're saying, sorry, but those two commits would have conflicted anyway when merging the two branches, with or without the cherry-pick. Maxime
diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c index 32f0857aec9f..e0174f82e353 100644 --- a/drivers/gpu/drm/solomon/ssd130x.c +++ b/drivers/gpu/drm/solomon/ssd130x.c @@ -910,7 +910,7 @@ static int ssd132x_primary_plane_atomic_check(struct drm_plane *plane, struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(state, plane); struct ssd130x_plane_state *ssd130x_state = to_ssd130x_plane_state(plane_state); struct drm_crtc *crtc = plane_state->crtc; - struct drm_crtc_state *crtc_state; + struct drm_crtc_state *crtc_state = NULL; const struct drm_format_info *fi; unsigned int pitch; int ret;