Message ID | 20211019163153.3692640-1-suzuki.poulose@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | arm64: Self-hosted trace related errata workarounds | expand |
On Tue, Oct 19, 2021 at 05:31:38PM +0100, Suzuki K Poulose wrote: > > This series adds CPU erratum work arounds related to the self-hosted > tracing. The list of affected errata handled in this series are : > > * TRBE may overwrite trace in FILL mode > - Arm Neoverse-N2 #2139208 > - Cortex-A710 #211985 > > * A TSB instruction may not flush the trace completely when executed > in trace prohibited region. > > - Arm Neoverse-N2 #2067961 > - Cortex-A710 #2054223 > > * TRBE may write to out-of-range address > - Arm Neoverse-N2 #2253138 > - Cortex-A710 #2224489 > > The series applies on coresight/next. The series has been reordered > to make it easier to merge the patches via arm64 tree and the coresight > tree. > > Patches 1-4 are could be picked up via arm64 tree. The rest can go via > the coresight tree. The Kconfig items for the TRBE errata are initially > dropped in with dependency on COMPILE_TEST. These are dropped only after > the driver is equipped with the work around in later patches. > > > A tree is available here : > > git@git.gitlab.arm.com:linux-arm/linux-skp.git coresight/errata/trbe-tsb-n2-a710/v6 > > Changes since v5: > * https://lkml.kernel.org/r/20211014223125.2605031-1-suzuki.poulose@arm.com > - Fix typo in the Kconfig symbol usage in errata listing (Will) > - Fix typo in commit description for > "arm64: errata: Add detection for TRBE overwrite in FILL mode" > - Fix commit description checkpatch warnings on column length for: > "arm64: errata: Add detection for TRBE write to out-of-range" > - Collected Reviews/Acks from Mathieu/Anshuman/Will > > Changes since v4: > * https://lkml.kernel.org/r/20211012131743.2040596-1-suzuki.poulose@arm.com > > - Fix WARN on trbe driver probe on a hotplugged CPU, by making > sure that the arm_trbe_probe_cpu() is called from non-premptible > context. this_cpu_has_cap() doesn't like to be called from a > preemptible() context. > > - Fix Kconfig text issues pointed out by Randy > > Changes since v3: > > - Fix missing Kconfig selection for TSB flush failure erratum (Will) > Merged the Kconfig changes to the core patch for TSB. > - Use COMPILE_TEST dependency for the TRBE work arounds instead of > delaying the Kconfig entries. > > Changes since v2: > * https://lkml.kernel.org/r/20210921134121.2423546-1-suzuki.poulose@arm.com > - Dropped patch adding a helper to reach cpudata from perf handle > - Split the TSB erratum work around patch to split the Kconfig/erratum > list update changes(pushed to the end of the series). > - Added wrappers to check the erratum : > trbe_has_erratum(cpudata, TRBE_ERRATUM_<TITLE>) -> trbe_may_<title> > - More ASCII art explanation on workaround. > > Changes since v1: > * https://lkml.kernel.org/r/20210728135217.591173-1-suzuki.poulose@arm.com > - Added a fix to the TRBE driver handling of sink_specific data > - Added more description and ASCII art for overwrite in FILL mode > work around > - Added another TRBE erratum to the list. > "TRBE may write to out-of-range address" > Patches from 12-17 > - Added comment to list the expectations around TSB erratum workaround. > > > > 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. Thanks, Mathieu > > -- > 2.25.4 >
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. Thanks, Will [1] https://lore.kernel.org/all/20211008073229.GB32625@willie-the-truck/
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? Thanks, Mathieu > > Thanks, > > Will > > [1] https://lore.kernel.org/all/20211008073229.GB32625@willie-the-truck/
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. 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? Will
On Tue, 19 Oct 2021 17:31:38 +0100, Suzuki K Poulose wrote: > This series adds CPU erratum work arounds related to the self-hosted > tracing. The list of affected errata handled in this series are : > > * TRBE may overwrite trace in FILL mode > - Arm Neoverse-N2 #2139208 > - Cortex-A710 #211985 > > [...] Applied first four patches to arm64 (for-next/trbe-errata), thanks! [01/15] arm64: Add Neoverse-N2, Cortex-A710 CPU part definition https://git.kernel.org/arm64/c/2d0d656700d6 [02/15] arm64: errata: Add detection for TRBE overwrite in FILL mode https://git.kernel.org/arm64/c/b9d216fcef42 [03/15] arm64: errata: Add workaround for TSB flush failures https://git.kernel.org/arm64/c/fa82d0b4b833 [04/15] arm64: errata: Add detection for TRBE write to out-of-range https://git.kernel.org/arm64/c/8d81b2a38ddf Mathieu -- feel free to pull this into the coresight tree, as I won't be rebasing it. Cheers,
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
On Thu, Oct 21, 2021 at 05:47:31PM +0100, Will Deacon 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. > > 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 :) thanks, greg k-h
On Fri, Oct 22, 2021 at 09:14:38AM +0200, Greg KH wrote: > On Thu, Oct 21, 2021 at 05:47:31PM +0100, Will Deacon 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. > > > > 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. Regards, Mathieu > > thanks, > > greg k-h
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: > > On Thu, Oct 21, 2021 at 05:47:31PM +0100, Will Deacon 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. > > > > > > 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 > > > > > thanks, > > > > greg k-h
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: > > On Thu, Oct 21, 2021 at 05:47:31PM +0100, Will Deacon 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. > > > > > > 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? For some reason I did not take a pull request for coresight patches in the beginning, right? I think it was due to a number of times that the patches submitted needed changes, which a pull request would not have allowed to have happen easily. > 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. If you feel the coresight subsystem should just go in through normal pull requests, I'm fine to take them that way now if it makes things easier for you as I can not remember an issue with these patches in quite some time. So perhaps it's time to change the workflow :) thanks, greg k-h