[PATCH 4/4 v2] arc: fix printk warning in arc/plat-eznps/mtm.c
From: Randy Dunlap
Fix printk format warning in arch/arc/plat-eznps/mtm.c:
In file included from ../include/linux/printk.h:7,
from ../include/linux/kernel.h:14,
from ../include/linux/list.h:9,
from ../include/linux/smp.h:12,
from ../arch/arc/plat-eznps/mtm.c:17:
../arch/arc/plat-eznps/mtm.c: In function 'set_mtm_hs_ctr':
../include/linux/kern_levels.h:5:18: warning: format '%d' expects argument of
type 'int', but argument 2 has type 'long int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^~
../include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
../include/linux/printk.h:308:9: note: in expansion of macro 'KERN_ERR'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
../arch/arc/plat-eznps/mtm.c:166:3: note: in expansion of macro 'pr_err'
pr_err("** Invalid @nps_mtm_hs_ctr [%d] needs to be [%d:%d] (incl)\n",
^~
../arch/arc/plat-eznps/mtm.c:166:40: note: format string is defined here
pr_err("** Invalid @nps_mtm_hs_ctr [%d] needs to be [%d:%d] (incl)\n",
~^
%ld
The hs_ctr variable can just be int instead of long, so also change
kstrtol() to kstrtoint() and leave the format string as %d.
Also add 2 header files since they are used in mtm.c and we prefer
not to depend on accidental/indirect #includes.
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
---
v2: no change
arch/arc/plat-eznps/mtm.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-next-20180723.orig/arch/arc/plat-eznps/mtm.c
+++ linux-next-20180723/arch/arc/plat-eznps/mtm.c
@@ -15,6 +15,8 @@
*/
#include
+#include
+#include
#include
#include
#include
@@ -157,10 +159,10 @@ void mtm_enable_core(unsigned int cpu)
/* Verify and set the value of the mtm hs counter */
static int __init set_mtm_hs_ctr(char *ctr_str)
{
- long hs_ctr;
+ int hs_ctr;
int ret;
- ret = kstrtol(ctr_str, 0, _ctr);
+ ret = kstrtoint(ctr_str, 0, _ctr);
if (ret || hs_ctr > MT_HS_CNT_MAX || hs_ctr < MT_HS_CNT_MIN) {
pr_err("** Invalid @nps_mtm_hs_ctr [%d] needs to be [%d:%d]
(incl)\n",
--
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 2/4 v2] arc: fix type warnings in arc/mm/cache.c
From: Randy Dunlap
Fix type warnings in arch/arc/mm/cache.c.
../arch/arc/mm/cache.c: In function 'flush_anon_page':
../arch/arc/mm/cache.c:1062:55: warning: passing argument 2 of
'__flush_dcache_page' makes integer from pointer without a cast
[-Wint-conversion]
__flush_dcache_page((phys_addr_t)page_address(page), page_address(page));
^~
../arch/arc/mm/cache.c:1013:59: note: expected 'long unsigned int' but argument
is of type 'void *'
void __flush_dcache_page(phys_addr_t paddr, unsigned long vaddr)
~~^
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
---
v2: drop some spurious (accidental) patch lines
arch/arc/mm/cache.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- linux-next-20180723.orig/arch/arc/mm/cache.c
+++ linux-next-20180723/arch/arc/mm/cache.c
@@ -1038,7 +1038,7 @@ void flush_cache_mm(struct mm_struct *mm
void flush_cache_page(struct vm_area_struct *vma, unsigned long u_vaddr,
unsigned long pfn)
{
- unsigned int paddr = pfn << PAGE_SHIFT;
+ phys_addr_t paddr = pfn << PAGE_SHIFT;
u_vaddr &= PAGE_MASK;
@@ -1058,8 +1058,9 @@ void flush_anon_page(struct vm_area_stru
unsigned long u_vaddr)
{
/* TBD: do we really need to clear the kernel mapping */
- __flush_dcache_page(page_address(page), u_vaddr);
- __flush_dcache_page(page_address(page), page_address(page));
+ __flush_dcache_page((phys_addr_t)page_address(page), u_vaddr);
+ __flush_dcache_page((phys_addr_t)page_address(page),
+ (phys_addr_t)page_address(page));
}
--
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 3/4 v2] arc: fix data type errors in platform headers
From: Randy Dunlap Add to fix build errors. Both ctop.h and use u32 types and cause many errors. Examples: ../include/soc/nps/common.h:71:4: error: unknown type name 'u32' u32 __reserved:20, cluster:4, core:4, thread:4; ../include/soc/nps/common.h:76:3: error: unknown type name 'u32' u32 value; ../include/soc/nps/common.h:124:4: error: unknown type name 'u32' u32 base:8, cl_x:4, cl_y:4, ../include/soc/nps/common.h:127:3: error: unknown type name 'u32' u32 value; ../arch/arc/plat-eznps/include/plat/ctop.h:83:4: error: unknown type name 'u32' u32 gen:1, gdis:1, clk_gate_dis:1, asb:1, ../arch/arc/plat-eznps/include/plat/ctop.h:86:3: error: unknown type name 'u32' u32 value; ../arch/arc/plat-eznps/include/plat/ctop.h:93:4: error: unknown type name 'u32' u32 csa:22, dmsid:6, __reserved:3, cs:1; ../arch/arc/plat-eznps/include/plat/ctop.h:95:3: error: unknown type name 'u32' u32 value; Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: linux-snps-arc@lists.infradead.org Cc: Elad Kanfi Cc: Leon Romanovsky Cc: Ofer Levi --- v2: no change arch/arc/plat-eznps/include/plat/ctop.h |1 + 1 file changed, 1 insertion(+) --- linux-next-20180723.orig/arch/arc/plat-eznps/include/plat/ctop.h +++ linux-next-20180723/arch/arc/plat-eznps/include/plat/ctop.h @@ -21,6 +21,7 @@ #error "Incorrect ctop.h include" #endif +#include #include /* core auxiliary registers */ -- ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 0/4 v2] arc: some allmodconfig build fixes
From: Randy Dunlap Hi, Here are a few patches that fix build errors or warnings that I encountered while doing arc "allmodconfig" builds. These patches do not fix all of the build issues. arch/arc/include/asm/delay.h|3 +++ arch/arc/mm/cache.c |7 --- arch/arc/plat-eznps/include/plat/ctop.h |1 + arch/arc/plat-eznps/mtm.c |6 -- 4 files changed, 12 insertions(+), 5 deletions(-) -- ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 1/4 v2] arc: fix build errors in arc/include/asm/delay.h
From: Randy Dunlap
Fix build errors in arch/arc/'s delay.h:
- add "extern unsigned long loops_per_jiffy;"
- add for "u64"
In file included from ../drivers/infiniband/hw/cxgb3/cxio_hal.c:32:
../arch/arc/include/asm/delay.h: In function '__udelay':
../arch/arc/include/asm/delay.h:61:12: error: 'u64' undeclared (first use in
this function)
loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32;
^~~
In file included from ../drivers/infiniband/hw/cxgb3/cxio_hal.c:32:
../arch/arc/include/asm/delay.h: In function '__udelay':
../arch/arc/include/asm/delay.h:63:37: error: 'loops_per_jiffy' undeclared
(first use in this function)
loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32;
^~~
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
---
v2: add extern for loops_per_jiffy instead of including
for it
arch/arc/include/asm/delay.h |3 +++
1 file changed, 3 insertions(+)
--- linux-next-20180723.orig/arch/arc/include/asm/delay.h
+++ linux-next-20180723/arch/arc/include/asm/delay.h
@@ -17,8 +17,11 @@
#ifndef __ASM_ARC_UDELAY_H
#define __ASM_ARC_UDELAY_H
+#include
#include /* HZ */
+extern unsigned long loops_per_jiffy;
+
static inline void __delay(unsigned long loops)
{
__asm__ __volatile__(
--
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: fix broken noncoherent cache ops
On 07/26/2018 02:08 AM, Christoph Hellwig wrote:
> On Tue, Jul 24, 2018 at 05:13:02PM +0300, Eugeniy Paltsev wrote:
>> All DMA devices on ARC haven't worked with SW cache control
>> since commit a8eb92d02dd7 ("arc: fix arc_dma_{map,unmap}_page")
>> This happens because we don't check direction argument at all in
>> new implementation. Fix that.
>>
>> Fixies: commit a8eb92d02dd7 ("arc: fix arc_dma_{map,unmap}_page")
>> Signed-off-by: Eugeniy Paltsev
> Looks sensible. Might be worth explaining that ARC can speculate
> into the areas under DMA, which is why this is required.
>
ARC CPUs do prefetch, but I doubt if they are doing so, so aggressively,
specially
when the region around DMA buffers is unlikely to be used for normal LD/ST
bleeding into DMA buffers. The issue here seems to be less technical and a bit
of
snafu in implementation details.
1. originally
dma_map_single(@dir) => honored @dir, and did inv, wback or both depending
on it
sync_for_device(@dir) => forced @dir DMA_TO_DEV = > cache wback
sync_for_cpu(@dir) => forced @dir DMA_FROM_DEV = > cache inv
2. After commit a8eb92d02dd7, dma_map_single() starting callingsync_for_device(
)
which as noted above didn't respect @dir, only doing cache wback, and thus would
fail for DMA_FROM_DEV/BIDIR cases where cpu needs to read from buffer and thus
requires cache inv as well. Likewise dma_unmap_single() would unconditionally do
cache inv, given usage of sync_for_cpu() which would be wrong for the TO_DEVICE
cases.
Too bad I didn't spot this in the code review myself at the time.
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] ARC: add SMP_CACHE_BYTES value validate
On 07/26/2018 06:15 AM, Eugeniy Paltsev wrote:
> Check that SMP_CACHE_BYTES (and hence ARCH_DMA_MINALIGN) is larger
> or equal to any cache line length by comparing it with values
> previously read from ARC cache BCR registers.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> Changes v1->v2:
> * None.
>
> arch/arc/mm/cache.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
> index 9dbe645ee127..b95365e1253a 100644
> --- a/arch/arc/mm/cache.c
> +++ b/arch/arc/mm/cache.c
> @@ -1246,6 +1246,16 @@ void __init arc_cache_init_master(void)
> }
> }
>
> + /*
> + * Check that SMP_CACHE_BYTES (and hence ARCH_DMA_MINALIGN) is larger
> + * or equal to any cache line length.
> + */
> + BUILD_BUG_ON_MSG(L1_CACHE_BYTES > SMP_CACHE_BYTES,
> + "SMP_CACHE_BYTES must be >= any cache line length");
> + if (is_isa_arcv2() && (l2_line_sz > SMP_CACHE_BYTES))
> + panic("L2 Cache line [%d] > kernel Config [%d]\n",
> + l2_line_sz, SMP_CACHE_BYTES);
> +
> /* Note that SLC disable not formally supported till HS 3.0 */
> if (is_isa_arcv2() && l2_line_sz && !slc_enable)
> arc_slc_disable();
LGTM. Both applied.
Thx,
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] Fix the ld flags not be applied to tst-execstack-mod.so
On Thu, 26 Jul 2018, Zong Li wrote: > In glibc now, this option doesn't pass to linker, the module is still > not executable on stack. I think that we need this patch to fix up it or > another patch to remove the variable in Makefile if it is not necessary. > Both are fine for me. For now, it is a little bit strange because it > present in Makefile but has no effect. I think we should have the option in a properly named variable. But the patch will need review and we're currently in a release freeze. -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 1/2] ARC: setup SMP_CACHE_BYTES and cache_line_size
As for today we don't setup SMP_CACHE_BYTESi and cache_line_size for ARC, so they are set to L1_CACHE_BYTES by default. L1 line length (L1_CACHE_BYTES) might be easily smaller than L2 line (which is usually the case BTW). This breaks code. For example this breaks ethernet infrastructure on HSDK/AXS103 boards with IOC disabled: Functions which alloc and manage sk_buff packet data area rely on SMP_CACHE_BYTES define. In the result we can share last L2 cache line in sk_buff linear packet data area between DMA buffer and some useful data in other structure. So we can lose this data when we invalidate DMA buffer. sk_buff linear packet data area | | | skb->endskb->tail V|| VV --. packet data| | --. -.--. SLC line| SLC (L2 cache) line (128B) | -.--. ^ ^ | | These cache lines will be invalidated when we invalidate skb linear packet data area before DMA transaction starting. This leads to issues painful to debug as it reproduces only if (sk_buff->end - sk_buff->tail) < SLC_LINE_SIZE and if we have some useful data right after sk_buff->end. Fix that by hardcode SMP_CACHE_BYTES to max line length we may have. Signed-off-by: Eugeniy Paltsev --- Changes v1->v2: * Fix ARCH_HAS_CACHE_LINE_SIZE selection in ARC Kconfig arch/arc/Kconfig | 3 +++ arch/arc/include/asm/cache.h | 4 +++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 9cf59fc60eab..5151d81476a1 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -50,6 +50,9 @@ config ARC select HAVE_KERNEL_LZMA select ARCH_HAS_PTE_SPECIAL +config ARCH_HAS_CACHE_LINE_SIZE + def_bool y + config MIGHT_HAVE_PCI bool diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h index 8486f328cc5d..ff7d3232764a 100644 --- a/arch/arc/include/asm/cache.h +++ b/arch/arc/include/asm/cache.h @@ -48,7 +48,9 @@ }) /* Largest line length for either L1 or L2 is 128 bytes */ -#define ARCH_DMA_MINALIGN 128 +#define SMP_CACHE_BYTES128 +#define cache_line_size() SMP_CACHE_BYTES +#define ARCH_DMA_MINALIGN SMP_CACHE_BYTES extern void arc_cache_init(void); extern char *arc_cache_mumbojumbo(int cpu_id, char *buf, int len); -- 2.14.4 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 2/2] ARC: add SMP_CACHE_BYTES value validate
Check that SMP_CACHE_BYTES (and hence ARCH_DMA_MINALIGN) is larger
or equal to any cache line length by comparing it with values
previously read from ARC cache BCR registers.
Signed-off-by: Eugeniy Paltsev
---
Changes v1->v2:
* None.
arch/arc/mm/cache.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 9dbe645ee127..b95365e1253a 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -1246,6 +1246,16 @@ void __init arc_cache_init_master(void)
}
}
+ /*
+* Check that SMP_CACHE_BYTES (and hence ARCH_DMA_MINALIGN) is larger
+* or equal to any cache line length.
+*/
+ BUILD_BUG_ON_MSG(L1_CACHE_BYTES > SMP_CACHE_BYTES,
+"SMP_CACHE_BYTES must be >= any cache line length");
+ if (is_isa_arcv2() && (l2_line_sz > SMP_CACHE_BYTES))
+ panic("L2 Cache line [%d] > kernel Config [%d]\n",
+ l2_line_sz, SMP_CACHE_BYTES);
+
/* Note that SLC disable not formally supported till HS 3.0 */
if (is_isa_arcv2() && l2_line_sz && !slc_enable)
arc_slc_disable();
--
2.14.4
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] NET: stmmac: align DMA stuff to largest cache line length
As for today STMMAC_ALIGN macro (which is used to align DMA stuff) relies on L1 line length (L1_CACHE_BYTES). This isn't correct in case of system with several cache levels which might have L1 cache line length smaller than L2 line. This can lead to sharing one cache line between DMA buffer and other data, so we can lose this data while invalidate DMA buffer before DMA transaction. Fix that by using SMP_CACHE_BYTES instead of L1_CACHE_BYTES for aligning. Signed-off-by: Eugeniy Paltsev --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 60f59abab009..ef6a8d39db2f 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -53,7 +53,7 @@ #include "dwmac1000.h" #include "hwif.h" -#define STMMAC_ALIGN(x)L1_CACHE_ALIGN(x) +#defineSTMMAC_ALIGN(x) __ALIGN_KERNEL(x, SMP_CACHE_BYTES) #defineTSO_MAX_BUFF_SIZE (SZ_16K - 1) /* Module parameters */ -- 2.14.4 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 1/2] ARC: setup SMP_CACHE_BYTES and cache_line_size
As for today we don't setup SMP_CACHE_BYTESi and cache_line_size for ARC, so they are set to L1_CACHE_BYTES by default. L1 line length (L1_CACHE_BYTES) might be easily smaller than L2 line (which is usually the case BTW). This breaks code. For example this breaks ethernet infrastructure on HSDK/AXS103 boards with IOC disabled: Functions which alloc and manage sk_buff packet data area rely on SMP_CACHE_BYTES define. In the result we can share last L2 cache line in sk_buff linear packet data area between DMA buffer and some useful data in other structure. So we can lose this data when we invalidate DMA buffer. sk_buff linear packet data area | | | skb->endskb->tail V|| VV --. packet data| | --. -.--. SLC line| SLC (L2 cache) line (128B) | -.--. ^ ^ | | These cache lines will be invalidated when we invalidate skb linear packet data area before DMA transaction starting. This leads to issues painful to debug as it reproduces only if (sk_buff->end - sk_buff->tail) < SLC_LINE_SIZE and if we have some useful data right after sk_buff->end. Fix that by hardcode SMP_CACHE_BYTES to max line length we may have. Signed-off-by: Eugeniy Paltsev Signed-off-by: Eugeniy Paltsev --- arch/arc/Kconfig | 1 + arch/arc/include/asm/cache.h | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 9cf59fc60eab..ee1a38c99197 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -9,6 +9,7 @@ config ARC def_bool y select ARC_TIMERS + select ARCH_HAS_CACHE_LINE_SIZE select ARCH_HAS_SYNC_DMA_FOR_CPU select ARCH_HAS_SYNC_DMA_FOR_DEVICE select ARCH_HAS_SG_CHAIN diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h index 8486f328cc5d..ff7d3232764a 100644 --- a/arch/arc/include/asm/cache.h +++ b/arch/arc/include/asm/cache.h @@ -48,7 +48,9 @@ }) /* Largest line length for either L1 or L2 is 128 bytes */ -#define ARCH_DMA_MINALIGN 128 +#define SMP_CACHE_BYTES128 +#define cache_line_size() SMP_CACHE_BYTES +#define ARCH_DMA_MINALIGN SMP_CACHE_BYTES extern void arc_cache_init(void); extern char *arc_cache_mumbojumbo(int cpu_id, char *buf, int len); -- 2.14.4 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 3/4] ARC: refactor arch/arc/mm/dma.c
On Tue, Jul 24, 2018 at 01:10:00PM +0300, Eugeniy Paltsev wrote:
> Refactoring, no functional change intended.
Might be worth explaining a bit why you are refactoring it (i.e. what is the
benefit).
>
> Signed-off-by: Eugeniy Paltsev
> ---
> arch/arc/mm/dma.c | 28 ++--
> 1 file changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
> index b693818cd8e5..46584c7c2858 100644
> --- a/arch/arc/mm/dma.c
> +++ b/arch/arc/mm/dma.c
> @@ -27,30 +27,24 @@ void *arch_dma_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle,
> struct page *page;
> phys_addr_t paddr;
> void *kvaddr;
> - int need_coh = 1, need_kvaddr = 0;
> + bool need_coh = !(attrs & DMA_ATTR_NON_CONSISTENT);
>
> page = alloc_pages(gfp, order);
> if (!page)
> return NULL;
>
> /* This is linear addr (0x8000_ based) */
> paddr = page_to_phys(page);
>
> *dma_handle = paddr;
>
> + /*
> + * - A coherent buffer needs MMU mapping to enforce non-cachability
> + * - A highmem page needs a virtual handle (hence MMU mapping)
> + * independent of cachability.
> + * kvaddr is kernel Virtual address (0x7000_ based)
> + */
> + if (PageHighMem(page) || need_coh) {
dma_alloc_attrs clears __GFP_HIGHMEM from the passed in gfp mask, so
you'll never get a highmem page here.
That also means you can merge this conditional with the one for the cache
writeback and invalidation and kill the need_coh flag entirely.
> kvaddr = ioremap_nocache(paddr, size);
> if (kvaddr == NULL) {
> __free_pages(page, order);
> @@ -81,11 +75,9 @@ void arch_dma_free(struct device *dev, size_t size, void
> *vaddr,
> {
> phys_addr_t paddr = dma_handle;
> struct page *page = virt_to_page(paddr);
> - int is_non_coh = 1;
> -
> - is_non_coh = (attrs & DMA_ATTR_NON_CONSISTENT);
> + bool is_coh = !(attrs & DMA_ATTR_NON_CONSISTENT);
>
> - if (PageHighMem(page) || !is_non_coh)
> + if (PageHighMem(page) || is_coh)
> iounmap((void __force __iomem *)vaddr);
>
Same here.
Also if you clean this up it would be great to take the per-device pfn offset
into account, even if that isn't used anywhere on arc yet, that is call
phys_to_dma and dma_to_phys to convert to an from the dma address.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/4] ARC: allow to use IOC and non-IOC DMA devices simultaneously
> select DMA_NONCOHERENT_OPS > + select DMA_DIRECT_OPS DMA_NONCOHERENT_OPS already selects DMA_DIRECT_OPS. Otherwise looks good: Reviewed-by: Christoph Hellwig ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: fix broken noncoherent cache ops
On Tue, Jul 24, 2018 at 05:13:02PM +0300, Eugeniy Paltsev wrote:
> All DMA devices on ARC haven't worked with SW cache control
> since commit a8eb92d02dd7 ("arc: fix arc_dma_{map,unmap}_page")
> This happens because we don't check direction argument at all in
> new implementation. Fix that.
>
> Fixies: commit a8eb92d02dd7 ("arc: fix arc_dma_{map,unmap}_page")
> Signed-off-by: Eugeniy Paltsev
Looks sensible. Might be worth explaining that ARC can speculate
into the areas under DMA, which is why this is required.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
