Fix some bugs on RV32 build fail and issue.

This patches fix up the building fail, less function and other issue on RV32.

Vincent Chen (1):
RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap

Zong Li (4):
RISC-V: Build tishift only on 64-bit
RISC-V: Use swiotlb on RV64 only
lib: Add umoddi3 and udivmoddi4 of GCC library routines
RISC-V: Select GENERIC_LIB_UMODDI3 on RV32

 arch/riscv/Kconfig        |   1 +
 arch/riscv/kernel/setup.c |   3 +
 arch/riscv/lib/Makefile   |   3 +-
 arch/riscv/mm/ioremap.c   |   2 +-
 lib/Kconfig               |   3 +
 lib/Makefile              |   1 +
 lib/udivmoddi4.c          | 291 ++++++++++++++++++++++++++++++++++++++++++++++
 lib/umoddi3.c             |  16 +++
 8 files changed, 318 insertions(+), 2 deletions(-)
 create mode 100644 lib/udivmoddi4.c
 create mode 100644 lib/umoddi3.c

2.7.4

Only RV64 supports 128 integer size.

---
 arch/riscv/lib/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

index 445ec84..5739bd0 100644
@@ -2,6 +2,7 @@ lib-y	+= delay.o
 lib-y	+= memcpy.o
 lib-y	+= memset.o
 lib-y	+= uaccess.o
-lib-y	+= tishift.o
+
+lib-(CONFIG_64BIT) += tishift.o
 
 lib-$(CONFIG_32BIT) += udivdi3.o

2.7.4

This looks fine. Just curious, what do we even need 128-bit integers for on riscv64? Did you see any issues if you drop it entirely?

Christoph Hellwig <[email protected]> ? 2018?9?21? ?? ??2:58???

You can refer to this issue, but I didn't try it.
https://github.com/riscv/riscv-linux/issues/136

Only RV64 supports swiotlb.

---
 arch/riscv/kernel/setup.c | 3 +++
 1 file changed, 3 insertions(+)

index aee6031..872a280 100644
@@ -227,7 +227,10 @@ void __init setup_arch(char **cmdline_p)
 	setup_bootmem();
 	paging_init();
 	unflatten_device_tree();
+
+#ifdef CONFIG_64bit
 	swiotlb_init(1);
+#endif
 
 #ifdef CONFIG_SMP
 	setup_smp();

2.7.4

Add umoddi3 and udivmoddi4 support for 32-bit.

---
 lib/Kconfig      |   3 +
 lib/Makefile     |   1 +
 lib/udivmoddi4.c | 291 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/umoddi3.c    |  16 +++
 4 files changed, 311 insertions(+)
 create mode 100644 lib/udivmoddi4.c
 create mode 100644 lib/umoddi3.c

index a3928d4..d82f206 100644
@@ -621,3 +621,6 @@ config GENERIC_LIB_CMPDI2
 
 config GENERIC_LIB_UCMPDI2
 	bool
+
+config GENERIC_LIB_UMODDI3
+	bool

index ca3f7eb..51bf24d 100644
@@ -271,3 +271,4 @@ obj-$(CONFIG_GENERIC_LIB_LSHRDI3) += lshrdi3.o
 obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o
 obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o
 obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o
+obj-$(CONFIG_GENERIC_LIB_UMODDI3) += umoddi3.o udivmoddi4.o

new file mode 100644
index 0000000..85b2b86
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/module.h>
+#include <linux/libgcc.h>
+
+extern unsigned long long __udivmoddi4(unsigned long long u,
+				       unsigned long long v,
+				       unsigned long long *rp);
+
+unsigned long long __umoddi3(unsigned long long u, unsigned long long v)
+{
+	unsigned long long w;
+	(void)__udivmoddi4(u, v, &w);
+	return w;
+}
+EXPORT_SYMBOL(__umoddi3);

2.7.4

This probably wants a better explanation of why you need them.

Christoph Hellwig <[email protected]> ? 2018?9?21? ?? ??3:00???

The RV32 need the umoddi3 to do modulo when the operands are long long type, like other libraries implementation such as ucmpdi2, lshrdi3 and so on. I encounter the undefined reference 'umoddi3' when I use the in house dma driver, although it is in house driver, but I think that umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for flexible extension in the future.

You probably should use the macros from <asm/div64.h> instead.

Andreas.

Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Andreas Schwab <[email protected]> ? 2018?9?25? ?? ??3:20???

Hi Andreas,

This doesn't work for me, the divisor of my case is also long long type.

I don't think libgcc is GPLv2 licensed, is it? Also please retain the copyright notices from libgcc.

Christoph Hellwig <[email protected]> ? 2018?9?25? ?? ??11:25???

I will give next version patch. Thanks.

On 32-bit, it need to use __umoddi3 by some drivers.

---
 arch/riscv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

index a344980..dc262fa 100644
@@ -108,6 +108,7 @@ config ARCH_RV32I
 	select GENERIC_LIB_ASHRDI3
 	select GENERIC_LIB_LSHRDI3
 	select GENERIC_LIB_UCMPDI2
+	select GENERIC_LIB_UMODDI3
 
 config ARCH_RV64I
 	bool "RV64I"

2.7.4

From: Vincent Chen <[email protected]>

For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero after AND with PAGE_MASK because the data type of PAGE_MASK is unsigned long. To fix this problem, the page alignment is done by subtracting the page offset instead of AND with PAGE_MASK.

---
 arch/riscv/mm/ioremap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 70ef272..bd2f2db 100644
@@ -42,7 +42,7 @@ static void __iomem *__ioremap_caller(phys_addr_t addr, size_t size,
 
 	/* Page-align mappings */
 	offset = addr & (~PAGE_MASK);
-	addr &= PAGE_MASK;
+	addr -= offset;
 	size = PAGE_ALIGN(size + offset);
 
 	area = get_vm_area_caller(size, VM_IOREMAP, caller);

2.7.4

Looks fine,