Re: [PATCH 0/1] coresight: Fix for v5.3-rc3

On Thu, Aug 01, 2019 at 02:16:46PM -0600, Mathieu Poirier wrote:

On Thu, 1 Aug 2019 at 12:17, Greg KH [off-list ref] wrote:

quoted

On Thu, Aug 01, 2019 at 11:23:22AM -0600, Mathieu Poirier wrote:

quoted

Good morning Greg,

Here is a fix I'd like you to consider for this cycle.  Do you think you
could apply it to driver-core-next rather than char-misc-next?

All of my -next branches are for 5.4-rc1, not 5.3 (i.e. the "next"
kernel).

So either one of them isn't going to matter to you for 5.3-final.

quoted

My current
coresight branch is based on driver-core-next to pick up Suzuki's
generic device lookup helpers patchset [1]. Applying it to char-misc-next
will create two different signature for the same patch, something that
gives Stephen a hard time when building the linux-next tree.

Why would Suzuki's patch matter for 5.3-final?

There was a similar situation during the 5.2 cycle [1].  Here too we
can fix a problem that is present in 5.3 rather than wait for 5.4.

[1]. https://www.spinics.net/lists/arm-kernel/msg736274.html

But that has nothing to do with Suzuki's patch that is in my driver core
tree.  I still fail to see the dependency here.

quoted

quoted

I also think this patch should go in stable but haven't marked it as such since
it doesn't apply to any of the stable trees.  Once it is part of v5.3 I intend
to send a new version of the patch that does apply cleanly to those trees.  Let
me know if you want me to proceed differently.

Thanks,
Mathieu

[1]. https://www.spinics.net/lists/dri-devel/msg219674.html


Suzuki K Poulose (1):
  coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute

 drivers/hwtracing/coresight/coresight-etm-perf.c | 1 +
 1 file changed, 1 insertion(+)

Why would this patch depend on anything in any of my trees?

I send you patches for inclusion in the next cycle and as such I
thought it should be the same for fixes in the current cycle.  If that
is not the case, should I send them directly to Linus?

You can send me fixes to forward on to Linus for this current cycle, if
they are not depending on patches that are only for the -next release.

I always keep 2 branches in my git trees:
	-linus : patches for Linus this release cycle
	-next  : patches for Linus the next release cycle

If you have bugfixes, make them against my -linus branch and send them
on.  Odds are they don't have dependancies other than what is in Linus's
tree, so that's fine.

If you have patches for the next cycle, send them against my -next
branch.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel