[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7e19c9a0-603f-bbef-bd13-bf7252ad38e6@arm.com>
Date: Thu, 18 Jan 2018 18:31:34 +0000
From: Suzuki K Poulose <Suzuki.Poulose@....com>
To: Dave Martin <Dave.Martin@....com>,
Robin Murphy <robin.murphy@....com>
Cc: mark.rutland@....com, marc.zyngier@....com,
catalin.marinas@....com, will.deacon@....com,
linux-kernel@...r.kernel.org, james.morse@....com,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 0/2] arm64: Run enable method for errata work arounds
on late CPUs
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
Powered by blists - more mailing lists