[PATCH 2/5] drivers/bus: Split Arm CCI driver

Robin Murphy robin.murphy at arm.com
Thu Feb 15 08:38:39 PST 2018


On 15/02/18 13:01, Will Deacon wrote:
> On Wed, Feb 14, 2018 at 02:28:15PM +0000, Robin Murphy wrote:
>> On 14/02/18 11:51, Will Deacon wrote:
>>> On Wed, Feb 07, 2018 at 01:07:53PM +0000, Robin Murphy wrote:
>>>> Hi Punit,
>>>>
>>>> On 07/02/18 12:22, Punit Agrawal wrote:
>>>> [...]
>>>>>> -static void __iomem *cci_ctrl_base;
>>>>>> +void __iomem *cci_ctrl_base __ro_after_init;
>>>>>
>>>>> Initially I wondered if cci_ctrl_base gets used in the pmu driver before
>>>>> it's initialised. But as it gets set in early_initcall() that looks to
>>>>> be fine.
>>>>
>>>> In fact it's even more robust than initcall ordering, since the PMU device
>>>> will only be created at all via cci_platform_probe(), thus cci_init() is
>>>> guaranteed to have run successfully before the PMU driver probe can ever
>>>> touch anything.
>>>
>>> Could you hijack the platform data at this point by passing an of_dev_auxdata
>>> to of_platform_populate and then use that to pass the __iomem address to the
>>> PMU driver?
>>
>> OK, I've cooked up the patch below (on top of this series), but I'm
>> currently somewhat on the fence about how nice it really is :/
> 
> Yeah, the ugly part is:
> 
>> +const struct of_dev_auxdata arm_cci_auxdata[] = {
>> +	OF_DEV_AUXDATA("arm,cci-400-pmu", 0, NULL, &cci_ctrl_base),
>> +	OF_DEV_AUXDATA("arm,cci-400-pmu,r0", 0, NULL, &cci_ctrl_base),
>> +	OF_DEV_AUXDATA("arm,cci-400-pmu,r1", 0, NULL, &cci_ctrl_base),
>> +	OF_DEV_AUXDATA("arm,cci-500-pmu,r0", 0, NULL, &cci_ctrl_base),
>> +	OF_DEV_AUXDATA("arm,cci-550-pmu,r0", 0, NULL, &cci_ctrl_base),
>> +	{}
>> +};
> 
> I suppose you could macro-ise this table to hide the redundancy, but it's up
> to you.

I did ponder various alternatives, but whatever the approach we still 
end up needing a copy of all the PMU compatible strings in this driver; 
in that context, I think the auxdata table is probably in fact the least 
invasive. And given that it's surrounded by MCPM code, trying to hide 
things behind more macros just brings to mind cosmetics and swine ;)

On reflection, I'm feeling a bit happier with this one now, so I'll add 
it on the end and resubmit the lot to arm-soc as you suggested (ta for 
the ack too).

Robin.



More information about the linux-arm-kernel mailing list