[PATCH v3 4/5] tools headers arm64: Update sysreg.h with kernel sources

[Eric Auger]

Hi Oliver,

On 10/19/23 02:06, Oliver Upton wrote:
> Hi Eric,
> 
> Thanks for reviewing the series.
> 
> On Wed, Oct 18, 2023 at 03:06:12PM +0200, Eric Auger wrote:
>> Hi Mark, Oliver,
>>
>> On 10/18/23 14:16, Mark Brown wrote:
>>> On Wed, Oct 18, 2023 at 01:57:31PM +0200, Eric Auger wrote:
>>>> On 10/11/23 21:57, Oliver Upton wrote:
>>>
>>>>>  #define set_pstate_pan(x)		asm volatile(SET_PSTATE_PAN(x))
>>>>>  #define set_pstate_uao(x)		asm volatile(SET_PSTATE_UAO(x))
>>>>>  #define set_pstate_ssbs(x)		asm volatile(SET_PSTATE_SSBS(x))
>>>>> +#define set_pstate_dit(x)		asm volatile(SET_PSTATE_DIT(x))
>>>
>>>> could you comment on the *DIT* addictions, what is it for?
>>>
>>> DIT is data independent timing, this tells the processor to ensure that
>>> instructions take a constant time regardless of the data they are
>>> handling.
>>
>>>
>>> Note that this file is just a copy of arch/arm64/include/asm/gpr-num.h,
>>> the main purpose here is to sync with the original.
>>
>> Ah thanks. that's helpful for me to understand where this gpr-num.h
>> comes from. This could be documented in the commit msg though.
>>
>> Something like:
>>
>> adding tools/arch/arm64/include/asm/gpr-num.h matching linux
>> arch/arm64/include/asm/gpr-num.h
>>
>> and syncing tools/arch/arm64/include/asm/sysreg.h with the fellow header
>> in the linux tree.
> 
> Yeah, I could've spelled it out a bit more. I already cracked this off
> of an even larger patch from before I picked up the series because the
> diff was massive.
> 
>> tbh I did not initially understand that all this diffstat was aimed to
>> match the linux arch/arm64/include/asm/sysreg.h. Now diffing both I have
>> some diffs. Doesn't it need a refresh?
> 
> I'm worried it is a fool's errand at this point to keep the two in sync,
> as I'm sure there will be more in -rc1. The tools copy of sysreg.h isn't
> a verbatim copy either, there are some deliberate deletions in there as
> well.
> 
> I've taken this as is, we can always come back and update the headers
> afterwards if we find a need for it

OK np. I did not notice you picked the series up and I jumped in too
late. Anyway that was worthwhile for my education ;-)

Eric
>