Hello,
I tried another script for the semantic patch language out.
This source code analysis approach points out that the implementation
of the function “exynos_iommu_add_device” contains still
an unchecked call of the function “device_link_add”.
https://git.kernel.org/pub/scm/linux/kernel/git/tor
On Tue, Jun 18, 2019 at 01:08:06AM +0200, Thomas Gleixner wrote:
> Stephane,
>
> On Mon, 17 Jun 2019, Stephane Eranian wrote:
> > On Mon, Jun 17, 2019 at 1:25 AM Thomas Gleixner wrote:
> > > Great that there is no trace of any mail from Andi or Stephane about this
> > > on LKML. There is no probl
Hi Tony,
On 8/26/19 7:14 PM, Suman Anna wrote:
> Hi Tony,
>
> The following 2 patches need to go along with the recent "iommu/omap: misc
> fixes" series [1] that is currently staged [2] for a 5.4 merge and available
> in linux-next. That series added runtime pm callbacks in preparation for
> the
From: Boqun Feng Sent: Wednesday, October 16, 2019 5:57
PM
>
> Currently hyperv-iommu is implemented in a x86 specific way, for
> example, apic is used. So make the HYPERV_IOMMU Kconfig depend on X86
> as a preparation for enabling HyperV on architecture other than x86.
>
> Cc: Lan Tianyu
> Cc
VT-d RMRR (Reserved Memory Region Reporting) regions are reserved
for device use only and should not be part of allocable memory pool of OS.
BIOS e820_table reports complete memory map to OS, including OS usable
memory ranges and BIOS reserved memory ranges etc.
x86 BIOS may not be trusted to inc
On Wed, Oct 16, 2019 at 06:07:36PM +0100, Robin Murphy wrote:
> @@ -1180,7 +1179,7 @@ int iommu_dma_prepare_msi(struct msi_desc *desc,
> phys_addr_t msi_addr)
> struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> struct iommu_dma_cookie *cookie;
> struct iommu_dma_msi_
On Thu, Oct 17, 2019 at 09:08:47AM +0200, Christoph Hellwig wrote:
> On Wed, Oct 16, 2019 at 03:15:52PM -0400, Arvind Sankar wrote:
> > > > Reported-by: Arvind Sankar
> > > > Tested-by: Arvind Sankar
> > > > Originally-by: Christoph Hellwig
> > > > Signed-off-by: Christoph Hellwig
> > > > Fixed
On Wed, 2019-10-16 at 17:44 +0200, Joerg Roedel wrote:
> On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> > BTW, the previous x86 warning was from only reverted one patch "iommu: Add
> > gfp
> > parameter to iommu_ops::map" where proved to be insufficient. Now, pasting
> > the
> > corr
> On Oct 16, 2019, at 6:59 PM, Jerry Snitselaar wrote:
>
> I guess the mode level 6 check is really for other potential callers
> increase_address_space, none exist at the moment, and the condition
> of the while loop in alloc_pte should fail if the mode level is 6.
Because there is no lockin
On 10/17/19 12:16 PM, Vladimir Murzin wrote:
On 10/17/19 11:03 AM, Alexandre Torgue wrote:
Hi Vlad
On 10/17/19 11:46 AM, Vladimir Murzin wrote:
On 10/14/19 4:01 PM, Vladimir Murzin wrote:
On 10/14/19 2:54 PM, Robin Murphy wrote:
On 13/10/2019 15:28, Daniele Alessandrelli wrote:
Hi,
It lo
Hi Vlad
On 10/17/19 11:46 AM, Vladimir Murzin wrote:
On 10/14/19 4:01 PM, Vladimir Murzin wrote:
On 10/14/19 2:54 PM, Robin Murphy wrote:
On 13/10/2019 15:28, Daniele Alessandrelli wrote:
Hi,
It looks like dma_alloc_coherent() is setting the dma_handle output
parameter to the memory physical
On 10/17/19 11:03 AM, Alexandre Torgue wrote:
> Hi Vlad
>
> On 10/17/19 11:46 AM, Vladimir Murzin wrote:
>> On 10/14/19 4:01 PM, Vladimir Murzin wrote:
>>> On 10/14/19 2:54 PM, Robin Murphy wrote:
On 13/10/2019 15:28, Daniele Alessandrelli wrote:
> Hi,
>
> It looks like dma_alloc_
On 10/14/19 4:01 PM, Vladimir Murzin wrote:
> On 10/14/19 2:54 PM, Robin Murphy wrote:
>> On 13/10/2019 15:28, Daniele Alessandrelli wrote:
>>> Hi,
>>>
>>> It looks like dma_alloc_coherent() is setting the dma_handle output
>>> parameter to the memory physical address and not the device bus
>>> add
13 matches
Mail list logo