[PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers

[Marek Szyprowski]

Hello,

On 2014-12-05 14:18, Thierry Reding wrote:
> On Fri, Dec 05, 2014 at 01:06:52PM +0000, Grant Likely wrote:
>> On Fri, Dec 5, 2014 at 12:35 PM, Robin Murphy <robin.murphy at arm.com> wrote:
>>> Hi Will,
>>>
>>> On 05/12/14 12:10, Will Deacon wrote:
>>> [...]
>>>>>> Do you expect drivers to modify that *priv pointer after the ops
>>>>>> structure is registered? I'd be very surprised if that was the use
>>>>>> case. It's fine for the driver to register a non-const version, but
>>>>>> once it is registered, the infrastructure can treat it as const from
>>>>>> then on.
>>>>>
>>>>> Possibly not - certainly my current port of the ARM SMMU which makes use
>>>>> of *priv is only ever reading it - although we did also wave around
>>>>> reasons for mutable ops like dynamically changing the pgsize_bitmap and
>>>>> possibly even swizzling individual ops for runtime reconfiguration. On
>>>>> consideration though, I'd agree that things like that are mad enough to
>>>>> stay well within individual drivers if they did ever happen, and
>>>>> certainly shouldn't apply to this bit of the infrastructure at any rate.
>>>>
>>>> I certainly need to update the pgsize_bitmap at runtime because I don't
>>>> know the supported page sizes until I've both (a) probed the hardware
>>>> and (b) allocated page tables for a domain. We've already discussed
>>>> moving the pgsize_bitmap out of the ops, but moving it somewhere where
>>>> it remains const doesn't really help.
>>>
>>> We can safely cast the call to get_ops in the SMMU driver though, since
>>> we'll know that we put a mutable per-instance ops in there in the first
>>> place. At least that way drivers that aren't taking advantage and just pass
>>> their static const ops around shouldn't provoke warnings. I deliberately
>>> didn't touch anything beyond get_ops as that would be too disruptive.
>>>
>>>> Can I just take the patch that Grant acked, in the interest of getting
>>>> something merged? As you say, there's plenty of planned changes in this
>>>> area anyway. I plan to send Olof a pull request this afternoon.
>>>
>>> Grant, Thierry? Personally I'm not fussed either way - the sooner something
>>> goes in, the sooner I can carry on working at replacing it :D
>> I've already acked it. Why are we still talking about it?  :-D
> Am I missing something? Why is there a need to rush things? Are there
> actually drivers that depend on this that will be merged during the 3.19
> merge window? It seems like that'd be cutting it really close given
> where we are in the release cycle.
>
> If that's not the case, why even bother getting this hack into 3.19 if
> nobody uses it and we're going to change it in 3.20 anyway?

There are Exynos SYSMMU patches ready & waiting for this gets merged...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland