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

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

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

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?

Thanks,
Mathieu

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