linux.git/arch/riscv, branch v5.11

Revert "dts: phy: add GPIO number and active state used for phy reset"

2021-02-11T00:06:14+00:00

VSC8541 phys need a special reset sequence, which the driver doesn't
currentlny support.  As a result enabling the reset via GPIO essentially
guarnteees that the device won't work correctly.  We've been relying on
bootloaders to reset the device for years, with this revert we'll go
back to doing so until we can sort out how to get the reset sequence
into the kernel.

This reverts commit a0fa9d727043da2238432471e85de0bdb8a8df65.

Fixes: a0fa9d727043 ("dts: phy: add GPIO number and active state used for phy reset")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt

RISC-V: Define MAXPHYSMEM_1GB only for RV32

2021-02-03T02:36:42+00:00

MAXPHYSMEM_1GB option was added for RV32 because RV32 only supports 1GB
of maximum physical memory. This lead to few compilation errors reported
by kernel test robot which created the following configuration combination
which are not useful but can be configured.

1. MAXPHYSMEM_1GB & RV64
2, MAXPHYSMEM_2GB & RV32

Fix this by restricting MAXPHYSMEM_1GB for RV32 and MAXPHYSMEM_2GB only for
RV64.

Fixes: e557793799c5 ("RISC-V: Fix maximum allowed phsyical memory for RV32")
Cc: stable@vger.kernel.org
Reported-by: Randy Dunlap 
Acked-by: Randy Dunlap 
Tested-by: Geert Uytterhoeven 
Signed-off-by: Atish Patra 
Signed-off-by: Palmer Dabbelt

riscv: Align on L1_CACHE_BYTES when STRICT_KERNEL_RWX

2021-02-03T02:36:29+00:00

Allows the sections to be aligned on smaller boundaries and
therefore results in a smaller kernel image size.

Signed-off-by: Sebastien Van Cauwenberghe 
Reviewed-by: Atish Patra 
Signed-off-by: Palmer Dabbelt

RISC-V: Fix .init section permission update

2021-02-03T02:35:42+00:00

.init section permission should only updated to non-execute if
STRICT_KERNEL_RWX is enabled. Otherwise, this will lead to a kernel hang.

Fixes: 19a00869028f ("RISC-V: Protect all kernel sections including init early")
Cc: stable@vger.kernel.org
Suggested-by: Geert Uytterhoeven 
Reported-by: Geert Uytterhoeven 
Signed-off-by: Atish Patra 
Reviewed-by: Atish Patra 
Signed-off-by: Palmer Dabbelt

riscv: virt_addr_valid must check the address belongs to linear mapping

2021-02-03T02:31:13+00:00

virt_addr_valid macro checks that a virtual address is valid, ie that
the address belongs to the linear mapping and that the corresponding
 physical page exists.

Add the missing check that ensures the virtual address belongs to the
linear mapping, otherwise __virt_to_phys, when compiled with
CONFIG_DEBUG_VIRTUAL enabled, raises a WARN that is interpreted as a
kernel bug by syzbot.

Signed-off-by: Alexandre Ghiti 
Reviewed-by: Atish Patra 
Signed-off-by: Palmer Dabbelt

riscv: Fixup pfn_valid error with wrong max_mapnr

2021-01-23T04:18:03+00:00

The max_mapnr is the number of PFNs, not absolute PFN offset.

Signed-off-by: Guo Ren 
Fixes: d0d8aae64566 ("RISC-V: Set maximum number of mapped pages correctly")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt

RISC-V: Fix maximum allowed phsyical memory for RV32

2021-01-16T05:35:48+00:00

Linux kernel can only map 1GB of address space for RV32 as the page offset
is set to 0xC0000000. The current description in the Kconfig is confusing
as it indicates that RV32 can support 2GB of physical memory. That is
simply not true for current kernel. In future, a 2GB split support can be
added to allow 2GB physical address space.

Reviewed-by: Anup Patel 
Signed-off-by: Atish Patra 
Signed-off-by: Palmer Dabbelt

RISC-V: Set current memblock limit

2021-01-16T05:35:47+00:00

Currently, linux kernel can not use last 4k bytes of addressable space
because IS_ERR_VALUE macro treats those as an error. This will be an issue
for RV32 as any memblock allocator potentially allocate chunk of memory
from the end of DRAM (2GB) leading bad address error even though the
address was technically valid.

Fix this issue by limiting the memblock if available memory spans the
entire address space.

Reviewed-by: Anup Patel 
Signed-off-by: Atish Patra 
Signed-off-by: Palmer Dabbelt

RISC-V: Do not allocate memblock while iterating reserved memblocks

2021-01-16T05:35:46+00:00

Currently, resource tree allocates memory blocks while iterating on the
list. It leads to following kernel warning because memblock allocation
also invokes memory block reservation API.

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at kernel/resource.c:795
__insert_resource+0x8e/0xd0
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
5.10.0-00022-ge20097fb37e2-dirty #549
[    0.000000] epc: c00125c2 ra : c001262c sp : c1c01f50
[    0.000000]  gp : c1d456e0 tp : c1c0a980 t0 : ffffcf20
[    0.000000]  t1 : 00000000 t2 : 00000000 s0 : c1c01f60
[    0.000000]  s1 : ffffcf00 a0 : ffffff00 a1 : c1c0c0c4
[    0.000000]  a2 : 80c12b15 a3 : 80402000 a4 : 80402000
[    0.000000]  a5 : c1c0c0c4 a6 : 80c12b15 a7 : f5faf600
[    0.000000]  s2 : c1c0c0c4 s3 : c1c0e000 s4 : c1009a80
[    0.000000]  s5 : c1c0c000 s6 : c1d48000 s7 : c1613b4c
[    0.000000]  s8 : 00000fff s9 : 80000200 s10: c1613b40
[    0.000000]  s11: 00000000 t3 : c1d4a000 t4 : ffffffff

This is also unnecessary as we can pre-compute the total memblocks required
for each memory region and allocate it before the loop. It save precious
boot time not going through memblock allocation code every time.

Fixes: 00ab027a3b82 ("RISC-V: Add kernel image sections to the resource tree")

Reviewed-by: Anup Patel 
Tested-by: Geert Uytterhoeven 
Signed-off-by: Atish Patra 
Signed-off-by: Palmer Dabbelt

riscv: stacktrace: Move register keyword to beginning of declaration

2021-01-15T02:31:47+00:00

Using global sp_in_global directly to fix the following warning,

arch/riscv/kernel/stacktrace.c:31:3: warning: ‘register’ is not at beginning of declaration [-Wold-style-declaration]
31 |   const register unsigned long current_sp = sp_in_global;
   |   ^~~~~

Signed-off-by: Kefeng Wang 
Signed-off-by: Palmer Dabbelt