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