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

Suzuki K Poulose suzuki.poulose at arm.com
Mon Oct 30 05:53:58 PDT 2023


On 30/10/2023 12:44, Greg KH wrote:
> 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 ?

Ok

> 
> 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.

Ok.

> 
>>      (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.

Noted.

Thanks
Suzuki

> 
> thanks,
> 
> greg k-h




More information about the linux-arm-kernel mailing list