Re: [PATCH v2 0/2] arm64: Run enable method for errata work arounds on late CPUs

[Suzuki K Poulose <Suzuki.Poulose@arm.com>]

On 18/01/18 14:25, Suzuki K Poulose wrote:
> On 18/01/18 14:21, Dave Martin wrote:
>> On Thu, Jan 18, 2018 at 12:08:43PM +0000, Robin Murphy wrote:
>>> On 18/01/18 12:00, Robin Murphy wrote:
>>> [...]
>>>>> +struct enable_arg {
>>>>> +    int (*enable)(struct arm64_cpu_capabilities const *);
>>>>> +    struct arm64_cpu_capabilities const *cap;
>>>>> +};
>>>>> +
>>>>> +static int __enable_cpu_capability(void *arg)
>>>>> +{
>>>>> +    struct enable_arg const *e = arg;
>>>>> +
>>>>> +    return e->enable(e->cap);
>>>>> +}
>>>>
>>>> AFAICS, you shouldn't even need the intermediate struct - if you were
>>>> instead to call stop_machine(&caps->enable, ...), the wrapper could be:
>>>>
>>>>      <type> **fn = arg;
>>>>      *fn(container_of(fn, struct arm64_cpu_capabilities, enable));
>>>>
>>>> (cheaty pseudocode because there's no way I'm going to write a
>>>> pointer-to-function-pointer type correctly in an email client...)
>>>>
>>>> That's certainly a fair bit simpler in terms of diffstat; whether it's
>>>> really as intuitive as I think it is is perhaps another matter, though.
>>>
>>> Ah, right, but then you'd be back to casting away const, and at that point
>>> it makes no sense to do the container_of dance instead of just passing the
>>> struct pointer itself around...
>>>
>>> I shall now excuse myself from this discussion, as I'm clearly not helping
>>> :)
>>>
>>> Robin.
>>
>> That's what I was about to say... but neat trick.
>>
>> However, it does concentrate the type fudge in one place and keeps the
>> arm64_cpu_capabilities::enable() prototype correct, so it's still better
>> than the original.
>>
>>
>> Thinking about it, the following is probably clearer and no worse:
>>
>> static int __enable_cpu_capability(void *arg)
>> {
>>     struct arm64_cpu_capabilities const *cap = arg;
>>
>>     return cap->enable(cap);
>> }
>>
>> ...
>>
>> stop_machine(__enable_cpu_capability, (void *)caps, cpu_online_mask);
>>
>>
>> In your version, the argument would be (void *)&caps->enable, which is
>> really just a proxy for (void *)caps, unless I missed something.
>>
>>
>> What do you think Suzuki?  I can respin my patch if you fancy picking it
>> up.  Either way, it's not urgent.
> 
> Thanks for cooking that up Dave & Robin. I prefer your second version.
> Please feel free to respin it. As you rightly said, this is not urgent
> and could pick it up in my re-writing of the capability infrastructure ;-)

Dave,

I have picked this up in my new series for revamping cpu capabilities and
will send it after a bit of testing. So, no need to respin it.

Cheers
Suzuki