On Wed, 19 Jun 2019, shuah wrote:
> I missed a lot of the thread info. and went looking for it and found the
> following summary of the problem:
>
> ==
> The issue which prompted the commit this thread is about arose in a
> situation where the block layer set up a scatterlist
Hi Alan,
On 6/18/19 9:28 AM, shuah wrote:
On 6/14/19 8:44 AM, Alan Stern wrote:
On Thu, 13 Jun 2019, shuah wrote:
Great! So all we have to do is fix vhci-hcd. Then we can remove all
the virt_boundary_mask stuff from usb-storage and uas entirely.
(I'm assuming wireless USB isn't a genuine
On Sun, 9 Jun 2019 06:44:03 -0700
Jacob Pan wrote:
> Traditionally, device specific faults are detected and handled within
> their own device drivers. When IOMMU is enabled, faults such as DMA
> related transactions are detected by IOMMU. There is no generic
> reporting mechanism to report
On Mon, Jun 17, 2019 at 10:33:42AM +0200, Christoph Hellwig wrote:
> > drivers/infiniband/hw/cxgb4/qp.c
> >129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
> >130 {
> >131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev),
> > sq->memsize,
> >
On Tue, 18 Jun 2019 01:08:06 +0200 (CEST)
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
On Mon, Jun 17, 2019 at 09:13:16AM -0700, Stefano Stabellini wrote:
> On Mon, 17 Jun 2019, Arnd Bergmann wrote:
> > On architectures that have a larger dma_addr_t than phys_addr_t,
> > the swiotlb_tbl_map_single() function truncates its return code
> > in the failure path, making it impossible to
On 18/06/2019 18:05, Jacob Pan wrote:
> On Tue, 18 Jun 2019 15:22:20 +0100
> Jean-Philippe Brucker wrote:
>
>> On 11/06/2019 19:13, Jacob Pan wrote:
>> +/**
>> + * ioasid_find - Find IOASID data
>> + * @set: the IOASID set
>> + * @ioasid: the IOASID to find
>> + * @getter:
On 10/06/2019 14:55, Yong Wu wrote:
> The iommu consumer should use device_link to connect with the
> smi-larb(supplier). then the smi-larb should run before the iommu
> consumer. Here we delay the iommu driver until the smi driver is
> ready, then all the iommu consumer always is after the smi
On 18/06/2019 19:08, Will Deacon wrote:
>> +/*
>> + * If the SMMU doesn't support 2-stage CD, limit the linear
>> + * tables to a reasonable number of contexts, let's say
>> + * 64kB / sizeof(ctx_desc) = 1024 = 2^10
>> + */
>> +if (!(smmu->features &
On 19/06/2019 01:19, Jacob Pan wrote:
>>> I see this as a future extension due to limited testing,
>>
>> I'm wondering how we deal with:
>> (1) old userspace that won't fill the new private_data field in
>> page_response. A new kernel still has to support it.
>> (2) old kernel that won't
On Tue, Jun 18, 2019 at 11:25 PM Will Deacon wrote:
>
> On Wed, Jun 12, 2019 at 12:45:51PM +0530, Vivek Gautam wrote:
> > There are scnenarios where drivers are required to make a
> > scm call in atomic context, such as in one of the qcom's
> > arm-smmu-500 errata [1].
> >
> > [1]
11 matches
Mail list logo