On Fri, Oct 22, 2021 at 09:13:11AM -0600, Mathieu Poirier wrote:

On Fri, Oct 22, 2021 at 09:14:38AM +0200, Greg KH wrote:

quoted

On Thu, Oct 21, 2021 at 05:47:31PM +0100, Will Deacon wrote:

quoted

Hi Mathieu,

[CC Greg]

On Thu, Oct 21, 2021 at 10:35:31AM -0600, Mathieu Poirier wrote:

quoted

On Thu, Oct 21, 2021 at 09:53:14AM +0100, Will Deacon wrote:

quoted

On Wed, Oct 20, 2021 at 09:42:07AM -0600, Mathieu Poirier wrote:

quoted

On Tue, Oct 19, 2021 at 05:31:38PM +0100, Suzuki K Poulose wrote:

quoted

Suzuki K Poulose (15):
  arm64: Add Neoverse-N2, Cortex-A710 CPU part definition
  arm64: errata: Add detection for TRBE overwrite in FILL mode
  arm64: errata: Add workaround for TSB flush failures
  arm64: errata: Add detection for TRBE write to out-of-range
  coresight: trbe: Add a helper to calculate the trace generated
  coresight: trbe: Add a helper to pad a given buffer area
  coresight: trbe: Decouple buffer base from the hardware base
  coresight: trbe: Allow driver to choose a different alignment
  coresight: trbe: Add infrastructure for Errata handling
  coresight: trbe: Workaround TRBE errata overwrite in FILL mode
  coresight: trbe: Add a helper to determine the minimum buffer size
  coresight: trbe: Make sure we have enough space
  coresight: trbe: Work around write to out of range
  arm64: errata: Enable workaround for TRBE overwrite in FILL mode
  arm64: errata: Enable TRBE workaround for write to out-of-range
    address

 Documentation/arm64/silicon-errata.rst       |  12 +
 arch/arm64/Kconfig                           | 111 ++++++
 arch/arm64/include/asm/barrier.h             |  16 +-
 arch/arm64/include/asm/cputype.h             |   4 +
 arch/arm64/kernel/cpu_errata.c               |  64 +++
 arch/arm64/tools/cpucaps                     |   3 +
 drivers/hwtracing/coresight/coresight-trbe.c | 394 +++++++++++++++++--
 7 files changed, 567 insertions(+), 37 deletions(-)

I have applied this set.

Mathieu -- the plan here (which we have discussed on the list [1]) is
for the first four patches to be shared with arm64. Since you've gone
ahead and applied the whole series, please can you provide me a stable
branch with the first four patches only so that I can include them in
the arm64 tree?

Failing that, I can create a branch for you to pull and apply the remaining
patches on top.

Please let me know.

Coresight patches flow through Greg's tree and as such the coresight-next tree
gets rebased anyway.  I will remove the first 4 patches and push again.  By the
way do you also want to pick up patches 14 and 16 since they are concerned with
"arch/arm64/Kconfig" or should I keep them?

I'll take the first 4 and put them on a stable branch, which you can choose
to pull if you like (but please don't rebase it or we'll end up with
duplicate commits). The rest of the patches, including the later Kconfig
changes, are yours but I doubt they'll apply cleanly without the initial
changes.

Are you sure Greg rebases everything? That sounds a bit weird to me, as it
means it's impossible to share branches with other trees. How do you usually
handle this situation?

No, I never rebase my trees.  For coresight patches I take them as
emailed patches due to previous history requiring me to review them all
myself.  If this is an issue here, I can always take a pull request as
long as you all don't want my review :)

Can you expand on the "previous history requiring" you to review coresight
patches?

Rebasing the coresight-next tree when patches are pulled in the char-misc tree
causes problems when features involve other subsystems.  I definitely appreciate
reviews of coresight patches from anyone. The subsystem has grown to be very
complex and more reviewers mean higher probabilities of catching problems.
There has to be a way for that to continue while making it easier to collaborate
with other subsystems.

For this particular patchset, Will has picked up the first 4 patches, I will pick up
patches 5 to 13 and patches 14 and 15 will have to go in the next cycle.  I
doubt this is the best we can do.

And that won't work either because some defines declared in in patches 1 to 4
are needed in patches 10 and 13.  I will send you a pull request for this cycle.

Regards,
Mathieu

quoted

thanks,

greg k-h

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