[RESEND] [GIT PULL] coresight: Update for v6.7

[Greg KH]

On Mon, Oct 30, 2023 at 12:04:55PM +0000, Suzuki K Poulose wrote:
> Hi Greg
> 
> On 30/10/2023 11:32, Greg KH wrote:
> > On Mon, Oct 30, 2023 at 11:02:04AM +0000, Suzuki K Poulose wrote:
> > > Hi Greg
> > > 
> > > Please find the updates for Linux v6.7. Kindly pull.
> > 
> > It's too late, sorry.  Last week might have been too late too, why the
> > last-minute pull request?
> 
> Apologies, I was out sick last week. I was hoping that there would be
> an rc8. The tree wasn't changed since last two weeks. I will try to
> send the pull request at rc5-rc6 now onwards.

Thank you.

> > Please send new changes after -rc1 is out for bugfixes and for normal
> > new features.
> 
> Just to make sure I understand this correctly,
>  - I can send a pull request with handpicked fixes for rc1

Yes, after -rc1 is out.

>  - What about the other new features ?

They need to wait until 6.8-rc1, you can send me a pull request for them
after -rc1 is out as well, for my -next branch.

>     (I can summaries the features below)
>     - TRBE ACPI support ( Parts of this feature went into v6.6 via
>  	Will's perf subsystem, the coresight part was dropped due to
>         a conflict. I queued it for v6.7 - 2patches)
>     - CoreSight TPDM support for DSB feature (~10patches)
>     - Support for configuring cycle count threshold for ETM (3 patches)
>    Do they need to wait for v6.8 or could some of them go in for v6.7 ?
> 
> 
> > 
> > > Please note the changes were queued and rebased onto v6.6-rc6 (which added
> > > some of the fixes in the cycle).
> > 
> > Why rebase?  What required that?
> 
> This was to be on the safer side. I don't think there was any conflict.

As Linus constantly says, NEVER rebase unless you have to.  That just
makes history messy, and makes me think that something actually changed.
Merge conflicts are fine, we can handle them trivially, do not rewrite
history just for that.

thanks,

greg k-h