Re: [iommu:apple/dart 3/3] drivers/iommu/apple-dart.c:730:17: error: initialization of 'size_t (*)(struct iommu_domain *, long unsigned int, size_t, struct iommu_iotlb_gather *)' {aka 'long unsigned int (*)(struct iommu_domain *, long unsigned int, long unsigned int, struct iom...

[Robin Murphy <robin.murphy@arm.com>]

On 2021-08-16 07:48, Sven Peter wrote:
> 
> 
> On Thu, Aug 12, 2021, at 13:29, Joerg Roedel wrote:
>> Hi Sven,
>>
>> On Tue, Aug 10, 2021 at 08:09:53AM +0200, Sven Peter wrote:
>>> This happens because apple/dart is missing the "Optimizing iommu_[map/unmap] performance"
>>> series which is already in the core branch [1].
>>> The same commit works fine in iommu/next since that branch merges both iommu/core and
>>> apple/dart.
>>
>> Okay, thanks. I re-based the DART patches on-top of my core branch,
>> which contains the changes for iommu_[map/unmap] performance. I
>> generally don't like rebasing topic branches, but made an exception here
>> to not break bisectability.
>>
>> Thanks,
>>
>> 	Joerg
>>
> 
> Hi Joerg,
> 
> Thanks, and sorry about that! I'll try to make it more clear if anything depends
> on another series in the future or just try to avoid it altogether if possible.
> 
> 
> Just a heads up about a similar situation you may already be aware of: Once Robin's
> DMA domain strictness refactoring [1] is merged, the current DART driver will fail due
> to patch 12 there, which unexports iommu_get_dma_cookie. It'll need a small
> adjustment just like all the other drivers (which will also fix two small bugs
> it just made me notice: I never use iommu_put_dma_cookie and also unconditionally
> grab a DMA cookie for all domain types).
> 
> Unless I'm mistaken I can't make that adjustment before the first patch of
> that series has been merged, and Robin can't make that adjustment in his series
> because it'll presumably go through another topic branch.

Hmm, the exports only affect modules though - the cookie functions are 
still public so that the core code can call them - so it should only 
break certain configs. Possibly the most self-contained way to avoid 
issues in -next would be to switch APPLE_DART from tristate to bool for 
now, then flip it back along with cleaning up the iommu-dma remnants at 
rc1. That should avoid any more rebasing at least.

At worst, my patch #12 could in principle be held back and applied at 
rc1 alongside the DART fixup - functionally it shouldn't be an issue, 
but patch #16 would need fixing up to apply without the context change.

Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu