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.mur...@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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
