On Thu, 21 Oct 2021 at 10:47, Will Deacon will@kernel.org wrote:
Hi Mathieu,
[CC Greg]
On Thu, Oct 21, 2021 at 10:35:31AM -0600, Mathieu Poirier wrote:
On Thu, Oct 21, 2021 at 09:53:14AM +0100, Will Deacon wrote:
On Wed, Oct 20, 2021 at 09:42:07AM -0600, Mathieu Poirier wrote:
On Tue, Oct 19, 2021 at 05:31:38PM +0100, Suzuki K Poulose wrote:
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.
Right - I just had another look at them and what I suggested above won't work.
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?
Greg applies the patches I send to him near the end of every cycle - see this one [1] as an example. Unfortunately that way of working makes it hard to deal with patchsets such as this one.
To move forward you can either pick up this whole series (just add my RB to all the CS patches) or I start sending pull requests to Greg.
Greg - what's your take on this?
[1]. https://www.spinics.net/lists/arm-kernel/msg915961.html
Will
Hi Mathieu,
On 21/10/2021 18:11, Mathieu Poirier wrote:
On Thu, 21 Oct 2021 at 10:47, Will Deacon will@kernel.org wrote:
Hi Mathieu,
[CC Greg]
On Thu, Oct 21, 2021 at 10:35:31AM -0600, Mathieu Poirier wrote:
On Thu, Oct 21, 2021 at 09:53:14AM +0100, Will Deacon wrote:
On Wed, Oct 20, 2021 at 09:42:07AM -0600, Mathieu Poirier wrote:
On Tue, Oct 19, 2021 at 05:31:38PM +0100, Suzuki K Poulose wrote:
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.
Right - I just had another look at them and what I suggested above won't work.
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?
Greg applies the patches I send to him near the end of every cycle - see this one [1] as an example. Unfortunately that way of working makes it hard to deal with patchsets such as this one.
To move forward you can either pick up this whole series (just add my RB to all the CS patches) or I start sending pull requests to Greg.
I don't think that may work well, as the CoreSight bits in the series depend on what is in coresight/next. So this series can't be pulled in to arm64 without what is already in coresight/next.
Suzuki
-
Mathieu Poirier -
Suzuki K Poulose