y apply
> to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
> don't inadvertently get sign-extended, and thus considered invalid, if
> they happen to be above 2GB in the TTB0 region.
>
> Reported-by: Stephan Gerhold
> Signed-off-by: Robin Murphy
>
Than
Hi Will, Hi Robin,
On Fri, Jan 10, 2020 at 03:28:52PM +, Will Deacon wrote:
> From: Robin Murphy
>
> Now that we can correctly extract top-level indices without relying on
> the remaining upper bits being zero, the only remaining impediments to
> using a given table for TTBR1 are the
> Reported-by: Naresh Kamboju
> Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu")
> Signed-off-by: Robin Murphy
This fixes the warning reported by Naresh Kamboju [1] for me. Thank you!
Tested-by: Stephan Gerhold
[1]:
https://lore.kernel.org/linux-arm-msm/CA+G9fYtScOpkLvx=
Hi Robin,
On Mon, Jan 06, 2020 at 01:26:58PM +, Robin Murphy wrote:
> On 04/01/2020 12:20 am, Brian Masney wrote:
> > When attempting to load the qcom-iommu driver, and an -EPROBE_DEFER
> > error occurs, the following attempted NULL pointer deference occurs:
> >
> > Unable to handle
v will always be NULL.
> qcom_iommu_detach_dev() is called prior to freeing the IOMMU domain and
> is what sets the iommu member to NULL.
>
> Let's fix this by adding the 'struct dev' pointer to the
> qcom_iommu_domain struct.
>
> Signed-off-by: Brian Masney
> Fixes: 0a
On Mon, Dec 09, 2019 at 01:08:32PM +, Robin Murphy wrote:
> It makes little sense for dma_limit to be a dma_addr_t when we only use
> it to pass u64 arguments, and combine it with another u64 along the way.
> Just make it u64, and head off any possible size mismatches.
>
> Signed-off-by:
