| Message ID | 20221116105702.746ce3cf@canb.auug.org.au (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | linux-next: manual merge of the drm-misc tree with the origin tree | expand |
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
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.