On Thu, 23 May 2019, Ricardo Neri wrote:
> +/**
> + * hpet_set_comparator() - Helper function for setting comparator register
> + * @num: The timer ID
> + * @cmp: The value to be written to the comparator/accumulator
> + * @period: The value to be written to the period (0 = oneshot mode)
Hi Christoph,
Regular question - do you have any public git repository with all this dma
changes?
I want to test it for ARC.
Pretty sure the
[PATCH 2/7] arc: remove the partial DMA_ATTR_NON_CONSISTENT support
is fine.
Not so sure about
[PATCH 7/7] arc: use the generic remapping allocator for
Need me to make them a patch?
MBR,
Yangtao
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Fri, Jun 14, 2019 at 03:47:13PM +0200, Christoph Hellwig wrote:
> Remove usage of the legacy drm PCI DMA wrappers, and with that the
> incorrect usage cocktail of __GFP_COMP, virt_to_page on DMA allocation
> and SetPageReserved.
>
> Signed-off-by: Christoph Hellwig
> ---
>
The pull request you sent on Fri, 14 Jun 2019 11:39:15 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.2-rc4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c78ad1be4b4d65eb214421b90a788abf3c85c3ea
Thank you!
--
On Thu, 13 Jun 2019, Ricardo Neri wrote:
> On Tue, Jun 11, 2019 at 09:54:25PM +0200, Thomas Gleixner wrote:
> > On Thu, 23 May 2019, Ricardo Neri wrote:
> >
> > > HPET timer 2 will be used to drive the HPET-based hardlockup detector.
> > > Reserve such timer to ensure it cannot be used by user
On Fri, 14 Jun 2019, Thomas Gleixner wrote:
> On Thu, 23 May 2019, Ricardo Neri wrote:
> > int hpet_alloc(struct hpet_data *hdp)
> > {
> > u64 cap, mcfg;
> > @@ -844,7 +867,6 @@ int hpet_alloc(struct hpet_data *hdp)
> > struct hpets *hpetp;
> > struct hpet __iomem *hpet;
> >
On Thu, 23 May 2019, Ricardo Neri wrote:
>
> +u64 hpet_get_ticks_per_sec(u64 hpet_caps)
> +{
> + u64 ticks_per_sec, period;
> +
> + period = (hpet_caps & HPET_COUNTER_CLK_PERIOD_MASK) >>
> + HPET_COUNTER_CLK_PERIOD_SHIFT; /* fs, 10^-15 */
> +
> + /*
> + * The
On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
> On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
> > On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> > > Perhaps a hint as to how we can fix this up? This is the first time
> > > I've heard of the comedi code
On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> > Perhaps a hint as to how we can fix this up? This is the first time
> > I've heard of the comedi code not handling dma properly.
>
> It can be fixed by:
>
> a)
From: Robin Murphy
> Sent: 14 June 2019 16:06
...
> Well, apart from the bit in DMA-API-HOWTO which has said this since
> forever (well, before Git history, at least):
>
> "The CPU virtual address and the DMA address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is
On Fri, Jun 14, 2019 at 04:05:33PM +0100, Robin Murphy wrote:
> That said, I don't believe this particular patch should make any
> appreciable difference - alloc_pages_exact() is still going to give back
> the same base address as the rounded up over-allocation would, and
> PAGE_ALIGN()ing the
On Fri, Jun 14, 2019 at 03:01:22PM +, David Laight wrote:
> I'm pretty sure there is a lot of code out there that makes that assumption.
> Without it many drivers will have to allocate almost double the
> amount of memory they actually need in order to get the required alignment.
> So instead
On 14/06/2019 15:50, 'Christoph Hellwig' wrote:
On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
Does this still guarantee that requests for 16k will not cross a 16k boundary?
It looks like you are losing the alignment parameter.
The DMA API never gave you alignment guarantees to
From: 'Christoph Hellwig'
> Sent: 14 June 2019 15:50
> To: David Laight
> On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
> > Does this still guarantee that requests for 16k will not cross a 16k
> > boundary?
> > It looks like you are losing the alignment parameter.
>
> The DMA API
On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
> Does this still guarantee that requests for 16k will not cross a 16k boundary?
> It looks like you are losing the alignment parameter.
The DMA API never gave you alignment guarantees to start with,
and you can get not naturally
On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> Perhaps a hint as to how we can fix this up? This is the first time
> I've heard of the comedi code not handling dma properly.
It can be fixed by:
a) never calling virt_to_page (or vmalloc_to_page for that matter)
on dma allocation
Replace the code that sets up uncached PTEs with the generic vmap based
remapping code. It also provides an atomic pool for allocations from
non-blocking context, which we not properly supported by the existing
arc code.
Signed-off-by: Christoph Hellwig
---
arch/arc/Kconfig | 2 ++
Only call into arch_dma_alloc if we require an uncached mapping,
and remove the parisc code manually doing normal cached
DMA_ATTR_NON_CONSISTENT allocations.
Signed-off-by: Christoph Hellwig
---
arch/parisc/kernel/pci-dma.c | 48 ++--
kernel/dma/direct.c
DMA_ATTR_NO_KERNEL_MAPPING is generally implemented by allocating
normal cacheable pages or CMA memory, and then returning the page
pointer as the opaque handle. Lift that code from the xtensa and
generic dma remapping implementations into the generic dma-direct
code so that we don't even call
Check if we need to allocate uncached memory for a device given the
allocation flags. Switch over the uncached segment check to this helper
to deal with architectures that do not support the dma_cache_sync
operation and thus should not returned cacheable memory for
DMA_ATTR_NON_CONSISTENT
The openrisc DMA code supports DMA_ATTR_NON_CONSISTENT allocations, but
does not provide a cache_sync operation. This means any user of it
will never be able to actually transfer cache ownership and thus cause
coherency bugs.
Signed-off-by: Christoph Hellwig
---
arch/openrisc/kernel/dma.c | 22
The arm-nommu DMA code supports DMA_ATTR_NON_CONSISTENT allocations, but
does not provide a cache_sync operation. This means any user of it
will never be able to actually transfer cache ownership and thus cause
coherency bugs.
Signed-off-by: Christoph Hellwig
---
The arc DMA code supports DMA_ATTR_NON_CONSISTENT allocations, but does
not provide a cache_sync operation. This means any user of it will
never be able to actually transfer cache ownership and thus cause
coherency bugs.
Signed-off-by: Christoph Hellwig
---
arch/arc/mm/dma.c | 21
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 issue. As far as I know, it
> > is pretty much abandoned at this
Hi all,,
this series ensures that the common dma-direct code handles the somewhat
special allocation types requested by the DMA_ATTR_NON_CONSISTENT and
DMA_ATTR_NO_KERNEL_MAPPING flags directly. To do so it also removes three
partial and thus broken implementations of DMA_ATTR_NON_CONSISTENT.
On Fri, Jun 14, 2019 at 12:10:10PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jun 14, 2019 at 11:39 AM Thierry Reding
> wrote:
> >
> > On Fri, Jun 14, 2019 at 11:10:58AM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Jun 13, 2019 at 07:00:11PM +0200, Thierry Reding wrote:
> > > > From: Thierry
From: Christoph Hellwig
> Sent: 14 June 2019 14:47
>
> Many architectures (e.g. arm, m68 and sh) have always used exact
> allocation in their dma coherent allocator, which avoids a lot of
> memory waste especially for larger allocations. Lift this behavior
> into the generic allocator so that
On Fri, Jun 14, 2019 at 03:47:22PM +0200, Christoph Hellwig wrote:
> comedi_buf.c abuse the DMA API in gravely broken ways, as it assumes it
> can call virt_to_page on the result, and the just remap it as uncached
> using vmap. Disable the driver until this API abuse has been fixed.
>
>
This fits in with the naming scheme used by alloc_pages_node.
Signed-off-by: Christoph Hellwig
---
include/linux/gfp.h | 2 +-
mm/page_alloc.c | 4 ++--
mm/page_ext.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index
Many architectures (e.g. arm, m68 and sh) have always used exact
allocation in their dma coherent allocator, which avoids a lot of
memory waste especially for larger allocations. Lift this behavior
into the generic allocator so that dma-direct and the generic IOMMU
code benefit from this behavior
No need to duplicate the logic over two functions that are almost the
same.
Signed-off-by: Christoph Hellwig
---
include/linux/gfp.h | 5 +++--
mm/page_alloc.c | 39 +++
2 files changed, 10 insertions(+), 34 deletions(-)
diff --git a/include/linux/gfp.h
Lift the code to clear __GFP_COMP from arm into the common DMA
allocator path. For one this fixes the various other patches that
call alloc_pages_exact or split_page in case a bogus driver passes
the argument, and it also prepares for doing exact allocation in
the generic dma-direct allocator.
comedi_buf.c abuse the DMA API in gravely broken ways, as it assumes it
can call virt_to_page on the result, and the just remap it as uncached
using vmap. Disable the driver until this API abuse has been fixed.
Signed-off-by: Christoph Hellwig
---
drivers/staging/comedi/Kconfig | 1 +
1 file
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/s390/net/ism_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 3 +--
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/broadcom/cnic.c | 4 ++--
1 file changed, 2 insertions(+),
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/infiniband/hw/hfi1/init.c | 22 +++---
1 file changed,
These functions are rather broken in that they try to pass __GFP_COMP
to dma_alloc_coherent, call virt_to_page on the return value and
mess with PageReserved. And not actually used by any modern driver.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/drm_bufs.c | 85
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/infiniband/hw/qib/qib_iba6120.c | 2 +-
We are not allowed to call virt_to_page on pages returned from
dma_alloc_coherent, as in many cases the virtual address returned
is aactually a kernel direct mapping. Also there generally is no
need to mark dma memory as reserved.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/drm_bufs.c
The memory returned from dma_alloc_coherent is opaqueue to the user,
thus the exact way of page refcounting shall not matter either.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/drm_bufs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bufs.c
Remove usage of the legacy drm PCI DMA wrappers, and with that the
incorrect usage cocktail of __GFP_COMP, virt_to_page on DMA allocation
and SetPageReserved.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/i915_gem.c| 30 +-
Remove usage of the legacy drm PCI DMA wrappers, and with that the
incorrect usage cocktail of __GFP_COMP, virt_to_page on DMA allocation
and SetPageReserved.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/ati_pcigart.c | 27 +++
include/drm/ati_pcigart.h | 5
dma_alloc_coherent does not return a physical address, but a DMA
address, which might be remapped or have an offset. Passing this
DMA address to vm_iomap_memory is completely bogus. Use the proper
dma_mmap_coherent helper instead, and stop passing __GFP_COMP
to dma_alloc_coherent, as the memory
Hi all,
various architectures have used exact memory allocations for dma
allocations for a long time, but x86 and thus the common code based
on it kept using our normal power of two allocator, which tends to
waste a lot of memory for certain allocations.
Switching to a slightly cleaned up
Hi Liu,
On 6/14/19 2:38 PM, Liu, Yi L wrote:
> Hi Eric,
>
>> From: Eric Auger [mailto:eric.au...@redhat.com]
>> Sent: Monday, May 27, 2019 12:10 AM
>> Subject: [PATCH v8 23/29] vfio: VFIO_IOMMU_CACHE_INVALIDATE
>>
>> From: "Liu, Yi L"
>>
>> When the guest "owns" the stage 1 translation
On Wed, May 08, 2019 at 06:56:46PM +0100, Jon Mason wrote:
> I do have a system. So, it could be tested. However given the age of
> the HW, I would say it is not worth the effort to update and it would
> be best to remove it from the kernel.
>
> I can send a patch to do this, unless you would
Hi Eric,
> From: Eric Auger [mailto:eric.au...@redhat.com]
> Sent: Monday, May 27, 2019 12:10 AM
> Subject: [PATCH v8 23/29] vfio: VFIO_IOMMU_CACHE_INVALIDATE
>
> From: "Liu, Yi L"
>
> When the guest "owns" the stage 1 translation structures, the host IOMMU
> driver
> has no knowledge of
Thanks,
applied to the dma-mapping for-next branch.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Fri, Jun 14, 2019 at 11:42:54AM +0100, Robin Murphy wrote:
> On 06/06/2019 07:28, Christoph Hellwig wrote:
>> Looks fine to me. Robin, any comments?
>
> AFAICS this looks like the obvious conversion, so... no? :)
Yep. Just want to make sure I don't apply dma-iommu patches without
your
Thanks,
applied to the dma-mapping for-next branch.
On Fri, Jun 14, 2019 at 07:35:29PM +0800, Greentime Hu wrote:
> It looks good to me. I just verified in nds32 platform and it works fine.
> Should I put it in my next-tree or you will pick it up in your tree? :)
Either way works for me, let me know what you prefer.
Christoph Hellwig 於 2019年6月14日 週五 下午6:09寫道：
>
> Hi Greentime and Vicent,
>
> can you take a look at the (untested) patch below? It converts nds32
> to use the generic remapping DMA allocator, which is also used by
> arm64 and csky.
Hi Christoph,
It looks good to me. I just verified in nds32
On 06/06/2019 07:28, Christoph Hellwig wrote:
Looks fine to me. Robin, any comments?
AFAICS this looks like the obvious conversion, so... no? :)
On Mon, Jun 03, 2019 at 03:52:59PM -0700, Nicolin Chen wrote:
This patch replaces dma_{alloc,release}_from_contiguous() with
> > + host->can_merge = 1;
> > + else
> > + host->can_merge = 0;
> > +
>
> can_merge seems a little too generic a name to me. Maybe can_iommu_merge?
Ack.
signature.asc
Description: PGP signature
When we remap memory as non-cached to be used as a DMA coherent buffer
we should writeback all cache and invalidate the cache lines so that
we make sure we have a clean slate. Implement this using the
cache_push() helper.
Signed-off-by: Christoph Hellwig
---
arch/m68k/Kconfig | 1 +
This switche to using common code for the DMA allocations, including
potential use of the CMA allocator if configure. Also add a
comment where the existing behavior seems to be lacking.
Signed-off-by: Christoph Hellwig
---
arch/m68k/Kconfig | 2 ++
arch/m68k/kernel/dma.c | 59
Hi Geert and Greg,
can you take a look at the (untested) patches below? They convert m68k
to use the generic remapping DMA allocator, which is also used by
arm64 and csky.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Fri, Jun 14, 2019 at 11:39 AM Thierry Reding
wrote:
>
> On Fri, Jun 14, 2019 at 11:10:58AM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Jun 13, 2019 at 07:00:11PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
[cut]
>
> To avoid further back and forth, what exactly is it that
Replace the code that sets up uncached PTEs with the generic vmap based
remapping code. It also provides an atomic pool for allocations from
non-blocking context, which we not properly supported by the existing
nds32 code.
Signed-off-by: Christoph Hellwig
---
arch/nds32/Kconfig | 2 +
Hi Greentime and Vicent,
can you take a look at the (untested) patch below? It converts nds32
to use the generic remapping DMA allocator, which is also used by
arm64 and csky.
On 13/06/2019 11:20, Yoshihiro Shimoda wrote:
This patch adds a helper function whether a queue can merge
the segments by an IOMMU.
Signed-off-by: Yoshihiro Shimoda
---
block/blk-settings.c | 28
include/linux/blkdev.h | 2 ++
2 files changed, 30
On Tue, Jun 11, 2019 at 10:58:25AM -0700, Florian Fainelli wrote:
> With a specifically contrived memory layout where there is no physical
> memory available to the kernel below the 4GB boundary, we will fail to
> perform the initial swiotlb_init() call and set no_iotlb_memory to true.
>
> There
On Tue, Jun 11, 2019 at 10:58:24AM -0700, Florian Fainelli wrote:
> Avoid repeating the zeroing of global swiotlb variables in two locations
> and introduce swiotlb_cleanup() to do that.
>
> Signed-off-by: Florian Fainelli
Looks good,
Reviewed-by: Christoph Hellwig
On 13/06/2019 11:20, Yoshihiro Shimoda wrote:
This patch adds an exported function to get minimum page size for
a domain. This patch also modifies similar codes on the iommu.c.
Heh, seeing this gave me a genuine déjà vu moment...
...but it turns out I actually *have* reviewed this patch
On Fri, Jun 14, 2019 at 11:10:58AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jun 13, 2019 at 07:00:11PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Some subsystems, such as pinctrl, allow continuing to defer probe
> > indefinitely. This is useful for devices that depend on
Hi Linus,
The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:
Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.2-rc4
for you to fetch changes up to
On 6/14/2019 9:35 AM, Bjorn Andersson wrote:
On Wed 12 Jun 00:15 PDT 2019, Vivek Gautam wrote:
Qcom's implementation of arm,mmu-500 adds a WAIT-FOR-SAFE logic
to address under-performance issues in real-time clients, such as
Display, and Camera.
On receiving an invalidation requests, the
On Thu, Jun 13, 2019 at 07:00:11PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Some subsystems, such as pinctrl, allow continuing to defer probe
> indefinitely. This is useful for devices that depend on resources
> provided by devices that are only probed after the init stage.
>
>
On Thu, Jun 13, 2019 at 7:00 PM Thierry Reding wrote:
>
> From: Thierry Reding
>
> Some subsystems, such as pinctrl, allow continuing to defer probe
> indefinitely. This is useful for devices that depend on resources
> provided by devices that are only probed after the init stage.
>
> One
On 6/14/2019 9:36 AM, Bjorn Andersson wrote:
On Wed 12 Jun 00:15 PDT 2019, Vivek Gautam wrote:
Indicate on MTP SDM845 that firmware implements handler to
TLB invalidate erratum SCM call where SAFE sequence is toggled
to achieve optimum performance on real-time clients, such as
display and
If I don't hear anything back in the next days I will just merge
these patches, please comment.
On Wed, May 29, 2019 at 02:22:19PM +0200, Christoph Hellwig wrote:
> Russell,
>
> any additional comments on this series?
>
> On Tue, May 21, 2019 at 03:15:03PM +0200, Christoph Hellwig wrote:
> > On
Hi jean,
On 5/30/19 7:09 PM, Jean-Philippe Brucker wrote:
> 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
Hi Christoph,
On Fri, Jun 14, 2019 at 9:18 AM Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 10:35:44PM +0200, Geert Uytterhoeven wrote:
> > I'm always triggered by the use of min_t() and other casts:
> > mmc->max_blk_size and mmc->max_blk_count are both unsigned int.
> >
On Thu, Jun 13, 2019 at 07:20:15PM +0900, Yoshihiro Shimoda wrote:
> +static unsigned int mmc_get_max_segments(struct mmc_host *host)
> +{
> + return host->can_merge ? BLK_MAX_SEGMENTS : host->max_segs;
> +}
Note that BLK_MAX_SEGMENTS is really a little misnamed, it just
is a
I'm a little worried about this directly calling into the iommu
API instead of going through the DMA mapping code. We still have
plenty of iommus not using the iommu layer for DMA mapping. But at
least this code is in the block layer and not the driver, so maybe
we can live with it.
On Thu, Jun 13, 2019 at 10:35:44PM +0200, Geert Uytterhoeven wrote:
> I'm always triggered by the use of min_t() and other casts:
> mmc->max_blk_size and mmc->max_blk_count are both unsigned int.
> dma_max_mapping_size() returns size_t, which can be 64-bit.
>
> 1) Can the multiplication
On Thu, Jun 13, 2019 at 09:37:59PM +0200, Wolfram Sang wrote:
> What about making this a 'static inline' in the iommu header file? I'd
> think it is simple enough and would save us the EXPORT symbol.
Agreed, this seems simple enought for an inline.
Thomas Gleixner is doing automated SPDX conversion that directly
got to Linux at the moment. I'd avoid doing more manual ones for
now as it will just create conflicts.
On Fri, Jun 14, 2019 at 06:11:00AM +, Tan, Ley Foon wrote:
> On Fri, 2019-06-14 at 07:44 +0200, Christoph Hellwig wrote:
> > On Fri, Jun 14, 2019 at 09:40:34AM +0800, Ley Foon Tan wrote:
> > >
> > > Hi Christoph
> > >
> > > Can this patch in http://git.infradead.org/users/hch/dma-mapping.gi
On Thu, 13 Jun 2019 at 18:27, Yangtao Li wrote:
>
> Updates license to use SPDX-License-Identifier.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/iommu/exynos-iommu.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
Splitting this per driver is too much... it is not necessary. Such
On Fri, 2019-06-14 at 07:44 +0200, Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 09:40:34AM +0800, Ley Foon Tan wrote:
> >
> > Hi Christoph
> >
> > Can this patch in http://git.infradead.org/users/hch/dma-mapping.gi
> > t/sh
> > ortlog/refs/heads/for-next
> >
> > [PATCH 1/2] nios2: use the
83 matches
Mail list logo
