On Mon, Nov 19, 2018 at 11:15:15PM +0530, Souptick Joarder wrote:
> On Mon, Nov 19, 2018 at 9:56 PM Mike Rapoport wrote:
> >
> > On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote:
> > > Hi Mike,
> > >
> > > On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox
> > > wrote:
> > > >
> > >
On Wed, Nov 21, 2018 at 06:35:58PM -0800, Matthew Wilcox wrote:
> I think you should look at using the page_frag allocator here. You can
> use whatever GFP_DMA flags you like.
So I actually tries to use page_frag to solve the XFS unaligned kmalloc
allocations problem, and I don't think it is the
Hi Jean-Philippe,
On Wed, Nov 21, 2018 at 11:16:07AM +, Jean-Philippe Brucker wrote:
> On 12/11/2018 14:40, Joerg Roedel wrote:
> > What is the intended use-case for this function?
>
> I'm using it in sva_bind(), to see if there already exists an io_mm
> associated to the mm_struct given as
On Thu, Nov 22, 2018 at 12:48:40PM +0200, Mika Westerberg wrote:
> We had an internal discussion regarding this and it was suggested that
> the new flag is called "is_untrusted" instead of "is_external". This
> covers Thunderbolt devices currently but can be extend to any other PCIe
> device such
On Wed, Nov 21, 2018 at 10:26:26PM +, Robin Murphy wrote:
> TBH, if this DMA32 stuff is going to be contentious we could possibly just
> rip out the offending kmem_cache - it seemed like good practice for the
> use-case, but provided kzalloc(SZ_1K, gfp | GFP_DMA32) can be relied upon to
> give
On Wed, Nov 21, 2018 at 07:10:20PM +, Koenig, Christian wrote:
> All of that is completely unrelated to IOMMU, but when IOMMU is enabled
> you need to use the same allocator because all use cases use the same ID
> space.
Okay, I see. Is there ever a case where we can have multiple PASIDs
On Thu, Nov 22, 2018 at 11:04:22AM +0900, Sergey Senozhatsky wrote:
> Some serial consoles call mod_timer(). So what we could have with the
> debug objects enabled was
>
> mod_timer()
>lock_timer_base()
> debug_activate()
> printk()
>
> From: j...@8bytes.org [mailto:j...@8bytes.org]
> Sent: Monday, November 12, 2018 10:56 PM
>
> Hi Jean-Philippe,
>
> On Thu, Nov 08, 2018 at 06:29:42PM +, Jean-Philippe Brucker wrote:
> > (1) My initial approach would have been to use the same page tables for
> > the default_domain and this
On Fri, Nov 16, 2018 at 11:32:10AM +0200, Mika Westerberg wrote:
> On Fri, Nov 16, 2018 at 01:18:04AM -0800, Christoph Hellwig wrote:
> > On Thu, Nov 15, 2018 at 09:10:26PM +0200, Mika Westerberg wrote:
> > > FireWire is kind of different but there are connectors such as
> > > ExpressCard and NVMe
On 22/11/2018 08:44, Joerg Roedel wrote:
> Hi Jean-Philippe,
>
> On Wed, Nov 21, 2018 at 11:16:07AM +, Jean-Philippe Brucker wrote:
>> On 12/11/2018 14:40, Joerg Roedel wrote:
>>> What is the intended use-case for this function?
>>
>> I'm using it in sva_bind(), to see if there already exists
Hi Will,
On Wed, Nov 21, 2018 at 11:09 PM Will Deacon wrote:
>
> On Fri, Nov 16, 2018 at 04:54:27PM +0530, Vivek Gautam wrote:
> > From: Sricharan R
> >
> > The smmu device probe/remove and add/remove master device callbacks
> > gets called when the smmu is not linked to its master, that is
Hi,
On Sat, Nov 17, 2018 at 10:35:27AM +0800, Yong Wu wrote:
> Yong Wu (14):
> dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI
> iommu/mediatek: Use a struct as the platform data
> memory: mtk-smi: Use a general config_port interface
> iommu/io-pgtable-arm-v7s: Add
On Thu, Nov 22, 2018 at 01:59:31PM +0100, Joerg Roedel wrote:
> On Sat, Nov 17, 2018 at 10:35:27AM +0800, Yong Wu wrote:
> > Yong Wu (14):
> > dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI
> > iommu/mediatek: Use a struct as the platform data
> > memory: mtk-smi: Use a general
On Thu, Nov 22, 2018 at 01:35:26PM +, Will Deacon wrote:
> Robin already reviewed the pgtable bits, I think.
Right, I missed the tags, sorry.
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
Return DMA_MAPPING_ERROR instead of the magic bad_dma_addr on a dma
mapping failure and let the core dma-mapping code handle the rest.
Remove the magic EMERGENCY_PAGES that the bad_dma_addr gets redirected to.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/amd_gart_64.c | 39
Return DMA_MAPPING_ERROR instead of the magic bad_dma_addr on a dma
mapping failure and let the core dma-mapping code handle the rest.
Remove the magic EMERGENCY_PAGES that the bad_dma_addr gets redirected to.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/pci-calgary_64.c | 29
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Note that the existing code used AMD_IOMMU_MAPPING_ERROR to check from
a 0 return from the IOVA allocator, which is replaced with an explicit
0 as in the implementation and other
Pass the page + offset to the low-level __iommu_map_single helper
(which gets renamed to fit the new calling conventions) as both
callers have the page at hand.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/intel-iommu.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/intel-iommu.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 7 +++
drivers/iommu/dma-iommu.c | 23 ---
include/linux/dma-iommu.h | 1 -
3 files
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
drivers/xen/swiotlb-xen.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/alpha/kernel/pci_iommu.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/alpha/kernel/pci_iommu.c
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/ia64/sn/pci/pci_dma.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/ia64/sn/pci/pci_dma.c
Remove the odd sba_{un,}map_single_attrs wrappers, check errors
everywhere, and remove the completly bogus alloc_pages_node call that
uses the dma attributes argument as the node id.
Signed-off-by: Christoph Hellwig
---
arch/ia64/hp/common/sba_iommu.c | 71 -
1
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/ia64/hp/common/sba_iommu.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c
S390 already returns (~(dma_addr_t)0x0) on mapping failures, so we can
switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping
code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/s390/pci/pci_dma.c | 18 +-
1 file changed, 5 insertions(+), 13
Sparc already returns (~(dma_addr_t)0x0) on mapping failures, so we can
switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping
code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/sparc/kernel/iommu.c| 12 +++-
arch/sparc/kernel/iommu_common.h | 2 --
The CCIO iommu code already returns (~(dma_addr_t)0x0) on mapping
failures, so we can switch over to returning DMA_MAPPING_ERROR and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
drivers/parisc/ccio-dma.c | 10 +-
1 file changed, 1 insertion(+), 9
The SBA iommu code already returns (~(dma_addr_t)0x0) on mapping
failures, so we can switch over to returning DMA_MAPPING_ERROR and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
drivers/parisc/sba_iommu.c | 10 +-
1 file changed, 1 insertion(+), 9
Just return DMA_MAPPING_ERROR from __dummy_map_page and let the core
dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c
Arm already returns (~(dma_addr_t)0x0) on mapping failures, so we can
switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping
code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/arm/common/dmabounce.c | 12 +++---
arch/arm/include/asm/dma-iommu.h | 2 --
The dma-direct code already returns (~(dma_addr_t)0x0) on mapping
failures, so we can switch over to returning DMA_MAPPING_ERROR and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/dma-swiotlb.c | 1 -
include/linux/dma-direct.h|
The Jazz iommu code already returns (~(dma_addr_t)0x0) on mapping
failures, so we can switch over to returning DMA_MAPPING_ERROR and
let the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/mips/include/asm/jazzdma.h | 6 --
arch/mips/jazz/jazzdma.c|
The powerpc iommu code already returns (~(dma_addr_t)0x0) on mapping
failures, so we can switch over to returning DMA_MAPPING_ERROR and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/iommu.h | 4
Error handling of the dma_map_single and dma_map_page APIs is a little
problematic at the moment, in that we use different encodings in the
returned dma_addr_t to indicate an error. That means we require an
additional indirect call to figure out if a dma mapping call returned
an error, and a lot
From: Robin Murphy
With the overflow buffer removed, we no longer have a unique address
which is guaranteed not to be a valid DMA target to use as an error
token. The DIRECT_MAPPING_ERROR value of 0 tries to at least represent
an unlikely DMA target, but unfortunately there are already SWIOTLB
From: Robin Murphy
If swiotlb_bounce_page() failed, calling arch_sync_dma_for_device() may
lead to such delights as performing cache maintenance on whatever
address phys_to_virt(SWIOTLB_MAP_ERROR) looks like, which is typically
outside the kernel memory map and goes about as well as expected.
Error reporting for the dma_map_single and dma_map_page operations is
currently a mess. Both APIs directly return the dma_addr_t to be used for
the DMA, with a magic error escape that is specific to the instance and
checked by another method provided. This has a few downsides:
- the error
On Thu, Nov 22, 2018 at 08:54:43AM -0500, Yangtao Li wrote:
> Because we already have the DEFINE_SHOW_ATTRIBUTE,there is no need
> to define such a macro.So remove DEBUG_SEQ_FOPS_RO.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/iommu/omap-iommu-debug.c | 25 ++---
> 1 file
No users left except for vmd which just forwards it. Also switch
dma_mapping_error to an explicit bool return value.
Signed-off-by: Christoph Hellwig
---
drivers/pci/controller/vmd.c | 6 --
include/linux/dma-mapping.h | 13 ++---
2 files changed, 2 insertions(+), 17 deletions(-)
On Thu 2018-11-22 11:04:22, Sergey Senozhatsky wrote:
> On (11/21/18 11:49), Waiman Long wrote:
> [..]
> > > case ODEBUG_STATE_ACTIVE:
> > > - debug_print_object(obj, "init");
> > > state = obj->state;
> > > raw_spin_unlock_irqrestore(>lock, flags);
> > > +
On Wed, Nov 21, 2018 at 05:53:47PM +0800, Pan Bian wrote:
> memunmap() should be used to free the return of memremap(), not
> iounmap().
>
> Fixes: dfddb969edf0("iommu/vt-d: Switch from ioremap_cache to memremap")
> Signed-off-by: Pan Bian
> ---
> drivers/iommu/intel-iommu.c | 2 +-
> 1 file
On Thu, Nov 22, 2018 at 08:30:47AM -0500, Yangtao Li wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/iommu/tegra-smmu.c | 24 ++--
> 1 file changed, 2 insertions(+), 22 deletions(-)
Applied, thanks.
On Thu, Nov 22, 2018 at 07:16:32AM -0800, Matthew Wilcox wrote:
> Yes, your allocations from the page_frag allocator have to have similar
> lifetimes. I thought that would be ideal for XFS though; as I understood
> the problem, these were per-IO allocations, and IOs to the same filesystem
> tend
On Wed, Nov 21, 2018 at 03:29:33PM -0800, Sohil Mehta wrote:
> drivers/iommu/intel-iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Thu, Nov 22, 2018 at 12:26:02AM -0800, Christoph Hellwig wrote:
> On Wed, Nov 21, 2018 at 06:35:58PM -0800, Matthew Wilcox wrote:
> > I think you should look at using the page_frag allocator here. You can
> > use whatever GFP_DMA flags you like.
>
> So I actually tries to use page_frag to
On Mon 2018-11-19 13:55:18, Waiman Long wrote:
> By making the object hash locks nestable terminal locks, we can avoid
> a bunch of unnecessary lockdep validations as well as saving space
> in the lockdep tables.
Please, explain which terminal lock might be nested.
Hmm, it would hide eventual
On Thu, Nov 22, 2018 at 6:03 AM Christoph Hellwig wrote:
>
> The 0 return doesn't work for direct mappings that have ram at address
> zero and a lot of IOMMUs that start allocating bus space from address
> zero, so we can't consolidate on that, but I think we can move everyone
> to all-Fs, which
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li
---
drivers/iommu/tegra-smmu.c | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 0d03341317c4..97b3c0461831
Because we already have the DEFINE_SHOW_ATTRIBUTE,there is no need
to define such a macro.So remove DEBUG_SEQ_FOPS_RO.
Signed-off-by: Yangtao Li
---
drivers/iommu/omap-iommu-debug.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git
On Thu, Nov 22, 2018 at 08:30:47AM -0500, Yangtao Li wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/iommu/tegra-smmu.c | 24 ++--
> 1 file changed, 2 insertions(+), 22 deletions(-)
Acked-by: Thierry Reding
On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux
wrote:
>
> I'm afraid that won't work very well - 32 bit platforms with 64-bit
> addresses (LPAE) would have dma_addr_t as a 64-bit value, which
> wouldn't fit into an unsigned long.
Good point. So we'd have to have a special IS_DMA_ERR()
On Thu, Nov 22, 2018 at 08:50:47AM -0800, Linus Torvalds wrote:
> On Thu, Nov 22, 2018 at 6:03 AM Christoph Hellwig wrote:
> >
> > The 0 return doesn't work for direct mappings that have ram at address
> > zero and a lot of IOMMUs that start allocating bus space from address
> > zero, so we can't
On 22/11/2018 17:09, Linus Torvalds wrote:
On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux
wrote:
I'm afraid that won't work very well - 32 bit platforms with 64-bit
addresses (LPAE) would have dma_addr_t as a 64-bit value, which
wouldn't fit into an unsigned long.
Good point. So
On Thu, Nov 22, 2018 at 9:52 AM Robin Murphy wrote:
>
> Unfortunately, with things like the top-down IOVA allocator, and 32-bit
> systems in general, "the top 4095" values may well still be valid
> addresses -
Ugh.
> The only immediate benefit I can see is that we could distinguish cases
> like
In PCI root complex nodes, the iommu-map property describes the IOMMU that
translates each endpoint. On some platforms, the IOMMU itself is presented
as a PCI endpoint (e.g. AMD IOMMU and virtio-iommu). This isn't supported
by the current OF driver, which expects all endpoints to have an IOMMU.
For PCI devices that have an OF node, set the fwnode as well. This way
drivers that rely on fwnode don't need the special case described by
commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately").
Acked-by: Bjorn Helgaas
Signed-off-by: Jean-Philippe Brucker
---
The nature of a virtio-mmio node is discovered by the virtio driver at
probe time. However the DMA relation between devices must be described
statically. When a virtio-mmio node is a virtio-iommu device, it needs an
"#iommu-cells" property as specified by bindings/iommu/iommu.txt.
Otherwise, the
Some systems implement virtio-iommu as a PCI endpoint. The operating
system needs to discover the relationship between IOMMU and masters long
before the PCI endpoint gets probed. Add a PCI child node to describe the
virtio-iommu device.
The virtio-pci-iommu is conceptually split between a PCI
On 11/21/2018 09:04 PM, Sergey Senozhatsky wrote:
> On (11/21/18 11:49), Waiman Long wrote:
> [..]
>>> case ODEBUG_STATE_ACTIVE:
>>> - debug_print_object(obj, "init");
>>> state = obj->state;
>>> raw_spin_unlock_irqrestore(>lock, flags);
>>> +
On Thu, Nov 22, 2018 at 09:55:25AM -0800, Linus Torvalds wrote:
> On Thu, Nov 22, 2018 at 9:52 AM Robin Murphy wrote:
> >
> > Unfortunately, with things like the top-down IOVA allocator, and 32-bit
> > systems in general, "the top 4095" values may well still be valid
> > addresses -
>
> Ugh.
>
Implement the virtio-iommu driver, following specification v0.9 [1].
Since v4 [2] I fixed the issues reported by Eric, and added Reviewed-by
from Eric and Rob. Thanks!
I changed the specification to fix one inconsistency discussed in v4.
That the device fills the probe buffer with zeroes is now
On Thu, Nov 22, 2018 at 09:09:47AM -0800, Linus Torvalds wrote:
> On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux
> wrote:
> >
> > I'm afraid that won't work very well - 32 bit platforms with 64-bit
> > addresses (LPAE) would have dma_addr_t as a 64-bit value, which
> > wouldn't fit into
The event queue offers a way for the device to report access faults from
endpoints. It is implemented on virtqueue #1. Whenever the host needs to
signal a fault, it fills one of the buffers offered by the guest and
interrupts it.
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
The virtio IOMMU is a para-virtualized device, allowing to send IOMMU
requests such as map/unmap over virtio transport without emulating page
tables. This implementation handles ATTACH, DETACH, MAP and UNMAP
requests.
The bulk of the code transforms calls coming from the IOMMU API into
When the device offers the probe feature, send a probe request for each
device managed by the IOMMU. Extract RESV_MEM information. When we
encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region.
This will tell other subsystems that there is no need to map the MSI
doorbell in the
On 11/22/2018 10:33 AM, Petr Mladek wrote:
> On Mon 2018-11-19 13:55:18, Waiman Long wrote:
>> By making the object hash locks nestable terminal locks, we can avoid
>> a bunch of unnecessary lockdep validations as well as saving space
>> in the lockdep tables.
> Please, explain which terminal lock
On Thu, 2018-11-22 at 13:35 +, Will Deacon wrote:
> On Thu, Nov 22, 2018 at 01:59:31PM +0100, Joerg Roedel wrote:
> > On Sat, Nov 17, 2018 at 10:35:27AM +0800, Yong Wu wrote:
> > > Yong Wu (14):
> > > dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI
> > > iommu/mediatek: Use a
On Sat, 2018-11-17 at 10:35 +0800, Yong Wu wrote:
> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
> mmu0 or mmu1 to balance the bandwidth via the smi-common register
> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>
> In mt8183, For better performance, we switch
On Thu, Nov 22, 2018 at 4:23 PM Christoph Hellwig wrote:
>
> On Wed, Nov 21, 2018 at 10:26:26PM +, Robin Murphy wrote:
> > TBH, if this DMA32 stuff is going to be contentious we could possibly just
> > rip out the offending kmem_cache - it seemed like good practice for the
> > use-case, but
Hi Tomasz,
On 11/20/18 4:48 AM, Tomasz Figa wrote:
> Hi Helen,
>
> On Tue, Nov 20, 2018 at 4:08 AM Helen Koike wrote:
>>
>> From: Enric Balletbo i Serra
>>
>> Add support to async updates of cursors by using the new atomic
>> interface for that.
>>
>> Signed-off-by: Enric Balletbo i Serra
>>
On 11/22/2018 11:02 AM, Petr Mladek wrote:
> On Thu 2018-11-22 11:04:22, Sergey Senozhatsky wrote:
>> On (11/21/18 11:49), Waiman Long wrote:
>> [..]
case ODEBUG_STATE_ACTIVE:
- debug_print_object(obj, "init");
state = obj->state;
Hi Helen,
On Fri, Nov 23, 2018 at 8:31 AM Helen Koike wrote:
>
> Hi Tomasz,
>
> On 11/20/18 4:48 AM, Tomasz Figa wrote:
> > Hi Helen,
> >
> > On Tue, Nov 20, 2018 at 4:08 AM Helen Koike
> > wrote:
> >>
> >> From: Enric Balletbo i Serra
> >>
> >> Add support to async updates of cursors by
On (11/22/18 14:57), Waiman Long wrote:
> > [..]
> >> As a side note, one of the test systems that I used generated a
> >> debugobjects splat in the bootup process and the system hanged
> >> afterward. Applying this patch alone fix the hanging problem and the
> >> system booted up successfully. So
On (11/22/18 11:16), Peter Zijlstra wrote:
> > So maybe we need to switch debug objects print-outs to _always_
> > printk_deferred(). Debug objects can be used in code which cannot
> > do direct printk() - timekeeping is just one example.
>
> No, printk_deferred() is a disease, it needs to be
On Fri, Nov 23, 2018 at 11:04 AM Nicolas Boichat wrote:
>
> On Thu, Nov 22, 2018 at 4:23 PM Christoph Hellwig wrote:
> >
> > On Wed, Nov 21, 2018 at 10:26:26PM +, Robin Murphy wrote:
> > > TBH, if this DMA32 stuff is going to be contentious we could possibly just
> > > rip out the offending
Hi Michael,
On Fri, Nov 23, 2018 at 1:58 PM Michael Zoran wrote:
>
> On Fri, 2018-11-23 at 11:27 +0900, Tomasz Figa wrote:
> >
> > The point here is not about setting and resetting the plane->fb
> > pointer. It's about what happens inside
> > drm_atomic_set_fb_for_plane().
> >
> > It calls
On Thu, Nov 22, 2018 at 09:55:25AM -0800, Linus Torvalds wrote:
> No, the big immediate benefit of allowing "return -EINVAL" etc is
> simply legibility and error avoidance.
Well, I can tweak the last patch to return -EINVAL from dma_mapping_error
instead of the old 1 is as bool true. The callers
On Thu, Nov 22, 2018 at 06:05:26PM +, Russell King - ARM Linux wrote:
> An alternative idea would be to migrate away from the
> dma_map_single() and dma_map_page() interfaces that return a
> dma_addr_t, and instead have them return an error code or zero
> on success.
See here for a proposal:
79 matches
Mail list logo
