[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