Sorry to nag, but did anyone have any comments about these patches? Is no
news good news?
Thanks,
Kevin
On Thu, Apr 18, 2019 at 11:14 AM Kevin Mitchell wrote:
> This series makes error handling more robust in the amd_iommu init
> code. It was initially motivated by problematic firmware that
On 5/5/19 11:11 PM, Qian Cai wrote:
> [CAUTION: External Email]
>
> The commit e7f63ffc1bf1 ("iommu/amd: Update logging information for new
> event type") introduced a variable "tag" but had never used it which
> generates a warning below,
>
> drivers/iommu/amd_iommu.c: In function
On 02/05/2019 17:46, Jacob Pan wrote:
> On Thu, 2 May 2019 11:53:34 +0100
> Jean-Philippe Brucker wrote:
>
>> On 02/05/2019 07:58, Auger Eric wrote:
>>> Hi Jean-Philippe,
>>>
>>> On 5/1/19 12:38 PM, Jean-Philippe Brucker wrote:
On 08/04/2019 13:18, Eric Auger wrote:
> +int
On Tue, May 07, 2019 at 08:37:20AM +0200, Christoph Hellwig wrote:
> On Fri, May 03, 2019 at 12:33:53PM +0100, Catalin Marinas wrote:
> > On Tue, Apr 30, 2019 at 06:51:50AM -0400, Christoph Hellwig wrote:
> > > DMA allocations that can't sleep may return non-remapped addresses, but
> > > we do not
On Tue, May 7, 2019 at 8:37 AM Christoph Hellwig wrote:
> On Mon, May 06, 2019 at 03:49:35PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >
> > On 04/30/2019 01:00 PM, Christoph Hellwig wrote:
> > > Virtual addresses return from dma(m)_alloc_coherent are opaque in what
> > > backs then, and drivers
On Mon, May 06, 2019 at 07:52:04PM +0100, Tom Murphy wrote:
> +static int handle_deferred_device(struct device *dev)
> +{
> + struct iommu_domain *domain;
> + const struct iommu_ops *ops;
> +
> + if (!is_kdump_kernel())
> + return 0;
> +
> + domain =
On Fri, May 03, 2019 at 12:33:53PM +0100, Catalin Marinas wrote:
> On Tue, Apr 30, 2019 at 06:51:50AM -0400, Christoph Hellwig wrote:
> > DMA allocations that can't sleep may return non-remapped addresses, but
> > we do not properly handle them in the mmap and get_sgtable methods.
> > Resolve
On Mon, May 06, 2019 at 03:49:35PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> On 04/30/2019 01:00 PM, Christoph Hellwig wrote:
> > Virtual addresses return from dma(m)_alloc_coherent are opaque in what
> > backs then, and drivers must not poke into them. Switch the driver
> > to use the generic
On Mon, May 06, 2019 at 06:56:13PM +0100, Tom Murphy wrote:
> Just to make this clear, I won't apply Christoph's patch (the one in
> this email thread) and instead the only change I will make is to
> rename dma_limit to dma_mask.
Sounds good for now.
Hi Qian,
On Mon, May 06, 2019 at 12:44:40PM -0400, Qian Cai wrote:
> The commit 1a1079011da3 ("iommu/amd: Flush not present cache in
> iommu_map_page") added domain_flush_np_cache() in map_sg() which
> triggered a crash below during boot. sg_next() could return NULL if
> sg_is_last() is true, so
On Mon, May 06, 2019 at 04:12:08PM -0500, Bjorn Helgaas wrote:
> On Fri, May 03, 2019 at 07:35:34PM +0530, Srinath Mannam wrote:
> > The IPROC host controller allows only a subset of physical address space
> > as target of inbound PCI memory transactions addresses.
> >
> > PCIe devices memory
Hi Bjorn,
Thank you.
Regards,
Srinath.
On Tue, May 7, 2019 at 3:11 PM Lorenzo Pieralisi
wrote:
>
> On Mon, May 06, 2019 at 04:12:08PM -0500, Bjorn Helgaas wrote:
> > On Fri, May 03, 2019 at 07:35:34PM +0530, Srinath Mannam wrote:
> > > The IPROC host controller allows only a subset of physical
On 06/05/2019 16:32, Tom Murphy via iommu wrote:
The AMD driver already solves this problem and uses the generic
iommu_request_dm_for_dev function. It seems like both drivers have the
same problem and could use the same solution. Is there any reason we
can't have use the same solution for the
13 matches
Mail list logo
