Message ID | 20221116105702.746ce3cf@canb.auug.org.au |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp3002725wru; Tue, 15 Nov 2022 16:00:06 -0800 (PST) X-Google-Smtp-Source: AA0mqf7EUTiZY3hoMT3dL0tfkgib9BvJAzrcRLIHksvg3FDa6MfXgLbmPwyMq5Z3rXWWCwpNxkl1 X-Received: by 2002:a17:906:4e0d:b0:7ad:b822:d2e4 with SMTP id z13-20020a1709064e0d00b007adb822d2e4mr15677499eju.35.1668556805618; Tue, 15 Nov 2022 16:00:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668556805; cv=none; d=google.com; s=arc-20160816; b=tfuAAm7SVmDG3mQbgqbDctI0ZfP8yi2X1Ofaj5h1obtFQOkQ6tnNHsV8IcOYPMhwIC KBtPpOS8m/eUXZ4vceXB2z4Y2fkQO2LlGi0jbdCIdFVommiEF3uGmizi32e7SwuMeGvY QDI/0OXTPzfMXpQ/X74eAbsjaYYcPt2+PJ7qHdyvqv4LjvO/ua+gr4VZSuhUX+eYZMkc GGL+B5ntmq01PYEGui9HlfLHgK7fofOKIiDTpMaI5fCUpvRPqZyqsw88W9Kdug4/1Rg+ w30eJX1yfJARWxknFmtLw53M8yKVsNzYZqx3MyLM+zinbjCLHpEQKjoETrCWLYlt7Bzh tOhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=SOAAR+njNw3INBbf23L+zGH83Vm3xaTAHvnq1EaTm9w=; b=zQtiRPruKMcUW3w18qendVIfp+QwEI6rAcOm2q3U1XStOzE4VLpfUUB7vfKg0RPf3z Gk+UMqo5vP1JROGsjX+KOMmxBgwTiFAgR6smrUeTHD0rXPu71XJyuGvfQy7ljhKlUdy7 lwyOg9M/jVxnwpchDp38DsQZGBZfzwrG3bVhIHSh/P8lZOhLeNPPakYcUZg5v4zTsOEE 3YLxYq3z8aBRg7DXS/MRq/JLaAUI+fJprKg9mT9pwSQE0QSdxNQqKXwmHfK2k+F1lh0X 0oz+BmGy5E8jdyNpby/W+H2zlP3j4wcQ6mXiVV/CUEKQA8dYZz0dHlpj/BYEEziGWqM9 E3zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b=dFFEw71Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x14-20020aa7d6ce000000b00461d97e5287si11204182edr.344.2022.11.15.15.59.41; Tue, 15 Nov 2022 16:00:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b=dFFEw71Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231216AbiKOX5J (ORCPT <rfc822;maxim.cournoyer@gmail.com> + 99 others); Tue, 15 Nov 2022 18:57:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231166AbiKOX5H (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 15 Nov 2022 18:57:07 -0500 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8356C1AF39; Tue, 15 Nov 2022 15:57:06 -0800 (PST) Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4NBjlN0Qr6z4xDK; Wed, 16 Nov 2022 10:57:04 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canb.auug.org.au; s=201702; t=1668556624; bh=SOAAR+njNw3INBbf23L+zGH83Vm3xaTAHvnq1EaTm9w=; h=Date:From:To:Cc:Subject:From; b=dFFEw71ZV9IPGSSlK8bMIhrvK/8LswAo675y4s0xoj8Fgx2vEVg/d0zAqCpC+KfW2 SLOHQqiTskERziUwvNS+PpxRYoYppcRNk7s7zCQdLXlGLAOFdewxgdp55TVhBhE3Qz VT5J23vwhNuwyuP8x40+oW+0ynF55YHlW+RfaXzWkaxQvJD92BaKfYBukng9UPXhoq 0sMzimdjNKJ8cfp/YkiOBb/VuWMQkWtvuWaxHuhSHstoeRrj1dSFOLt4W5nWDVsxE3 Ux6+Nt1yS+MBCNbkGojfL/lNzl6bjNsuXC34B5gCthzbb+WtWtQXQy9E7FP8cdwdos oaVfNwb6KKVFw== Date: Wed, 16 Nov 2022 10:57:02 +1100 From: Stephen Rothwell <sfr@canb.auug.org.au> To: Daniel Vetter <daniel.vetter@ffwll.ch>, Intel Graphics <intel-gfx@lists.freedesktop.org>, DRI <dri-devel@lists.freedesktop.org> Cc: =?utf-8?b?Sm9zw6kgRXhww7NzaXRv?= <jose.exposito89@gmail.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Next Mailing List <linux-next@vger.kernel.org>, Maxime Ripard <maxime@cerno.tech> Subject: linux-next: manual merge of the drm-misc tree with the origin tree Message-ID: <20221116105702.746ce3cf@canb.auug.org.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/P12Sa_2We=6e8ciHH2y4_Od"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749608620887790735?= X-GMAIL-MSGID: =?utf-8?q?1749608620887790735?= |
Series |
linux-next: manual merge of the drm-misc tree with the origin tree
|
|
Commit Message
Stephen Rothwell
Nov. 15, 2022, 11:57 p.m. UTC
Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/vc4/vc4_hdmi.c between commit: 682f99b8ae88 ("drm/vc4: hdmi: Take our lock to reset the link") from the origin tree and commits: d218750805a3 ("drm/vc4: hdmi: Pass vc4_hdmi to vc4_hdmi_supports_scrambling()") 0a99962c0dbf ("drm/vc4: hdmi: Fix pointer dereference before check") from the drm-misc tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts.
Comments
Hi Stephen, On Wed, Nov 16, 2022 at 10:57:02AM +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the drm-misc tree got a conflict in: > > drivers/gpu/drm/vc4/vc4_hdmi.c > > between commit: > > 682f99b8ae88 ("drm/vc4: hdmi: Take our lock to reset the link") > > from the origin tree and commits: > > d218750805a3 ("drm/vc4: hdmi: Pass vc4_hdmi to vc4_hdmi_supports_scrambling()") > 0a99962c0dbf ("drm/vc4: hdmi: Fix pointer dereference before check") > > from the drm-misc tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > -- > Cheers, > Stephen Rothwell > > diff --cc drivers/gpu/drm/vc4/vc4_hdmi.c > index d7fcc7a4c082,6b223a5fcf6f..000000000000 > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c > @@@ -349,12 -348,9 +348,13 @@@ static int vc4_hdmi_reset_link(struct d > if (!crtc_state->active) > return 0; > > + mutex_lock(&vc4_hdmi->mutex); > + > - if (!vc4_hdmi_supports_scrambling(encoder)) { > + vc4_hdmi = connector_to_vc4_hdmi(connector); > - if (!vc4_hdmi_supports_scrambling(vc4_hdmi)) > ++ if (!vc4_hdmi_supports_scrambling(vc4_hdmi)) { > + mutex_unlock(&vc4_hdmi->mutex); > return 0; > + } > > scrambling_needed = vc4_hdmi_mode_needs_scrambling(&vc4_hdmi->saved_adjusted_mode, > vc4_hdmi->output_bpc, This resolution is not quite right, as pointed out by clang: drivers/gpu/drm/vc4/vc4_hdmi.c:351:14: error: variable 'vc4_hdmi' is uninitialized when used here [-Werror,-Wuninitialized] mutex_lock(&vc4_hdmi->mutex); ^~~~~~~~ ./include/linux/mutex.h:187:44: note: expanded from macro 'mutex_lock' #define mutex_lock(lock) mutex_lock_nested(lock, 0) ^~~~ drivers/gpu/drm/vc4/vc4_hdmi.c:322:27: note: initialize the variable 'vc4_hdmi' to silence this warning struct vc4_hdmi *vc4_hdmi; ^ = NULL 1 error generated. Obviously, the assignment of vc4_hdmi should be before mutex_lock(). Cheers, Nathan
Hi Nathan, On Thu, 17 Nov 2022 10:29:33 -0700 Nathan Chancellor <nathan@kernel.org> wrote: > > This resolution is not quite right, as pointed out by clang: > > drivers/gpu/drm/vc4/vc4_hdmi.c:351:14: error: variable 'vc4_hdmi' is uninitialized when used here [-Werror,-Wuninitialized] > mutex_lock(&vc4_hdmi->mutex); > ^~~~~~~~ > ./include/linux/mutex.h:187:44: note: expanded from macro 'mutex_lock' > #define mutex_lock(lock) mutex_lock_nested(lock, 0) > ^~~~ > drivers/gpu/drm/vc4/vc4_hdmi.c:322:27: note: initialize the variable 'vc4_hdmi' to silence this warning > struct vc4_hdmi *vc4_hdmi; > ^ > = NULL > 1 error generated. > > Obviously, the assignment of vc4_hdmi should be before mutex_lock(). Thanks for pointing that out (silly me :-) ). I have fixed up the resolution for today.
On Fri, Nov 18, 2022 at 09:06:36AM +1100, Stephen Rothwell wrote: > Hi Nathan, > > On Thu, 17 Nov 2022 10:29:33 -0700 Nathan Chancellor <nathan@kernel.org> wrote: > > > > This resolution is not quite right, as pointed out by clang: > > > > drivers/gpu/drm/vc4/vc4_hdmi.c:351:14: error: variable 'vc4_hdmi' is uninitialized when used here [-Werror,-Wuninitialized] > > mutex_lock(&vc4_hdmi->mutex); > > ^~~~~~~~ > > ./include/linux/mutex.h:187:44: note: expanded from macro 'mutex_lock' > > #define mutex_lock(lock) mutex_lock_nested(lock, 0) > > ^~~~ > > drivers/gpu/drm/vc4/vc4_hdmi.c:322:27: note: initialize the variable 'vc4_hdmi' to silence this warning > > struct vc4_hdmi *vc4_hdmi; > > ^ > > = NULL > > 1 error generated. > > > > Obviously, the assignment of vc4_hdmi should be before mutex_lock(). > > Thanks for pointing that out (silly me :-) ). I have fixed up the > resolution for today. Great, thank you so much! One less warning to worry about :) Cheers, Nathan
On Thu, Nov 17, 2022 at 05:01:08PM -0700, Nathan Chancellor wrote: > On Fri, Nov 18, 2022 at 09:06:36AM +1100, Stephen Rothwell wrote: > > Hi Nathan, > > > > On Thu, 17 Nov 2022 10:29:33 -0700 Nathan Chancellor <nathan@kernel.org> wrote: > > > > > > This resolution is not quite right, as pointed out by clang: > > > > > > drivers/gpu/drm/vc4/vc4_hdmi.c:351:14: error: variable 'vc4_hdmi' is uninitialized when used here [-Werror,-Wuninitialized] > > > mutex_lock(&vc4_hdmi->mutex); > > > ^~~~~~~~ > > > ./include/linux/mutex.h:187:44: note: expanded from macro 'mutex_lock' > > > #define mutex_lock(lock) mutex_lock_nested(lock, 0) > > > ^~~~ > > > drivers/gpu/drm/vc4/vc4_hdmi.c:322:27: note: initialize the variable 'vc4_hdmi' to silence this warning > > > struct vc4_hdmi *vc4_hdmi; > > > ^ > > > = NULL > > > 1 error generated. > > > > > > Obviously, the assignment of vc4_hdmi should be before mutex_lock(). > > > > Thanks for pointing that out (silly me :-) ). I have fixed up the > > resolution for today. > > Great, thank you so much! One less warning to worry about :) I actually did the same conflict resolution in drm-tip. I've fixed it up too, thanks for your report :) Maxime
diff --cc drivers/gpu/drm/vc4/vc4_hdmi.c index d7fcc7a4c082,6b223a5fcf6f..000000000000 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c