[PATCH v6 00/15] arm64: Self-hosted trace related errata workarounds

[Greg KH]

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