Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board

2021-04-17 Thread Atish Patra
On Sat, Apr 17, 2021 at 8:36 PM Atish Patra  wrote:
>
> On Mon, Mar 29, 2021 at 10:04 AM Vitaly Wool  wrote:
> >
> > On Sat, Mar 27, 2021 at 6:24 PM Alex Ghiti  wrote:
> > >
> > > Hi Atish,
> > >
> > > Le 3/3/21 à 3:02 PM, Atish Patra a écrit :
> > > > Add initial DTS for Microchip ICICLE board having only
> > > > essential devices (clocks, sdhci, ethernet, serial, etc).
> > > > The device tree is based on the U-Boot patch.
> > > >
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/
> > > >
> > > > Signed-off-by: Atish Patra 
> > > > ---
> > > >   arch/riscv/boot/dts/Makefile  |   1 +
> > > >   arch/riscv/boot/dts/microchip/Makefile|   2 +
> > > >   .../microchip/microchip-mpfs-icicle-kit.dts   |  72 
> > > >   .../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++
> > > >   4 files changed, 404 insertions(+)
> > > >   create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> > > >   create mode 100644 
> > > > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > >   create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > > >
> > > > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> > > > index 7ffd502e3e7b..fe996b88319e 100644
> > > > --- a/arch/riscv/boot/dts/Makefile
> > > > +++ b/arch/riscv/boot/dts/Makefile
> > > > @@ -1,5 +1,6 @@
> > > >   # SPDX-License-Identifier: GPL-2.0
> > > >   subdir-y += sifive
> > > >   subdir-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += canaan
> > > > +subdir-y += microchip
> > > >
> > > >   obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
> > > > diff --git a/arch/riscv/boot/dts/microchip/Makefile 
> > > > b/arch/riscv/boot/dts/microchip/Makefile
> > > > new file mode 100644
> > > > index ..622b12771fd3
> > > > --- /dev/null
> > > > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > > > @@ -0,0 +1,2 @@
> > > > +# SPDX-License-Identifier: GPL-2.0
> > > > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> > >
> > > I'm playing (or trying to...) with XIP_KERNEL and I had to add the
> > > following to have the device tree actually builtin the kernel:
> > >
> > > diff --git a/arch/riscv/boot/dts/microchip/Makefile
> > > b/arch/riscv/boot/dts/microchip/Makefile
> > > index 622b12771fd3..855c1502d912 100644
> > > --- a/arch/riscv/boot/dts/microchip/Makefile
> > > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > > @@ -1,2 +1,3 @@
> > >   # SPDX-License-Identifier: GPL-2.0
> > >   dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> > > +obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y))
> > >
> > > Alex
> >
> > Yes, I believe this is necessary for BUILTIN_DTB to work on Polarfire,
> > regardless of whether the kernel is XIP or not.
> >
>
> But there is no usecase for BUILTIN_DTB for polarfire except XIP kernel.
> The bootloaders for polarfire is capable of providing a DTB to kernel.
>
> If XIP kernel is enabled, the following line in
> arch/riscv/boot/dts/Makefile should take care of things
>
(Sorry. The mail was sent by mistake earlier with incomplete response)
Otherwise, we need a similar change for unleashed as well. No ?

>
> > Best regards,
> >Vitaly
> >
> > > > diff --git 
> > > > a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts 
> > > > b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > > new file mode 100644
> > > > index ..ec79944065c9
> > > > --- /dev/null
> > > > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > > @@ -0,0 +1,72 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > > +/* Copyright (c) 2020 Microchip Technology Inc */
> > > > +
> > > > +/dts-v1/;
> > > > +
> > > > +#include "microchip-mpfs.dtsi"
> > > > +
> > > > +/* Clock frequency (in Hz) of the rtcclk */
> > > > +#define RTCCLK_FREQ  100
> > > > +
> > > > +/ {
> > > > + #address-cells = <2>;
> > > > + #siz

Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board

2021-04-17 Thread Atish Patra
On Mon, Mar 29, 2021 at 10:04 AM Vitaly Wool  wrote:
>
> On Sat, Mar 27, 2021 at 6:24 PM Alex Ghiti  wrote:
> >
> > Hi Atish,
> >
> > Le 3/3/21 à 3:02 PM, Atish Patra a écrit :
> > > Add initial DTS for Microchip ICICLE board having only
> > > essential devices (clocks, sdhci, ethernet, serial, etc).
> > > The device tree is based on the U-Boot patch.
> > >
> > > https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/
> > >
> > > Signed-off-by: Atish Patra 
> > > ---
> > >   arch/riscv/boot/dts/Makefile  |   1 +
> > >   arch/riscv/boot/dts/microchip/Makefile|   2 +
> > >   .../microchip/microchip-mpfs-icicle-kit.dts   |  72 
> > >   .../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++
> > >   4 files changed, 404 insertions(+)
> > >   create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> > >   create mode 100644 
> > > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > >   create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > >
> > > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> > > index 7ffd502e3e7b..fe996b88319e 100644
> > > --- a/arch/riscv/boot/dts/Makefile
> > > +++ b/arch/riscv/boot/dts/Makefile
> > > @@ -1,5 +1,6 @@
> > >   # SPDX-License-Identifier: GPL-2.0
> > >   subdir-y += sifive
> > >   subdir-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += canaan
> > > +subdir-y += microchip
> > >
> > >   obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
> > > diff --git a/arch/riscv/boot/dts/microchip/Makefile 
> > > b/arch/riscv/boot/dts/microchip/Makefile
> > > new file mode 100644
> > > index ..622b12771fd3
> > > --- /dev/null
> > > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > > @@ -0,0 +1,2 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> >
> > I'm playing (or trying to...) with XIP_KERNEL and I had to add the
> > following to have the device tree actually builtin the kernel:
> >
> > diff --git a/arch/riscv/boot/dts/microchip/Makefile
> > b/arch/riscv/boot/dts/microchip/Makefile
> > index 622b12771fd3..855c1502d912 100644
> > --- a/arch/riscv/boot/dts/microchip/Makefile
> > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > @@ -1,2 +1,3 @@
> >   # SPDX-License-Identifier: GPL-2.0
> >   dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> > +obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y))
> >
> > Alex
>
> Yes, I believe this is necessary for BUILTIN_DTB to work on Polarfire,
> regardless of whether the kernel is XIP or not.
>

But there is no usecase for BUILTIN_DTB for polarfire except XIP kernel.
The bootloaders for polarfire is capable of providing a DTB to kernel.

If XIP kernel is enabled, the following line in
arch/riscv/boot/dts/Makefile should take care of things


> Best regards,
>Vitaly
>
> > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts 
> > > b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > new file mode 100644
> > > index ..ec79944065c9
> > > --- /dev/null
> > > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > @@ -0,0 +1,72 @@
> > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > +/* Copyright (c) 2020 Microchip Technology Inc */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "microchip-mpfs.dtsi"
> > > +
> > > +/* Clock frequency (in Hz) of the rtcclk */
> > > +#define RTCCLK_FREQ  100
> > > +
> > > +/ {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + model = "Microchip PolarFire-SoC Icicle Kit";
> > > + compatible = "microchip,mpfs-icicle-kit";
> > > +
> > > + chosen {
> > > + stdout-path = 
> > > + };
> > > +
> > > + cpus {
> > > + timebase-frequency = ;
> > > + };
> > > +
> > > + memory@8000 {
> > > + device_type = "memory";
> > > + reg = <0x0 0x8000 0x0 0x4000>;
> > > + clocks = < 26>;
> > > + };
> > > +
> > &g

Re: [PATCH v4 0/5] Add Microchip PolarFire Soc Support

2021-04-17 Thread Atish Patra
On Mon, Mar 29, 2021 at 9:17 PM Palmer Dabbelt  wrote:
>
> On Wed, 03 Mar 2021 12:02:48 PST (-0800), Atish Patra wrote:
> > This series adds minimal support for Microchip Polar Fire Soc Icicle kit.
> > It is rebased on v5.12-rc1 and depends on clock support.
> > Only MMC and ethernet drivers are enabled via this series.
> > The idea here is to add the foundational patches so that other drivers
> > can be added to on top of this. The device tree may change based on
> > feedback on bindings of individual driver support patches.
> >
> > This series has been tested on Qemu and Polar Fire Soc Icicle kit.
> > It depends on the updated clock-series[2] and macb fix[3].
> > The series is also tested by Lewis from Microchip.
> >
> > The series can also be found at.
> > https://github.com/atishp04/linux/tree/polarfire_support_upstream_v4
> >
> > [1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html
> > [2] https://www.spinics.net/lists/linux-clk/msg54579.html
> >
> > Changes from v3->v4:
> > 1. Fixed few DT specific issues.
> > 2. Rebased on top of new clock driver.
> > 3. SD card functionality is verified.
> >
> > Changes from v2->v3:
> > 1. Fixed a typo in dt binding.
> > 2. Included MAINTAINERS entry for PolarFire SoC.
> > 3. Improved the dts file by using lowercase clock names and keeping phy
> >details in board specific dts file.
> >
> > Changes from v1->v2:
> > 1. Modified the DT to match the device tree in U-Boot.
> > 2. Added both eMMC & SDcard entries in DT. However, SD card is only enabled
> >as it allows larger storage option for linux distros.
> >
> > Atish Patra (4):
> > RISC-V: Add Microchip PolarFire SoC kconfig option
> > dt-bindings: riscv: microchip: Add YAML documentation for the
> > PolarFire SoC
> > RISC-V: Initial DTS for Microchip ICICLE board
> > RISC-V: Enable Microchip PolarFire ICICLE SoC
> >
> > Conor Dooley (1):
> > MAINTAINERS: add microchip polarfire soc support
> >
> > .../devicetree/bindings/riscv/microchip.yaml  |  27 ++
> > MAINTAINERS   |   8 +
> > arch/riscv/Kconfig.socs   |   7 +
> > arch/riscv/boot/dts/Makefile  |   1 +
> > arch/riscv/boot/dts/microchip/Makefile|   2 +
> > .../microchip/microchip-mpfs-icicle-kit.dts   |  72 
> > .../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++
> > arch/riscv/configs/defconfig  |   4 +
> > 8 files changed, 450 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml
> > create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> > create mode 100644 
> > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
>
> I had this left in my inbox waiting for either some reviews to come in or a 
> v2,
> but I don't see any.  Did I miss something?
>
Sorry for the late reply. I am on vacation until May. I think I saw
all the patches have already been reviewed.
Let me know if it is not the case.

> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


[RFC 2/6] RISC-V: Add CSR encodings for all HPMCOUNTERS

2021-03-19 Thread Atish Patra
Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/csr.h | 58 
 1 file changed, 58 insertions(+)

diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index caadfc1d7487..7ce8df8f1683 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -89,9 +89,67 @@
 #define CSR_CYCLE  0xc00
 #define CSR_TIME   0xc01
 #define CSR_INSTRET0xc02
+#define CSR_HPMCOUNTER30xc03
+#define CSR_HPMCOUNTER40xc04
+#define CSR_HPMCOUNTER50xc05
+#define CSR_HPMCOUNTER60xc06
+#define CSR_HPMCOUNTER70xc07
+#define CSR_HPMCOUNTER80xc08
+#define CSR_HPMCOUNTER90xc09
+#define CSR_HPMCOUNTER10   0xc0a
+#define CSR_HPMCOUNTER11   0xc0b
+#define CSR_HPMCOUNTER12   0xc0c
+#define CSR_HPMCOUNTER13   0xc0d
+#define CSR_HPMCOUNTER14   0xc0e
+#define CSR_HPMCOUNTER15   0xc0f
+#define CSR_HPMCOUNTER16   0xc10
+#define CSR_HPMCOUNTER17   0xc11
+#define CSR_HPMCOUNTER18   0xc12
+#define CSR_HPMCOUNTER19   0xc13
+#define CSR_HPMCOUNTER20   0xc14
+#define CSR_HPMCOUNTER21   0xc15
+#define CSR_HPMCOUNTER22   0xc16
+#define CSR_HPMCOUNTER23   0xc17
+#define CSR_HPMCOUNTER24   0xc18
+#define CSR_HPMCOUNTER25   0xc19
+#define CSR_HPMCOUNTER26   0xc1a
+#define CSR_HPMCOUNTER27   0xc1b
+#define CSR_HPMCOUNTER28   0xc1c
+#define CSR_HPMCOUNTER29   0xc1d
+#define CSR_HPMCOUNTER30   0xc1e
+#define CSR_HPMCOUNTER31   0xc1f
 #define CSR_CYCLEH 0xc80
 #define CSR_TIMEH  0xc81
 #define CSR_INSTRETH   0xc82
+#define CSR_HPMCOUNTER3H   0xc83
+#define CSR_HPMCOUNTER4H   0xc84
+#define CSR_HPMCOUNTER5H   0xc85
+#define CSR_HPMCOUNTER6H   0xc86
+#define CSR_HPMCOUNTER7H   0xc87
+#define CSR_HPMCOUNTER8H   0xc88
+#define CSR_HPMCOUNTER9H   0xc89
+#define CSR_HPMCOUNTER10H  0xc8a
+#define CSR_HPMCOUNTER11H  0xc8b
+#define CSR_HPMCOUNTER12H  0xc8c
+#define CSR_HPMCOUNTER13H  0xc8d
+#define CSR_HPMCOUNTER14H  0xc8e
+#define CSR_HPMCOUNTER15H  0xc8f
+#define CSR_HPMCOUNTER16H  0xc90
+#define CSR_HPMCOUNTER17H  0xc91
+#define CSR_HPMCOUNTER18H  0xc92
+#define CSR_HPMCOUNTER19H  0xc93
+#define CSR_HPMCOUNTER20H  0xc94
+#define CSR_HPMCOUNTER21H  0xc95
+#define CSR_HPMCOUNTER22H  0xc96
+#define CSR_HPMCOUNTER23H  0xc97
+#define CSR_HPMCOUNTER24H  0xc98
+#define CSR_HPMCOUNTER25H  0xc99
+#define CSR_HPMCOUNTER26H  0xc9a
+#define CSR_HPMCOUNTER27H  0xc9b
+#define CSR_HPMCOUNTER28H  0xc9c
+#define CSR_HPMCOUNTER29H  0xc9d
+#define CSR_HPMCOUNTER30H  0xc9e
+#define CSR_HPMCOUNTER31H  0xc9f
 
 #define CSR_SSTATUS0x100
 #define CSR_SIE0x104
-- 
2.25.1



[RFC 3/6] RISC-V: Add a perf core platform driver

2021-03-19 Thread Atish Patra
Implement a perf platform driver that can support all the essential perf
features in future. It can also accommodate any type of PMU implementation
in future. Currently, both SBI based perf driver and legacy driver
implemented using the core driver. Most of the common perf functionalities
are kept in this core driver wile PMU specific driver can implement PMU
specific features. For example, the SBI specific functionality will be
implemented in the SBI specific driver.

Signed-off-by: Atish Patra 
---
 drivers/perf/Kconfig   |   8 +
 drivers/perf/Makefile  |   1 +
 drivers/perf/riscv_pmu.c   | 385 +
 include/linux/cpuhotplug.h |   1 +
 include/linux/perf/riscv_pmu.h |  59 +
 5 files changed, 454 insertions(+)
 create mode 100644 drivers/perf/riscv_pmu.c
 create mode 100644 include/linux/perf/riscv_pmu.h

diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 77522e5efe11..fc42ab613ea0 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -56,6 +56,14 @@ config ARM_PMU
  Say y if you want to use CPU performance monitors on ARM-based
  systems.
 
+config RISCV_PMU
+   depends on RISCV
+   bool "RISC-V PMU framework"
+   default y
+   help
+ Say y if you want to use CPU performance monitors on RISCV-based
+ systems.
+
 config ARM_PMU_ACPI
depends on ARM_PMU && ACPI
def_bool y
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 5260b116c7da..76e5c50e24bb 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_FSL_IMX8_DDR_PMU) += fsl_imx8_ddr_perf.o
 obj-$(CONFIG_HISI_PMU) += hisilicon/
 obj-$(CONFIG_QCOM_L2_PMU)  += qcom_l2_pmu.o
 obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
+obj-$(CONFIG_RISCV_PMU) += riscv_pmu.o
 obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
 obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
diff --git a/drivers/perf/riscv_pmu.c b/drivers/perf/riscv_pmu.c
new file mode 100644
index ..ce9d35069ac0
--- /dev/null
+++ b/drivers/perf/riscv_pmu.c
@@ -0,0 +1,385 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RISC-V performance counter support.
+ *
+ * Copyright (C) 2021 Western Digital Corporation or its affiliates.
+ *
+ * This implementation is based on old RISC-V perf and ARM perf event code
+ * which are in turn based on sparc64 and x86 code.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static unsigned long csr_read_num(int csr_num)
+{
+#define switchcase_csr_read(__csr_num, __val)  {\
+   case __csr_num: \
+   __val = csr_read(__csr_num);\
+   break; }
+#define switchcase_csr_read_2(__csr_num, __val){\
+   switchcase_csr_read(__csr_num + 0, __val)\
+   switchcase_csr_read(__csr_num + 1, __val)}
+#define switchcase_csr_read_4(__csr_num, __val){\
+   switchcase_csr_read_2(__csr_num + 0, __val)  \
+   switchcase_csr_read_2(__csr_num + 2, __val)}
+#define switchcase_csr_read_8(__csr_num, __val){\
+   switchcase_csr_read_4(__csr_num + 0, __val)  \
+   switchcase_csr_read_4(__csr_num + 4, __val)}
+#define switchcase_csr_read_16(__csr_num, __val)   {\
+   switchcase_csr_read_8(__csr_num + 0, __val)  \
+   switchcase_csr_read_8(__csr_num + 8, __val)}
+#define switchcase_csr_read_32(__csr_num, __val)   {\
+   switchcase_csr_read_16(__csr_num + 0, __val) \
+   switchcase_csr_read_16(__csr_num + 16, __val)}
+
+   unsigned long ret = 0;
+
+   switch (csr_num) {
+   switchcase_csr_read_32(CSR_CYCLE, ret)
+   switchcase_csr_read_32(CSR_CYCLEH, ret)
+   default :
+   break;
+   }
+
+   return ret;
+#undef switchcase_csr_read_32
+#undef switchcase_csr_read_16
+#undef switchcase_csr_read_8
+#undef switchcase_csr_read_4
+#undef switchcase_csr_read_2
+#undef switchcase_csr_read
+}
+
+/*
+ * Read the CSR of a corresponding counter.
+ */
+unsigned long riscv_pmu_read_ctr_csr(unsigned long csr)
+{
+   if (csr < CSR_CYCLE || csr > CSR_HPMCOUNTER31H ||
+  (csr > CSR_HPMCOUNTER31 && csr < CSR_CYCLEH)) {
+   pr_err("Invalid performance counter csr %lx\n", csr);
+   return -EINVAL;
+   }
+
+   return csr_read_num(csr);
+}
+
+static unsigned long riscv_pmu_get_ctr_mask(struct perf_event *event)
+{
+   int cwidth;
+   struct riscv_pmu *rvpmu = to_riscv_pmu(event->pmu);
+   struct hw_perf_event *hwc = >hw;
+
+   if (!rvpmu->get_ctr_width)
+   /**
+* If the pmu driver doesn't support counter width, set it to default 
maximum
+* allowed by the specification.
+*/
+   cwidth = 63;
+   else {
+   if (hwc->idx == -1)
+   

[RFC 4/6] RISC-V: Add a simple platform driver for RISC-V legacy perf

2021-03-19 Thread Atish Patra
The old RISC-V perf implementation allowed counting of only
cycle/instruction counters using perf. Restore that feature by implementing
a simple platform driver under a separate config to provide backward
compatibility. Any existing software stack will continue to work as it is.
However, it provides an easy way out in future where we can remove the
legacy driver.

Signed-off-by: Atish Patra 
---
 drivers/perf/Kconfig|  9 
 drivers/perf/Makefile   |  3 ++
 drivers/perf/riscv_pmu.c|  2 +
 drivers/perf/riscv_pmu_legacy.c | 88 +
 include/linux/perf/riscv_pmu.h  |  1 +
 5 files changed, 103 insertions(+)
 create mode 100644 drivers/perf/riscv_pmu_legacy.c

diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index fc42ab613ea0..1546a487d970 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -64,6 +64,15 @@ config RISCV_PMU
  Say y if you want to use CPU performance monitors on RISCV-based
  systems.
 
+config RISCV_PMU_LEGACY
+   depends on RISCV_PMU
+   bool "RISC-V legacy PMU implementation"
+   default y
+   help
+ Say y if you want to use the legacy CPU performance monitor
+ implementation on RISC-V based systems. This only allows counting
+ of cycle/instruction counter and will be removed in future.
+
 config ARM_PMU_ACPI
depends on ARM_PMU && ACPI
def_bool y
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 76e5c50e24bb..e8aa666a9d28 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -11,6 +11,9 @@ obj-$(CONFIG_HISI_PMU) += hisilicon/
 obj-$(CONFIG_QCOM_L2_PMU)  += qcom_l2_pmu.o
 obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
 obj-$(CONFIG_RISCV_PMU) += riscv_pmu.o
+ifeq ($(CONFIG_RISCV_PMU), y)
+obj-$(CONFIG_RISCV_PMU_LEGACY) += riscv_pmu_legacy.o
+endif
 obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
 obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
diff --git a/drivers/perf/riscv_pmu.c b/drivers/perf/riscv_pmu.c
index ce9d35069ac0..838dca2ffca8 100644
--- a/drivers/perf/riscv_pmu.c
+++ b/drivers/perf/riscv_pmu.c
@@ -350,6 +350,8 @@ static int riscv_pmu_device_probe(struct platform_device 
*pdev)
if (!pmu)
return -ENOMEM;
 
+   riscv_pmu_legacy_init(pmu);
+
cpuhp_setup_state(CPUHP_AP_PERF_RISCV_STARTING,
  "perf/riscv/pmu:starting",
  riscv_perf_starting_cpu, riscv_perf_dying_cpu);
diff --git a/drivers/perf/riscv_pmu_legacy.c b/drivers/perf/riscv_pmu_legacy.c
new file mode 100644
index ..d75353824f4a
--- /dev/null
+++ b/drivers/perf/riscv_pmu_legacy.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RISC-V performance counter support.
+ *
+ * Copyright (C) 2021 Western Digital Corporation or its affiliates.
+ *
+ * This implementation is based on old RISC-V perf and ARM perf event code
+ * which are in turn based on sparc64 and x86 code.
+ */
+
+#include 
+
+#define RISCV_PMU_LEGACY_CYCLE 0
+#define RISCV_PMU_LEGACY_INSTRET   1
+#define RISCV_PMU_LEGACY_NUM_CTR   2
+
+static int pmu_legacy_get_ctr_idx(struct perf_event *event)
+{
+   struct perf_event_attr *attr = >attr;
+
+   if (event->attr.type != PERF_TYPE_HARDWARE)
+   return -EOPNOTSUPP;
+   if (attr->config == PERF_COUNT_HW_CPU_CYCLES)
+   return RISCV_PMU_LEGACY_CYCLE;
+   else if (attr->config == PERF_COUNT_HW_INSTRUCTIONS)
+   return RISCV_PMU_LEGACY_INSTRET;
+   else
+   return -EOPNOTSUPP;
+}
+
+/* For legacy config & counter index are same */
+static int pmu_legacy_map_event(struct perf_event *event, u64 *config)
+{
+   return pmu_legacy_get_ctr_idx(event);
+}
+
+static u64 pmu_legacy_read_ctr(struct perf_event *event)
+{
+   struct hw_perf_event *hwc = >hw;
+   int idx = hwc->idx;
+   u64 val;
+
+   if (idx == RISCV_PMU_LEGACY_CYCLE) {
+   val = riscv_pmu_read_ctr_csr(CSR_CYCLE);
+   if (IS_ENABLED(CONFIG_32BIT))
+   val = (u64)riscv_pmu_read_ctr_csr(CSR_CYCLEH) << 32 | 
val;
+   } else if (idx == RISCV_PMU_LEGACY_INSTRET) {
+   val = riscv_pmu_read_ctr_csr(CSR_INSTRET);
+   if (IS_ENABLED(CONFIG_32BIT))
+   val = ((u64)riscv_pmu_read_ctr_csr(CSR_INSTRETH)) << 32 
| val;
+   } else
+   return 0;
+
+   return val;
+}
+
+static void pmu_legacy_start_ctr(struct perf_event *event, u64 ival)
+{
+   struct hw_perf_event *hwc = >hw;
+   u64 initial_val = pmu_legacy_read_ctr(event);
+
+   /**
+* The legacy method doesn't really have a start/stop method.
+* It also can not update the counter with a initial value.
+* But we still need to set the prev_count so that read() can compute
+* th

[RFC 5/6] RISC-V: Add RISC-V SBI PMU extension definitions

2021-03-19 Thread Atish Patra
This patch adds all the definitions defined by the SBI PMU extension.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/sbi.h | 80 
 1 file changed, 80 insertions(+)

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 99895d9c3bdd..01b261bc6b68 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -27,6 +27,7 @@ enum sbi_ext_id {
SBI_EXT_IPI = 0x735049,
SBI_EXT_RFENCE = 0x52464E43,
SBI_EXT_HSM = 0x48534D,
+   SBI_EXT_PMU = 0x504D55,
 };
 
 enum sbi_ext_base_fid {
@@ -70,6 +71,85 @@ enum sbi_hsm_hart_status {
SBI_HSM_HART_STATUS_STOP_PENDING,
 };
 
+
+enum sbi_ext_pmu_fid {
+   SBI_EXT_PMU_NUM_COUNTERS = 0,
+   SBI_EXT_PMU_COUNTER_GET_INFO,
+   SBI_EXT_PMU_COUNTER_CFG_MATCH,
+   SBI_EXT_PMU_COUNTER_FW_READ,
+   SBI_EXT_PMU_COUNTER_START,
+   SBI_EXT_PMU_COUNTER_STOP,
+};
+
+#define RISCV_PMU_RAW_EVENT_MASK 0x7FFF
+#define RISCV_PMU_RAW_EVENT_IDX 0x2
+
+/* SBI PMU Hardware general events */
+enum sbi_pmu_hw_generic_events_t {
+   SBI_PMU_HW_NO_EVENT = 0,
+   SBI_PMU_HW_CPU_CYCLES,
+   SBI_PMU_HW_INSTRUCTIONS,
+   SBI_PMU_HW_CACHE_REFERENCES,
+   SBI_PMU_HW_CACHE_MISSES,
+   SBI_PMU_HW_BRANCH_INSTRUCTIONS,
+   SBI_PMU_HW_BRANCH_MISSES,
+   SBI_PMU_HW_BUS_CYCLES,
+   SBI_PMU_HW_STALLED_CYCLES_FRONTEND,
+   SBI_PMU_HW_STALLED_CYCLES_BACKEND,
+   SBI_PMU_HW_REF_CPU_CYCLES,
+   SBI_PMU_HW_MISALIGNED_LOAD,
+   SBI_PMU_HW_MISALIGNED_STORE,
+
+   SBI_PMU_HW_GENERIC_MAX,
+};
+
+/**
+ * Special "firmware" events provided by the firmware, even if the hardware
+ * does not support performance events. These events are encoded as a raw
+ * event type in Linux kernel perf framework.
+ */
+enum sbi_pmu_fw_generic_events_t {
+   SBI_PMU_FW_MISALIGNED_LOAD  = 0,
+   SBI_PMU_FW_MISALIGNED_STORE = 1,
+   SBI_PMU_FW_ACCESS_LOAD  = 2,
+   SBI_PMU_FW_ACCESS_STORE = 3,
+   SBI_PMU_FW_ILLEGAL_INSN = 4,
+   SBI_PMU_FW_SET_TIMER= 5,
+   SBI_PMU_FW_IPI_SENT = 6,
+   SBI_PMU_FW_IPI_RECVD= 7,
+   SBI_PMU_FW_FENCE_I_SENT = 8,
+   SBI_PMU_FW_FENCE_I_RECVD= 9,
+   SBI_PMU_FW_SFENCE_VMA_SENT  = 10,
+   SBI_PMU_FW_SFENCE_VMA_RCVD  = 11,
+   SBI_PMU_FW_SFENCE_VMA_ASID_SENT = 12,
+   SBI_PMU_FW_SFENCE_VMA_ASID_RCVD = 13,
+
+   SBI_PMU_FW_HFENCE_GVMA_SENT = 14,
+   SBI_PMU_FW_HFENCE_GVMA_RCVD = 15,
+   SBI_PMU_FW_HFENCE_GVMA_VMID_SENT = 16,
+   SBI_PMU_FW_HFENCE_GVMA_VMID_RCVD = 17,
+
+   SBI_PMU_FW_HFENCE_VVMA_SENT = 18,
+   SBI_PMU_FW_HFENCE_VVMA_RCVD = 19,
+   SBI_PMU_FW_HFENCE_VVMA_ASID_SENT = 20,
+   SBI_PMU_FW_HFENCE_VVMA_ASID_RCVD = 21,
+   SBI_PMU_FW_MAX,
+};
+
+/* SBI PMU event types */
+enum sbi_pmu_event_type {
+   SBI_PMU_EVENT_TYPE_HW = 0x0,
+   SBI_PMU_EVENT_TYPE_CACHE = 0x1,
+   SBI_PMU_EVENT_TYPE_RAW = 0x2,
+   SBI_PMU_EVENT_TYPE_FW = 0xf,
+};
+
+/* SBI PMU event types */
+enum sbi_pmu_ctr_type {
+   SBI_PMU_CTR_TYPE_HW = 0x0,
+   SBI_PMU_CTR_TYPE_FW,
+};
+
 #define SBI_SPEC_VERSION_DEFAULT   0x1
 #define SBI_SPEC_VERSION_MAJOR_SHIFT   24
 #define SBI_SPEC_VERSION_MAJOR_MASK0x7f
-- 
2.25.1



[RFC 0/6] Improve RISC-V Perf support using SBI PMU extension

2021-03-19 Thread Atish Patra
This series adds improved perf support for RISC-V based system using
SBI PMU extension[1]. It is based on a platform driver instead of a existing
arch specific implementation. The core platform driver is implemented in
such a way that most of the generic event handling is done in the core driver
while individual PMUs need to only implement necessary features specific to
the PMU. This is easily extensible and any future RISC-V PMU implementation
can leverage this. Currently, SBI PMU driver & legacy PMU driver are implemented
as a part of this series.

The SBI based driver provides more advanced features such as event configure
start/stop. This version does not implement counter overflow
& filtering yet. That will implemented in the future on top of this series
using "Sscof" extension. The RISC-V perf documentation will also be updated
at that time with all the bits.

The legacy driver tries to reimplement the existing minimal perf under a new
config to maintain backward compatibility. This implementation only allows
monitoring of always running cycle/instruction counters. Moreover, they can
not be started or stopped. In general, this is very limited and not very useful.
That's why, I am not very keen to carry the support into the new driver.
However, I don't want to break perf for any existing hardware platforms.
If nobody really uses perf currently, I will be happy to drop PATCH 4.

This series has been tested in Qemu on RV64 only. Qemu[2] & OpenSBI [3] patches
are required to test it. Qemu changes are not backward compatible. That means,
you can not use perf anymore on older Qemu versions with latest OpenSBI
and/or Kernel. However, newer kernel will just use legacy pmu driver if
old OpenSBI is detected or hardware doesn't implement mcountinhibit.

Here is an output of perf stat while running hackbench.

[root@fedora-riscv riscv]# perf stat -e r8007 -e r8006 \
-e r0002 -e r0004 -e branch-misses -e cache-misses \
-e cycles -e instructions ./hackbench -pipe 15 process 15

Running with 15*40 (== 600) tasks.
Time: 1.548

 Performance counter stats for './hackbench -pipe 15 process 15':

 7,103  r8007 (62.56%) --> SBI_PMU_FW_IPI_RECVD
 7,767  r8006 (12.19%) --> SBI_PMU_FW_IPI_SENT
 0  r0002 (24.79%) --> a custom raw event 
described in DT
   r0004 (0.00%)  --> non-supported raw 
event described in DT
 0  branch-misses (12.65%) 
 0  cache-misses  (25.36%)
27,978,868,702  cycles(38.12%)
27,849,527,556  instructions  # 1.00  insn per cycle  (50.46%)

   2.431195184 seconds time elapsed

   1.553153000 seconds user
  13.615924000 seconds sys

The patches can also be found in the github[4].

[1] https://lists.riscv.org/g/tech-unixplatformspec/message/598
[2] https://github.com/atishp04/qemu/tree/riscv_pmu_v1
[3] https://github.com/atishp04/opensbi/tree/riscv_pmu_v1
[4] https://github.com/atishp04/linux/tree/riscv_pmu_v1

Atish Patra (6):
RISC-V: Remove the current perf implementation
RISC-V: Add CSR encodings for all HPMCOUNTERS
RISC-V: Add a perf core platform driver
RISC-V: Add a simple platform driver for RISC-V legacy perf
RISC-V: Add RISC-V SBI PMU extension definitions
RISC-V: Add perf platform driver based on SBI PMU extension

arch/riscv/Kconfig  |  13 -
arch/riscv/include/asm/csr.h|  58 
arch/riscv/include/asm/perf_event.h |  72 -
arch/riscv/include/asm/sbi.h|  80 +
arch/riscv/kernel/Makefile  |   1 -
arch/riscv/kernel/perf_event.c  | 485 
drivers/perf/Kconfig|  25 ++
drivers/perf/Makefile   |   5 +
drivers/perf/riscv_pmu.c| 397 +++
drivers/perf/riscv_pmu_legacy.c |  88 +
drivers/perf/riscv_pmu_sbi.c| 464 ++
include/linux/cpuhotplug.h  |   1 +
include/linux/perf/riscv_pmu.h  |  61 
13 files changed, 1179 insertions(+), 571 deletions(-)
delete mode 100644 arch/riscv/kernel/perf_event.c
create mode 100644 drivers/perf/riscv_pmu.c
create mode 100644 drivers/perf/riscv_pmu_legacy.c
create mode 100644 drivers/perf/riscv_pmu_sbi.c
create mode 100644 include/linux/perf/riscv_pmu.h

--
2.25.1



[RFC 1/6] RISC-V: Remove the current perf implementation

2021-03-19 Thread Atish Patra
The current perf implementation in RISC-V is not very useful as it can not
count any events other than cycle/instructions. Moreover, perf record
can not be used or the events can not be started or stopped.

Remove the implementation now for a better platform driver in future
that will implement most of the missing functionality.

Signed-off-by: Atish Patra 
---
 arch/riscv/Kconfig  |  13 -
 arch/riscv/include/asm/perf_event.h |  72 -
 arch/riscv/kernel/Makefile  |   1 -
 arch/riscv/kernel/perf_event.c  | 485 
 4 files changed, 571 deletions(-)
 delete mode 100644 arch/riscv/kernel/perf_event.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 85d626b8ce5e..fdbdba852137 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -351,19 +351,6 @@ config RISCV_ISA_C
 
   If you don't know what to do here, say Y.
 
-menu "supported PMU type"
-   depends on PERF_EVENTS
-
-config RISCV_BASE_PMU
-   bool "Base Performance Monitoring Unit"
-   def_bool y
-   help
- A base PMU that serves as a reference implementation and has limited
- feature of perf.  It can run on any RISC-V machines so serves as the
- fallback, but this option can also be disable to reduce kernel size.
-
-endmenu
-
 config FPU
bool "FPU support"
default y
diff --git a/arch/riscv/include/asm/perf_event.h 
b/arch/riscv/include/asm/perf_event.h
index 062efd3a1d5d..dc6d5803c0e2 100644
--- a/arch/riscv/include/asm/perf_event.h
+++ b/arch/riscv/include/asm/perf_event.h
@@ -9,77 +9,5 @@
 #define _ASM_RISCV_PERF_EVENT_H
 
 #include 
-#include 
-#include 
-
-#ifdef CONFIG_RISCV_BASE_PMU
-#define RISCV_BASE_COUNTERS2
-
-/*
- * The RISCV_MAX_COUNTERS parameter should be specified.
- */
-
-#define RISCV_MAX_COUNTERS 2
-
-/*
- * These are the indexes of bits in counteren register *minus* 1,
- * except for cycle.  It would be coherent if it can directly mapped
- * to counteren bit definition, but there is a *time* register at
- * counteren[1].  Per-cpu structure is scarce resource here.
- *
- * According to the spec, an implementation can support counter up to
- * mhpmcounter31, but many high-end processors has at most 6 general
- * PMCs, we give the definition to MHPMCOUNTER8 here.
- */
-#define RISCV_PMU_CYCLE0
-#define RISCV_PMU_INSTRET  1
-#define RISCV_PMU_MHPMCOUNTER3 2
-#define RISCV_PMU_MHPMCOUNTER4 3
-#define RISCV_PMU_MHPMCOUNTER5 4
-#define RISCV_PMU_MHPMCOUNTER6 5
-#define RISCV_PMU_MHPMCOUNTER7 6
-#define RISCV_PMU_MHPMCOUNTER8 7
-
-#define RISCV_OP_UNSUPP(-EOPNOTSUPP)
-
-struct cpu_hw_events {
-   /* # currently enabled events*/
-   int n_events;
-   /* currently enabled events */
-   struct perf_event   *events[RISCV_MAX_COUNTERS];
-   /* vendor-defined PMU data */
-   void*platform;
-};
-
-struct riscv_pmu {
-   struct pmu  *pmu;
-
-   /* generic hw/cache events table */
-   const int   *hw_events;
-   const int   (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
-  [PERF_COUNT_HW_CACHE_OP_MAX]
-  [PERF_COUNT_HW_CACHE_RESULT_MAX];
-   /* method used to map hw/cache events */
-   int (*map_hw_event)(u64 config);
-   int (*map_cache_event)(u64 config);
-
-   /* max generic hw events in map */
-   int max_events;
-   /* number total counters, 2(base) + x(general) */
-   int num_counters;
-   /* the width of the counter */
-   int counter_width;
-
-   /* vendor-defined PMU features */
-   void*platform;
-
-   irqreturn_t (*handle_irq)(int irq_num, void *dev);
-   int irq;
-};
-
-#endif
-#ifdef CONFIG_PERF_EVENTS
-#define perf_arch_bpf_user_pt_regs(regs) (struct user_regs_struct *)regs
-#endif
 
 #endif /* _ASM_RISCV_PERF_EVENT_H */
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index 3dc0abde988a..5f8f6290a0e1 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -45,7 +45,6 @@ obj-$(CONFIG_MODULE_SECTIONS) += module-sections.o
 obj-$(CONFIG_FUNCTION_TRACER)  += mcount.o ftrace.o
 obj-$(CONFIG_DYNAMIC_FTRACE)   += mcount-dyn.o
 
-obj-$(CONFIG_RISCV_BASE_PMU)   += perf_event.o
 obj-$(CONFIG_PERF_EVENTS)  += perf_callchain.o
 obj-$(CONFIG_HAVE_PERF_REGS)   += perf_regs.o
 obj-$(CONFIG_RISCV_SBI)+= sbi.o
diff --git a/arch/riscv/kernel/perf_event.c b/arch/riscv/kernel/perf_event.c
deleted file mode 100644
index c835f0362d94..
--- a/arch/riscv/kernel/perf_event.c
+++ /dev/null
@@ -1,485 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (C) 2008 Thomas Gleixner 
- * Copyright (C) 2008-2009 Red Hat, Inc., Ingo Molnar
- * Copyright (C) 2009 Jaswinder Singh Rajput
-

[RFC 6/6] RISC-V: Add perf platform driver based on SBI PMU extension

2021-03-19 Thread Atish Patra
RISC-V SBI specification added a PMU extension that allows to configure
/start/stop any pmu counter. The RISC-V perf can use most of the generic
perf features except interrupt overflow and event filtering based on
privilege mode which will be added in future.

It also allows to monitor a handful of firmware counters that can provide
insights into firmware activity during a performance analysis.

Signed-off-by: Atish Patra 
---
 drivers/perf/Kconfig   |   8 +
 drivers/perf/Makefile  |   1 +
 drivers/perf/riscv_pmu.c   |  12 +-
 drivers/perf/riscv_pmu_sbi.c   | 464 +
 include/linux/perf/riscv_pmu.h |   1 +
 5 files changed, 485 insertions(+), 1 deletion(-)
 create mode 100644 drivers/perf/riscv_pmu_sbi.c

diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 1546a487d970..2acb5feaab35 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -73,6 +73,14 @@ config RISCV_PMU_LEGACY
  implementation on RISC-V based systems. This only allows counting
  of cycle/instruction counter and will be removed in future.
 
+config RISCV_PMU_SBI
+   depends on RISCV_PMU
+   bool "RISC-V PMU based on SBI PMU extension"
+   default y
+   help
+ Say y if you want to use the CPU performance monitor
+ using SBI PMU extension on RISC-V based systems.
+
 config ARM_PMU_ACPI
depends on ARM_PMU && ACPI
def_bool y
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index e8aa666a9d28..7bcac4b5a983 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
 obj-$(CONFIG_RISCV_PMU) += riscv_pmu.o
 ifeq ($(CONFIG_RISCV_PMU), y)
 obj-$(CONFIG_RISCV_PMU_LEGACY) += riscv_pmu_legacy.o
+obj-$(CONFIG_RISCV_PMU_SBI) += riscv_pmu_sbi.o
 endif
 obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
diff --git a/drivers/perf/riscv_pmu.c b/drivers/perf/riscv_pmu.c
index 838dca2ffca8..95e4ca07dd29 100644
--- a/drivers/perf/riscv_pmu.c
+++ b/drivers/perf/riscv_pmu.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 
+#include 
+
 static unsigned long csr_read_num(int csr_num)
 {
 #define switchcase_csr_read(__csr_num, __val)  {\
@@ -350,7 +352,15 @@ static int riscv_pmu_device_probe(struct platform_device 
*pdev)
if (!pmu)
return -ENOMEM;
 
-   riscv_pmu_legacy_init(pmu);
+   if (sbi_major_version() == 0 &&
+   sbi_minor_version() == 3 &&
+   sbi_probe_extension(SBI_EXT_PMU) > 0) {
+   pr_info("SBI PMU extension detected\n");
+   riscv_pmu_sbi_init(pmu);
+   } else {
+   pr_info("Legacy PMU is in use as SBI PMU extension is not 
available\n");
+   riscv_pmu_legacy_init(pmu);
+   }
 
cpuhp_setup_state(CPUHP_AP_PERF_RISCV_STARTING,
  "perf/riscv/pmu:starting",
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
new file mode 100644
index ..1f27802bd0e9
--- /dev/null
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -0,0 +1,464 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RISC-V performance counter support.
+ *
+ * Copyright (C) 2021 Western Digital Corporation or its affiliates.
+ *
+ * This code is based on ARM perf event code which is in turn based on
+ * sparc64 and x86 code.
+ */
+
+#include 
+
+#include 
+
+union sbi_pmu_ctr_info {
+   unsigned long value;
+   struct {
+   unsigned long csr:12;
+   unsigned long width:6;
+#if __riscv_xlen == 32
+   unsigned long reserved:13;
+#else
+   unsigned long reserved:45;
+#endif
+   unsigned long type:1;
+   };
+};
+
+/**
+ * RISC-V doesn't have hetergenous harts yet. This need to be part of
+ * per_cpu in case of harts with different pmu counters
+ */
+static union sbi_pmu_ctr_info *pmu_ctr_list;
+
+struct pmu_event_data {
+   union {
+   union {
+   struct hw_gen_event {
+   uint32_t event_code:16;
+   uint32_t event_type:4;
+   uint32_t reserved:12;
+   } hw_gen_event;
+   struct hw_cache_event {
+   uint32_t result_id:1;
+   uint32_t op_id:2;
+   uint32_t cache_id:13;
+   uint32_t event_type:4;
+   uint32_t reserved:12;
+   } hw_cache_event;
+   };
+   uint32_t event_idx;
+   };
+};
+
+static const struct pmu_event_data pmu_hw_event_map[] = {
+   [PERF_COUNT_HW_CPU_CYCLES]  = {.hw_gen_event = {
+   SBI_PMU_HW_CPU_CYCLES,
+ 

Re: [PATCH] RISC-V: Fix out-of-bounds accesses in init_resources()

2021-03-15 Thread Atish Patra
On Fri, Mar 12, 2021 at 7:46 AM Geert Uytterhoeven  wrote:
>
> init_resources() allocates an array of resources, based on the current
> total number of memory regions and reserved memory regions.  However,
> allocating this array using memblock_alloc() might increase the number
> of reserved memory regions.  If that happens, populating the array later
> based on the new number of regions will cause out-of-bounds writes
> beyond the end of the allocated array.
>
> Fix this by allocating one more entry, which may or may not be used.
>
> Fixes: 797f0375dd2ef5cd ("RISC-V: Do not allocate memblock while iterating 
> reserved memblocks")
> Signed-off-by: Geert Uytterhoeven 
> ---
> Tested on vexriscv, which works now using L1_CACHE_SHIFT = 6, too.
>
> This issue may show up during early boot as:
>
> Unable to handle kernel paging request at virtual address c808
> Oops [#1]
> CPU: 0 PID: 0 Comm: swapper Not tainted 
> 5.11.0-orangecrab-00023-g7c4fc8e3e982-dirty #137
> epc: c04d6660 ra : c04d6560 sp : c05ddf70
>  gp : c0678bc0 tp : c05e5b40 t0 : c800
>  t1 : 0003 t2 :  s0 : c05ddfc0
>  s1 : c800 a0 :  a1 : c7e0
>  a2 : 0005 a3 : 0001 a4 : 000c
>  a5 :  a6 : c04fe000 a7 : 000c
>  s2 : c04fe098 s3 : 00a0 s4 : c760
>  s5 : c04fe0dc s6 : 8200 s7 : c059f1d4
>  s8 : 81000200 s9 : c059f1f0 s10: 8200
>  s11: c059f1d4 t3 : 405dbb60 t4 : c05e6f08
>  t5 : 81000200 t6 : 40501000
> status: 0100 badaddr: c808 cause: 000f
> random: get_random_bytes called from print_oops_end_marker+0x38/0x7c with 
> crng_init=0
> ---[ end trace  ]---
>
> or much later as:
>
> Unable to handle kernel paging request at virtual address 69726573
> ---
>  arch/riscv/kernel/setup.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index e85bacff1b5075ee..f8f15332caa20263 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -147,7 +147,8 @@ static void __init init_resources(void)
> bss_res.end = __pa_symbol(__bss_stop) - 1;
> bss_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
>
> -   mem_res_sz = (memblock.memory.cnt + memblock.reserved.cnt) * 
> sizeof(*mem_res);
> +   /* + 1 as memblock_alloc() might increase memblock.reserved.cnt */
> +   mem_res_sz = (memblock.memory.cnt + memblock.reserved.cnt + 1) * 
> sizeof(*mem_res);
> mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
> if (!mem_res)
> panic("%s: Failed to allocate %zu bytes\n", __func__, 
> mem_res_sz);
> --
> 2.25.1
>
>
> _______
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Thanks for catching the bug & fixing it.


Reviewed-by: Atish Patra 
-- 
Regards,
Atish


Re: [PATCH v6 1/2] RISC-V: Don't print SBI version for all detected extensions

2021-03-15 Thread Atish Patra
On Mon, Mar 15, 2021 at 4:07 AM Anup Patel  wrote:
>
> The sbi_init() already prints SBI version before detecting
> various SBI extensions so we don't need to print SBI version
> for all detected SBI extensions.
>
> Signed-off-by: Anup Patel 
> ---
>  arch/riscv/kernel/sbi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
> index f4a7db3d309e..c0dcebdd30ec 100644
> --- a/arch/riscv/kernel/sbi.c
> +++ b/arch/riscv/kernel/sbi.c
> @@ -577,19 +577,19 @@ void __init sbi_init(void)
> sbi_get_firmware_id(), sbi_get_firmware_version());
> if (sbi_probe_extension(SBI_EXT_TIME) > 0) {
> __sbi_set_timer = __sbi_set_timer_v02;
> -   pr_info("SBI v0.2 TIME extension detected\n");
> +   pr_info("SBI TIME extension detected\n");
> } else {
> __sbi_set_timer = __sbi_set_timer_v01;
> }
> if (sbi_probe_extension(SBI_EXT_IPI) > 0) {
> __sbi_send_ipi  = __sbi_send_ipi_v02;
> -   pr_info("SBI v0.2 IPI extension detected\n");
> +   pr_info("SBI IPI extension detected\n");
> } else {
> __sbi_send_ipi  = __sbi_send_ipi_v01;
> }
> if (sbi_probe_extension(SBI_EXT_RFENCE) > 0) {
> __sbi_rfence= __sbi_rfence_v02;
> -   pr_info("SBI v0.2 RFENCE extension detected\n");
> +   pr_info("SBI RFENCE extension detected\n");
> } else {
> __sbi_rfence= __sbi_rfence_v01;
> }
> --
> 2.25.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra 

-- 
Regards,
Atish


Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board

2021-03-09 Thread Atish Patra
On Tue, 2021-03-09 at 13:30 +, lewis.ha...@microchip.com wrote:
> 
> 
> From: Ben Dooks 
> Sent: Tuesday, March 9, 2021 10:56 AM
> To: Atish Patra ; linux-kernel@vger.kernel.org <
> linux-kernel@vger.kernel.org>
> Cc: Albert Ou ; Alistair Francis <
> alistair.fran...@wdc.com>; Anup Patel ; Björn
> Töpel ; devicet...@vger.kernel.org <
> devicet...@vger.kernel.org>; linux-ri...@lists.infradead.org <
> linux-ri...@lists.infradead.org>; Palmer Dabbelt
> ; Paul Walmsley ; Rob
> Herring < robh...@kernel.org>; Conor Dooley - M52691 <
> conor.doo...@microchip.com>; Daire McNamara - X61553 <
> daire.mcnam...@microchip.com>; Ivan Griffin - X61451 <
> ivan.grif...@microchip.com>; Lewis Hanly - M34782 <
> lewis.ha...@microchip.com>
> Subject: Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE
> board 
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> On 03/03/2021 20:02, Atish Patra wrote:
> > Add initial DTS for Microchip ICICLE board having only
> > essential devices (clocks, sdhci, ethernet, serial, etc).
> > The device tree is based on the U-Boot patch.
> > 
> > https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/
> > 
> > Signed-off-by: Atish Patra 
> > ---
> >    arch/riscv/boot/dts/Makefile  |   1 +
> >    arch/riscv/boot/dts/microchip/Makefile    |   2 +
> >    .../microchip/microchip-mpfs-icicle-kit.dts   |  72 
> >    .../boot/dts/microchip/microchip-mpfs.dtsi    | 329
> > ++
> >    4 files changed, 404 insertions(+)
> >    create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> >    create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-
> > icicle-kit.dts
> >    create mode 100644 arch/riscv/boot/dts/microchip/microchip-
> > mpfs.dtsi
> > 
> > diff --git a/arch/riscv/boot/dts/Makefile
> > b/arch/riscv/boot/dts/Makefile
> > index 7ffd502e3e7b..fe996b88319e 100644
> > --- a/arch/riscv/boot/dts/Makefile
> > +++ b/arch/riscv/boot/dts/Makefile
> > @@ -1,5 +1,6 @@
> >    # SPDX-License-Identifier: GPL-2.0
> >    subdir-y += sifive
> >    subdir-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += canaan
> > +subdir-y += microchip
> > 
> >    obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
> > diff --git a/arch/riscv/boot/dts/microchip/Makefile
> > b/arch/riscv/boot/dts/microchip/Makefile
> > new file mode 100644
> > index ..622b12771fd3
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-
> > kit.dtb
> > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-
> > kit.dts b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-
> > kit.dts
> > new file mode 100644
> > index ..ec79944065c9
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > @@ -0,0 +1,72 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/* Copyright (c) 2020 Microchip Technology Inc */
> > +
> > +/dts-v1/;
> > +
> > +#include "microchip-mpfs.dtsi"
> > +
> > +/* Clock frequency (in Hz) of the rtcclk */
> > +#define RTCCLK_FREQ  100
> > +
> > +/ {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + model = "Microchip PolarFire-SoC Icicle Kit";
> > + compatible = "microchip,mpfs-icicle-kit";
> > +
> > + chosen {
> > + stdout-path = 
> > + };
> > +
> > + cpus {
> > + timebase-frequency = ;
> > + };
> > +
> > + memory@8000 {
> > + device_type = "memory";
> > + reg = <0x0 0x8000 0x0 0x4000>;
> > + clocks = < 26>;
> > + };
> > +
> 
> The latest Microchip releases have two memory nodes to provide the
> full 2GiB of memory space.
> > > For this release we want to leave it at 1GB, wip memory remapping
> > > with the newer releases.
> 

Thanks for the clarification. For some reason, your reply did not land
in the mailing lists.


> > + soc {
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + phy-mode = "sgmii";
> > + phy-handle = <>;
> > + phy0: ethernet-phy@8 {
> > + reg = <8>;
> > + ti,fifo-depth = <0x01>;
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > + phy-mode = "sgmii";
> > + phy-handle = <>;
> > + phy1: ethernet-phy@9 {
> > + reg = <9>;
> > + ti,fifo-depth = <0x01>;
> > + };
> > +};
> 
> 
> 
> --
> Ben Dooks   http://www.codethink.co.uk/
> Senior Engineer Codethink - Providing Genius
> 
> https://www.codethink.co.uk/privacy.html

-- 
Regards,
Atish


Re: [PATCH 1/1] RISC-V: correct enum sbi_ext_rfence_fid

2021-03-09 Thread Atish Patra
On Mon, Mar 8, 2021 at 2:55 AM Anup Patel  wrote:
>
> On Mon, Mar 8, 2021 at 1:19 PM Atish Patra  wrote:
> >
> > On Sat, Mar 6, 2021 at 4:12 AM Anup Patel  wrote:
> > >
> > > On Sat, Mar 6, 2021 at 11:19 AM Heinrich Schuchardt  
> > > wrote:
> > > >
> > > > The constants in enum sbi_ext_rfence_fid should match the SBI
> > > > specification. See
> > > > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc#78-function-listing
> > > >
> > > > | Function Name   | FID | EID
> > > > | sbi_remote_fence_i  |   0 | 0x52464E43
> > > > | sbi_remote_sfence_vma   |   1 | 0x52464E43
> > > > | sbi_remote_sfence_vma_asid  |   2 | 0x52464E43
> > > > | sbi_remote_hfence_gvma_vmid |   3 | 0x52464E43
> > > > | sbi_remote_hfence_gvma  |   4 | 0x52464E43
> > > > | sbi_remote_hfence_vvma_asid |   5 | 0x52464E43
> > > > | sbi_remote_hfence_vvma  |   6 | 0x52464E43
> > > >
> > > > Fixes: ecbacc2a3efd ("RISC-V: Add SBI v0.2 extension definitions")
> > > > Reported-by: Sean Anderson 
> > > > Signed-off-by: Heinrich Schuchardt 
> > >

Reviewed-by: Atish Patra 

> > > Good catch.
> > >
> > > I guess we never saw any issues because these calls are only used by
> > > KVM RISC-V which is not merged yet. Further for KVM RISC-V, the HFENCE
> > > instruction is emulated as flush everything on FPGA, QEMU, and Spike so
> > > we did not notice any issue with KVM RISC-V too.
> > >
> >
> > OpenSBI & Xvisor also define the same order as Linux kernel. The
> > existing order(in Linux kernel)
> > makes more sense w.r.to Lexicographic order as well.
> >
> > Should we just fix the spec instead ?
>
> I would not recommend that because RFENCE is part of the released SBI v0.2 
> spec.
>

Fair enough.

> We have to be more careful in software to follow the spec correctly.
>

Agreed. Apologies for the slip up.

> Regards,
> Anup
>
> >
> > > Looks good to me.
> > >
> > > Reviewed-by: Anup Patel 
> > >
> > > Regards,
> > > Anup
> > >
> > > > ---
> > > >  arch/riscv/include/asm/sbi.h | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> > > > index 99895d9c3bdd..d7027411dde8 100644
> > > > --- a/arch/riscv/include/asm/sbi.h
> > > > +++ b/arch/riscv/include/asm/sbi.h
> > > > @@ -51,10 +51,10 @@ enum sbi_ext_rfence_fid {
> > > > SBI_EXT_RFENCE_REMOTE_FENCE_I = 0,
> > > > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
> > > > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
> > > > -   SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > > > SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID,
> > > > -   SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> > > > +   SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > > > SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID,
> > > > +   SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> > > >  };
> > > >
> > > >  enum sbi_ext_hsm_fid {
> > > > --
> > > > 2.30.1
> > > >
> > > >
> > > > ___
> > > > linux-riscv mailing list
> > > > linux-ri...@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > >
> > > ___
> > > linux-riscv mailing list
> > > linux-ri...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> >
> >
> >
> > --
> > Regards,
> > Atish



-- 
Regards,
Atish


Re: [PATCH 1/1] RISC-V: correct enum sbi_ext_rfence_fid

2021-03-08 Thread Atish Patra
On Sun, Mar 7, 2021 at 11:49 PM Atish Patra  wrote:
>
> On Sat, Mar 6, 2021 at 4:12 AM Anup Patel  wrote:
> >
> > On Sat, Mar 6, 2021 at 11:19 AM Heinrich Schuchardt  
> > wrote:
> > >
> > > The constants in enum sbi_ext_rfence_fid should match the SBI
> > > specification. See
> > > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc#78-function-listing
> > >
> > > | Function Name   | FID | EID
> > > | sbi_remote_fence_i  |   0 | 0x52464E43
> > > | sbi_remote_sfence_vma   |   1 | 0x52464E43
> > > | sbi_remote_sfence_vma_asid  |   2 | 0x52464E43
> > > | sbi_remote_hfence_gvma_vmid |   3 | 0x52464E43
> > > | sbi_remote_hfence_gvma  |   4 | 0x52464E43
> > > | sbi_remote_hfence_vvma_asid |   5 | 0x52464E43
> > > | sbi_remote_hfence_vvma  |   6 | 0x52464E43
> > >
> > > Fixes: ecbacc2a3efd ("RISC-V: Add SBI v0.2 extension definitions")
> > > Reported-by: Sean Anderson 
> > > Signed-off-by: Heinrich Schuchardt 
> >
> > Good catch.
> >
> > I guess we never saw any issues because these calls are only used by
> > KVM RISC-V which is not merged yet. Further for KVM RISC-V, the HFENCE
> > instruction is emulated as flush everything on FPGA, QEMU, and Spike so
> > we did not notice any issue with KVM RISC-V too.
> >
>
> OpenSBI & Xvisor also define the same order as Linux kernel. The
> existing order(in Linux kernel)
> makes more sense w.r.to Lexicographic order as well.
>
> Should we just fix the spec instead ?
>

We do need to notify RustSBI & Diosix authors about this change in
case we decide to do so.
However, RustSBI added rfence support a few weeks back only [1]. I
could not find any rfence reference in Diosix.
Thus, the impact should be very minimal if the spec is fixed.

[1] 
https://github.com/luojia65/rustsbi/commit/6e06b4e8e96e05b69157dd5477d433cc932c8a64
> > Looks good to me.
> >
> > Reviewed-by: Anup Patel 
> >
> > Regards,
> > Anup
> >
> > > ---
> > >  arch/riscv/include/asm/sbi.h | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> > > index 99895d9c3bdd..d7027411dde8 100644
> > > --- a/arch/riscv/include/asm/sbi.h
> > > +++ b/arch/riscv/include/asm/sbi.h
> > > @@ -51,10 +51,10 @@ enum sbi_ext_rfence_fid {
> > > SBI_EXT_RFENCE_REMOTE_FENCE_I = 0,
> > > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
> > > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
> > > -   SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > > SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID,
> > > -   SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> > > +   SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > > SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID,
> > > +   SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> > >  };
> > >
> > >  enum sbi_ext_hsm_fid {
> > > --
> > > 2.30.1
> > >
> > >
> > > ___
> > > linux-riscv mailing list
> > > linux-ri...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> >
> > ___
> > linux-riscv mailing list
> > linux-ri...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
>
>
> --
> Regards,
> Atish



-- 
Regards,
Atish


Re: [PATCH 1/1] RISC-V: correct enum sbi_ext_rfence_fid

2021-03-07 Thread Atish Patra
On Sat, Mar 6, 2021 at 4:12 AM Anup Patel  wrote:
>
> On Sat, Mar 6, 2021 at 11:19 AM Heinrich Schuchardt  
> wrote:
> >
> > The constants in enum sbi_ext_rfence_fid should match the SBI
> > specification. See
> > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc#78-function-listing
> >
> > | Function Name   | FID | EID
> > | sbi_remote_fence_i  |   0 | 0x52464E43
> > | sbi_remote_sfence_vma   |   1 | 0x52464E43
> > | sbi_remote_sfence_vma_asid  |   2 | 0x52464E43
> > | sbi_remote_hfence_gvma_vmid |   3 | 0x52464E43
> > | sbi_remote_hfence_gvma  |   4 | 0x52464E43
> > | sbi_remote_hfence_vvma_asid |   5 | 0x52464E43
> > | sbi_remote_hfence_vvma  |   6 | 0x52464E43
> >
> > Fixes: ecbacc2a3efd ("RISC-V: Add SBI v0.2 extension definitions")
> > Reported-by: Sean Anderson 
> > Signed-off-by: Heinrich Schuchardt 
>
> Good catch.
>
> I guess we never saw any issues because these calls are only used by
> KVM RISC-V which is not merged yet. Further for KVM RISC-V, the HFENCE
> instruction is emulated as flush everything on FPGA, QEMU, and Spike so
> we did not notice any issue with KVM RISC-V too.
>

OpenSBI & Xvisor also define the same order as Linux kernel. The
existing order(in Linux kernel)
makes more sense w.r.to Lexicographic order as well.

Should we just fix the spec instead ?

> Looks good to me.
>
> Reviewed-by: Anup Patel 
>
> Regards,
> Anup
>
> > ---
> >  arch/riscv/include/asm/sbi.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> > index 99895d9c3bdd..d7027411dde8 100644
> > --- a/arch/riscv/include/asm/sbi.h
> > +++ b/arch/riscv/include/asm/sbi.h
> > @@ -51,10 +51,10 @@ enum sbi_ext_rfence_fid {
> > SBI_EXT_RFENCE_REMOTE_FENCE_I = 0,
> > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
> > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
> > -   SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID,
> > -   SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> > +   SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID,
> > +   SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> >  };
> >
> >  enum sbi_ext_hsm_fid {
> > --
> > 2.30.1
> >
> >
> > ___
> > linux-riscv mailing list
> > linux-ri...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


[PATCH v4 5/5] MAINTAINERS: add microchip polarfire soc support

2021-03-03 Thread Atish Patra
From: Conor Dooley 

Add Cyril Jean and Lewis Hanly as maintainers for the Microchip SoC
directory

Signed-off-by: Conor Dooley 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..cf186eca1784 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15358,6 +15358,14 @@ F: arch/riscv/
 N: riscv
 K: riscv
 
+RISC-V/MICROCHIP POLARFIRE SOC SUPPORT
+M: Lewis Hanly 
+M: Cyril Jean 
+L: linux-ri...@lists.infradead.org
+S: Supported
+F: drivers/soc/microchip/
+F: include/soc/microchip/mpfs.h
+
 RNBD BLOCK DRIVERS
 M: Danil Kipnis 
 M: Jack Wang 
-- 
2.25.1



[PATCH v4 4/5] RISC-V: Enable Microchip PolarFire ICICLE SoC

2021-03-03 Thread Atish Patra
Enable Microchip PolarFire ICICLE soc config in defconfig.
It allows the default upstream kernel to boot on PolarFire ICICLE board.

Signed-off-by: Atish Patra 
Reviewed-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 arch/riscv/configs/defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 6c0625aa96c7..1f2be234b11c 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -16,6 +16,7 @@ CONFIG_EXPERT=y
 CONFIG_BPF_SYSCALL=y
 CONFIG_SOC_SIFIVE=y
 CONFIG_SOC_VIRT=y
+CONFIG_SOC_MICROCHIP_POLARFIRE=y
 CONFIG_SMP=y
 CONFIG_HOTPLUG_CPU=y
 CONFIG_JUMP_LABEL=y
@@ -82,6 +83,9 @@ CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_UAS=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_CADENCE=y
 CONFIG_MMC=y
 CONFIG_MMC_SPI=y
 CONFIG_RTC_CLASS=y
-- 
2.25.1



[PATCH v4 1/5] RISC-V: Add Microchip PolarFire SoC kconfig option

2021-03-03 Thread Atish Patra
Add Microchip PolarFire kconfig option which selects SoC specific
and common drivers that is required for this SoC.

Signed-off-by: Atish Patra 
Reviewed-by: Bin Meng 
Reviewed-by: Anup Patel 
---
 arch/riscv/Kconfig.socs | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 7efcece8896c..82b298bfd3be 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -1,5 +1,12 @@
 menu "SoC selection"
 
+config SOC_MICROCHIP_POLARFIRE
+   bool "Microchip PolarFire SoCs"
+   select MCHP_CLK_MPFS
+   select SIFIVE_PLIC
+   help
+ This enables support for Microchip PolarFire SoC platforms.
+
 config SOC_SIFIVE
bool "SiFive SoCs"
select SERIAL_SIFIVE if TTY
-- 
2.25.1



[PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board

2021-03-03 Thread Atish Patra
Add initial DTS for Microchip ICICLE board having only
essential devices (clocks, sdhci, ethernet, serial, etc).
The device tree is based on the U-Boot patch.

https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/

Signed-off-by: Atish Patra 
---
 arch/riscv/boot/dts/Makefile  |   1 +
 arch/riscv/boot/dts/microchip/Makefile|   2 +
 .../microchip/microchip-mpfs-icicle-kit.dts   |  72 
 .../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++
 4 files changed, 404 insertions(+)
 create mode 100644 arch/riscv/boot/dts/microchip/Makefile
 create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
 create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi

diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index 7ffd502e3e7b..fe996b88319e 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 subdir-y += sifive
 subdir-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += canaan
+subdir-y += microchip
 
 obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
diff --git a/arch/riscv/boot/dts/microchip/Makefile 
b/arch/riscv/boot/dts/microchip/Makefile
new file mode 100644
index ..622b12771fd3
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts 
b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
new file mode 100644
index ..ec79944065c9
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2020 Microchip Technology Inc */
+
+/dts-v1/;
+
+#include "microchip-mpfs.dtsi"
+
+/* Clock frequency (in Hz) of the rtcclk */
+#define RTCCLK_FREQ100
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   model = "Microchip PolarFire-SoC Icicle Kit";
+   compatible = "microchip,mpfs-icicle-kit";
+
+   chosen {
+   stdout-path = 
+   };
+
+   cpus {
+   timebase-frequency = ;
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x0 0x8000 0x0 0x4000>;
+   clocks = < 26>;
+   };
+
+   soc {
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   phy-mode = "sgmii";
+   phy-handle = <>;
+   phy0: ethernet-phy@8 {
+   reg = <8>;
+   ti,fifo-depth = <0x01>;
+   };
+};
+
+ {
+   status = "okay";
+   phy-mode = "sgmii";
+   phy-handle = <>;
+   phy1: ethernet-phy@9 {
+   reg = <9>;
+   ti,fifo-depth = <0x01>;
+   };
+};
diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi 
b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
new file mode 100644
index ..b9819570a7d1
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2020 Microchip Technology Inc */
+
+/dts-v1/;
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   model = "Microchip MPFS Icicle Kit";
+   compatible = "microchip,mpfs-icicle-kit";
+
+   chosen {
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   clock-frequency = <0>;
+   compatible = "sifive,e51", "sifive,rocket0", "riscv";
+   device_type = "cpu";
+   i-cache-block-size = <64>;
+   i-cache-sets = <128>;
+   i-cache-size = <16384>;
+   reg = <0>;
+   riscv,isa = "rv64imac";
+   status = "disabled";
+
+   cpu0_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+
+   cpu@1 {
+   clock-frequency = <0>;
+   compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+

[PATCH v4 2/5] dt-bindings: riscv: microchip: Add YAML documentation for the PolarFire SoC

2021-03-03 Thread Atish Patra
Add YAML DT binding documentation for the Microchip PolarFire SoC.
It is documented at:

https://www.microsemi.com/products/fpga-soc/polarfire-soc-icicle-quick-start-guide

Signed-off-by: Atish Patra 
---
 .../devicetree/bindings/riscv/microchip.yaml  | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml

diff --git a/Documentation/devicetree/bindings/riscv/microchip.yaml 
b/Documentation/devicetree/bindings/riscv/microchip.yaml
new file mode 100644
index ..3f981e897126
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/microchip.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/microchip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PolarFire SoC-based boards device tree bindings
+
+maintainers:
+  - Cyril Jean 
+  - Lewis Hanly 
+
+description:
+  Microchip PolarFire SoC-based boards
+
+properties:
+  $nodename:
+const: '/'
+  compatible:
+items:
+  - enum:
+  - microchip,mpfs-icicle-kit
+  - const: microchip,mpfs
+
+additionalProperties: true
+
+...
-- 
2.25.1



[PATCH v4 0/5] Add Microchip PolarFire Soc Support

2021-03-03 Thread Atish Patra
This series adds minimal support for Microchip Polar Fire Soc Icicle kit.
It is rebased on v5.12-rc1 and depends on clock support. 
Only MMC and ethernet drivers are enabled via this series.
The idea here is to add the foundational patches so that other drivers
can be added to on top of this. The device tree may change based on
feedback on bindings of individual driver support patches.

This series has been tested on Qemu and Polar Fire Soc Icicle kit.
It depends on the updated clock-series[2] and macb fix[3].
The series is also tested by Lewis from Microchip.

The series can also be found at.
https://github.com/atishp04/linux/tree/polarfire_support_upstream_v4

[1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html
[2] https://www.spinics.net/lists/linux-clk/msg54579.html 

Changes from v3->v4:
1. Fixed few DT specific issues.
2. Rebased on top of new clock driver.
3. SD card functionality is verified.

Changes from v2->v3:
1. Fixed a typo in dt binding.
2. Included MAINTAINERS entry for PolarFire SoC.
3. Improved the dts file by using lowercase clock names and keeping phy
   details in board specific dts file.

Changes from v1->v2:
1. Modified the DT to match the device tree in U-Boot.
2. Added both eMMC & SDcard entries in DT. However, SD card is only enabled
   as it allows larger storage option for linux distros.

Atish Patra (4):
RISC-V: Add Microchip PolarFire SoC kconfig option
dt-bindings: riscv: microchip: Add YAML documentation for the
PolarFire SoC
RISC-V: Initial DTS for Microchip ICICLE board
RISC-V: Enable Microchip PolarFire ICICLE SoC

Conor Dooley (1):
MAINTAINERS: add microchip polarfire soc support

.../devicetree/bindings/riscv/microchip.yaml  |  27 ++
MAINTAINERS   |   8 +
arch/riscv/Kconfig.socs   |   7 +
arch/riscv/boot/dts/Makefile  |   1 +
arch/riscv/boot/dts/microchip/Makefile|   2 +
.../microchip/microchip-mpfs-icicle-kit.dts   |  72 
.../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++
arch/riscv/configs/defconfig  |   4 +
8 files changed, 450 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml
create mode 100644 arch/riscv/boot/dts/microchip/Makefile
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi

--
2.25.1



Re: [PATCH v4] RISC-V: Use SBI SRST extension when available

2021-03-02 Thread Atish Patra
   pr_info("SBI SRST extension detected\n");
> +   pm_power_off = sbi_srst_power_off;
> +   sbi_srst_reboot_nb.notifier_call = sbi_srst_reboot;
> +   sbi_srst_reboot_nb.priority = 192;
> +   register_restart_handler(_srst_reboot_nb);
> +   }
> } else {
> __sbi_set_timer = __sbi_set_timer_v01;
> __sbi_send_ipi  = __sbi_send_ipi_v01;
> --
> 2.25.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Reviewed-by: Atish Patra 

-- 
Regards,
Atish


Re: [PATCH] RISC-V: Add a non-void return for sbi v02 functions

2021-02-22 Thread Atish Patra
On Mon, Feb 22, 2021 at 5:52 PM Palmer Dabbelt  wrote:
>
> On Mon, 22 Feb 2021 14:38:28 PST (-0800), ati...@atishpatra.org wrote:
> > On Mon, Feb 22, 2021 at 12:23 PM Guenter Roeck  wrote:
> >>
> >> On Wed, Feb 03, 2021 at 09:26:43PM -0800, Atish Patra wrote:
> >> > SBI v0.2 functions can return an error code from SBI implementation.
> >> > We are already processing the SBI error code and coverts it to the Linux
> >> > error code.
> >> >
> >> > Propagate to the error code to the caller as well. As of now, kvm is the
> >> > only user of these error codes.
> >> >
> >> > Signed-off-by: Atish Patra 
> >> > ---
> >> ...
> >> >  #else /* CONFIG_RISCV_SBI */
> >> > -static inline void sbi_remote_fence_i(const unsigned long *hart_mask) {}
> >> > +static inline int sbi_remote_fence_i(const unsigned long *hart_mask) {}
> >>
> >> Error log:
> >> In file included from arch/riscv/kernel/setup.c:29:
> >> arch/riscv/include/asm/sbi.h: In function 'sbi_remote_fence_i':
> >> arch/riscv/include/asm/sbi.h:150:1: error: no return statement in function 
> >> returning non-void
> >>
> >
> > Sorry for the oversight. The return statement is missing.
> >
> > @Palmer Dabbelt : Can you fix it in for-next or should I send a v2 ?
>
> I just fixed it up.

Thanks!

-- 
Regards,
Atish


Re: [PATCH] RISC-V: Add a non-void return for sbi v02 functions

2021-02-22 Thread Atish Patra
On Mon, Feb 22, 2021 at 12:23 PM Guenter Roeck  wrote:
>
> On Wed, Feb 03, 2021 at 09:26:43PM -0800, Atish Patra wrote:
> > SBI v0.2 functions can return an error code from SBI implementation.
> > We are already processing the SBI error code and coverts it to the Linux
> > error code.
> >
> > Propagate to the error code to the caller as well. As of now, kvm is the
> > only user of these error codes.
> >
> > Signed-off-by: Atish Patra 
> > ---
> ...
> >  #else /* CONFIG_RISCV_SBI */
> > -static inline void sbi_remote_fence_i(const unsigned long *hart_mask) {}
> > +static inline int sbi_remote_fence_i(const unsigned long *hart_mask) {}
>
> Error log:
> In file included from arch/riscv/kernel/setup.c:29:
> arch/riscv/include/asm/sbi.h: In function 'sbi_remote_fence_i':
> arch/riscv/include/asm/sbi.h:150:1: error: no return statement in function 
> returning non-void
>

Sorry for the oversight. The return statement is missing.

@Palmer Dabbelt : Can you fix it in for-next or should I send a v2 ?

> Guenter
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


Re: [PATCH] docs: update EFI stub description

2021-02-08 Thread Atish Patra
On Sat, Feb 6, 2021 at 2:02 AM Heinrich Schuchardt  wrote:
>
> * Mention RISC-V.
> * Update code references.
> * initrd= does not specify a path relative on the ESP but to the partition
>   from which the EFI stub was loaded (as specified in the loaded image
>   protocol).
> * Mention that ACPI tables and device trees are alternatives.
> * Provide the FDT GUID.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  Documentation/admin-guide/efi-stub.rst | 47 +++---
>  1 file changed, 27 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/admin-guide/efi-stub.rst 
> b/Documentation/admin-guide/efi-stub.rst
> index 833edb0d0bc4..9e1bb79e8655 100644
> --- a/Documentation/admin-guide/efi-stub.rst
> +++ b/Documentation/admin-guide/efi-stub.rst
> @@ -8,15 +8,20 @@ it as an EFI executable. The code that modifies the bzImage 
> header,
>  along with the EFI-specific entry point that the firmware loader
>  jumps to are collectively known as the "EFI boot stub", and live in
>  arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
> -respectively. For ARM the EFI stub is implemented in
> -arch/arm/boot/compressed/efi-header.S and
> -arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared
> -between architectures is in drivers/firmware/efi/libstub.
> +respectively. For ARM the EFI stub entry point is implemented in
> +arch/arm/boot/compressed/efi-header.S.
>
> -For arm64, there is no compressed kernel support, so the Image itself
> -masquerades as a PE/COFF image and the EFI stub is linked into the
> -kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S
> -and drivers/firmware/efi/libstub/arm64-stub.c.
> +For ARM64 and RISC-V, there is no compressed kernel support, so the Image
> +itself masquerades as a PE/COFF image and the EFI stub is linked into the
> +kernel. The EFI stub entry point is in  arch/ARM64/kernel/efi-entry.S for
> +ARM64 and in arch/riscv/kernel/efi-header.S for RISC-V.
> +
> +EFI stub code that is shared between architectures is in
> +drivers/firmware/efi/libstub.
> +
> +The common secondary entry point efi_pe_entry() for ARM, ARM64, and RISC-V
> +into the stub is in drivers/firmware/efi/libstub/efi-stub.c while x86 uses
> +drivers/firmware/efi/libstub/x86-stub.c.
>
>  By using the EFI boot stub it's possible to boot a Linux kernel
>  without the use of a conventional EFI boot loader, such as grub or
> @@ -35,7 +40,7 @@ the extension the EFI firmware loader will refuse to 
> execute it. It's
>  not possible to execute bzImage.efi from the usual Linux file systems
>  because EFI firmware doesn't have support for them. For ARM the
>  arch/arm/boot/zImage should be copied to the system partition, and it
> -may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image
> +may not need to be renamed. Similarly for ARM64, arch/arm64/boot/Image
>  should be copied but not necessarily renamed.
>

Should we change the title of the paragraph to something like "How to
install EFI image"
 RISC-V image location can be added as well.
>
> @@ -55,10 +60,11 @@ multiple initrd files using the "initrd=" option. This is 
> the only EFI
>  stub-specific command line parameter, everything else is passed to the
>  kernel when it boots.
>
> -The path to the initrd file must be an absolute path from the
> -beginning of the ESP, relative path names do not work. Also, the path
> -is an EFI-style path and directory elements must be separated with
> -backslashes (\). For example, given the following directory layout::
> +The path to the initrd file must be an absolute path from the beginning of
> +the partition from which the kernel was loaded, relative path names do not
> +work. Also, the path is an EFI-style path and directory elements must be
> +separated with backslashes (\). For example, given the following directory
> +layout::
>
>fs0:>
> Kernels\
> @@ -83,18 +89,19 @@ is passed to bzImage.efi.
>  The "dtb=" option
>  -
>
> -For the ARM and arm64 architectures, a device tree must be provided to
> -the kernel. Normally firmware shall supply the device tree via the
> -EFI CONFIGURATION TABLE. However, the "dtb=" command line option can
> -be used to override the firmware supplied device tree, or to supply
> -one when firmware is unable to.
> +If ACPI tables are not available, a device tree must be provided to the
> +kernel. Normally the firmware shall supply the device tree as an EFI
> +configuration table with GUID b1b621d5-f19c-41a5-830b-d9152c69aae0.
> +However, the "dtb=" command line option can be used to override the
> +firmware supplied device tree, or to supply one when firmware is unable
> +to.
>
>  Please note: Firmware adds runtime configuration information to the
>  device tree before booting the kernel. If dtb= is used to override
>  the device tree, then any runtime data provided by firmware will be
>  lost. The dtb= option should only be used either as a debug tool, or
> -as a last resort when a device tree is not 

[PATCH v2 6/6] RISC-V: Add SBI RESET extension in KVM

2021-02-03 Thread Atish Patra
SBI RESET extension allows OS to initiate a system wide reboot or shutdown.

Implement the SBI RESET extension so that guests can issue shutdown/reset
requests as well.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/kvm_vcpu_sbi.h |  1 +
 arch/riscv/kvm/vcpu_sbi.c | 17 +++
 arch/riscv/kvm/vcpu_sbi_legacy.c  | 17 +--
 arch/riscv/kvm/vcpu_sbi_replace.c | 44 +++
 4 files changed, 63 insertions(+), 16 deletions(-)

diff --git a/arch/riscv/include/asm/kvm_vcpu_sbi.h 
b/arch/riscv/include/asm/kvm_vcpu_sbi.h
index e208c8ac57fe..4f08bb45d8ce 100644
--- a/arch/riscv/include/asm/kvm_vcpu_sbi.h
+++ b/arch/riscv/include/asm/kvm_vcpu_sbi.h
@@ -29,4 +29,5 @@ struct kvm_vcpu_sbi_extension {
 
 void kvm_riscv_vcpu_sbi_forward(struct kvm_vcpu *vcpu, struct kvm_run *run);
 const struct kvm_vcpu_sbi_extension *kvm_vcpu_sbi_find_ext(unsigned long 
extid);
+void kvm_sbi_system_event(struct kvm_vcpu *vcpu, struct kvm_run *run, u32 
type);
 #endif /* __RISCV_KVM_VCPU_SBI_H__ */
diff --git a/arch/riscv/kvm/vcpu_sbi.c b/arch/riscv/kvm/vcpu_sbi.c
index 20ef59ed83a6..858203b46700 100644
--- a/arch/riscv/kvm/vcpu_sbi.c
+++ b/arch/riscv/kvm/vcpu_sbi.c
@@ -38,6 +38,7 @@ extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_time;
 extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_ipi;
 extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_rfence;
 extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_hsm;
+extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_srst;
 
 static const struct kvm_vcpu_sbi_extension *sbi_ext[] = {
_sbi_ext_legacy,
@@ -46,8 +47,24 @@ static const struct kvm_vcpu_sbi_extension *sbi_ext[] = {
_sbi_ext_ipi,
_sbi_ext_rfence,
_sbi_ext_hsm,
+   _sbi_ext_srst,
 };
 
+void kvm_sbi_system_event(struct kvm_vcpu *vcpu,
+ struct kvm_run *run, u32 type)
+{
+   int i;
+   struct kvm_vcpu *tmp;
+
+   kvm_for_each_vcpu(i, tmp, vcpu->kvm)
+   tmp->arch.power_off = true;
+   kvm_make_all_cpus_request(vcpu->kvm, KVM_REQ_SLEEP);
+
+   memset(>system_event, 0, sizeof(run->system_event));
+   run->system_event.type = type;
+   run->exit_reason = KVM_EXIT_SYSTEM_EVENT;
+}
+
 void kvm_riscv_vcpu_sbi_forward(struct kvm_vcpu *vcpu, struct kvm_run *run)
 {
struct kvm_cpu_context *cp = >arch.guest_context;
diff --git a/arch/riscv/kvm/vcpu_sbi_legacy.c b/arch/riscv/kvm/vcpu_sbi_legacy.c
index 126d97b1292d..9fd7ea386d5f 100644
--- a/arch/riscv/kvm/vcpu_sbi_legacy.c
+++ b/arch/riscv/kvm/vcpu_sbi_legacy.c
@@ -14,21 +14,6 @@
 #include 
 #include 
 
-static void kvm_sbi_system_shutdown(struct kvm_vcpu *vcpu,
-   struct kvm_run *run, u32 type)
-{
-   int i;
-   struct kvm_vcpu *tmp;
-
-   kvm_for_each_vcpu(i, tmp, vcpu->kvm)
-   tmp->arch.power_off = true;
-   kvm_make_all_cpus_request(vcpu->kvm, KVM_REQ_SLEEP);
-
-   memset(>system_event, 0, sizeof(run->system_event));
-   run->system_event.type = type;
-   run->exit_reason = KVM_EXIT_SYSTEM_EVENT;
-}
-
 static int kvm_sbi_ext_legacy_handler(struct kvm_vcpu *vcpu, struct kvm_run 
*run,
  unsigned long *out_val,
  struct kvm_cpu_trap *utrap,
@@ -83,7 +68,7 @@ static int kvm_sbi_ext_legacy_handler(struct kvm_vcpu *vcpu, 
struct kvm_run *run
}
break;
case SBI_EXT_0_1_SHUTDOWN:
-   kvm_sbi_system_shutdown(vcpu, run, KVM_SYSTEM_EVENT_SHUTDOWN);
+   kvm_sbi_system_event(vcpu, run, KVM_SYSTEM_EVENT_SHUTDOWN);
*exit = true;
break;
case SBI_EXT_0_1_REMOTE_FENCE_I:
diff --git a/arch/riscv/kvm/vcpu_sbi_replace.c 
b/arch/riscv/kvm/vcpu_sbi_replace.c
index dffb1930cada..7504e36ededb 100644
--- a/arch/riscv/kvm/vcpu_sbi_replace.c
+++ b/arch/riscv/kvm/vcpu_sbi_replace.c
@@ -134,3 +134,47 @@ const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_rfence = {
.extid_end = SBI_EXT_RFENCE,
.handler = kvm_sbi_ext_rfence_handler,
 };
+
+static int kvm_sbi_ext_srst_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
+ unsigned long *out_val,
+ struct kvm_cpu_trap *utrap, bool *exit)
+{
+   int ret = 0;
+   struct kvm_cpu_context *cp = >arch.guest_context;
+   unsigned long reset_type = cp->a0;
+   unsigned long reset_reason = cp->a1;
+   unsigned long funcid = cp->a6;
+
+   if (!cp)
+   return -EINVAL;
+
+   if u32)-1U) <= ((u64)reset_type)) ||
+   (((u32)-1U) <= ((u64)reset_reason)))
+   return -EINVAL;
+
+   if ((funcid != SBI_EXT_SRST_RESET) ||
+   (reset_reason > SBI_SRST_RESET_REASON_SYS_FAILURE))
+   ret = -EOPNOTSUPP;
+
+

[PATCH v2 5/6] RISC-V: Add SBI HSM extension in KVM

2021-02-03 Thread Atish Patra
SBI HSM extension allows OS to start/stop harts any time. It also allows
ordered booting of harts instead of random booting.

Implement SBI HSM exntesion and designate the vcpu 0 as the boot vcpu id.
All other non-zero non-booting vcpus should be brought up by the OS
implementing HSM extension. If the guest OS doesn't implement HSM
extension, only single vcpu will be available to OS.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/sbi.h  |   1 +
 arch/riscv/kvm/Makefile   |   2 +-
 arch/riscv/kvm/vcpu.c |  19 ++
 arch/riscv/kvm/vcpu_sbi.c |   4 ++
 arch/riscv/kvm/vcpu_sbi_hsm.c | 109 ++
 5 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 arch/riscv/kvm/vcpu_sbi_hsm.c

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 4a405f583d32..881e89078785 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -106,6 +106,7 @@ enum sbi_srst_reset_reason {
 #define SBI_ERR_INVALID_PARAM  -3
 #define SBI_ERR_DENIED -4
 #define SBI_ERR_INVALID_ADDRESS-5
+#define SBI_ERR_ALREADY_AVAILABLE -6
 
 extern unsigned long sbi_spec_version;
 struct sbiret {
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 302501295397..5627c9c7f249 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm/Makefile
@@ -11,5 +11,5 @@ kvm-objs := $(common-objs-y)
 
 kvm-objs += main.o vm.o vmid.o tlb.o mmu.o
 kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o
-kvm-objs += vcpu_sbi.o vcpu_sbi_base.o vcpu_sbi_legacy.o vcpu_sbi_replace.o
+kvm-objs += vcpu_sbi.o vcpu_sbi_base.o vcpu_sbi_legacy.o vcpu_sbi_replace.o 
vcpu_sbi_hsm.o
 obj-$(CONFIG_KVM)  += kvm.o
diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
index bcc4af9d2fa9..99f94ab27cea 100644
--- a/arch/riscv/kvm/vcpu.c
+++ b/arch/riscv/kvm/vcpu.c
@@ -130,6 +130,13 @@ static void kvm_riscv_reset_vcpu(struct kvm_vcpu *vcpu)
struct kvm_vcpu_csr *reset_csr = >arch.guest_reset_csr;
struct kvm_cpu_context *cntx = >arch.guest_context;
struct kvm_cpu_context *reset_cntx = >arch.guest_reset_context;
+   bool loaded;
+
+   /* Disable preemption to avoid race with preempt notifiers */
+   preempt_disable();
+   loaded = (vcpu->cpu != -1);
+   if (loaded)
+   kvm_arch_vcpu_put(vcpu);
 
memcpy(csr, reset_csr, sizeof(*csr));
 
@@ -141,6 +148,11 @@ static void kvm_riscv_reset_vcpu(struct kvm_vcpu *vcpu)
 
WRITE_ONCE(vcpu->arch.irqs_pending, 0);
WRITE_ONCE(vcpu->arch.irqs_pending_mask, 0);
+
+   /* Reset the guest CSRs for hotplug usecase */
+   if (loaded)
+   kvm_arch_vcpu_load(vcpu, smp_processor_id());
+   preempt_enable();
 }
 
 int kvm_arch_vcpu_precreate(struct kvm *kvm, unsigned int id)
@@ -182,6 +194,13 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 
 void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
 {
+   /**
+* vcpu with id 0 is the designated boot cpu.
+* Keep all vcpus with non-zero cpu id in power-off state so that they
+* can brought to online using SBI HSM extension.
+*/
+   if (vcpu->vcpu_idx != 0)
+   kvm_riscv_vcpu_power_off(vcpu);
 }
 
 void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
diff --git a/arch/riscv/kvm/vcpu_sbi.c b/arch/riscv/kvm/vcpu_sbi.c
index e21ce1e69e03..20ef59ed83a6 100644
--- a/arch/riscv/kvm/vcpu_sbi.c
+++ b/arch/riscv/kvm/vcpu_sbi.c
@@ -25,6 +25,8 @@ static int kvm_linux_err_map_sbi(int err)
return SBI_ERR_INVALID_ADDRESS;
case -EOPNOTSUPP:
return SBI_ERR_NOT_SUPPORTED;
+   case -EALREADY:
+   return SBI_ERR_ALREADY_AVAILABLE;
default:
return SBI_ERR_FAILURE;
};
@@ -35,6 +37,7 @@ extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_base;
 extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_time;
 extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_ipi;
 extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_rfence;
+extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_hsm;
 
 static const struct kvm_vcpu_sbi_extension *sbi_ext[] = {
_sbi_ext_legacy,
@@ -42,6 +45,7 @@ static const struct kvm_vcpu_sbi_extension *sbi_ext[] = {
_sbi_ext_time,
_sbi_ext_ipi,
_sbi_ext_rfence,
+   _sbi_ext_hsm,
 };
 
 void kvm_riscv_vcpu_sbi_forward(struct kvm_vcpu *vcpu, struct kvm_run *run)
diff --git a/arch/riscv/kvm/vcpu_sbi_hsm.c b/arch/riscv/kvm/vcpu_sbi_hsm.c
new file mode 100644
index ..ce6cfe125559
--- /dev/null
+++ b/arch/riscv/kvm/vcpu_sbi_hsm.c
@@ -0,0 +1,109 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Copyright (c) 2020 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Atish Patra 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int kvm_sbi_hsm_vcpu_start(struct kvm_vcpu *vcpu)
+{
+   struct kvm_cp

[PATCH v2 3/6] RISC-V: Add SBI v0.2 base extension

2021-02-03 Thread Atish Patra
SBI v0.2 base extension defined to allow backward compatibility and
probing of future extensions. This is also the only mandatory SBI
extension that must be implemented by SBI implementors.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/kvm_vcpu_sbi.h |  2 +
 arch/riscv/include/asm/sbi.h  |  8 +++
 arch/riscv/kvm/Makefile   |  4 +-
 arch/riscv/kvm/vcpu_sbi.c |  3 ++
 arch/riscv/kvm/vcpu_sbi_base.c| 73 +++
 5 files changed, 88 insertions(+), 2 deletions(-)
 create mode 100644 arch/riscv/kvm/vcpu_sbi_base.c

diff --git a/arch/riscv/include/asm/kvm_vcpu_sbi.h 
b/arch/riscv/include/asm/kvm_vcpu_sbi.h
index 743c71f0c331..e208c8ac57fe 100644
--- a/arch/riscv/include/asm/kvm_vcpu_sbi.h
+++ b/arch/riscv/include/asm/kvm_vcpu_sbi.h
@@ -9,6 +9,8 @@
 #ifndef __RISCV_KVM_VCPU_SBI_H__
 #define __RISCV_KVM_VCPU_SBI_H__
 
+#define KVM_SBI_IMPID 3
+
 #define KVM_SBI_VERSION_MAJOR 0
 #define KVM_SBI_VERSION_MINOR 2
 
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 3e7141a7d11f..4a405f583d32 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -28,6 +28,14 @@ enum sbi_ext_id {
SBI_EXT_RFENCE = 0x52464E43,
SBI_EXT_HSM = 0x48534D,
SBI_EXT_SRST = 0x53525354,
+
+   /* Experimentals extensions must lie within this range */
+   SBI_EXT_EXPERIMENTAL_START = 0x080,
+   SBI_EXT_EXPERIMENTAL_END = 0x08FF,
+
+   /* Vendor extensions must lie within this range */
+   SBI_EXT_VENDOR_START = 0x0900,
+   SBI_EXT_VENDOR_END = 0x09FF,
 };
 
 enum sbi_ext_base_fid {
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 1ba4afe112f1..0f17dffe8d46 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm/Makefile
@@ -10,6 +10,6 @@ ccflags-y := -Ivirt/kvm -Iarch/riscv/kvm
 kvm-objs := $(common-objs-y)
 
 kvm-objs += main.o vm.o vmid.o tlb.o mmu.o
-kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o vcpu_sbi.o 
vcpu_sbi_legacy.o
-
+kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o
+kvm-objs += vcpu_sbi.o vcpu_sbi_base.o vcpu_sbi_legacy.o
 obj-$(CONFIG_KVM)  += kvm.o
diff --git a/arch/riscv/kvm/vcpu_sbi.c b/arch/riscv/kvm/vcpu_sbi.c
index 29eecf8cbdc3..c85c3b1dd2eb 100644
--- a/arch/riscv/kvm/vcpu_sbi.c
+++ b/arch/riscv/kvm/vcpu_sbi.c
@@ -31,8 +31,11 @@ static int kvm_linux_err_map_sbi(int err)
 }
 
 extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_legacy;
+extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_base;
+
 static const struct kvm_vcpu_sbi_extension *sbi_ext[] = {
_sbi_ext_legacy,
+   _sbi_ext_base,
 };
 
 void kvm_riscv_vcpu_sbi_forward(struct kvm_vcpu *vcpu, struct kvm_run *run)
diff --git a/arch/riscv/kvm/vcpu_sbi_base.c b/arch/riscv/kvm/vcpu_sbi_base.c
new file mode 100644
index ..48f1164f189c
--- /dev/null
+++ b/arch/riscv/kvm/vcpu_sbi_base.c
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Copyright (c) 2020 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Atish Patra 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int kvm_sbi_ext_base_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
+   unsigned long *out_val,
+   struct kvm_cpu_trap *trap, bool *exit)
+{
+   int ret = 0;
+   struct kvm_cpu_context *cp = >arch.guest_context;
+   struct sbiret ecall_ret;
+
+   if (!cp)
+   return -EINVAL;
+
+   switch (cp->a6) {
+   case SBI_EXT_BASE_GET_SPEC_VERSION:
+   *out_val = (KVM_SBI_VERSION_MAJOR <<
+   SBI_SPEC_VERSION_MAJOR_SHIFT) |
+   KVM_SBI_VERSION_MINOR;
+   break;
+   case SBI_EXT_BASE_GET_IMP_ID:
+   *out_val = KVM_SBI_IMPID;
+   break;
+   case SBI_EXT_BASE_GET_IMP_VERSION:
+   *out_val = 0;
+   break;
+   case SBI_EXT_BASE_PROBE_EXT:
+   *out_val = kvm_vcpu_sbi_find_ext(cp->a0) ? 1 : 0;
+   if ((!*out_val) &&
+   ((cp->a0 >= SBI_EXT_EXPERIMENTAL_START &&
+cp->a0 <= SBI_EXT_EXPERIMENTAL_END) ||
+   ((cp->a0 >= SBI_EXT_VENDOR_START &&
+cp->a0 <= SBI_EXT_VENDOR_END {
+   /* For experimental/vendor extensions forward to the userspace*/
+   kvm_riscv_vcpu_sbi_forward(vcpu, run);
+   *exit = true;
+   }
+   break;
+   case SBI_EXT_BASE_GET_MVENDORID:
+   case SBI_EXT_BASE_GET_MARCHID:
+   case SBI_EXT_BASE_GET_MIMPID:
+   ecall_ret = sbi_ecall(SBI_EXT_BASE, cp->a6, 0, 0, 0, 0, 0, 0);
+   if (!ecall_ret.error)
+   *out_val = ecall_ret.value;
+   /*TODO: We a

[PATCH v2 2/6] RISC-V: Reorganize SBI code by moving legacy SBI to its own file

2021-02-03 Thread Atish Patra
With SBI v0.2, there may be more SBI extensions in future. It makes more
sense to group related extensions in separate files. Guest kernel will
choose appropriate SBI version dynamically.

Move the existing implementation to a separate file so that it can be
removed in future without much conflict.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/kvm_vcpu_sbi.h |   1 +
 arch/riscv/kvm/Makefile   |   2 +-
 arch/riscv/kvm/vcpu_sbi.c | 126 +
 arch/riscv/kvm/vcpu_sbi_legacy.c  | 129 ++
 4 files changed, 136 insertions(+), 122 deletions(-)
 create mode 100644 arch/riscv/kvm/vcpu_sbi_legacy.c

diff --git a/arch/riscv/include/asm/kvm_vcpu_sbi.h 
b/arch/riscv/include/asm/kvm_vcpu_sbi.h
index 5b3523a01bce..743c71f0c331 100644
--- a/arch/riscv/include/asm/kvm_vcpu_sbi.h
+++ b/arch/riscv/include/asm/kvm_vcpu_sbi.h
@@ -25,5 +25,6 @@ struct kvm_vcpu_sbi_extension {
   bool *exit);
 };
 
+void kvm_riscv_vcpu_sbi_forward(struct kvm_vcpu *vcpu, struct kvm_run *run);
 const struct kvm_vcpu_sbi_extension *kvm_vcpu_sbi_find_ext(unsigned long 
extid);
 #endif /* __RISCV_KVM_VCPU_SBI_H__ */
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 7cf0015d9142..1ba4afe112f1 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm/Makefile
@@ -10,6 +10,6 @@ ccflags-y := -Ivirt/kvm -Iarch/riscv/kvm
 kvm-objs := $(common-objs-y)
 
 kvm-objs += main.o vm.o vmid.o tlb.o mmu.o
-kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o vcpu_sbi.o
+kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o vcpu_sbi.o 
vcpu_sbi_legacy.o
 
 obj-$(CONFIG_KVM)  += kvm.o
diff --git a/arch/riscv/kvm/vcpu_sbi.c b/arch/riscv/kvm/vcpu_sbi.c
index a96ed3e3a9a3..29eecf8cbdc3 100644
--- a/arch/riscv/kvm/vcpu_sbi.c
+++ b/arch/riscv/kvm/vcpu_sbi.c
@@ -9,9 +9,7 @@
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 
 static int kvm_linux_err_map_sbi(int err)
@@ -32,23 +30,12 @@ static int kvm_linux_err_map_sbi(int err)
};
 }
 
-static void kvm_sbi_system_shutdown(struct kvm_vcpu *vcpu,
-   struct kvm_run *run, u32 type)
-{
-   int i;
-   struct kvm_vcpu *tmp;
-
-   kvm_for_each_vcpu(i, tmp, vcpu->kvm)
-   tmp->arch.power_off = true;
-   kvm_make_all_cpus_request(vcpu->kvm, KVM_REQ_SLEEP);
-
-   memset(>system_event, 0, sizeof(run->system_event));
-   run->system_event.type = type;
-   run->exit_reason = KVM_EXIT_SYSTEM_EVENT;
-}
+extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_legacy;
+static const struct kvm_vcpu_sbi_extension *sbi_ext[] = {
+   _sbi_ext_legacy,
+};
 
-static void kvm_riscv_vcpu_sbi_forward(struct kvm_vcpu *vcpu,
-  struct kvm_run *run)
+void kvm_riscv_vcpu_sbi_forward(struct kvm_vcpu *vcpu, struct kvm_run *run)
 {
struct kvm_cpu_context *cp = >arch.guest_context;
 
@@ -86,109 +73,6 @@ int kvm_riscv_vcpu_sbi_return(struct kvm_vcpu *vcpu, struct 
kvm_run *run)
return 0;
 }
 
-static int kvm_sbi_ext_legacy_handler(struct kvm_vcpu *vcpu, struct kvm_run 
*run,
- unsigned long *out_val,
- struct kvm_cpu_trap *utrap,
- bool *exit)
-{
-   ulong hmask;
-   int i, ret = 0;
-   u64 next_cycle;
-   struct kvm_vcpu *rvcpu;
-   struct cpumask cm, hm;
-   struct kvm *kvm = vcpu->kvm;
-   struct kvm_cpu_context *cp = >arch.guest_context;
-
-   if (!cp)
-   return -EINVAL;
-
-   switch (cp->a7) {
-   case SBI_EXT_0_1_CONSOLE_GETCHAR:
-   case SBI_EXT_0_1_CONSOLE_PUTCHAR:
-   /*
-* The CONSOLE_GETCHAR/CONSOLE_PUTCHAR SBI calls cannot be
-* handled in kernel so we forward these to user-space
-*/
-   kvm_riscv_vcpu_sbi_forward(vcpu, run);
-   *exit = true;
-   break;
-   case SBI_EXT_0_1_SET_TIMER:
-#if __riscv_xlen == 32
-   next_cycle = ((u64)cp->a1 << 32) | (u64)cp->a0;
-#else
-   next_cycle = (u64)cp->a0;
-#endif
-   ret = kvm_riscv_vcpu_timer_next_event(vcpu, next_cycle);
-   break;
-   case SBI_EXT_0_1_CLEAR_IPI:
-   ret = kvm_riscv_vcpu_unset_interrupt(vcpu, IRQ_VS_SOFT);
-   break;
-   case SBI_EXT_0_1_SEND_IPI:
-   if (cp->a0)
-   hmask = kvm_riscv_vcpu_unpriv_read(vcpu, false, cp->a0,
-  utrap);
-   else
-   hmask = (1UL << atomic_read(>online_vcpus)) - 1;
-   if (utrap->scause)
-   break;
-
-   for_each_set_bit(i, , BITS_PER_LONG) {
-   rvcpu = kvm_get_vcpu_by_id(vcpu-&g

[PATCH v2 4/6] RISC-V: Add v0.1 replacement SBI extensions defined in v02

2021-02-03 Thread Atish Patra
The SBI v0.2 contains some of the improved versions of required v0.1
extensions such as remote fence, timer and IPI.

This patch implements those extensions.

Signed-off-by: Atish Patra 
---
 arch/riscv/kvm/Makefile   |   2 +-
 arch/riscv/kvm/vcpu_sbi.c |   6 ++
 arch/riscv/kvm/vcpu_sbi_replace.c | 136 ++
 3 files changed, 143 insertions(+), 1 deletion(-)
 create mode 100644 arch/riscv/kvm/vcpu_sbi_replace.c

diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 0f17dffe8d46..302501295397 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm/Makefile
@@ -11,5 +11,5 @@ kvm-objs := $(common-objs-y)
 
 kvm-objs += main.o vm.o vmid.o tlb.o mmu.o
 kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o
-kvm-objs += vcpu_sbi.o vcpu_sbi_base.o vcpu_sbi_legacy.o
+kvm-objs += vcpu_sbi.o vcpu_sbi_base.o vcpu_sbi_legacy.o vcpu_sbi_replace.o
 obj-$(CONFIG_KVM)  += kvm.o
diff --git a/arch/riscv/kvm/vcpu_sbi.c b/arch/riscv/kvm/vcpu_sbi.c
index c85c3b1dd2eb..e21ce1e69e03 100644
--- a/arch/riscv/kvm/vcpu_sbi.c
+++ b/arch/riscv/kvm/vcpu_sbi.c
@@ -32,10 +32,16 @@ static int kvm_linux_err_map_sbi(int err)
 
 extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_legacy;
 extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_base;
+extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_time;
+extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_ipi;
+extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_rfence;
 
 static const struct kvm_vcpu_sbi_extension *sbi_ext[] = {
_sbi_ext_legacy,
_sbi_ext_base,
+   _sbi_ext_time,
+   _sbi_ext_ipi,
+   _sbi_ext_rfence,
 };
 
 void kvm_riscv_vcpu_sbi_forward(struct kvm_vcpu *vcpu, struct kvm_run *run)
diff --git a/arch/riscv/kvm/vcpu_sbi_replace.c 
b/arch/riscv/kvm/vcpu_sbi_replace.c
new file mode 100644
index ..dffb1930cada
--- /dev/null
+++ b/arch/riscv/kvm/vcpu_sbi_replace.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Copyright (c) 2020 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Atish Patra 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int kvm_sbi_ext_time_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
+   unsigned long *out_val,
+   struct kvm_cpu_trap *utrap, bool *exit)
+{
+   int ret = 0;
+   struct kvm_cpu_context *cp = >arch.guest_context;
+   u64 next_cycle;
+
+   if (!cp || (cp->a6 != SBI_EXT_TIME_SET_TIMER))
+   return -EINVAL;
+
+#if __riscv_xlen == 32
+   next_cycle = ((u64)cp->a1 << 32) | (u64)cp->a0;
+#else
+   next_cycle = (u64)cp->a0;
+#endif
+   kvm_riscv_vcpu_timer_next_event(vcpu, next_cycle);
+
+   return ret;
+}
+
+const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_time = {
+   .extid_start = SBI_EXT_TIME,
+   .extid_end = SBI_EXT_TIME,
+   .handler = kvm_sbi_ext_time_handler,
+};
+
+static int kvm_sbi_ext_ipi_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
+  unsigned long *out_val,
+  struct kvm_cpu_trap *utrap, bool *exit)
+{
+   int i, ret = 0;
+   struct kvm_vcpu *tmp;
+   struct kvm_cpu_context *cp = >arch.guest_context;
+   unsigned long hmask = cp->a0;
+   unsigned long hbase = cp->a1;
+
+   if (!cp || (cp->a6 != SBI_EXT_IPI_SEND_IPI))
+   return -EINVAL;
+
+   kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
+   if (hbase != -1UL) {
+   if (tmp->vcpu_id < hbase)
+   continue;
+   if (!(hmask & (1UL << (tmp->vcpu_id - hbase
+   continue;
+   }
+   ret = kvm_riscv_vcpu_set_interrupt(tmp, IRQ_VS_SOFT);
+   if (ret < 0)
+   break;
+   }
+
+   return ret;
+}
+
+const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_ipi = {
+   .extid_start = SBI_EXT_IPI,
+   .extid_end = SBI_EXT_IPI,
+   .handler = kvm_sbi_ext_ipi_handler,
+};
+
+static int kvm_sbi_ext_rfence_handler(struct kvm_vcpu *vcpu, struct kvm_run 
*run,
+ unsigned long *out_val,
+ struct kvm_cpu_trap *utrap, bool *exit)
+{
+   int i, ret = 0;
+   struct cpumask cm, hm;
+   struct kvm_vcpu *tmp;
+   struct kvm_cpu_context *cp = >arch.guest_context;
+   unsigned long hmask = cp->a0;
+   unsigned long hbase = cp->a1;
+   unsigned long funcid = cp->a6;
+
+   if (!cp)
+   return -EINVAL;
+
+   cpumask_clear();
+   cpumask_clear();
+   kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
+   if (hbase != -1UL) {
+   if (tmp->vcpu_id < hbase)
+ 

[PATCH v2 0/6] Add SBI v0.2 support for KVM

2021-02-03 Thread Atish Patra
The Supervisor Binary Interface(SBI) specification[1] now defines a
base extension that provides extendability to add future extensions
while maintaining backward compatibility with previous versions.
The new version is defined as 0.2 and older version is marked as 0.1.

This series adds following features to RISC-V Linux KVM.
1. Adds support for SBI v0.2 in KVM
2. SBI Hart state management extension (HSM) in KVM
3. Ordered booting of guest vcpus in guest Linux
4. SBI Reset extension in KVM

This series depends on the base kvm support series v16[2].

Guest kernel needs to also support SBI v0.2 and HSM extension in Kernel
to boot multiple vcpus. Linux kernel supports both starting v5.7.
In absense of that, guest can only boot 1 vcpu.

Changes from v1->v2:
1. Sent the patch 1 separately as it can merged independently.
2. Added Reset extension functionality.

Tested on Qemu and FPGA with Rocket core design.

[1] https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
[2] http://lists.infradead.org/pipermail/linux-riscv/2021-January/004251.html

Atish Patra (6):
RISC-V: Mark the existing SBI v0.1 implementation as legacy
RISC-V: Reorganize SBI code by moving legacy SBI to its own file
RISC-V: Add SBI v0.2 base extension
RISC-V: Add v0.1 replacement SBI extensions defined in v02
RISC-V: Add SBI HSM extension in KVM
RISC-V: Add SBI RESET extension in KVM

arch/riscv/include/asm/kvm_vcpu_sbi.h |  33 +
arch/riscv/include/asm/sbi.h  |   9 ++
arch/riscv/kvm/Makefile   |   4 +-
arch/riscv/kvm/vcpu.c |  19 +++
arch/riscv/kvm/vcpu_sbi.c | 189 +-
arch/riscv/kvm/vcpu_sbi_base.c|  73 ++
arch/riscv/kvm/vcpu_sbi_hsm.c | 109 +++
arch/riscv/kvm/vcpu_sbi_legacy.c  | 114 
arch/riscv/kvm/vcpu_sbi_replace.c | 180 
9 files changed, 635 insertions(+), 95 deletions(-)
create mode 100644 arch/riscv/include/asm/kvm_vcpu_sbi.h
create mode 100644 arch/riscv/kvm/vcpu_sbi_base.c
create mode 100644 arch/riscv/kvm/vcpu_sbi_hsm.c
create mode 100644 arch/riscv/kvm/vcpu_sbi_legacy.c
create mode 100644 arch/riscv/kvm/vcpu_sbi_replace.c

--
2.25.1



[PATCH v2 1/6] RISC-V: Mark the existing SBI v0.1 implementation as legacy

2021-02-03 Thread Atish Patra
The existing SBI specification impelementation follows v0.1 or legacy
specification. The latest specification known as v0.2 allows more
scalability and performance improvements.

Rename the existing implementation as legacy and provide a way to allow
future extensions.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/kvm_vcpu_sbi.h |  29 +
 arch/riscv/kvm/vcpu_sbi.c | 149 --
 2 files changed, 148 insertions(+), 30 deletions(-)
 create mode 100644 arch/riscv/include/asm/kvm_vcpu_sbi.h

diff --git a/arch/riscv/include/asm/kvm_vcpu_sbi.h 
b/arch/riscv/include/asm/kvm_vcpu_sbi.h
new file mode 100644
index ..5b3523a01bce
--- /dev/null
+++ b/arch/riscv/include/asm/kvm_vcpu_sbi.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/**
+ * Copyright (c) 2020 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Atish Patra 
+ */
+
+#ifndef __RISCV_KVM_VCPU_SBI_H__
+#define __RISCV_KVM_VCPU_SBI_H__
+
+#define KVM_SBI_VERSION_MAJOR 0
+#define KVM_SBI_VERSION_MINOR 2
+
+struct kvm_vcpu_sbi_extension {
+   unsigned long extid_start;
+   unsigned long extid_end;
+   /**
+* SBI extension handler. It can be defined for a given extension or 
group of
+* extension. But it should always return linux error codes rather than 
SBI
+* specific error codes.
+*/
+   int (*handler)(struct kvm_vcpu *vcpu, struct kvm_run *run,
+  unsigned long *out_val, struct kvm_cpu_trap *utrap,
+  bool *exit);
+};
+
+const struct kvm_vcpu_sbi_extension *kvm_vcpu_sbi_find_ext(unsigned long 
extid);
+#endif /* __RISCV_KVM_VCPU_SBI_H__ */
diff --git a/arch/riscv/kvm/vcpu_sbi.c b/arch/riscv/kvm/vcpu_sbi.c
index 9d1d25cf217f..a96ed3e3a9a3 100644
--- a/arch/riscv/kvm/vcpu_sbi.c
+++ b/arch/riscv/kvm/vcpu_sbi.c
@@ -12,9 +12,25 @@
 #include 
 #include 
 #include 
+#include 
 
-#define SBI_VERSION_MAJOR  0
-#define SBI_VERSION_MINOR  1
+static int kvm_linux_err_map_sbi(int err)
+{
+   switch (err) {
+   case 0:
+   return SBI_SUCCESS;
+   case -EPERM:
+   return SBI_ERR_DENIED;
+   case -EINVAL:
+   return SBI_ERR_INVALID_PARAM;
+   case -EFAULT:
+   return SBI_ERR_INVALID_ADDRESS;
+   case -EOPNOTSUPP:
+   return SBI_ERR_NOT_SUPPORTED;
+   default:
+   return SBI_ERR_FAILURE;
+   };
+}
 
 static void kvm_sbi_system_shutdown(struct kvm_vcpu *vcpu,
struct kvm_run *run, u32 type)
@@ -70,16 +86,17 @@ int kvm_riscv_vcpu_sbi_return(struct kvm_vcpu *vcpu, struct 
kvm_run *run)
return 0;
 }
 
-int kvm_riscv_vcpu_sbi_ecall(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static int kvm_sbi_ext_legacy_handler(struct kvm_vcpu *vcpu, struct kvm_run 
*run,
+ unsigned long *out_val,
+ struct kvm_cpu_trap *utrap,
+ bool *exit)
 {
ulong hmask;
-   int i, ret = 1;
+   int i, ret = 0;
u64 next_cycle;
struct kvm_vcpu *rvcpu;
-   bool next_sepc = true;
struct cpumask cm, hm;
struct kvm *kvm = vcpu->kvm;
-   struct kvm_cpu_trap utrap = { 0 };
struct kvm_cpu_context *cp = >arch.guest_context;
 
if (!cp)
@@ -93,8 +110,7 @@ int kvm_riscv_vcpu_sbi_ecall(struct kvm_vcpu *vcpu, struct 
kvm_run *run)
 * handled in kernel so we forward these to user-space
 */
kvm_riscv_vcpu_sbi_forward(vcpu, run);
-   next_sepc = false;
-   ret = 0;
+   *exit = true;
break;
case SBI_EXT_0_1_SET_TIMER:
 #if __riscv_xlen == 32
@@ -102,47 +118,42 @@ int kvm_riscv_vcpu_sbi_ecall(struct kvm_vcpu *vcpu, 
struct kvm_run *run)
 #else
next_cycle = (u64)cp->a0;
 #endif
-   kvm_riscv_vcpu_timer_next_event(vcpu, next_cycle);
+   ret = kvm_riscv_vcpu_timer_next_event(vcpu, next_cycle);
break;
case SBI_EXT_0_1_CLEAR_IPI:
-   kvm_riscv_vcpu_unset_interrupt(vcpu, IRQ_VS_SOFT);
+   ret = kvm_riscv_vcpu_unset_interrupt(vcpu, IRQ_VS_SOFT);
break;
case SBI_EXT_0_1_SEND_IPI:
if (cp->a0)
hmask = kvm_riscv_vcpu_unpriv_read(vcpu, false, cp->a0,
-  );
+  utrap);
else
hmask = (1UL << atomic_read(>online_vcpus)) - 1;
-   if (utrap.scause) {
-   utrap.sepc = cp->sepc;
-   kvm_riscv_vcpu_trap_redirect(vcpu, );
-   next_sepc = false;
+   if (utrap->scause)

[PATCH] RISC-V: Add a non-void return for sbi v02 functions

2021-02-03 Thread Atish Patra
SBI v0.2 functions can return an error code from SBI implementation.
We are already processing the SBI error code and coverts it to the Linux
error code.

Propagate to the error code to the caller as well. As of now, kvm is the
only user of these error codes.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/sbi.h | 10 +-
 arch/riscv/kernel/sbi.c  | 32 
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 1b26ec8e6a15..3e7141a7d11f 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -116,13 +116,13 @@ int sbi_console_getchar(void);
 void sbi_set_timer(uint64_t stime_value);
 void sbi_shutdown(void);
 void sbi_clear_ipi(void);
-void sbi_send_ipi(const unsigned long *hart_mask);
-void sbi_remote_fence_i(const unsigned long *hart_mask);
-void sbi_remote_sfence_vma(const unsigned long *hart_mask,
+int sbi_send_ipi(const unsigned long *hart_mask);
+int sbi_remote_fence_i(const unsigned long *hart_mask);
+int sbi_remote_sfence_vma(const unsigned long *hart_mask,
   unsigned long start,
   unsigned long size);
 
-void sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
+int sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
unsigned long start,
unsigned long size,
unsigned long asid);
@@ -163,7 +163,7 @@ static inline unsigned long sbi_minor_version(void)
 
 int sbi_err_map_linux_errno(int err);
 #else /* CONFIG_RISCV_SBI */
-static inline void sbi_remote_fence_i(const unsigned long *hart_mask) {}
+static inline int sbi_remote_fence_i(const unsigned long *hart_mask) {}
 static inline void sbi_init(void) {}
 #endif /* CONFIG_RISCV_SBI */
 #endif /* _ASM_RISCV_SBI_H */
diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
index 8d60b2ebcad3..f904af48635d 100644
--- a/arch/riscv/kernel/sbi.c
+++ b/arch/riscv/kernel/sbi.c
@@ -352,7 +352,7 @@ static int __sbi_rfence_v02(int fid, const unsigned long 
*hart_mask,
  * sbi_set_timer() - Program the timer for next timer event.
  * @stime_value: The value after which next timer event should fire.
  *
- * Return: None
+ * Return: None.
  */
 void sbi_set_timer(uint64_t stime_value)
 {
@@ -363,11 +363,11 @@ void sbi_set_timer(uint64_t stime_value)
  * sbi_send_ipi() - Send an IPI to any hart.
  * @hart_mask: A cpu mask containing all the target harts.
  *
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
  */
-void sbi_send_ipi(const unsigned long *hart_mask)
+int sbi_send_ipi(const unsigned long *hart_mask)
 {
-   __sbi_send_ipi(hart_mask);
+   return __sbi_send_ipi(hart_mask);
 }
 EXPORT_SYMBOL(sbi_send_ipi);
 
@@ -375,12 +375,12 @@ EXPORT_SYMBOL(sbi_send_ipi);
  * sbi_remote_fence_i() - Execute FENCE.I instruction on given remote harts.
  * @hart_mask: A cpu mask containing all the target harts.
  *
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
  */
-void sbi_remote_fence_i(const unsigned long *hart_mask)
+int sbi_remote_fence_i(const unsigned long *hart_mask)
 {
-   __sbi_rfence(SBI_EXT_RFENCE_REMOTE_FENCE_I,
-hart_mask, 0, 0, 0, 0);
+   return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_FENCE_I,
+   hart_mask, 0, 0, 0, 0);
 }
 EXPORT_SYMBOL(sbi_remote_fence_i);
 
@@ -391,14 +391,14 @@ EXPORT_SYMBOL(sbi_remote_fence_i);
  * @start: Start of the virtual address
  * @size: Total size of the virtual address range.
  *
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
  */
-void sbi_remote_sfence_vma(const unsigned long *hart_mask,
+int sbi_remote_sfence_vma(const unsigned long *hart_mask,
   unsigned long start,
   unsigned long size)
 {
-   __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
-hart_mask, start, size, 0, 0);
+   return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
+   hart_mask, start, size, 0, 0);
 }
 EXPORT_SYMBOL(sbi_remote_sfence_vma);
 
@@ -411,15 +411,15 @@ EXPORT_SYMBOL(sbi_remote_sfence_vma);
  * @size: Total size of the virtual address range.
  * @asid: The value of address space identifier (ASID).
  *
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
  */
-void sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
+int sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
unsigned long start,
unsigned long size,
unsigned long asid)
 {
-   __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
-hart_mask, start, size, asid, 0);
+   return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID

Re: [PATCH -next] RISCV: Add some depends for NUMA

2021-02-03 Thread Atish Patra
On Wed, Feb 3, 2021 at 6:20 AM Kefeng Wang  wrote:
>
> The numa feature is useless for riscv32 platform(MAXPHYSMEM_1GB if 32bit),
> and it should depends on SMP feature, this also fix the build error,
>
>   riscv64-buildroot-linux-gnu-ld: mm/page_alloc.o: in function `.L0 ':
>   page_alloc.c:(.text+0x4808): undefined reference to `node_reclaim_distance'
>

Thanks for the fix. The commit text is a bit ambiguous. The
compilation issue error is due to SMP.
RV32 dependency is just another fix  as NUMA is not very useful for RV32.

> Fixes: 4f0e8eef772e ("riscv: Add numa support for riscv64 platform")
> Signed-off-by: Kefeng Wang 
> ---
>  arch/riscv/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 22fa17898d29..ac7f5801bd82 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -312,6 +312,8 @@ endchoice
>  # Common NUMA Features
>  config NUMA
> bool "NUMA Memory Allocation and Scheduler Support"
> +   depends on SMP
> +   depends on 64BIT
> select GENERIC_ARCH_NUMA
> select OF_NUMA
> select ARCH_SUPPORTS_NUMA_BALANCING
> --
> 2.26.2
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra 
-- 
Regards,
Atish


Re: [PATCH] riscv: virt_addr_valid must check the address belongs to linear mapping

2021-01-29 Thread Atish Patra
On Fri, Jan 29, 2021 at 9:31 AM Alexandre Ghiti  wrote:
>
> 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 
> ---
>  arch/riscv/include/asm/page.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
> index 2d50f76efe48..64a675c5c30a 100644
> --- a/arch/riscv/include/asm/page.h
> +++ b/arch/riscv/include/asm/page.h
> @@ -135,7 +135,10 @@ extern phys_addr_t __phys_addr_symbol(unsigned long x);
>
>  #endif /* __ASSEMBLY__ */
>
> -#define virt_addr_valid(vaddr) (pfn_valid(virt_to_pfn(vaddr)))
> +#define virt_addr_valid(vaddr) ({
>   \
> +   unsigned long _addr = (unsigned long)vaddr;   
>   \
> +   (unsigned long)(_addr) >= PAGE_OFFSET && 
> pfn_valid(virt_to_pfn(_addr)); \
> +})
>
>  #define VM_DATA_DEFAULT_FLAGS  VM_DATA_FLAGS_NON_EXEC
>
> --
> 2.20.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra 

-- 
Regards,
Atish


[PATCH 2/3] riscv: Align on L1_CACHE_BYTES when STRICT_KERNEL_RWX

2021-01-29 Thread Atish Patra
From: Sebastien Van Cauwenberghe 

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 
---
 arch/riscv/include/asm/set_memory.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/include/asm/set_memory.h 
b/arch/riscv/include/asm/set_memory.h
index 211eb8244a45..8b80c80c7f1a 100644
--- a/arch/riscv/include/asm/set_memory.h
+++ b/arch/riscv/include/asm/set_memory.h
@@ -32,14 +32,14 @@ bool kernel_page_present(struct page *page);
 
 #endif /* __ASSEMBLY__ */
 
-#ifdef CONFIG_ARCH_HAS_STRICT_KERNEL_RWX
+#ifdef CONFIG_STRICT_KERNEL_RWX
 #ifdef CONFIG_64BIT
 #define SECTION_ALIGN (1 << 21)
 #else
 #define SECTION_ALIGN (1 << 22)
 #endif
-#else /* !CONFIG_ARCH_HAS_STRICT_KERNEL_RWX */
+#else /* !CONFIG_STRICT_KERNEL_RWX */
 #define SECTION_ALIGN L1_CACHE_BYTES
-#endif /* CONFIG_ARCH_HAS_STRICT_KERNEL_RWX */
+#endif /* CONFIG_STRICT_KERNEL_RWX */
 
 #endif /* _ASM_RISCV_SET_MEMORY_H */
-- 
2.25.1



[PATCH 3/3] RISC-V: Define MAXPHYSMEM_1GB only for RV32

2021-01-29 Thread Atish Patra
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

Fixes: e557793799c5 ("RISC-V: Fix maximum allowed phsyical memory for RV32")

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

Reported-by: Randy Dunlap 
Acked-by: Randy Dunlap 
Tested-by: Geert Uytterhoeven 
Signed-off-by: Atish Patra 
---
 arch/riscv/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index e9e2c1f0a690..e0a34eb5ed3b 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -252,8 +252,10 @@ choice
default MAXPHYSMEM_128GB if 64BIT && CMODEL_MEDANY
 
config MAXPHYSMEM_1GB
+   depends on 32BIT
bool "1GiB"
config MAXPHYSMEM_2GB
+   depends on 64BIT && CMODEL_MEDLOW
bool "2GiB"
config MAXPHYSMEM_128GB
depends on 64BIT && CMODEL_MEDANY
-- 
2.25.1



[PATCH 1/3] RISC-V: Fix .init section permission update

2021-01-29 Thread Atish Patra
.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")

Suggested-by: Geert Uytterhoeven 
Reported-by: Geert Uytterhoeven 
Signed-off-by: Atish Patra 
---
 arch/riscv/kernel/setup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 3fa3f26dde85..c7c0655dd45b 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -293,6 +293,8 @@ void free_initmem(void)
unsigned long init_begin = (unsigned long)__init_begin;
unsigned long init_end = (unsigned long)__init_end;
 
-   set_memory_rw_nx(init_begin, (init_end - init_begin) >> PAGE_SHIFT);
+   if (IS_ENABLED(CONFIG_STRICT_KERNEL_RWX))
+   set_memory_rw_nx(init_begin, (init_end - init_begin) >> 
PAGE_SHIFT);
+
free_initmem_default(POISON_FREE_INITMEM);
 }
-- 
2.25.1



Re: [PATCH] arch_numa: fix common code printing of phys_addr_t

2021-01-28 Thread Atish Patra
On Wed, 2021-01-27 at 19:55 -0800, Randy Dunlap wrote:
> Fix build warnings in the arch_numa common code:
> 
> ../include/linux/kern_levels.h:5:18: warning: format '%Lx' expects
> argument of type 'long long unsigned int', but argument 3 has type
> 'phys_addr_t' {aka 'unsigned int'} [-Wformat=]
> ../drivers/base/arch_numa.c:360:56: note: format string is defined
> here
>   360 |    pr_warn("Warning: invalid memblk node %d [mem %#010Lx-
> %#010Lx]\n",
> ../drivers/base/arch_numa.c:435:39: note: format string is defined
> here
>   435 |  pr_info("Faking a node at [mem %#018Lx-%#018Lx]\n", start,
> end - 1);
> 
> Fixes: ae3c107cd8be ("numa: Move numa implementation to common code")
> Signed-off-by: Randy Dunlap 
> Reported-by: kernel test robot 
> Cc: Atish Patra 
> Cc: Palmer Dabbelt 
> ---
>  drivers/base/arch_numa.c |   13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> --- linux-next-20210125.orig/drivers/base/arch_numa.c
> +++ linux-next-20210125/drivers/base/arch_numa.c
> @@ -355,11 +355,12 @@ static int __init numa_register_nodes(vo
> /* Check that valid nid is set to memblks */
> for_each_mem_region(mblk) {
> int mblk_nid = memblock_get_region_node(mblk);
> +   phys_addr_t start = mblk->base;
> +   phys_addr_t end = mblk->base + mblk->size - 1;
>  
> if (mblk_nid == NUMA_NO_NODE || mblk_nid >=
> MAX_NUMNODES) {
> -   pr_warn("Warning: invalid memblk node %d [mem
> %#010Lx-%#010Lx]\n",
> -   mblk_nid, mblk->base,
> -   mblk->base + mblk->size - 1);
> +   pr_warn("Warning: invalid memblk node %d [mem
> %pap-%pap]\n",
> +   mblk_nid, , );
> return -EINVAL;
> }
> }
> @@ -427,14 +428,14 @@ out_free_distance:
>  static int __init dummy_numa_init(void)
>  {
> phys_addr_t start = memblock_start_of_DRAM();
> -   phys_addr_t end = memblock_end_of_DRAM();
> +   phys_addr_t end = memblock_end_of_DRAM() - 1;
> int ret;
>  
> if (numa_off)
> pr_info("NUMA disabled\n"); /* Forced off on command
> line. */
> -   pr_info("Faking a node at [mem %#018Lx-%#018Lx]\n", start,
> end - 1);
> +   pr_info("Faking a node at [mem %pap-%pap]\n", , );
>  
> -   ret = numa_add_memblk(0, start, end);
> +   ret = numa_add_memblk(0, start, end + 1);
> if (ret) {
> pr_err("NUMA init failed\n");
> return ret;

Thanks for the fix.

Reviewed-by: Atish Patra 


-- 
Regards,
Atish


Re: Kconfig-induced build errors: CONFIG_PAGE_OFFSET

2021-01-28 Thread Atish Patra
On Wed, Jan 27, 2021 at 7:18 PM Randy Dunlap  wrote:
>
> Hi,
>
> I took a riscv-32 .config from kernel test robot (it was for a clang build)
> and did a "make olddefconfig" (using gcc tools) and got build errors
> due to this config item from arch/riscv/Kconfig;
>
>
> config PAGE_OFFSET
> hex
> default 0xC000 if 32BIT && MAXPHYSMEM_1GB
> default 0x8000 if 64BIT && !MMU
> default 0x8000 if 64BIT && MAXPHYSMEM_2GB
> default 0xffe0 if 64BIT && MAXPHYSMEM_128GB
>
> PAGE_OFFSET is undefined for the case of 32BIT && MAXPHYSMEM_2GB.

Because, RV32 doesn't support 2GB physical memory yet.

The compilation errors can be fixed by not allowing MAXPHYSMEM_2GB for RV32 and
MAXPHYSMEM_1GB for RV64. How about this ?

--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -253,8 +253,10 @@ choice
default MAXPHYSMEM_128GB if 64BIT && CMODEL_MEDANY

config MAXPHYSMEM_1GB
+   depends on 32BIT
bool "1GiB"
config MAXPHYSMEM_2GB
+   depends on 64BIT && CMODEL_MEDLOW
bool "2GiB"
config MAXPHYSMEM_128GB
depends on 64BIT && CMODEL_MEDANY


> That causes lots of errors when _AC() is used to paste
> CONFIG_PAGE_OFFSET to "UL", like these:
>
> In file included from ../include/vdso/const.h:5,
>  from ../include/linux/const.h:4,
>  from ../include/linux/bits.h:5,
>  from ../include/linux/bitops.h:6,
>  from ../include/linux/kernel.h:11,
>  from ../init/do_mounts_initrd.c:3:
> ../arch/riscv/include/asm/uaccess.h: In function '__access_ok':
> ../arch/riscv/include/asm/page.h:34:46: error: 'UL' undeclared (first use in 
> this function)
>34 | #define PAGE_OFFSET  _AC(CONFIG_PAGE_OFFSET, UL)
>   |  ^~
> ../include/uapi/linux/const.h:20:23: note: in definition of macro '__AC'
>20 | #define __AC(X,Y) (X##Y)
>   |   ^
> ../arch/riscv/include/asm/page.h:34:22: note: in expansion of macro '_AC'
>34 | #define PAGE_OFFSET  _AC(CONFIG_PAGE_OFFSET, UL)
>   |  ^~~
> ../arch/riscv/include/asm/pgtable.h:26:27: note: in expansion of macro 
> 'PAGE_OFFSET'
>26 | #define VMALLOC_START(PAGE_OFFSET - VMALLOC_SIZE)
>   |   ^~~
> ../arch/riscv/include/asm/pgtable.h:41:24: note: in expansion of macro 
> 'VMALLOC_START'
>41 | #define VMEMMAP_START (VMALLOC_START - VMEMMAP_SIZE)
>   |^
> ../arch/riscv/include/asm/pgtable.h:50:26: note: in expansion of macro 
> 'VMEMMAP_START'
>50 | #define PCI_IO_END   VMEMMAP_START
>   |  ^
> ../arch/riscv/include/asm/pgtable.h:51:27: note: in expansion of macro 
> 'PCI_IO_END'
>51 | #define PCI_IO_START (PCI_IO_END - PCI_IO_SIZE)
>   |   ^~
> ../arch/riscv/include/asm/pgtable.h:53:26: note: in expansion of macro 
> 'PCI_IO_START'
>53 | #define FIXADDR_TOP  PCI_IO_START
>   |  ^~~~
> ../arch/riscv/include/asm/pgtable.h:59:27: note: in expansion of macro 
> 'FIXADDR_TOP'
>59 | #define FIXADDR_START(FIXADDR_TOP - FIXADDR_SIZE)
>   |   ^~~
> ../arch/riscv/include/asm/pgtable.h:471:19: note: in expansion of macro 
> 'FIXADDR_START'
>   471 | #define TASK_SIZE FIXADDR_START
>   |   ^
> ../arch/riscv/include/asm/uaccess.h:56:17: note: in expansion of macro 
> 'TASK_SIZE'
>56 |  return size <= TASK_SIZE && addr <= TASK_SIZE - size;
>
>
> I suppose that it wants something like this, but someone else can
> fix/use the correct default value here:
>
> ---
>
> From: Randy Dunlap 
>
> Provide a default value for PAGE_OFFSET for the case of
> 32BIT and MAXPHYSMEM_2GB.
>
> Fixes many build errors.
>
> Signed-off-by: Randy Dunlap 
> ---
>  arch/riscv/Kconfig |1 +
>  1 file changed, 1 insertion(+)
>
> --- linux-next-20210125.orig/arch/riscv/Kconfig
> +++ linux-next-20210125/arch/riscv/Kconfig
> @@ -143,6 +143,7 @@ config PA_BITS
>  config PAGE_OFFSET
> hex
> default 0xC000 if 32BIT && MAXPHYSMEM_1GB
> +   default 0x8000 if 32BIT && MAXPHYSMEM_2GB
> default 0x8000 if 64BIT && !MMU
> default 0x8000 if 64BIT && MAXPHYSMEM_2GB
> default 0xffe0 if 64BIT && MAXPHYSMEM_128GB
>
>
>
> --
> ~Randy
> Reported-by: Randy Dunlap 
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


Re: [PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32

2021-01-15 Thread Atish Patra
On Thu, Jan 14, 2021 at 11:59 PM Geert Uytterhoeven
 wrote:
>
> Hi Atish,
>
> On Thu, Jan 14, 2021 at 10:11 PM Atish Patra  wrote:
> > On Thu, Jan 14, 2021 at 11:46 AM Palmer Dabbelt  wrote:
> > > On Thu, 14 Jan 2021 10:33:01 PST (-0800), ati...@atishpatra.org wrote:
> > > > On Wed, Jan 13, 2021 at 9:10 PM Palmer Dabbelt  
> > > > wrote:
> > > >>
> > > >> On Thu, 07 Jan 2021 01:26:51 PST (-0800), Atish Patra wrote:
> > > >> > SMP_CACHE_BYTES/L1_CACHE_BYTES should be defined as 32 instead of
> > > >> > 64 for RV32. Otherwise, there will be hole of 32 bytes with each 
> > > >> > memblock
> > > >> > allocation if it is requested to be aligned with SMP_CACHE_BYTES.
> > > >> >
> > > >> > Signed-off-by: Atish Patra 
> > > >> > ---
> > > >> >  arch/riscv/include/asm/cache.h | 4 
> > > >> >  1 file changed, 4 insertions(+)
> > > >> >
> > > >> > diff --git a/arch/riscv/include/asm/cache.h 
> > > >> > b/arch/riscv/include/asm/cache.h
> > > >> > index 9b58b104559e..c9c669ea2fe6 100644
> > > >> > --- a/arch/riscv/include/asm/cache.h
> > > >> > +++ b/arch/riscv/include/asm/cache.h
> > > >> > @@ -7,7 +7,11 @@
> > > >> >  #ifndef _ASM_RISCV_CACHE_H
> > > >> >  #define _ASM_RISCV_CACHE_H
> > > >> >
> > > >> > +#ifdef CONFIG_64BIT
> > > >> >  #define L1_CACHE_SHIFT   6
> > > >> > +#else
> > > >> > +#define L1_CACHE_SHIFT   5
> > > >> > +#endif
> > > >> >
> > > >> >  #define L1_CACHE_BYTES   (1 << L1_CACHE_SHIFT)
> > > >>
> > > >> Should we not instead just
> > > >>
> > > >> #define SMP_CACHE_BYTES L1_CACHE_BYTES
> > > >>
> > > >> like a handful of architectures do?
> > > >>
> > > >
> > > > The generic code already defines it that way in include/linux/cache.h
> > > >
> > > >> The cache size is sort of fake here, as we don't have any non-coherent
> > > >> mechanisms, but IIRC we wrote somewhere that it's recommended to have 
> > > >> 64-byte
> > > >> cache lines in RISC-V implementations as software may assume that for
> > > >> performance reasons.  Not really a strong reason, but I'd prefer to 
> > > >> just make
> > > >> these match.
> > > >>
> > > >
> > > > If it is documented somewhere in the kernel, we should update that. I
> > > > think SMP_CACHE_BYTES being 64
> > > > actually degrades the performance as there will be a fragmented memory
> > > > blocks with 32 bit bytes gap wherever
> > > > SMP_CACHE_BYTES is used as an alignment requirement.
> > >
> > > I don't buy that: if you're trying to align to the cache size then the 
> > > gaps are
> > > the whole point.  IIUC the 64-byte cache lines come from DDR, not XLEN, so
> > > there's really no reason for these to be different between the base ISAs.
> > >
> >
> > Got your point. I noticed this when fixing the resource tree issue
> > where the SMP_CACHE_BYTES
> > alignment was not intentional but causing the issue. The real issue
> > was solved via another patch in this series though.
> >
> > Just to clarify, if the allocation function intends to allocate
> > consecutive memory, it should use 32 instead of SMP_CACHE_BYTES.
> > This will lead to a #ifdef macro in the code.
> >
> > > > In addition to that, Geert Uytterhoeven mentioned some panic on vex32
> > > > without this patch.
> > > > I didn't see anything in Qemu though.
> > >
> > > Something like that is probably only going to show up on real hardware, 
> > > QEMU
> > > doesn't really do anything with the cache line size.  That said, as 
> > > there's
> > > nothing in our kernel now related to non-coherent memory there really 
> > > should
> > > only be performance issue (at least until we have non-coherent systems).
> > >
> > > I'd bet that the change is just masking some other bug, either in the 
> > > software
> > > or the hardware.  I'd prefer to root cause this rather than just working 
> > > around
> > > it, as it'll proba

Re: [PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32

2021-01-14 Thread Atish Patra
On Thu, Jan 14, 2021 at 11:46 AM Palmer Dabbelt  wrote:
>
> On Thu, 14 Jan 2021 10:33:01 PST (-0800), ati...@atishpatra.org wrote:
> > On Wed, Jan 13, 2021 at 9:10 PM Palmer Dabbelt  wrote:
> >>
> >> On Thu, 07 Jan 2021 01:26:51 PST (-0800), Atish Patra wrote:
> >> > SMP_CACHE_BYTES/L1_CACHE_BYTES should be defined as 32 instead of
> >> > 64 for RV32. Otherwise, there will be hole of 32 bytes with each memblock
> >> > allocation if it is requested to be aligned with SMP_CACHE_BYTES.
> >> >
> >> > Signed-off-by: Atish Patra 
> >> > ---
> >> >  arch/riscv/include/asm/cache.h | 4 
> >> >  1 file changed, 4 insertions(+)
> >> >
> >> > diff --git a/arch/riscv/include/asm/cache.h 
> >> > b/arch/riscv/include/asm/cache.h
> >> > index 9b58b104559e..c9c669ea2fe6 100644
> >> > --- a/arch/riscv/include/asm/cache.h
> >> > +++ b/arch/riscv/include/asm/cache.h
> >> > @@ -7,7 +7,11 @@
> >> >  #ifndef _ASM_RISCV_CACHE_H
> >> >  #define _ASM_RISCV_CACHE_H
> >> >
> >> > +#ifdef CONFIG_64BIT
> >> >  #define L1_CACHE_SHIFT   6
> >> > +#else
> >> > +#define L1_CACHE_SHIFT   5
> >> > +#endif
> >> >
> >> >  #define L1_CACHE_BYTES   (1 << L1_CACHE_SHIFT)
> >>
> >> Should we not instead just
> >>
> >> #define SMP_CACHE_BYTES L1_CACHE_BYTES
> >>
> >> like a handful of architectures do?
> >>
> >
> > The generic code already defines it that way in include/linux/cache.h
> >
> >> The cache size is sort of fake here, as we don't have any non-coherent
> >> mechanisms, but IIRC we wrote somewhere that it's recommended to have 
> >> 64-byte
> >> cache lines in RISC-V implementations as software may assume that for
> >> performance reasons.  Not really a strong reason, but I'd prefer to just 
> >> make
> >> these match.
> >>
> >
> > If it is documented somewhere in the kernel, we should update that. I
> > think SMP_CACHE_BYTES being 64
> > actually degrades the performance as there will be a fragmented memory
> > blocks with 32 bit bytes gap wherever
> > SMP_CACHE_BYTES is used as an alignment requirement.
>
> I don't buy that: if you're trying to align to the cache size then the gaps 
> are
> the whole point.  IIUC the 64-byte cache lines come from DDR, not XLEN, so
> there's really no reason for these to be different between the base ISAs.
>

Got your point. I noticed this when fixing the resource tree issue
where the SMP_CACHE_BYTES
alignment was not intentional but causing the issue. The real issue
was solved via another patch in this series though.

Just to clarify, if the allocation function intends to allocate
consecutive memory, it should use 32 instead of SMP_CACHE_BYTES.
This will lead to a #ifdef macro in the code.

> > In addition to that, Geert Uytterhoeven mentioned some panic on vex32
> > without this patch.
> > I didn't see anything in Qemu though.
>
> Something like that is probably only going to show up on real hardware, QEMU
> doesn't really do anything with the cache line size.  That said, as there's
> nothing in our kernel now related to non-coherent memory there really should
> only be performance issue (at least until we have non-coherent systems).
>
> I'd bet that the change is just masking some other bug, either in the software
> or the hardware.  I'd prefer to root cause this rather than just working 
> around
> it, as it'll probably come back later and in a more difficult way to find.
>

Agreed. @Geert Uytterhoeven Can you do a further analysis of the panic
you were saying ?
We may need to change an alignment requirement to 32 for RV32 manually
at some place in code.

> >> ___
> >> linux-riscv mailing list
> >> linux-ri...@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


Re: [PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32

2021-01-14 Thread Atish Patra
On Wed, Jan 13, 2021 at 9:10 PM Palmer Dabbelt  wrote:
>
> On Thu, 07 Jan 2021 01:26:51 PST (-0800), Atish Patra wrote:
> > SMP_CACHE_BYTES/L1_CACHE_BYTES should be defined as 32 instead of
> > 64 for RV32. Otherwise, there will be hole of 32 bytes with each memblock
> > allocation if it is requested to be aligned with SMP_CACHE_BYTES.
> >
> > Signed-off-by: Atish Patra 
> > ---
> >  arch/riscv/include/asm/cache.h | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/riscv/include/asm/cache.h b/arch/riscv/include/asm/cache.h
> > index 9b58b104559e..c9c669ea2fe6 100644
> > --- a/arch/riscv/include/asm/cache.h
> > +++ b/arch/riscv/include/asm/cache.h
> > @@ -7,7 +7,11 @@
> >  #ifndef _ASM_RISCV_CACHE_H
> >  #define _ASM_RISCV_CACHE_H
> >
> > +#ifdef CONFIG_64BIT
> >  #define L1_CACHE_SHIFT   6
> > +#else
> > +#define L1_CACHE_SHIFT   5
> > +#endif
> >
> >  #define L1_CACHE_BYTES   (1 << L1_CACHE_SHIFT)
>
> Should we not instead just
>
> #define SMP_CACHE_BYTES L1_CACHE_BYTES
>
> like a handful of architectures do?
>

The generic code already defines it that way in include/linux/cache.h

> The cache size is sort of fake here, as we don't have any non-coherent
> mechanisms, but IIRC we wrote somewhere that it's recommended to have 64-byte
> cache lines in RISC-V implementations as software may assume that for
> performance reasons.  Not really a strong reason, but I'd prefer to just make
> these match.
>

If it is documented somewhere in the kernel, we should update that. I
think SMP_CACHE_BYTES being 64
actually degrades the performance as there will be a fragmented memory
blocks with 32 bit bytes gap wherever
SMP_CACHE_BYTES is used as an alignment requirement.

In addition to that, Geert Uytterhoeven mentioned some panic on vex32
without this patch.
I didn't see anything in Qemu though.


> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


Re: [PATCH] riscv: Remove duplicate definition in pagtable.h

2021-01-12 Thread Atish Patra
On Mon, Jan 11, 2021 at 6:38 PM  wrote:
>
> From: Guo Ren 
>
> PAGE_KERNEL_EXEC has been defined above.
>
> Signed-off-by: Guo Ren 
> Cc: Palmer Dabbelt 
> Cc: Pekka Enberg 
> ---
>  arch/riscv/include/asm/pgtable.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/arch/riscv/include/asm/pgtable.h 
> b/arch/riscv/include/asm/pgtable.h
> index 41a72861987c..dff51a84e52e 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -101,7 +101,6 @@
>  #define PAGE_KERNEL__pgprot(_PAGE_KERNEL)
>  #define PAGE_KERNEL_EXEC   __pgprot(_PAGE_KERNEL | _PAGE_EXEC)
>  #define PAGE_KERNEL_READ   __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
> -#define PAGE_KERNEL_EXEC   __pgprot(_PAGE_KERNEL | _PAGE_EXEC)
>  #define PAGE_KERNEL_READ_EXEC  __pgprot((_PAGE_KERNEL & ~_PAGE_WRITE) \
>  | _PAGE_EXEC)
>
> --
> 2.17.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

It's already on the fixes.

http://lists.infradead.org/pipermail/linux-riscv/2021-January/004134.html


-- 
Regards,
Atish


Re: [PATCH] net: macb: Add default usrio config to default gem config

2021-01-11 Thread Atish Patra
On Mon, 2021-01-11 at 15:13 -0800, Jakub Kicinski wrote:
> On Mon, 11 Jan 2021 11:55:53 -0800 Atish Patra wrote:
> > There is no usrio config defined for default gem config leading to
> > a kernel panic devices that don't define a data. This issue can be
> > reprdouced with microchip polar fire soc where compatible string
> > is defined as "cdns,macb".
> > 
> > Fixes: edac63861db7 ("add userio bits as platform configuration")
> > 
> > Signed-off-by: Atish Patra 
> 
> Fixes tag needs work:
> 
> Fixes tag: Fixes: edac63861db7 ("add userio bits as platform
> configuration")
> Has these problem(s):
> - empty line after the tag
> - Subject does not match target commit subject
>   Just use
> git log -1 --format='Fixes: %h ("%s")'
> 
> Please put [PATCH net] as subject prefix, to indicate this 
> is a networking fix.
> 
> You can also CC Andrew Lunn like get_maintainer.pl suggests,
> but drop linux-kernel from the CC/To.

Done. Thanks for the feedback.

-- 
Regards,
Atish


[PATCH v2 0/4] Assorted fixes for RV32

2021-01-11 Thread Atish Patra
This series fixes various issues observed in latest kernel on RV32.
The first two patches fixes an resource tree introduced in 5.11-rc1
while the last two fixes the case where 2GB physical memory is used
on RV32.

There are may be better way to fix the issue pointed out in PATCH 3
as it seems a generic kernel issue where kernel pointers can not use
last 4k of addressable memory. I am open to other better alternate
suggestions.

Changes from v1->v2:
1. Added Reviewed/Tested by tags.
2. Replaced PHYS_ADDR_MAX with explicit __pa(~(ulong)0).

Atish Patra (4):
RISC-V: Do not allocate memblock while iterating reserved memblocks
RISC-V: Set current memblock limit
RISC-V: Fix L1_CACHE_BYTES for RV32
RISC-V: Fix maximum allowed phsyical memory for RV32

arch/riscv/Kconfig |  6 --
arch/riscv/include/asm/cache.h |  4 
arch/riscv/kernel/setup.c  | 24 +---
arch/riscv/mm/init.c   | 16 ++--
4 files changed, 35 insertions(+), 15 deletions(-)

--
2.25.1



[PATCH v2 2/4] RISC-V: Set current memblock limit

2021-01-11 Thread Atish Patra
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 
---
 arch/riscv/mm/init.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index bf5379135e39..7cd4993f4ff2 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -157,9 +157,10 @@ static void __init setup_initrd(void)
 void __init setup_bootmem(void)
 {
phys_addr_t mem_start = 0;
-   phys_addr_t start, end = 0;
+   phys_addr_t start, dram_end, end = 0;
phys_addr_t vmlinux_end = __pa_symbol(&_end);
phys_addr_t vmlinux_start = __pa_symbol(&_start);
+   phys_addr_t max_mapped_addr = __pa(~(ulong)0);
u64 i;
 
/* Find the memory region containing the kernel */
@@ -181,7 +182,18 @@ void __init setup_bootmem(void)
/* Reserve from the start of the kernel to the end of the kernel */
memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start);
 
-   max_pfn = PFN_DOWN(memblock_end_of_DRAM());
+   dram_end = memblock_end_of_DRAM();
+
+   /*
+* memblock allocator is not aware of the fact that last 4K bytes of
+* the addressable memory can not be mapped because of IS_ERR_VALUE
+* macro. Make sure that last 4k bytes are not usable by memblock
+* if end of dram is equal to maximum addressable memory.
+*/
+   if (max_mapped_addr == (dram_end - 1))
+   memblock_set_current_limit(max_mapped_addr - 4096);
+
+   max_pfn = PFN_DOWN(dram_end);
max_low_pfn = max_pfn;
dma32_phys_limit = min(4UL * SZ_1G, (unsigned 
long)PFN_PHYS(max_low_pfn));
set_max_mapnr(max_low_pfn);
-- 
2.25.1



[PATCH v2 4/4] RISC-V: Fix maximum allowed phsyical memory for RV32

2021-01-11 Thread Atish Patra
Linux kernel can only map 1GB of address space for RV32 as the page offset
is set to 0xC000. 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 
---
 arch/riscv/Kconfig | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 81b76d44725d..e9e2c1f0a690 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -137,7 +137,7 @@ config PA_BITS
 
 config PAGE_OFFSET
hex
-   default 0xC000 if 32BIT && MAXPHYSMEM_2GB
+   default 0xC000 if 32BIT && MAXPHYSMEM_1GB
default 0x8000 if 64BIT && !MMU
default 0x8000 if 64BIT && MAXPHYSMEM_2GB
default 0xffe0 if 64BIT && MAXPHYSMEM_128GB
@@ -247,10 +247,12 @@ config MODULE_SECTIONS
 
 choice
prompt "Maximum Physical Memory"
-   default MAXPHYSMEM_2GB if 32BIT
+   default MAXPHYSMEM_1GB if 32BIT
default MAXPHYSMEM_2GB if 64BIT && CMODEL_MEDLOW
default MAXPHYSMEM_128GB if 64BIT && CMODEL_MEDANY
 
+   config MAXPHYSMEM_1GB
+   bool "1GiB"
config MAXPHYSMEM_2GB
bool "2GiB"
config MAXPHYSMEM_128GB
-- 
2.25.1



[PATCH v2 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32

2021-01-11 Thread Atish Patra
SMP_CACHE_BYTES/L1_CACHE_BYTES should be defined as 32 instead of
64 for RV32. Otherwise, there will be hole of 32 bytes with each memblock
allocation if it is requested to be aligned with SMP_CACHE_BYTES.

Reviewed-by: Anup Patel 
Tested-by: Geert Uytterhoeven 
(on vexriscv)
Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/cache.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/include/asm/cache.h b/arch/riscv/include/asm/cache.h
index 9b58b104559e..c9c669ea2fe6 100644
--- a/arch/riscv/include/asm/cache.h
+++ b/arch/riscv/include/asm/cache.h
@@ -7,7 +7,11 @@
 #ifndef _ASM_RISCV_CACHE_H
 #define _ASM_RISCV_CACHE_H
 
+#ifdef CONFIG_64BIT
 #define L1_CACHE_SHIFT 6
+#else
+#define L1_CACHE_SHIFT 5
+#endif
 
 #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
 
-- 
2.25.1



[PATCH v2 1/4] RISC-V: Do not allocate memblock while iterating reserved memblocks

2021-01-11 Thread Atish Patra
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.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at kernel/resource.c:795
__insert_resource+0x8e/0xd0
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
5.10.0-00022-ge20097fb37e2-dirty #549
[0.00] epc: c00125c2 ra : c001262c sp : c1c01f50
[0.00]  gp : c1d456e0 tp : c1c0a980 t0 : cf20
[0.00]  t1 :  t2 :  s0 : c1c01f60
[0.00]  s1 : cf00 a0 : ff00 a1 : c1c0c0c4
[0.00]  a2 : 80c12b15 a3 : 80402000 a4 : 80402000
[0.00]  a5 : c1c0c0c4 a6 : 80c12b15 a7 : f5faf600
[0.00]  s2 : c1c0c0c4 s3 : c1c0e000 s4 : c1009a80
[0.00]  s5 : c1c0c000 s6 : c1d48000 s7 : c1613b4c
[0.00]  s8 : 0fff s9 : 8200 s10: c1613b40
[0.00]  s11:  t3 : c1d4a000 t4 : 

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 
---
 arch/riscv/kernel/setup.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 1d85e9bf783c..3fa3f26dde85 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -127,7 +127,9 @@ static void __init init_resources(void)
 {
struct memblock_region *region = NULL;
struct resource *res = NULL;
-   int ret = 0;
+   struct resource *mem_res = NULL;
+   size_t mem_res_sz = 0;
+   int ret = 0, i = 0;
 
code_res.start = __pa_symbol(_text);
code_res.end = __pa_symbol(_etext) - 1;
@@ -145,16 +147,17 @@ static void __init init_resources(void)
bss_res.end = __pa_symbol(__bss_stop) - 1;
bss_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
+   mem_res_sz = (memblock.memory.cnt + memblock.reserved.cnt) * 
sizeof(*mem_res);
+   mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
+   if (!mem_res)
+   panic("%s: Failed to allocate %zu bytes\n", __func__, 
mem_res_sz);
/*
 * Start by adding the reserved regions, if they overlap
 * with /memory regions, insert_resource later on will take
 * care of it.
 */
for_each_reserved_mem_region(region) {
-   res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-   if (!res)
-   panic("%s: Failed to allocate %zu bytes\n", __func__,
- sizeof(struct resource));
+   res = _res[i++];
 
res->name = "Reserved";
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
@@ -171,8 +174,10 @@ static void __init init_resources(void)
 * Ignore any other reserved regions within
 * system memory.
 */
-   if (memblock_is_memory(res->start))
+   if (memblock_is_memory(res->start)) {
+   memblock_free((phys_addr_t) res, sizeof(struct 
resource));
continue;
+   }
 
ret = add_resource(_resource, res);
if (ret < 0)
@@ -181,10 +186,7 @@ static void __init init_resources(void)
 
/* Add /memory regions to the resource tree */
for_each_mem_region(region) {
-   res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-   if (!res)
-   panic("%s: Failed to allocate %zu bytes\n", __func__,
- sizeof(struct resource));
+   res = _res[i++];
 
if (unlikely(memblock_is_nomap(region))) {
res->name = "Reserved";
@@ -205,9 +207,9 @@ static void __init init_resources(void)
return;
 
  error:
-   memblock_free((phys_addr_t) res, sizeof(struct resource));
/* Better an empty resource tree than an inconsistent one */
release_child_resources(_resource);
+   memblock_free((phys_addr_t) mem_res, mem_res_sz);
 }
 
 
-- 
2.25.1



[PATCH] net: macb: Add default usrio config to default gem config

2021-01-11 Thread Atish Patra
There is no usrio config defined for default gem config leading to
a kernel panic devices that don't define a data. This issue can be
reprdouced with microchip polar fire soc where compatible string
is defined as "cdns,macb".

Fixes: edac63861db7 ("add userio bits as platform configuration")

Signed-off-by: Atish Patra 
---
 drivers/net/ethernet/cadence/macb_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index 814a5b10141d..47ee72ab7002 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -4590,6 +4590,7 @@ static const struct macb_config default_gem_config = {
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
+   .usrio = _default_usrio,
.jumbo_max_len = 10240,
 };
 
-- 
2.25.1



Re: [PATCH v5 0/5] Unify NUMA implementation between ARM64 & RISC-V

2021-01-11 Thread Atish Patra
On Sat, Jan 9, 2021 at 12:51 PM Palmer Dabbelt  wrote:
>
> On Sun, 13 Dec 2020 17:02:19 PST (-0800), ati...@atishpatra.org wrote:
> > On Wed, Nov 18, 2020 at 4:39 PM Atish Patra  wrote:
> >>
> >> This series attempts to move the ARM64 numa implementation to common
> >> code so that RISC-V can leverage that as well instead of reimplementing
> >> it again.
> >>
> >> RISC-V specific bits are based on initial work done by Greentime Hu [1] but
> >> modified to reuse the common implementation to avoid duplication.
> >>
> >> [1] https://lkml.org/lkml/2020/1/10/233
> >>
> >> This series has been tested on qemu with numa enabled for both RISC-V & 
> >> ARM64.
> >> It would be great if somebody can test it on numa capable ARM64 hardware 
> >> platforms.
> >> This patch series doesn't modify the maintainers list for the common code 
> >> (arch_numa)
> >> as I am not sure if somebody from ARM64 community or Greg should take up 
> >> the
> >> maintainership. Ganapatrao was the original author of the arm64 version.
> >> I would be happy to update that in the next revision once it is decided.
> >>
> >> # numactl --hardware
> >> available: 2 nodes (0-1)
> >> node 0 cpus: 0 1 2 3
> >> node 0 size: 486 MB
> >> node 0 free: 470 MB
> >> node 1 cpus: 4 5 6 7
> >> node 1 size: 424 MB
> >> node 1 free: 408 MB
> >> node distances:
> >> node   0   1
> >>   0:  10  20
> >>   1:  20  10
> >> # numactl -show
> >> policy: default
> >> preferred node: current
> >> physcpubind: 0 1 2 3 4 5 6 7
> >> cpubind: 0 1
> >> nodebind: 0 1
> >> membind: 0 1
> >>
> >> The patches are also available at
> >> https://github.com/atishp04/linux/tree/5.11_numa_unified_v5
> >>
> >> For RISC-V, the following qemu series is a pre-requisite(already available 
> >> in upstream)
> >> https://patchwork.kernel.org/project/qemu-devel/list/?series=303313
> >>
> >> Testing:
> >> RISC-V:
> >> Tested in Qemu and 2 socket OmniXtend FPGA.
> >>
> >> ARM64:
> >> 2 socket kunpeng920 (4 nodes around 250G a node)
> >> Tested-by: Jonathan Cameron 
> >>
> >> Changes from v4->v5:
> >> 1. Added by Acked-by & Reviewed-by tags.
> >> 2. Swapped patch 1 & 2 in v4 version.
> >>
> >> Changes from v3->v4:
> >> 1. Removed redundant duplicate header.
> >> 2. Added Reviewed-by tags.
> >>
> >> Changes from v2->v3:
> >> 1. Added Acked-by/Reviewed-by tags.
> >> 2. Replaced asm/acpi.h with linux/acpi.h
> >> 3. Defined arch_acpi_numa_init as static.
> >>
> >> Changes from v1->v2:
> >> 1. Replaced ARM64 specific compile time protection with ACPI specific ones.
> >> 2. Dropped common pcibus_to_node changes. Added required changes in RISC-V.
> >> 3. Fixed few typos.
> >>
> >> Atish Patra (4):
> >> arm64, numa: Change the numa init functions name to be generic
> >> numa: Move numa implementation to common code
> >> riscv: Separate memory init from paging init
> >> riscv: Add numa support for riscv64 platform
> >>
> >> Greentime Hu (1):
> >> riscv: Add support pte_protnone and pmd_protnone if
> >> CONFIG_NUMA_BALANCING
> >>
> >> arch/arm64/Kconfig|  1 +
> >> arch/arm64/include/asm/numa.h | 48 +
> >> arch/arm64/kernel/acpi_numa.c | 12 -
> >> arch/arm64/mm/Makefile|  1 -
> >> arch/arm64/mm/init.c  |  4 +-
> >> arch/riscv/Kconfig| 31 ++-
> >> arch/riscv/include/asm/mmzone.h   | 13 +
> >> arch/riscv/include/asm/numa.h |  8 +++
> >> arch/riscv/include/asm/pci.h  | 14 +
> >> arch/riscv/include/asm/pgtable.h  | 21 
> >> arch/riscv/kernel/setup.c | 11 +++-
> >> arch/riscv/kernel/smpboot.c   | 12 -
> >> arch/riscv/mm/init.c  | 10 +++-
> >> drivers/base/Kconfig  |  6 +++
> >> drivers/base/Makefile |  1 +
> >> .../mm/numa.c => drivers/base/arch_numa.c | 27 --
> >> include/asm-generic/numa.h| 52 +++

Re: [PATCH 2/4] RISC-V: Set current memblock limit

2021-01-11 Thread Atish Patra
On Sun, Jan 10, 2021 at 7:59 PM Anup Patel  wrote:
>
> On Thu, Jan 7, 2021 at 2:57 PM Atish Patra  wrote:
> >
> > 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.
> >
> > Signed-off-by: Atish Patra 
> > ---
> >  arch/riscv/mm/init.c | 16 ++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > index bf5379135e39..da53902ef0fc 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -157,9 +157,10 @@ static void __init setup_initrd(void)
> >  void __init setup_bootmem(void)
> >  {
> > phys_addr_t mem_start = 0;
> > -   phys_addr_t start, end = 0;
> > +   phys_addr_t start, dram_end, end = 0;
> > phys_addr_t vmlinux_end = __pa_symbol(&_end);
> > phys_addr_t vmlinux_start = __pa_symbol(&_start);
> > +   phys_addr_t max_mapped_addr = __pa(PHYS_ADDR_MAX);
>
> Using PHYS_ADDR_MAX as the max virtual address does not look right.
>
> Better use __pa(~(ulong)0) here. Otherwise looks good to me.
>

ok will change it. Thanks for the review.

> Reviewed-by: Anup Patel 
>
> > u64 i;
> >
> > /* Find the memory region containing the kernel */
> > @@ -181,7 +182,18 @@ void __init setup_bootmem(void)
> > /* Reserve from the start of the kernel to the end of the kernel */
> > memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start);
> >
> > -   max_pfn = PFN_DOWN(memblock_end_of_DRAM());
> > +   dram_end = memblock_end_of_DRAM();
> > +
> > +   /*
> > +* memblock allocator is not aware of the fact that last 4K bytes of
> > +* the addressable memory can not be mapped because of IS_ERR_VALUE
> > +* macro. Make sure that last 4k bytes are not usable by memblock
> > +* if end of dram is equal to maximum addressable memory.
> > +*/
> > +   if (max_mapped_addr == (dram_end - 1))
> > +   memblock_set_current_limit(max_mapped_addr - 4096);
> > +
> > +   max_pfn = PFN_DOWN(dram_end);
> > max_low_pfn = max_pfn;
> > dma32_phys_limit = min(4UL * SZ_1G, (unsigned 
> > long)PFN_PHYS(max_low_pfn));
> > set_max_mapnr(max_low_pfn);
> > --
> > 2.25.1
> >
> >
> > ___
> > linux-riscv mailing list
> > linux-ri...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> Regards,
> Anup
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


Re: [PATCH v2 0/2] CLK: microchip: Add clkcfg driver for Microchip PolarFire SoC

2021-01-08 Thread Atish Patra
On Thu, 2021-01-07 at 11:34 +, daire.mcnam...@microchip.com wrote:
> From: Daire McNamara 
> 
> This patchset adds support for the Microchip PolarFire clkcfg
> hardware block.
> 
> Major changes since v1:
>  * Dependency on SOC_MICROCHIP_POLARFIRE

Does the sdcard work for with latest kernel ?

I get following error while detecting the sdcard

[1.063897] NET: Registered protocol family 10
[1.071042] Segment Routing with IPv6
[1.075023] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[1.082427] NET: Registered protocol family 17
[1.085812] mmc0: SDHCI controller on 20008000.sdhc [20008000.sdhc]
using ADMA 64-bit
[1.087508] 9pnet: Installing 9P2000 support
[1.099614] Key type dns_resolver registered
[1.104462] debug_vm_pgtable: [debug_vm_pgtable ]:
Validating architecture page table helpers
[1.122625] Waiting for root device /dev/mmcblk0p3...
[   11.229725] mmc0: Timeout waiting for hardware cmd interrupt.
[   11.235592] mmc0: sdhci:  SDHCI REGISTER DUMP
===

Here is series rebased on top of 5.11-rc2

https://github.com/atishp04/linux/tree/polarfire_support_upstream_v4

FYI: I have added below macb fix on top of last version of the series
along with few other minor dt fixups.

net: macb: Add defailt usrio config to default gem config

>  * All references to PFSOC/pfsoc changed to MPFS/mpfs
>  * Cleaned error handling in _probe
>  * Re-ordered code to place structs et al at top
> 
> Daire McNamara (2):
>   dt-bindings: clk: microchip: Add Microchip PolarFire host binding
>   clk: microchip: Add driver for Microchip PolarFire SoC
> 
>  .../bindings/clock/microchip,mpfs.yaml    |  73 +++
>  drivers/clk/Kconfig   |   1 +
>  drivers/clk/Makefile  |   2 +-
>  drivers/clk/microchip/Kconfig |   7 +
>  drivers/clk/microchip/Makefile    |   6 +-
>  drivers/clk/microchip/clk-mpfs.c  | 443
> ++
>  .../dt-bindings/clock/microchip,mpfs-clock.h  |  45 ++
>  7 files changed, 574 insertions(+), 3 deletions(-)
>  create mode 100644
> Documentation/devicetree/bindings/clock/microchip,mpfs.yaml
>  create mode 100644 drivers/clk/microchip/Kconfig
>  create mode 100644 drivers/clk/microchip/clk-mpfs.c
>  create mode 100644 include/dt-bindings/clock/microchip,mpfs-clock.h
> 
> 
> base-commit: f804b3159482eedbb4250b1e9248c308fb63b805
> prerequisite-patch-id: 961d8e88a8979add1d563b9f841a426f0ca0061d
> prerequisite-patch-id: 27e03792a5ac74127c66ecba47bd7d5b1471dfef
> prerequisite-patch-id: 8c9c4f565197190f4e2ed52c3d83418133ef5a51
> prerequisite-patch-id: bd73fb05ce3d6ce1226a95a1ee4ff2e8088a0d4a
> prerequisite-patch-id: d33f2f1ff57076d7845af27242d3b86d5a9e8059

-- 
Regards,
Atish


Re: [PATCH v3 3/5] RISC-V: Initial DTS for Microchip ICICLE board

2021-01-07 Thread Atish Patra
On Thu, Jan 7, 2021 at 3:44 AM  wrote:
>
> Hi Atish,
>
> On 12/4/20 8:58 AM, Atish Patra wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> > content is safe
> >
> > Add initial DTS for Microchip ICICLE board having only
> > essential devices (clocks, sdhci, ethernet, serial, etc).
> > The device tree is based on the U-Boot patch.
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/
> >
> > Signed-off-by: Atish Patra 
> > ---
> >   arch/riscv/boot/dts/Makefile  |   1 +
> >   arch/riscv/boot/dts/microchip/Makefile|   2 +
> >   .../microchip/microchip-mpfs-icicle-kit.dts   |  72 
> >   .../boot/dts/microchip/microchip-mpfs.dtsi| 331 ++
> >   4 files changed, 406 insertions(+)
> >   create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> >   create mode 100644 
> > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> >   create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> >
> > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> > index ca1f8cbd78c0..3ea94ea0a18a 100644
> > --- a/arch/riscv/boot/dts/Makefile
> > +++ b/arch/riscv/boot/dts/Makefile
> > @@ -1,5 +1,6 @@
> >   # SPDX-License-Identifier: GPL-2.0
> >   subdir-y += sifive
> >   subdir-y += kendryte
> > +subdir-y += microchip
> >
> >   obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
> > diff --git a/arch/riscv/boot/dts/microchip/Makefile 
> > b/arch/riscv/boot/dts/microchip/Makefile
> > new file mode 100644
> > index ..622b12771fd3
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts 
> > b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > new file mode 100644
> > index ..5b51dad13c72
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > @@ -0,0 +1,72 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/* Copyright (c) 2020 Microchip Technology Inc */
> > +
> > +/dts-v1/;
> > +
> > +#include "microchip-mpfs.dtsi"
> > +
> > +/* Clock frequency (in Hz) of the rtcclk */
> > +#define RTCCLK_FREQ100
> > +
> > +/ {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +   model = "Microchip PolarFire-SoC Icicle Kit";
> > +   compatible = "microchip,mpfs-icicle-kit", "microchip,polarfire-soc";
> > +
> > +   chosen {
> > +   stdout-path = 
> > +   };
> > +
> > +   cpus {
> > +   timebase-frequency = ;
> > +   };
> > +
> > +   memory@8000 {
> > +   device_type = "memory";
> > +   reg = <0x0 0x8000 0x0 0x4000>;
> > +   clocks = < 26>;
> > +   };
> > +
> > +   soc {
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   phy-mode = "sgmii";
> > +   phy-handle = <>;
> > +   phy0: ethernet-phy@8 {
> > +   reg = <8>;
> > +   ti,fifo-depth = <0x01>;
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +   phy-mode = "sgmii";
> > +   phy-handle = <>;
> > +   phy1: ethernet-phy@9 {
> > +   reg = <9>;
> > +   ti,fifo-depth = <0x01>;
> > +   };
> > +};
> > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi 
> > b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > new file mode 100644
> > index ..7a076aa4c78d
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > @@ 

Re: [PATCH v3 1/5] RISC-V: Add Microchip PolarFire SoC kconfig option

2021-01-07 Thread Atish Patra
On Thu, Jan 7, 2021 at 3:40 AM  wrote:
>
> Hi Atish,
>
> On 12/4/20 8:58 AM, Atish Patra wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> > content is safe
> >
> > Add Microchip PolarFire kconfig option which selects SoC specific
> > and common drivers that is required for this SoC.
> >
> > Signed-off-by: Atish Patra 
> > Reviewed-by: Bin Meng 
> > Reviewed-by: Anup Patel 
> > ---
> >   arch/riscv/Kconfig.socs | 7 +++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> > index 8a55f6156661..148ab095966b 100644
> > --- a/arch/riscv/Kconfig.socs
> > +++ b/arch/riscv/Kconfig.socs
> > @@ -1,5 +1,12 @@
> >   menu "SoC selection"
> >
> > +config SOC_MICROCHIP_POLARFIRE
> > +   bool "Microchip PolarFire SoCs"
> > +   select MCHP_CLK_PFSOC
> Can you change MCHP_CLK_PFSOC to MCHP_CLK_MPFS to align with the v2
> clock driver?

Sure. Will do that.

> > +   select SIFIVE_PLIC
> > +   help
> > + This enables support for Microchip PolarFire SoC platforms.
> > +
> >   config SOC_SIFIVE
> >  bool "SiFive SoCs"
> >  select SERIAL_SIFIVE if TTY
> > --
> > 2.25.1
> >
> Regards,
>
> Cyril.
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


[PATCH 4/4] RISC-V: Fix maximum allowed phsyical memory for RV32

2021-01-07 Thread Atish Patra
Linux kernel can only map 1GB of address space for RV32 as the page offset
is set to 0xC000. 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.

Signed-off-by: Atish Patra 
---
 arch/riscv/Kconfig | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 81b76d44725d..e9e2c1f0a690 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -137,7 +137,7 @@ config PA_BITS
 
 config PAGE_OFFSET
hex
-   default 0xC000 if 32BIT && MAXPHYSMEM_2GB
+   default 0xC000 if 32BIT && MAXPHYSMEM_1GB
default 0x8000 if 64BIT && !MMU
default 0x8000 if 64BIT && MAXPHYSMEM_2GB
default 0xffe0 if 64BIT && MAXPHYSMEM_128GB
@@ -247,10 +247,12 @@ config MODULE_SECTIONS
 
 choice
prompt "Maximum Physical Memory"
-   default MAXPHYSMEM_2GB if 32BIT
+   default MAXPHYSMEM_1GB if 32BIT
default MAXPHYSMEM_2GB if 64BIT && CMODEL_MEDLOW
default MAXPHYSMEM_128GB if 64BIT && CMODEL_MEDANY
 
+   config MAXPHYSMEM_1GB
+   bool "1GiB"
config MAXPHYSMEM_2GB
bool "2GiB"
config MAXPHYSMEM_128GB
-- 
2.25.1



[PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32

2021-01-07 Thread Atish Patra
SMP_CACHE_BYTES/L1_CACHE_BYTES should be defined as 32 instead of
64 for RV32. Otherwise, there will be hole of 32 bytes with each memblock
allocation if it is requested to be aligned with SMP_CACHE_BYTES.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/cache.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/include/asm/cache.h b/arch/riscv/include/asm/cache.h
index 9b58b104559e..c9c669ea2fe6 100644
--- a/arch/riscv/include/asm/cache.h
+++ b/arch/riscv/include/asm/cache.h
@@ -7,7 +7,11 @@
 #ifndef _ASM_RISCV_CACHE_H
 #define _ASM_RISCV_CACHE_H
 
+#ifdef CONFIG_64BIT
 #define L1_CACHE_SHIFT 6
+#else
+#define L1_CACHE_SHIFT 5
+#endif
 
 #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
 
-- 
2.25.1



[PATCH 2/4] RISC-V: Set current memblock limit

2021-01-07 Thread Atish Patra
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.

Signed-off-by: Atish Patra 
---
 arch/riscv/mm/init.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index bf5379135e39..da53902ef0fc 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -157,9 +157,10 @@ static void __init setup_initrd(void)
 void __init setup_bootmem(void)
 {
phys_addr_t mem_start = 0;
-   phys_addr_t start, end = 0;
+   phys_addr_t start, dram_end, end = 0;
phys_addr_t vmlinux_end = __pa_symbol(&_end);
phys_addr_t vmlinux_start = __pa_symbol(&_start);
+   phys_addr_t max_mapped_addr = __pa(PHYS_ADDR_MAX);
u64 i;
 
/* Find the memory region containing the kernel */
@@ -181,7 +182,18 @@ void __init setup_bootmem(void)
/* Reserve from the start of the kernel to the end of the kernel */
memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start);
 
-   max_pfn = PFN_DOWN(memblock_end_of_DRAM());
+   dram_end = memblock_end_of_DRAM();
+
+   /*
+* memblock allocator is not aware of the fact that last 4K bytes of
+* the addressable memory can not be mapped because of IS_ERR_VALUE
+* macro. Make sure that last 4k bytes are not usable by memblock
+* if end of dram is equal to maximum addressable memory.
+*/
+   if (max_mapped_addr == (dram_end - 1))
+   memblock_set_current_limit(max_mapped_addr - 4096);
+
+   max_pfn = PFN_DOWN(dram_end);
max_low_pfn = max_pfn;
dma32_phys_limit = min(4UL * SZ_1G, (unsigned 
long)PFN_PHYS(max_low_pfn));
set_max_mapnr(max_low_pfn);
-- 
2.25.1



[PATCH 0/4] Assorted fixes for RV32

2021-01-07 Thread Atish Patra
This series fixes various issues observed in latest kernel on RV32.
The first two patches fixes an resource tree introduced in 5.11-rc1
while the last two fixes the case where 2GB physical memory is used
on RV32.

There are may be better way to fix the issue pointed out in PATCH 3
as it seems a generic kernel issue where kernel pointers can not use
last 4k of addressable memory. I am open to other better alternate
suggestions.

Atish Patra (4):
RISC-V: Do not allocate memblock while iterating reserved memblocks
RISC-V: Set current memblock limit
RISC-V: Fix L1_CACHE_BYTES for RV32
RISC-V: Fix maximum allowed phsyical memory for RV32

arch/riscv/Kconfig |  6 --
arch/riscv/include/asm/cache.h |  4 
arch/riscv/kernel/setup.c  | 24 +---
arch/riscv/mm/init.c   | 16 ++--
4 files changed, 35 insertions(+), 15 deletions(-)

--
2.25.1



[PATCH 1/4] RISC-V: Do not allocate memblock while iterating reserved memblocks

2021-01-07 Thread Atish Patra
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.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at kernel/resource.c:795
__insert_resource+0x8e/0xd0
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
5.10.0-00022-ge20097fb37e2-dirty #549
[0.00] epc: c00125c2 ra : c001262c sp : c1c01f50
[0.00]  gp : c1d456e0 tp : c1c0a980 t0 : cf20
[0.00]  t1 :  t2 :  s0 : c1c01f60
[0.00]  s1 : cf00 a0 : ff00 a1 : c1c0c0c4
[0.00]  a2 : 80c12b15 a3 : 80402000 a4 : 80402000
[0.00]  a5 : c1c0c0c4 a6 : 80c12b15 a7 : f5faf600
[0.00]  s2 : c1c0c0c4 s3 : c1c0e000 s4 : c1009a80
[0.00]  s5 : c1c0c000 s6 : c1d48000 s7 : c1613b4c
[0.00]  s8 : 0fff s9 : 8200 s10: c1613b40
[0.00]  s11:  t3 : c1d4a000 t4 : 

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")

Signed-off-by: Atish Patra 
---
 arch/riscv/kernel/setup.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 1d85e9bf783c..3fa3f26dde85 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -127,7 +127,9 @@ static void __init init_resources(void)
 {
struct memblock_region *region = NULL;
struct resource *res = NULL;
-   int ret = 0;
+   struct resource *mem_res = NULL;
+   size_t mem_res_sz = 0;
+   int ret = 0, i = 0;
 
code_res.start = __pa_symbol(_text);
code_res.end = __pa_symbol(_etext) - 1;
@@ -145,16 +147,17 @@ static void __init init_resources(void)
bss_res.end = __pa_symbol(__bss_stop) - 1;
bss_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
+   mem_res_sz = (memblock.memory.cnt + memblock.reserved.cnt) * 
sizeof(*mem_res);
+   mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
+   if (!mem_res)
+   panic("%s: Failed to allocate %zu bytes\n", __func__, 
mem_res_sz);
/*
 * Start by adding the reserved regions, if they overlap
 * with /memory regions, insert_resource later on will take
 * care of it.
 */
for_each_reserved_mem_region(region) {
-   res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-   if (!res)
-   panic("%s: Failed to allocate %zu bytes\n", __func__,
- sizeof(struct resource));
+   res = _res[i++];
 
res->name = "Reserved";
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
@@ -171,8 +174,10 @@ static void __init init_resources(void)
 * Ignore any other reserved regions within
 * system memory.
 */
-   if (memblock_is_memory(res->start))
+   if (memblock_is_memory(res->start)) {
+   memblock_free((phys_addr_t) res, sizeof(struct 
resource));
continue;
+   }
 
ret = add_resource(_resource, res);
if (ret < 0)
@@ -181,10 +186,7 @@ static void __init init_resources(void)
 
/* Add /memory regions to the resource tree */
for_each_mem_region(region) {
-   res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-   if (!res)
-   panic("%s: Failed to allocate %zu bytes\n", __func__,
- sizeof(struct resource));
+   res = _res[i++];
 
if (unlikely(memblock_is_nomap(region))) {
res->name = "Reserved";
@@ -205,9 +207,9 @@ static void __init init_resources(void)
return;
 
  error:
-   memblock_free((phys_addr_t) res, sizeof(struct resource));
/* Better an empty resource tree than an inconsistent one */
release_child_resources(_resource);
+   memblock_free((phys_addr_t) mem_res, mem_res_sz);
 }
 
 
-- 
2.25.1



Re: [PATCH v5 4/9] riscv: Fixup patch_text panic in ftrace

2020-12-22 Thread Atish Patra
all:
>0xffe00020817a <+0>: addisp,sp,-8
>0xffe00020817c <+2>: sd  ra,0(sp)
>0xffe00020817e <+4>: auipc   ra,0xf
>0xffe000208182 <+8>: jalr-1822(ra) # 0xffe000206a60 
> 
>0xffe000208186 <+12>:ld  ra,0(sp)
>0xffe000208188 <+14>:addisp,sp,8
>0xffe00020818a <+0>: addisp,sp,-16
>0xffe00020818c <+2>: sd  s0,0(sp)
>0xffe00020818e <+4>: sd  ra,8(sp)
>0xffe000208190 <+6>: addis0,sp,16
>0xffe000208192 <+8>: li  a0,0
>0xffe000208194 <+10>:auipc   ra,0xf
>0xffe000208198 <+14>:jalr-410(ra) # 0xffe000206ffa 
> 
>0xffe00020819c <+18>:ld  s0,0(sp)
>0xffe00020819e <+20>:ld  ra,8(sp)
>0xffe0002081a0 <+22>:addisp,sp,16
>0xffe0002081a2 <+24>:ret
>
> (gdb) frame 5
> (rec=0xffe01ae40c30, enable=3) at kernel/trace/ftrace.c:2503
> 2503return ftrace_make_call(rec, ftrace_addr);
> (gdb) p /x rec->ip
> $2 = 0xffe00020817a -> flush_icache_all !
>
> When we modified flush_icache_all's patchable-entry with ftrace_caller:
>  - Insert ftrace_caller at flush_icache_all prologue.
>  - Call flush_icache_all to sync I/Dcache, but flush_icache_all is
> just we modified by half.
>
> Link: 
> https://lore.kernel.org/linux-riscv/CAJF2gTT=odweswe0jvwvtpgi60-gpbnhyldfwn_5ebyeqoe...@mail.gmail.com/T/#t
> Signed-off-by: Guo Ren 
> Cc: Atish Patra 
> Cc: Steven Rostedt (VMware) 
> ---
>  arch/riscv/kernel/Makefile | 1 +
>  arch/riscv/mm/Makefile | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index 27f10eb..62de075 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -6,6 +6,7 @@
>  ifdef CONFIG_FTRACE
>  CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
>  CFLAGS_REMOVE_patch.o  = $(CC_FLAGS_FTRACE)
> +CFLAGS_REMOVE_sbi.o= $(CC_FLAGS_FTRACE)
>  endif
>
>  extra-y += head.o
> diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
> index 6b4b7ec..7ebaef1 100644
> --- a/arch/riscv/mm/Makefile
> +++ b/arch/riscv/mm/Makefile
> @@ -3,6 +3,7 @@
>  CFLAGS_init.o := -mcmodel=medany
>  ifdef CONFIG_FTRACE
>  CFLAGS_REMOVE_init.o = $(CC_FLAGS_FTRACE)
> +CFLAGS_REMOVE_cacheflush.o = $(CC_FLAGS_FTRACE)
>  endif
>
>  KCOV_INSTRUMENT_init.o := n
> --
> 2.7.4
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Reviewed-by: Atish Patra 


-- 
Regards,
Atish


Re: [PATCH v3 0/5] Add Microchip PolarFire Soc Support

2020-12-22 Thread Atish Patra
On Mon, Dec 21, 2020 at 7:19 PM Palmer Dabbelt  wrote:
>
> On Fri, 04 Dec 2020 00:58:30 PST (-0800), Atish Patra wrote:
> > This series adds minimal support for Microchip Polar Fire Soc Icicle kit.
> > It is rebased on v5.10-rc6 and depends on clock support.
> > Only MMC and ethernet drivers are enabled via this series.
> > The idea here is to add the foundational patches so that other drivers
> > can be added to on top of this. The device tree may change based on
> > feedback on bindings of individual driver support patches.
> >
> > This series has been tested on Qemu and Polar Fire Soc Icicle kit.
> > The following qemu series is necessary to test it on Qemu.
> >
> > The series can also be found at.
> > https://github.com/atishp04/linux/tree/polarfire_support_upstream_v3
> >
> > I noticed the latest version of mmc driver[2] hangs on the board with
> > the latest clock driver. That's why, I have tested with the old clock
> > driver available in the above github repo.
>
> IIRC the previous version was an RFC, but this is a PATCH.  I'd be generally
> happy to take it on for-next, but I don't want to merge something that doesn't
> boot and that I don't have any way to fix (I don't have one of the boards 
> yet).
>

Fair enough. We can wait for clock patches to be merged before merging
this series.

> > [1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html
> > [2] https://www.spinics.net/lists/devicetree/msg383626.html
> >
> > Changes from v2->v3:
> > 1. Fixed a typo in dt binding.
> > 2. Included MAINTAINERS entry for PolarFire SoC.
> > 3. Improved the dts file by using lowercase clock names and keeping phy
> >details in board specific dts file.
> >
> > Changes from v1->v2:
> > 1. Modified the DT to match the device tree in U-Boot.
> > 2. Added both eMMC & SDcard entries in DT. However, SD card is only enabled
> >as it allows larger storage option for linux distros.
> >
> > Atish Patra (4):
> > RISC-V: Add Microchip PolarFire SoC kconfig option
> > dt-bindings: riscv: microchip: Add YAML documentation for the
> > PolarFire SoC
> > RISC-V: Initial DTS for Microchip ICICLE board
> > RISC-V: Enable Microchip PolarFire ICICLE SoC
> >
> > Conor Dooley (1):
> > MAINTAINERS: add microchip polarfire soc support
> >
> > .../devicetree/bindings/riscv/microchip.yaml  |  28 ++
> > MAINTAINERS   |   8 +
> > arch/riscv/Kconfig.socs   |   7 +
> > arch/riscv/boot/dts/Makefile  |   1 +
> > arch/riscv/boot/dts/microchip/Makefile|   2 +
> > .../microchip/microchip-mpfs-icicle-kit.dts   |  72 
> > .../boot/dts/microchip/microchip-mpfs.dtsi| 331 ++
> > arch/riscv/configs/defconfig  |   4 +
> > 8 files changed, 453 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml
> > create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> > create mode 100644 
> > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

@Daire McNamara Do you have a v2 of the clock patch series that works
with the latest upstream.

-- 
Regards,
Atish


[PATCH] riscv: Trace irq on only interrupt is enabled

2020-12-18 Thread Atish Patra
We should call irq trace only if interrupt is going to be enabled during
excecption handling. Otherwise, it results in following warning during
boot with lock debugging enabled.

[0.00] [ cut here ]
[0.00] DEBUG_LOCKS_WARN_ON(early_boot_irqs_disabled)
[0.00] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:4085 
lockdep_hardirqs_on_prepare+0x22a/0x22e
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
5.10.0-00022-ge20097fb37e2-dirty #548
[0.00] epc: c005d5d4 ra : c005d5d4 sp : c1c01e80
[0.00]  gp : c1d456e0 tp : c1c0a980 t0 : 
[0.00]  t1 :  t2 :  s0 : c1c01ea0
[0.00]  s1 : c100f360 a0 : 002d a1 : c00666ee
[0.00]  a2 :  a3 :  a4 : 
[0.00]  a5 :  a6 : c1c6b390 a7 : 300e
[0.00]  s2 : c2384fe8 s3 :  s4 : 0001
[0.00]  s5 : c1c0a980 s6 : c1d48000 s7 : c1613b4c
[0.00]  s8 : 0fff s9 : 8200 s10: c1613b40
[0.00]  s11:  t3 :  t4 : 
[0.00]  t5 : 0001 t6 : 

Fixes: 3c4697982982 ("riscv:Enable LOCKDEP_SUPPORT & fixup 
TRACE_IRQFLAGS_SUPPORT")
Cc: sta...@vger.kernel.org

Signed-off-by: Atish Patra 
---
 arch/riscv/kernel/entry.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 524d918f3601..7dea5ee5a3ac 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -124,15 +124,15 @@ skip_context_tracking:
REG_L a1, (a1)
jr a1
 1:
-#ifdef CONFIG_TRACE_IRQFLAGS
-   call trace_hardirqs_on
-#endif
/*
 * Exceptions run with interrupts enabled or disabled depending on the
 * state of SR_PIE in m/sstatus.
 */
andi t0, s1, SR_PIE
beqz t0, 1f
+#ifdef CONFIG_TRACE_IRQFLAGS
+   call trace_hardirqs_on
+#endif
csrs CSR_STATUS, SR_IE
 
 1:
-- 
2.25.1



[PATCH v2] RISC-V: Fix usage of memblock_enforce_memory_limit

2020-12-18 Thread Atish Patra
memblock_enforce_memory_limit accepts the maximum memory size not the
maximum address that can be handled by kernel. Fix the function invocation
accordingly.

Fixes: 1bd14a66ee52 ("RISC-V: Remove any memblock representing unusable memory 
area")
Cc: sta...@vger.kernel.org

Reported-by: Bin Meng 
Tested-by: Bin Meng 
Acked-by: Mike Rapoport 
Signed-off-by: Atish Patra 
---
Changes from v1->v2:
1. Added stable-kernel in cc.
2. Added reported/tested by tag.
---
 arch/riscv/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 13ba533f462b..bf5379135e39 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -176,7 +176,7 @@ void __init setup_bootmem(void)
 * Make sure that any memory beyond mem_start + (-PAGE_OFFSET) is 
removed
 * as it is unusable by kernel.
 */
-   memblock_enforce_memory_limit(mem_start - PAGE_OFFSET);
+   memblock_enforce_memory_limit(-PAGE_OFFSET);
 
/* Reserve from the start of the kernel to the end of the kernel */
memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start);
-- 
2.25.1



Re: [PATCH v3 3/5] RISC-V: Align the .init.text section

2020-12-18 Thread Atish Patra
On Thu, Dec 17, 2020 at 12:33 AM Atish Patra  wrote:
>
> On Wed, Dec 16, 2020 at 10:51 PM Palmer Dabbelt  wrote:
> >
> > On Tue, 15 Dec 2020 22:02:54 PST (-0800), Palmer Dabbelt wrote:
> > > On Wed, 04 Nov 2020 16:04:37 PST (-0800), Atish Patra wrote:
> > >> In order to improve kernel text protection, we need separate .init.text/
> > >> .init.data/.text in separate sections. However, RISC-V linker relaxation
> > >> code is not aware of any alignment between sections. As a result, it may
> > >> relax any RISCV_CALL relocations between sections to JAL without 
> > >> realizing
> > >> that an inter section alignment may move the address farther. That may
> > >> lead to a relocation truncated fit error. However, linker relaxation code
> > >> is aware of the individual section alignments.
> > >>
> > >> The detailed discussion on this issue can be found here.
> > >> https://github.com/riscv/riscv-gnu-toolchain/issues/738
> > >>
> > >> Keep the .init.text section aligned so that linker relaxation will take
> > >> that as a hint while relaxing inter section calls.
> > >> Here are the code size changes for each section because of this change.
> > >>
> > >> section change in size (in bytes)
> > >>   .head.text  +4
> > >>   .text   +40
> > >>   .init.text  +6530
> > >>   .exit.text  +84
> > >>
> > >> The only significant increase in size happened for .init.text because
> > >> all intra relocations also use 2MB alignment.
> > >>
> > >> Suggested-by: Jim Wilson 
> > >> Signed-off-by: Atish Patra 
> > >> ---
> > >>  arch/riscv/kernel/vmlinux.lds.S | 8 +++-
> > >>  1 file changed, 7 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/riscv/kernel/vmlinux.lds.S 
> > >> b/arch/riscv/kernel/vmlinux.lds.S
> > >> index 3ffbd6cbdb86..cacd7898ba7f 100644
> > >> --- a/arch/riscv/kernel/vmlinux.lds.S
> > >> +++ b/arch/riscv/kernel/vmlinux.lds.S
> > >> @@ -30,7 +30,13 @@ SECTIONS
> > >>  . = ALIGN(PAGE_SIZE);
> > >>
> > >>  __init_begin = .;
> > >> -INIT_TEXT_SECTION(PAGE_SIZE)
> > >> +__init_text_begin = .;
> > >> +.init.text : AT(ADDR(.init.text) - LOAD_OFFSET) 
> > >> ALIGN(SECTION_ALIGN) { \
> > >> +_sinittext = .; \
> > >> +INIT_TEXT   \
> > >> +_einittext = .; \
> > >> +}
> > >> +
> > >>  . = ALIGN(8);
> > >>  __soc_early_init_table : {
> > >>  __soc_early_init_table_start = .;
> > >
> > > Not sure what's going on here (or why I wasn't catching it earlier), but 
> > > this
> > > is breaking boot on one of my test configs.  I'm not getting any Linux 
> > > boot
> > > spew, so it's something fairly early.  I'm running defconfig with
> > >
> > > CONFIG_PREEMPT=y
> > > CONFIG_DEBUG_PREEMPT=y
> > > CONFIG_PROVE_LOCKING=y
> > >
> > > It looks like that's been throwing a bunch of warnings for a while, but 
> > > it did
> > > at least used to boot.  No idea what PREEMPT would have to do with this, 
> > > and
> > > the other two don't generally trigger issues that early in boot (or at 
> > > least,
> > > trigger halts that early in boot).
> > >

I am able to reproduce this issue but with CONFIG_PROVE_LOCKING not
CONFIG_PREEMPT.
With CONFIG_PREEMPT, I see a bunch of warnings around smp_processor_id
but it boots even with 5.0.
If CONFIG_PROVE_LOCKING is enabled, I am not able to boot using 5.0.
However, 5.2.0 works fine.
I am going to take a look at the issue with 5.0 and PROVE_LOCKING.

The config preempt warnings are resolved by the following patch. I
have tested it in Qemu.

https://patchwork.kernel.org/project/linux-riscv/patch/20201116081238.44223-1-wangkefeng.w...@huawei.com/

> > > There's a bunch of other stuff that depends on this that's on for-next so 
> > > I
> > > don't want to just drop it, but I also don't want to break something.  
> > > I'm just
> > > running QEMU's virt board.
> > >
>
> I just verified for-next on QEMU 5.2.0 for virt (RV32,64, nommu) and
> sifive_u as well.
> I will give it a try on unleashed tomorrow as well with the above
> configs enabled.
>
> > > I'll take a look again tomorrow night, but if anyone has some time to look
> > > that'd be great!
> >
> > Looks like this breaks on QEMU 5.0.0 but works on 5.2.0.
>
> I will take a look tomorrow to check the root cause.
>
> I guess technically
> > that means could be considered a regression, but as we don't really have any
> > scheme for which old versions of QEMU we support it's not absolute.  I'd
> > usually err on the side of keeping support for older platforms, but in this
> > case it's probably just not worth the time so I'm going to just ignore it.
> >
> > ___
> > linux-riscv mailing list
> > linux-ri...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
>
>
> --
> Regards,
> Atish



-- 
Regards,
Atish


Re: [PATCH] RISC-V: Fix usage of memblock_enforce_memory_limit

2020-12-17 Thread Atish Patra
On Thu, Dec 17, 2020 at 12:53 AM Bin Meng  wrote:
>
> Hi Atish,
>
> On Thu, Dec 17, 2020 at 4:43 PM Atish Patra  wrote:
> >
> > On Thu, Dec 17, 2020 at 12:12 AM Bin Meng  wrote:
> > >
> > > Hi Atish,
> > >
> > > On Thu, Dec 17, 2020 at 3:49 PM Atish Patra  wrote:
> > > >
> > > > memblock_enforce_memory_limit accepts the maximum memory size not the 
> > > > last
> > > > address. Fix the function invocation correctly.
> > > >
> > > > Fixes: 1bd14a66ee52 ("RISC-V: Remove any memblock representing unusable 
> > > > memory area")
> > > >
> > > > Signed-off-by: Atish Patra 
> > > > ---
> > > >  arch/riscv/mm/init.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > >
> > > Thank you for working on this.
> > >
> > > Tested with QEMU 5.2.0 on 32-bit 'virt' and 'sifive_u', with
> > > fw_jump.bin used as the -bios.
> >
> > fw_dynamic should also work unless you are using more than 1G of memory.
> > Linux kernel can only support 1G of memory for RV32. The current
>
> I have always been using -m 2G for testing both 32-bit and 64-bit.
> 32-bit 'virt' with 2G memory boots the 32-bit kernel fine.
>

2GB issue with fw_dynamic is fixed with this patch.

https://www.mail-archive.com/qemu-devel@nongnu.org/msg768341.html

> $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel
> arch/riscv/boot/Image -bios fw_jump.bin
>
> > Kconfig is bit misleading and
> > I will send a patch to update the description.
> >
> > However, kernel should be able to ignore any memory beyond what it can
> > address and continue.
> > I will investigate more.
> >
> > > 32-bit 'virt' boots, but 32-bit 'sifive_u' still does not boot, which
> > > should be another issue because reverting the original 1bd14a66ee52 it
> > > still does not help 'sifive_u'.
> > >
> >
> > Are you using more than 1G of memory ? Let me know if the kernel boots
> > if you use 1G.
>
> Kernel does not boot with 1G memory on 32-bit 'sifive_u', either with
> fw_jump.bin or fw_dynamic.bin.
>
> $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 -kernel
> arch/riscv/boot/Image -bios fw_jump.bin
>

This happened because of the incorrect loading address. It is already
fixed by Alistair.
https://www.mail-archive.com/qemu-devel@nongnu.org/msg768279.html

> >
> > > Tested-by: Bin Meng 
> > >

Thanks for testing it.

> > > I believe the following tag should also be added and patch cc'ed to
> > > stable-kernel:
> > >
> > > Reported-by: Bin Meng 
> > > Cc:  # 5.10
>

Sure. I will add that and resend it.

> Regards,
> Bin



-- 
Regards,
Atish


Re: [PATCH] RISC-V: Fix usage of memblock_enforce_memory_limit

2020-12-17 Thread Atish Patra
On Thu, Dec 17, 2020 at 12:12 AM Bin Meng  wrote:
>
> Hi Atish,
>
> On Thu, Dec 17, 2020 at 3:49 PM Atish Patra  wrote:
> >
> > memblock_enforce_memory_limit accepts the maximum memory size not the last
> > address. Fix the function invocation correctly.
> >
> > Fixes: 1bd14a66ee52 ("RISC-V: Remove any memblock representing unusable 
> > memory area")
> >
> > Signed-off-by: Atish Patra 
> > ---
> >  arch/riscv/mm/init.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Thank you for working on this.
>
> Tested with QEMU 5.2.0 on 32-bit 'virt' and 'sifive_u', with
> fw_jump.bin used as the -bios.

fw_dynamic should also work unless you are using more than 1G of memory.
Linux kernel can only support 1G of memory for RV32. The current
Kconfig is bit misleading and
I will send a patch to update the description.

However, kernel should be able to ignore any memory beyond what it can
address and continue.
I will investigate more.

> 32-bit 'virt' boots, but 32-bit 'sifive_u' still does not boot, which
> should be another issue because reverting the original 1bd14a66ee52 it
> still does not help 'sifive_u'.
>

Are you using more than 1G of memory ? Let me know if the kernel boots
if you use 1G.

> Tested-by: Bin Meng 
>
> I believe the following tag should also be added and patch cc'ed to
> stable-kernel:
>
> Reported-by: Bin Meng 
> Cc:  # 5.10
>
> Regards,
> Bin
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


Re: [PATCH v3 3/5] RISC-V: Align the .init.text section

2020-12-17 Thread Atish Patra
On Wed, Dec 16, 2020 at 10:51 PM Palmer Dabbelt  wrote:
>
> On Tue, 15 Dec 2020 22:02:54 PST (-0800), Palmer Dabbelt wrote:
> > On Wed, 04 Nov 2020 16:04:37 PST (-0800), Atish Patra wrote:
> >> In order to improve kernel text protection, we need separate .init.text/
> >> .init.data/.text in separate sections. However, RISC-V linker relaxation
> >> code is not aware of any alignment between sections. As a result, it may
> >> relax any RISCV_CALL relocations between sections to JAL without realizing
> >> that an inter section alignment may move the address farther. That may
> >> lead to a relocation truncated fit error. However, linker relaxation code
> >> is aware of the individual section alignments.
> >>
> >> The detailed discussion on this issue can be found here.
> >> https://github.com/riscv/riscv-gnu-toolchain/issues/738
> >>
> >> Keep the .init.text section aligned so that linker relaxation will take
> >> that as a hint while relaxing inter section calls.
> >> Here are the code size changes for each section because of this change.
> >>
> >> section change in size (in bytes)
> >>   .head.text  +4
> >>   .text   +40
> >>   .init.text  +6530
> >>   .exit.text  +84
> >>
> >> The only significant increase in size happened for .init.text because
> >> all intra relocations also use 2MB alignment.
> >>
> >> Suggested-by: Jim Wilson 
> >> Signed-off-by: Atish Patra 
> >> ---
> >>  arch/riscv/kernel/vmlinux.lds.S | 8 +++-
> >>  1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/riscv/kernel/vmlinux.lds.S 
> >> b/arch/riscv/kernel/vmlinux.lds.S
> >> index 3ffbd6cbdb86..cacd7898ba7f 100644
> >> --- a/arch/riscv/kernel/vmlinux.lds.S
> >> +++ b/arch/riscv/kernel/vmlinux.lds.S
> >> @@ -30,7 +30,13 @@ SECTIONS
> >>  . = ALIGN(PAGE_SIZE);
> >>
> >>  __init_begin = .;
> >> -INIT_TEXT_SECTION(PAGE_SIZE)
> >> +__init_text_begin = .;
> >> +.init.text : AT(ADDR(.init.text) - LOAD_OFFSET) ALIGN(SECTION_ALIGN) 
> >> { \
> >> +_sinittext = .; \
> >> +INIT_TEXT   \
> >> +_einittext = .; \
> >> +}
> >> +
> >>  . = ALIGN(8);
> >>  __soc_early_init_table : {
> >>  __soc_early_init_table_start = .;
> >
> > Not sure what's going on here (or why I wasn't catching it earlier), but 
> > this
> > is breaking boot on one of my test configs.  I'm not getting any Linux boot
> > spew, so it's something fairly early.  I'm running defconfig with
> >
> > CONFIG_PREEMPT=y
> > CONFIG_DEBUG_PREEMPT=y
> > CONFIG_PROVE_LOCKING=y
> >
> > It looks like that's been throwing a bunch of warnings for a while, but it 
> > did
> > at least used to boot.  No idea what PREEMPT would have to do with this, and
> > the other two don't generally trigger issues that early in boot (or at 
> > least,
> > trigger halts that early in boot).
> >
> > There's a bunch of other stuff that depends on this that's on for-next so I
> > don't want to just drop it, but I also don't want to break something.  I'm 
> > just
> > running QEMU's virt board.
> >

I just verified for-next on QEMU 5.2.0 for virt (RV32,64, nommu) and
sifive_u as well.
I will give it a try on unleashed tomorrow as well with the above
configs enabled.

> > I'll take a look again tomorrow night, but if anyone has some time to look
> > that'd be great!
>
> Looks like this breaks on QEMU 5.0.0 but works on 5.2.0.

I will take a look tomorrow to check the root cause.

I guess technically
> that means could be considered a regression, but as we don't really have any
> scheme for which old versions of QEMU we support it's not absolute.  I'd
> usually err on the side of keeping support for older platforms, but in this
> case it's probably just not worth the time so I'm going to just ignore it.
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


[PATCH] RISC-V: Fix usage of memblock_enforce_memory_limit

2020-12-16 Thread Atish Patra
memblock_enforce_memory_limit accepts the maximum memory size not the last
address. Fix the function invocation correctly.

Fixes: 1bd14a66ee52 ("RISC-V: Remove any memblock representing unusable memory 
area")

Signed-off-by: Atish Patra 
---
 arch/riscv/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 8e577f14f120..e4133c20744c 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -174,7 +174,7 @@ void __init setup_bootmem(void)
 * Make sure that any memory beyond mem_start + (-PAGE_OFFSET) is 
removed
 * as it is unusable by kernel.
 */
-   memblock_enforce_memory_limit(mem_start - PAGE_OFFSET);
+   memblock_enforce_memory_limit(-PAGE_OFFSET);
 
/* Reserve from the start of the kernel to the end of the kernel */
memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start);
-- 
2.25.1



Re: [PATCH v5 0/5] Unify NUMA implementation between ARM64 & RISC-V

2020-12-13 Thread Atish Patra
On Wed, Nov 18, 2020 at 4:39 PM Atish Patra  wrote:
>
> This series attempts to move the ARM64 numa implementation to common
> code so that RISC-V can leverage that as well instead of reimplementing
> it again.
>
> RISC-V specific bits are based on initial work done by Greentime Hu [1] but
> modified to reuse the common implementation to avoid duplication.
>
> [1] https://lkml.org/lkml/2020/1/10/233
>
> This series has been tested on qemu with numa enabled for both RISC-V & ARM64.
> It would be great if somebody can test it on numa capable ARM64 hardware 
> platforms.
> This patch series doesn't modify the maintainers list for the common code 
> (arch_numa)
> as I am not sure if somebody from ARM64 community or Greg should take up the
> maintainership. Ganapatrao was the original author of the arm64 version.
> I would be happy to update that in the next revision once it is decided.
>
> # numactl --hardware
> available: 2 nodes (0-1)
> node 0 cpus: 0 1 2 3
> node 0 size: 486 MB
> node 0 free: 470 MB
> node 1 cpus: 4 5 6 7
> node 1 size: 424 MB
> node 1 free: 408 MB
> node distances:
> node   0   1
>   0:  10  20
>   1:  20  10
> # numactl -show
> policy: default
> preferred node: current
> physcpubind: 0 1 2 3 4 5 6 7
> cpubind: 0 1
> nodebind: 0 1
> membind: 0 1
>
> The patches are also available at
> https://github.com/atishp04/linux/tree/5.11_numa_unified_v5
>
> For RISC-V, the following qemu series is a pre-requisite(already available in 
> upstream)
> https://patchwork.kernel.org/project/qemu-devel/list/?series=303313
>
> Testing:
> RISC-V:
> Tested in Qemu and 2 socket OmniXtend FPGA.
>
> ARM64:
> 2 socket kunpeng920 (4 nodes around 250G a node)
> Tested-by: Jonathan Cameron 
>
> Changes from v4->v5:
> 1. Added by Acked-by & Reviewed-by tags.
> 2. Swapped patch 1 & 2 in v4 version.
>
> Changes from v3->v4:
> 1. Removed redundant duplicate header.
> 2. Added Reviewed-by tags.
>
> Changes from v2->v3:
> 1. Added Acked-by/Reviewed-by tags.
> 2. Replaced asm/acpi.h with linux/acpi.h
> 3. Defined arch_acpi_numa_init as static.
>
> Changes from v1->v2:
> 1. Replaced ARM64 specific compile time protection with ACPI specific ones.
> 2. Dropped common pcibus_to_node changes. Added required changes in RISC-V.
> 3. Fixed few typos.
>
> Atish Patra (4):
> arm64, numa: Change the numa init functions name to be generic
> numa: Move numa implementation to common code
> riscv: Separate memory init from paging init
> riscv: Add numa support for riscv64 platform
>
> Greentime Hu (1):
> riscv: Add support pte_protnone and pmd_protnone if
> CONFIG_NUMA_BALANCING
>
> arch/arm64/Kconfig|  1 +
> arch/arm64/include/asm/numa.h | 48 +
> arch/arm64/kernel/acpi_numa.c | 12 -
> arch/arm64/mm/Makefile|  1 -
> arch/arm64/mm/init.c  |  4 +-
> arch/riscv/Kconfig| 31 ++-
> arch/riscv/include/asm/mmzone.h   | 13 +
> arch/riscv/include/asm/numa.h |  8 +++
> arch/riscv/include/asm/pci.h  | 14 +
> arch/riscv/include/asm/pgtable.h  | 21 
> arch/riscv/kernel/setup.c | 11 +++-
> arch/riscv/kernel/smpboot.c   | 12 -
> arch/riscv/mm/init.c  | 10 +++-
> drivers/base/Kconfig  |  6 +++
> drivers/base/Makefile |  1 +
> .../mm/numa.c => drivers/base/arch_numa.c | 27 --
> include/asm-generic/numa.h| 52 +++
> 17 files changed, 200 insertions(+), 72 deletions(-)
> create mode 100644 arch/riscv/include/asm/mmzone.h
> create mode 100644 arch/riscv/include/asm/numa.h
> rename arch/arm64/mm/numa.c => drivers/base/arch_numa.c (96%)
> create mode 100644 include/asm-generic/numa.h
>
> --
> 2.25.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Hey Palmer,
I did not see this series in for-next. Let me know if you need
anything else to be done for this series.

-- 
Regards,
Atish


[PATCH v3 5/5] MAINTAINERS: add microchip polarfire soc support

2020-12-04 Thread Atish Patra
From: Conor Dooley 

Add Cyril Jean and Lewis Hanly as maintainers for the Microchip SoC
directory

Signed-off-by: Conor Dooley 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2daa6ee673f7..cccb7d6c58aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14989,6 +14989,14 @@ F: arch/riscv/
 N: riscv
 K: riscv
 
+RISC-V/MICROCHIP POLARFIRE SOC SUPPORT
+M: Lewis Hanly 
+M: Cyril Jean 
+L: linux-ri...@lists.infradead.org
+S: Supported
+F: drivers/soc/microchip/
+F: include/soc/microchip/mpfs.h
+
 RNBD BLOCK DRIVERS
 M: Danil Kipnis 
 M: Jack Wang 
-- 
2.25.1



[PATCH v3 3/5] RISC-V: Initial DTS for Microchip ICICLE board

2020-12-04 Thread Atish Patra
Add initial DTS for Microchip ICICLE board having only
essential devices (clocks, sdhci, ethernet, serial, etc).
The device tree is based on the U-Boot patch.

https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/

Signed-off-by: Atish Patra 
---
 arch/riscv/boot/dts/Makefile  |   1 +
 arch/riscv/boot/dts/microchip/Makefile|   2 +
 .../microchip/microchip-mpfs-icicle-kit.dts   |  72 
 .../boot/dts/microchip/microchip-mpfs.dtsi| 331 ++
 4 files changed, 406 insertions(+)
 create mode 100644 arch/riscv/boot/dts/microchip/Makefile
 create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
 create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi

diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index ca1f8cbd78c0..3ea94ea0a18a 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 subdir-y += sifive
 subdir-y += kendryte
+subdir-y += microchip
 
 obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
diff --git a/arch/riscv/boot/dts/microchip/Makefile 
b/arch/riscv/boot/dts/microchip/Makefile
new file mode 100644
index ..622b12771fd3
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts 
b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
new file mode 100644
index ..5b51dad13c72
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2020 Microchip Technology Inc */
+
+/dts-v1/;
+
+#include "microchip-mpfs.dtsi"
+
+/* Clock frequency (in Hz) of the rtcclk */
+#define RTCCLK_FREQ100
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   model = "Microchip PolarFire-SoC Icicle Kit";
+   compatible = "microchip,mpfs-icicle-kit", "microchip,polarfire-soc";
+
+   chosen {
+   stdout-path = 
+   };
+
+   cpus {
+   timebase-frequency = ;
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x0 0x8000 0x0 0x4000>;
+   clocks = < 26>;
+   };
+
+   soc {
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   phy-mode = "sgmii";
+   phy-handle = <>;
+   phy0: ethernet-phy@8 {
+   reg = <8>;
+   ti,fifo-depth = <0x01>;
+   };
+};
+
+ {
+   status = "okay";
+   phy-mode = "sgmii";
+   phy-handle = <>;
+   phy1: ethernet-phy@9 {
+   reg = <9>;
+   ti,fifo-depth = <0x01>;
+   };
+};
diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi 
b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
new file mode 100644
index ..7a076aa4c78d
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2020 Microchip Technology Inc */
+
+/dts-v1/;
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   model = "Microchip PolarFire-SoC";
+   compatible = "microchip,polarfire-soc";
+
+   chosen {
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   clock-frequency = <0>;
+   compatible = "sifive,rocket0", "riscv";
+   device_type = "cpu";
+   i-cache-block-size = <64>;
+   i-cache-sets = <128>;
+   i-cache-size = <16384>;
+   reg = <0>;
+   riscv,isa = "rv64imac";
+   status = "disabled";
+
+   cpu0_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+
+   cpu@1 {
+   clock-frequency = <0>;
+   compatible = "sifive,rocket0", "riscv";
+   d-cache-block-size = <64>;
+ 

[PATCH v3 4/5] RISC-V: Enable Microchip PolarFire ICICLE SoC

2020-12-04 Thread Atish Patra
Enable Microchip PolarFire ICICLE soc config in defconfig.
It allows the default upstream kernel to boot on PolarFire ICICLE board.

Signed-off-by: Atish Patra 
Reviewed-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 arch/riscv/configs/defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index d222d353d86d..2660fa05451e 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -16,6 +16,7 @@ CONFIG_EXPERT=y
 CONFIG_BPF_SYSCALL=y
 CONFIG_SOC_SIFIVE=y
 CONFIG_SOC_VIRT=y
+CONFIG_SOC_MICROCHIP_POLARFIRE=y
 CONFIG_SMP=y
 CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
@@ -79,6 +80,9 @@ CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_UAS=y
+CONFIG_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_CADENCE=y
 CONFIG_MMC=y
 CONFIG_MMC_SPI=y
 CONFIG_RTC_CLASS=y
-- 
2.25.1



[PATCH v3 2/5] dt-bindings: riscv: microchip: Add YAML documentation for the PolarFire SoC

2020-12-04 Thread Atish Patra
Add YAML DT binding documentation for the Microchip PolarFire SoC.
It is documented at:

https://www.microsemi.com/products/fpga-soc/polarfire-soc-icicle-quick-start-guide

Signed-off-by: Atish Patra 
---
 .../devicetree/bindings/riscv/microchip.yaml  | 28 +++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml

diff --git a/Documentation/devicetree/bindings/riscv/microchip.yaml 
b/Documentation/devicetree/bindings/riscv/microchip.yaml
new file mode 100644
index ..66e63c2bf359
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/microchip.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: (GPL-2.0 OR MIT)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/microchip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PolarFire SoC-based boards device tree bindings
+
+maintainers:
+  - Cyril Jean 
+  - Lewis Hanly 
+
+description:
+  Microchip PolarFire SoC-based boards
+
+properties:
+  $nodename:
+const: '/'
+  compatible:
+items:
+  - enum:
+  - microchip,mpfs-icicle-kit
+  - const: microchip,polarfire-soc
+  - const: microchip,mpfs
+
+additionalProperties: true
+
+...
-- 
2.25.1



[PATCH v3 1/5] RISC-V: Add Microchip PolarFire SoC kconfig option

2020-12-04 Thread Atish Patra
Add Microchip PolarFire kconfig option which selects SoC specific
and common drivers that is required for this SoC.

Signed-off-by: Atish Patra 
Reviewed-by: Bin Meng 
Reviewed-by: Anup Patel 
---
 arch/riscv/Kconfig.socs | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 8a55f6156661..148ab095966b 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -1,5 +1,12 @@
 menu "SoC selection"
 
+config SOC_MICROCHIP_POLARFIRE
+   bool "Microchip PolarFire SoCs"
+   select MCHP_CLK_PFSOC
+   select SIFIVE_PLIC
+   help
+ This enables support for Microchip PolarFire SoC platforms.
+
 config SOC_SIFIVE
bool "SiFive SoCs"
select SERIAL_SIFIVE if TTY
-- 
2.25.1



[PATCH v3 0/5] Add Microchip PolarFire Soc Support

2020-12-04 Thread Atish Patra
This series adds minimal support for Microchip Polar Fire Soc Icicle kit.
It is rebased on v5.10-rc6 and depends on clock support. 
Only MMC and ethernet drivers are enabled via this series.
The idea here is to add the foundational patches so that other drivers
can be added to on top of this. The device tree may change based on
feedback on bindings of individual driver support patches.

This series has been tested on Qemu and Polar Fire Soc Icicle kit.
The following qemu series is necessary to test it on Qemu.

The series can also be found at.
https://github.com/atishp04/linux/tree/polarfire_support_upstream_v3

I noticed the latest version of mmc driver[2] hangs on the board with
the latest clock driver. That's why, I have tested with the old clock
driver available in the above github repo.

[1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html
[2] https://www.spinics.net/lists/devicetree/msg383626.html

Changes from v2->v3:
1. Fixed a typo in dt binding.
2. Included MAINTAINERS entry for PolarFire SoC.
3. Improved the dts file by using lowercase clock names and keeping phy
   details in board specific dts file.

Changes from v1->v2:
1. Modified the DT to match the device tree in U-Boot.
2. Added both eMMC & SDcard entries in DT. However, SD card is only enabled
   as it allows larger storage option for linux distros.

Atish Patra (4):
RISC-V: Add Microchip PolarFire SoC kconfig option
dt-bindings: riscv: microchip: Add YAML documentation for the
PolarFire SoC
RISC-V: Initial DTS for Microchip ICICLE board
RISC-V: Enable Microchip PolarFire ICICLE SoC

Conor Dooley (1):
MAINTAINERS: add microchip polarfire soc support

.../devicetree/bindings/riscv/microchip.yaml  |  28 ++
MAINTAINERS   |   8 +
arch/riscv/Kconfig.socs   |   7 +
arch/riscv/boot/dts/Makefile  |   1 +
arch/riscv/boot/dts/microchip/Makefile|   2 +
.../microchip/microchip-mpfs-icicle-kit.dts   |  72 
.../boot/dts/microchip/microchip-mpfs.dtsi| 331 ++
arch/riscv/configs/defconfig  |   4 +
8 files changed, 453 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml
create mode 100644 arch/riscv/boot/dts/microchip/Makefile
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi

--
2.25.1



Re: [RFC PATCH v2 3/4] RISC-V: Initial DTS for Microchip ICICLE board

2020-12-02 Thread Atish Patra
On Wed, 2020-12-02 at 16:20 +, daire.mcnam...@microchip.com wrote:
> 
> 
> From: Atish Patra 
> Sent: Friday 13 November 2020 20:25
> To: linux-kernel@vger.kernel.org 
> Cc: Atish Patra ; Albert Ou < 
> a...@eecs.berkeley.edu>; Alistair Francis ;
> Anup Patel ; devicet...@vger.kernel.org < 
> devicet...@vger.kernel.org>; linux-ri...@lists.infradead.org < 
> linux-ri...@lists.infradead.org>; Palmer Dabbelt
> ; Paul Walmsley ; Rob
> Herring <  robh...@kernel.org>; Daire McNamara - X61553 < 
> daire.mcnam...@microchip.com>; Cyril Jean - M31571 < 
> cyril.j...@microchip.com>; Ivan Griffin - X61451 < 
> ivan.grif...@microchip.com>; Conor Dooley - M52691 < 
> conor.doo...@microchip.com>
> Subject: [RFC PATCH v2 3/4] RISC-V: Initial DTS for Microchip ICICLE
> board 
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> Add initial DTS for Microchip ICICLE board having only
> essential devcies (clocks, sdhci, ethernet, serial, etc).
> The device tree is based on the U-Boot patch.
> 
>  
> https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/
> 
> Signed-off-by: Atish Patra 
> ---
>  arch/riscv/boot/dts/Makefile  |   1 +
>  arch/riscv/boot/dts/microchip/Makefile    |   2 +
>  .../microchip/microchip-mpfs-icicle-kit.dts   |  54 +++
>  .../boot/dts/microchip/microchip-mpfs.dtsi    | 342
> ++
>  4 files changed, 399 insertions(+)
>  create mode 100644 arch/riscv/boot/dts/microchip/Makefile
>  create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-
> icicle-kit.dts
>  create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> 
> diff --git a/arch/riscv/boot/dts/Makefile
> b/arch/riscv/boot/dts/Makefile
> index ca1f8cbd78c0..3ea94ea0a18a 100644
> --- a/arch/riscv/boot/dts/Makefile
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  subdir-y += sifive
>  subdir-y += kendryte
> +subdir-y += microchip
> 
>  obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
> diff --git a/arch/riscv/boot/dts/microchip/Makefile
> b/arch/riscv/boot/dts/microchip/Makefile
> new file mode 100644
> index ..622b12771fd3
> --- /dev/null
> +++ b/arch/riscv/boot/dts/microchip/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-
> kit.dtb
> diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-
> kit.dts b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> new file mode 100644
> index ..9a382ab0a799
> --- /dev/null
> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> @@ -0,0 +1,54 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Copyright (c) 2020 Microchip Technology Inc */
> +
> +/dts-v1/;
> +
> +#include "microchip-mpfs.dtsi"
> +
> +/* Clock frequency (in Hz) of the rtcclk */
> +#define RTCCLK_FREQ    100
> +
> +/ {
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +   model = "Microchip PolarFire-SoC Icicle Kit";
> +   compatible = "microchip,mpfs-icicle-kit",
> "microchip,polarfire-soc";
> +
> +   chosen {
> +   stdout-path = 
> +   };
> +
> +   cpus {
> +   timebase-frequency = ;
> +   };
> +
> +   memory@8000 {
> +   device_type = "memory";
> +   reg = <0x0 0x8000 0x0 0x4000>;
> +   clocks = < 26>;
> +   };
> +
> +   soc {
> +   };
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> new file mode 100644
> index ..63ac60f345d8
> --- /dev/null
> +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> @@ -0,0 +1,342 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Copyright (c) 2020 Microchip Technology Inc */
> +
> +/dts-v1/;
> +
> +/ {
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +   model = "Microchip PolarFire-SoC";
> +   compatible = "microchip,polarfire-soc";
> +
> +   chosen {
> +   

Re: [PATCH] riscv: toggle mmu_enabled flag in a precise manner

2020-12-01 Thread Atish Patra
On Tue, Dec 1, 2020 at 1:01 AM  wrote:
>
> From: Vitaly Wool 
>
> Cuurently mmu_enabled flag is set to true way later than the actual
> MMU enablement takes place. This leads to hard-to-track races in
> e. g. SBI earlycon initialization taking wrong path configuring
> fixmap.
>

This code path is significantly changed in 5.10-rcX with UEFI series.
https://patchwork.kernel.org/project/linux-riscv/patch/20200917223716.2300238-4-atish.pa...@wdc.com/

Can you check if you can still reproduce the issue you were seeing
with the latest upstream kernel ?
If yes, please share the steps to reproduce the issue.

> To fix that, move mmu_enabled toggling to head.S and rename it to
> _mmu_enabled to avoid possible name clashes since it's not a static
> variable any more.
>
> Signed-off-by: Vitaly Wool 
> ---
>  arch/riscv/kernel/head.S |  9 +
>  arch/riscv/mm/init.c | 13 +
>  2 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
> index 0a4e81b8dc79..33cd57285be3 100644
> --- a/arch/riscv/kernel/head.S
> +++ b/arch/riscv/kernel/head.S
> @@ -248,6 +248,10 @@ clear_bss_done:
> call relocate
>  #endif /* CONFIG_MMU */
>
> +   la a0, _mmu_enabled
> +   li a1, 1
> +   sw a1, (a0)
> +
> call setup_trap_vector
> /* Restore C environment */
> la tp, init_task
> @@ -370,6 +374,11 @@ ENTRY(reset_regs)
>  END(reset_regs)
>  #endif /* CONFIG_RISCV_M_MODE */
>
> +.section ".data"
> +   .global _mmu_enabled
> +_mmu_enabled:
> +   .word 0
> +
>  __PAGE_ALIGNED_BSS
> /* Empty zero page */
> .balign PAGE_SIZE
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 787c75f751a5..4038be635e25 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -211,7 +211,7 @@ EXPORT_SYMBOL(pfn_base);
>  pgd_t swapper_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
>  pgd_t trampoline_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
>  pte_t fixmap_pte[PTRS_PER_PTE] __page_aligned_bss;
> -static bool mmu_enabled;
> +extern bool _mmu_enabled;
>
>  #define MAX_EARLY_MAPPING_SIZE SZ_128M
>
> @@ -236,7 +236,7 @@ void __set_fixmap(enum fixed_addresses idx, phys_addr_t 
> phys, pgprot_t prot)
>
>  static pte_t *__init get_pte_virt(phys_addr_t pa)
>  {
> -   if (mmu_enabled) {
> +   if (_mmu_enabled) {
> clear_fixmap(FIX_PTE);
> return (pte_t *)set_fixmap_offset(FIX_PTE, pa);
> } else {
> @@ -250,7 +250,7 @@ static phys_addr_t __init alloc_pte(uintptr_t va)
>  * We only create PMD or PGD early mappings so we
>  * should never reach here with MMU disabled.
>  */
> -   BUG_ON(!mmu_enabled);
> +   BUG_ON(!_mmu_enabled);
>
> return memblock_phys_alloc(PAGE_SIZE, PAGE_SIZE);
>  }
> @@ -281,7 +281,7 @@ pmd_t early_pmd[PTRS_PER_PMD * NUM_EARLY_PMDS] __initdata 
> __aligned(PAGE_SIZE);
>
>  static pmd_t *__init get_pmd_virt(phys_addr_t pa)
>  {
> -   if (mmu_enabled) {
> +   if (_mmu_enabled) {
> clear_fixmap(FIX_PMD);
> return (pmd_t *)set_fixmap_offset(FIX_PMD, pa);
> } else {
> @@ -293,7 +293,7 @@ static phys_addr_t __init alloc_pmd(uintptr_t va)
>  {
> uintptr_t pmd_num;
>
> -   if (mmu_enabled)
> +   if (_mmu_enabled)
> return memblock_phys_alloc(PAGE_SIZE, PAGE_SIZE);
>
> pmd_num = (va - PAGE_OFFSET) >> PGDIR_SHIFT;
> @@ -467,9 +467,6 @@ static void __init setup_vm_final(void)
> phys_addr_t pa, start, end;
> struct memblock_region *reg;
>
> -   /* Set mmu_enabled flag */
> -   mmu_enabled = true;
> -
> /* Setup swapper PGD for fixmap */
> create_pgd_mapping(swapper_pg_dir, FIXADDR_START,
>__pa_symbol(fixmap_pgd_next),
> --
> 2.20.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


Re: [PATCH v3] RISC-V: Use SBI SRST extension when available

2020-11-30 Thread Atish Patra
On Tue, Nov 24, 2020 at 9:18 PM Anup Patel  wrote:
>
> The SBI SRST extension provides a standard way to poweroff and
> reboot the system irrespective to whether Linux RISC-V S-mode
> is running natively (HS-mode) or inside Guest/VM (VS-mode).
>
> The SBI SRST extension is available in latest SBI v0.3-draft
> specification at: https://github.com/riscv/riscv-sbi-doc.
>
> This patch extends Linux RISC-V SBI implementation to detect
> and use SBI SRST extension.
>
> Signed-off-by: Anup Patel 
> ---
> Changes since v2:
>  - Rebased on Linux-5.10-rc5
>  - Updated patch as-per SBI SRST extension available in the latest
>SBI v0.3-draft specification
> Changes since v1:
>  - Updated patch as-per latest SBI SRST extension draft spec where
>we have only one SBI call with "reset_type" parameter
> ---
>  arch/riscv/include/asm/sbi.h | 16 
>  arch/riscv/kernel/sbi.c  | 34 ++
>  2 files changed, 50 insertions(+)
>
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 653edb25d495..5b2d6d614c20 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -27,6 +27,7 @@ enum sbi_ext_id {
> SBI_EXT_IPI = 0x735049,
> SBI_EXT_RFENCE = 0x52464E43,
> SBI_EXT_HSM = 0x48534D,
> +   SBI_EXT_SRST = 0x53525354,
>  };
>
>  enum sbi_ext_base_fid {
> @@ -70,6 +71,21 @@ enum sbi_hsm_hart_status {
> SBI_HSM_HART_STATUS_STOP_PENDING,
>  };
>
> +enum sbi_ext_srst_fid {
> +   SBI_EXT_SRST_RESET = 0,
> +};
> +
> +enum sbi_srst_reset_type {
> +   SBI_SRST_RESET_TYPE_SHUTDOWN = 0,
> +   SBI_SRST_RESET_TYPE_COLD_REBOOT,
> +   SBI_SRST_RESET_TYPE_WARM_REBOOT,
> +};
> +
> +enum sbi_srst_reset_reason {
> +   SBI_SRST_RESET_REASON_NONE = 0,
> +   SBI_SRST_RESET_REASON_SYS_FAILURE,
> +};
> +
>  #define SBI_SPEC_VERSION_DEFAULT   0x1
>  #define SBI_SPEC_VERSION_MAJOR_SHIFT   24
>  #define SBI_SPEC_VERSION_MAJOR_MASK0x7f
> diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
> index 226ccce0f9e0..33b834ecd195 100644
> --- a/arch/riscv/kernel/sbi.c
> +++ b/arch/riscv/kernel/sbi.c
> @@ -7,6 +7,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -501,6 +502,32 @@ int sbi_remote_hfence_vvma_asid(const unsigned long 
> *hart_mask,
>  }
>  EXPORT_SYMBOL(sbi_remote_hfence_vvma_asid);
>
> +static void sbi_srst_reset(unsigned long type, unsigned long reason)
> +{
> +   sbi_ecall(SBI_EXT_SRST, SBI_EXT_SRST_RESET, type, reason,
> + 0, 0, 0, 0);
> +   pr_warn("%s: type=0x%lx reason=0x%lx failed\n",
> +   __func__, type, reason);

sbi_system_reset may return the failure reason as well. I think we can
print that in the warning message if present.

> +}
> +
> +static int sbi_srst_reboot(struct notifier_block *this,
> +  unsigned long mode, void *cmd)
> +{
> +   sbi_srst_reset((mode == REBOOT_WARM || mode == REBOOT_SOFT) ?
> +  SBI_SRST_RESET_TYPE_WARM_REBOOT :
> +  SBI_SRST_RESET_TYPE_COLD_REBOOT,
> +  SBI_SRST_RESET_REASON_NONE);
> +   return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block sbi_srst_reboot_nb;
> +
> +static void sbi_srst_power_off(void)
> +{
> +   sbi_srst_reset(SBI_SRST_RESET_TYPE_SHUTDOWN,
> +  SBI_SRST_RESET_REASON_NONE);
> +}
> +
>  /**
>   * sbi_probe_extension() - Check if an SBI extension ID is supported or not.
>   * @extid: The extension ID to be probed.
> @@ -593,6 +620,13 @@ int __init sbi_init(void)
> } else {
> __sbi_rfence= __sbi_rfence_v01;
> }
> +   if (sbi_probe_extension(SBI_EXT_SRST) > 0) {
> +   pr_info("SBI v0.2 SRST extension detected\n");
> +   pm_power_off = sbi_srst_power_off;
> +   sbi_srst_reboot_nb.notifier_call = sbi_srst_reboot;
> +   sbi_srst_reboot_nb.priority = 192;
> +   register_restart_handler(_srst_reboot_nb);
> +   }
> } else {
> __sbi_set_timer = __sbi_set_timer_v01;
> __sbi_send_ipi  = __sbi_send_ipi_v01;
> --
> 2.25.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Apart from that, it looks good to me.

Reviewed-by: Atish Patra 

-- 
Regards,
Atish


Re: [PATCH 0/6] Add SBI v0.2 support for KVM

2020-11-30 Thread Atish Patra
On Fri, 2020-11-27 at 13:44 +0530, Anup Patel wrote:
> On Mon, Aug 3, 2020 at 11:29 PM Atish Patra 
> wrote:
> > 
> > The Supervisor Binary Interface(SBI) specification[1] now defines a
> > base extension that provides extendability to add future extensions
> > while maintaining backward compatibility with previous versions.
> > The new version is defined as 0.2 and older version is marked as
> > 0.1.
> > 
> > This series adds following features to RISC-V Linux KVM.
> > 1. Adds support for SBI v0.2 in KVM
> > 2. SBI Hart state management extension (HSM) in KVM
> > 3. Ordered booting of guest vcpus in guest Linux
> > 
> > This series depends on the base kvm support series[2].
> > 
> > Guest kernel needs to also support SBI v0.2 and HSM extension in
> > Kernel
> > to boot multiple vcpus. Linux kernel supports both starting v5.7.
> > In absense of that, guest can only boot 1vcpu.
> > 
> > [1]  
> > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
> > [2]  
> > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001028.html
> > 
> > Atish Patra (6):
> > RISC-V: Add a non-void return for sbi v02 functions
> > RISC-V: Mark the existing SBI v0.1 implementation as legacy
> > RISC-V: Reorganize SBI code by moving legacy SBI to its own file
> > RISC-V: Add SBI v0.2 base extension
> > RISC-V: Add v0.1 replacement SBI extensions defined in v02
> > RISC-V: Add SBI HSM extension in KVM
> > 
> > arch/riscv/include/asm/kvm_vcpu_sbi.h |  32 +
> > arch/riscv/include/asm/sbi.h  |  17 ++-
> > arch/riscv/kernel/sbi.c   |  32 ++---
> > arch/riscv/kvm/Makefile   |   4 +-
> > arch/riscv/kvm/vcpu.c |  19 +++
> > arch/riscv/kvm/vcpu_sbi.c | 194 ---
> > ---
> > arch/riscv/kvm/vcpu_sbi_base.c    |  73 ++
> > arch/riscv/kvm/vcpu_sbi_hsm.c | 109 +++
> > arch/riscv/kvm/vcpu_sbi_legacy.c  | 129 +
> > arch/riscv/kvm/vcpu_sbi_replace.c | 136 ++
> > 10 files changed, 619 insertions(+), 126 deletions(-)
> > create mode 100644 arch/riscv/include/asm/kvm_vcpu_sbi.h
> > create mode 100644 arch/riscv/kvm/vcpu_sbi_base.c
> > create mode 100644 arch/riscv/kvm/vcpu_sbi_hsm.c
> > create mode 100644 arch/riscv/kvm/vcpu_sbi_legacy.c
> > create mode 100644 arch/riscv/kvm/vcpu_sbi_replace.c
> > 
> > --
> > 2.24.0
> > 
> 
> Please implement the SBI SRST extension in your series.
> 

Yeah. I will update the series as per new SRST extension.

> Also, the PATCH1 can be merged separately so I would suggest
> you to send this patch separately.
> 

Sure will do that.

> Regards,
> Anup

-- 
Regards,
Atish


Re: [PATCH] RISC-V: Define get_cycles64() regardless of M-mode

2020-11-25 Thread Atish Patra
On Wed, Nov 25, 2020 at 11:58 AM Palmer Dabbelt  wrote:
>
> From: Palmer Dabbelt 
>
> The timer driver uses get_cycles64() unconditionally to obtain the current
> time.  A recent refactoring lost the common definition for some configs, which
> is now the only one we need.
>
> Fixes: d5be89a8d118 ("RISC-V: Resurrect the MMIO timer implementation for 
> M-mode systems")
> Reported-by: kernel test robot 
> Signed-off-by: Palmer Dabbelt 
> ---
>  arch/riscv/include/asm/timex.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/include/asm/timex.h b/arch/riscv/include/asm/timex.h
> index ab104905d4db..81de51e6aa32 100644
> --- a/arch/riscv/include/asm/timex.h
> +++ b/arch/riscv/include/asm/timex.h
> @@ -60,6 +60,8 @@ static inline u32 get_cycles_hi(void)
>  }
>  #define get_cycles_hi get_cycles_hi
>
> +#endif /* !CONFIG_RISCV_M_MODE */
> +
>  #ifdef CONFIG_64BIT
>  static inline u64 get_cycles64(void)
>  {
> @@ -79,8 +81,6 @@ static inline u64 get_cycles64(void)
>  }
>  #endif /* CONFIG_64BIT */
>
> -#endif /* !CONFIG_RISCV_M_MODE */
> -
>  #define ARCH_HAS_READ_CURRENT_TIMER
>  static inline int read_current_timer(unsigned long *timer_val)
>  {
> --
> 2.29.2.454.gaff20da3a2-goog
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra 
-- 
Regards,
Atish


[PATCH v5 1/5] arm64, numa: Change the numa init functions name to be generic

2020-11-18 Thread Atish Patra
This is a preparatory patch for unifying numa implementation between
ARM64 & RISC-V. As the numa implementation will be moved to generic
code, rename the arm64 related functions to a generic one.

Signed-off-by: Atish Patra 
Acked-by: Catalin Marinas 
---
 arch/arm64/include/asm/numa.h |  4 ++--
 arch/arm64/kernel/acpi_numa.c | 12 
 arch/arm64/mm/init.c  |  4 ++--
 arch/arm64/mm/numa.c  | 27 +++
 4 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index dd870390d639..ffc1dcdf1871 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -32,7 +32,7 @@ static inline const struct cpumask *cpumask_of_node(int node)
 }
 #endif
 
-void __init arm64_numa_init(void);
+void __init arch_numa_init(void);
 int __init numa_add_memblk(int nodeid, u64 start, u64 end);
 void __init numa_set_distance(int from, int to, int distance);
 void __init numa_free_distance(void);
@@ -46,7 +46,7 @@ void numa_remove_cpu(unsigned int cpu);
 static inline void numa_store_cpu_info(unsigned int cpu) { }
 static inline void numa_add_cpu(unsigned int cpu) { }
 static inline void numa_remove_cpu(unsigned int cpu) { }
-static inline void arm64_numa_init(void) { }
+static inline void arch_numa_init(void) { }
 static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
 
 #endif /* CONFIG_NUMA */
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 7ff800045434..fdfecf0991ce 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -118,15 +118,3 @@ void __init acpi_numa_gicc_affinity_init(struct 
acpi_srat_gicc_affinity *pa)
node_set(node, numa_nodes_parsed);
 }
 
-int __init arm64_acpi_numa_init(void)
-{
-   int ret;
-
-   ret = acpi_numa_init();
-   if (ret) {
-   pr_info("Failed to initialise from firmware\n");
-   return ret;
-   }
-
-   return srat_disabled() ? -EINVAL : 0;
-}
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 095540667f0f..977b47f6815a 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -407,10 +407,10 @@ void __init bootmem_init(void)
max_pfn = max_low_pfn = max;
min_low_pfn = min;
 
-   arm64_numa_init();
+   arch_numa_init();
 
/*
-* must be done after arm64_numa_init() which calls numa_init() to
+* must be done after arch_numa_init() which calls numa_init() to
 * initialize node_online_map that gets used in hugetlb_cma_reserve()
 * while allocating required CMA size across online nodes.
 */
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index a8303bc6b62a..0dae54ce7d43 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
@@ -445,16 +444,36 @@ static int __init dummy_numa_init(void)
return 0;
 }
 
+#ifdef CONFIG_ACPI_NUMA
+static int __init arch_acpi_numa_init(void)
+{
+   int ret;
+
+   ret = acpi_numa_init();
+   if (ret) {
+   pr_info("Failed to initialise from firmware\n");
+   return ret;
+   }
+
+   return srat_disabled() ? -EINVAL : 0;
+}
+#else
+static int __init arch_acpi_numa_init(void)
+{
+   return -EOPNOTSUPP;
+}
+#endif
+
 /**
- * arm64_numa_init() - Initialize NUMA
+ * arch_numa_init() - Initialize NUMA
  *
  * Try each configured NUMA initialization method until one succeeds. The
  * last fallback is dummy single node config encompassing whole memory.
  */
-void __init arm64_numa_init(void)
+void __init arch_numa_init(void)
 {
if (!numa_off) {
-   if (!acpi_disabled && !numa_init(arm64_acpi_numa_init))
+   if (!acpi_disabled && !numa_init(arch_acpi_numa_init))
return;
if (acpi_disabled && !numa_init(of_numa_init))
return;
-- 
2.25.1



[PATCH v5 3/5] riscv: Separate memory init from paging init

2020-11-18 Thread Atish Patra
Currently, we perform some memory init functions in paging init. But,
that will be an issue for NUMA support where DT needs to be flattened
before numa initialization and memblock_present can only be called
after numa initialization.

Move memory initialization related functions to a separate function.

Signed-off-by: Atish Patra 
Reviewed-by: Greentime Hu 
Reviewed-by: Anup Patel 
Reviewed-by: Palmer Dabbelt 
---
 arch/riscv/include/asm/pgtable.h | 1 +
 arch/riscv/kernel/setup.c| 1 +
 arch/riscv/mm/init.c | 6 +-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 183f1f4b2ae6..a0f8a86236e8 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -471,6 +471,7 @@ extern void *dtb_early_va;
 extern uintptr_t dtb_early_pa;
 void setup_bootmem(void);
 void paging_init(void);
+void misc_mem_init(void);
 
 #define FIRST_USER_ADDRESS  0
 
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index c424cc6dd833..eb1cbdc29ea7 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -88,6 +88,7 @@ void __init setup_arch(char **cmdline_p)
else
pr_err("No DTB found in kernel mappings\n");
 #endif
+   misc_mem_init();
 
 #ifdef CONFIG_SWIOTLB
swiotlb_init(1);
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 8e577f14f120..826e7de73f45 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -664,8 +664,12 @@ static void __init resource_init(void)
 void __init paging_init(void)
 {
setup_vm_final();
-   sparse_init();
setup_zero_page();
+}
+
+void __init misc_mem_init(void)
+{
+   sparse_init();
zone_sizes_init();
resource_init();
 }
-- 
2.25.1



[PATCH v5 5/5] riscv: Add numa support for riscv64 platform

2020-11-18 Thread Atish Patra
Use the generic numa implementation to add NUMA support for RISC-V.
This is based on Greentime's patch[1] but modified to use generic NUMA
implementation and few more fixes.

[1] https://lkml.org/lkml/2020/1/10/233

Co-developed-by: Greentime Hu 
Signed-off-by: Greentime Hu 
Signed-off-by: Atish Patra 
Reviewed-by: Anup Patel 
Reviewed-by: Palmer Dabbelt 
---
 arch/riscv/Kconfig  | 31 ++-
 arch/riscv/include/asm/mmzone.h | 13 +
 arch/riscv/include/asm/numa.h   |  8 
 arch/riscv/include/asm/pci.h| 14 ++
 arch/riscv/kernel/setup.c   | 10 --
 arch/riscv/kernel/smpboot.c | 12 +++-
 arch/riscv/mm/init.c|  4 +++-
 7 files changed, 87 insertions(+), 5 deletions(-)
 create mode 100644 arch/riscv/include/asm/mmzone.h
 create mode 100644 arch/riscv/include/asm/numa.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 44377fd7860e..5414fe747f64 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -140,7 +140,7 @@ config PAGE_OFFSET
default 0xffe0 if 64BIT && MAXPHYSMEM_128GB
 
 config ARCH_FLATMEM_ENABLE
-   def_bool y
+   def_bool !NUMA
 
 config ARCH_SPARSEMEM_ENABLE
def_bool y
@@ -298,6 +298,35 @@ config TUNE_GENERIC
 
 endchoice
 
+# Common NUMA Features
+config NUMA
+   bool "NUMA Memory Allocation and Scheduler Support"
+   select GENERIC_ARCH_NUMA
+   select OF_NUMA
+   select ARCH_SUPPORTS_NUMA_BALANCING
+   help
+ Enable NUMA (Non-Uniform Memory Access) support.
+
+ The kernel will try to allocate memory used by a CPU on the
+ local memory of the CPU and add some more NUMA awareness to the 
kernel.
+
+config NODES_SHIFT
+   int "Maximum NUMA Nodes (as a power of 2)"
+   range 1 10
+   default "2"
+   depends on NEED_MULTIPLE_NODES
+   help
+ Specify the maximum number of NUMA Nodes available on the target
+ system.  Increases memory reserved to accommodate various tables.
+
+config USE_PERCPU_NUMA_NODE_ID
+   def_bool y
+   depends on NUMA
+
+config NEED_PER_CPU_EMBED_FIRST_CHUNK
+   def_bool y
+   depends on NUMA
+
 config RISCV_ISA_C
bool "Emit compressed instructions when building Linux"
default y
diff --git a/arch/riscv/include/asm/mmzone.h b/arch/riscv/include/asm/mmzone.h
new file mode 100644
index ..fa17e01d9ab2
--- /dev/null
+++ b/arch/riscv/include/asm/mmzone.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_MMZONE_H
+#define __ASM_MMZONE_H
+
+#ifdef CONFIG_NUMA
+
+#include 
+
+extern struct pglist_data *node_data[];
+#define NODE_DATA(nid) (node_data[(nid)])
+
+#endif /* CONFIG_NUMA */
+#endif /* __ASM_MMZONE_H */
diff --git a/arch/riscv/include/asm/numa.h b/arch/riscv/include/asm/numa.h
new file mode 100644
index ..8c8cf4297cc3
--- /dev/null
+++ b/arch/riscv/include/asm/numa.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_NUMA_H
+#define __ASM_NUMA_H
+
+#include 
+#include 
+
+#endif /* __ASM_NUMA_H */
diff --git a/arch/riscv/include/asm/pci.h b/arch/riscv/include/asm/pci.h
index 1c473a1bd986..658e112c3ce7 100644
--- a/arch/riscv/include/asm/pci.h
+++ b/arch/riscv/include/asm/pci.h
@@ -32,6 +32,20 @@ static inline int pci_proc_domain(struct pci_bus *bus)
/* always show the domain in /proc */
return 1;
 }
+
+#ifdef CONFIG_NUMA
+
+static inline int pcibus_to_node(struct pci_bus *bus)
+{
+   return dev_to_node(>dev);
+}
+#ifndef cpumask_of_pcibus
+#define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ?\
+cpu_all_mask : \
+cpumask_of_node(pcibus_to_node(bus)))
+#endif
+#endif /* CONFIG_NUMA */
+
 #endif  /* CONFIG_PCI */
 
 #endif  /* _ASM_RISCV_PCI_H */
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index eb1cbdc29ea7..26712745c5df 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -111,13 +111,19 @@ void __init setup_arch(char **cmdline_p)
 
 static int __init topology_init(void)
 {
-   int i;
+   int i, ret;
+
+   for_each_online_node(i)
+   register_one_node(i);
 
for_each_possible_cpu(i) {
struct cpu *cpu = _cpu(cpu_devices, i);
 
cpu->hotpluggable = cpu_has_hotplug(i);
-   register_cpu(cpu, i);
+   ret = register_cpu(cpu, i);
+   if (unlikely(ret))
+   pr_warn("Warning: %s: register_cpu %d failed (%d)\n",
+  __func__, i, ret);
}
 
return 0;
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 96167d55ed98..5e276c25646f 100644
--- a/arch/riscv/kernel/smpboot.c
+++ b/arch/riscv/kernel/smpboot.c
@@ -27,6 +27,7 @@
 #include 
 #include 

[PATCH v5 2/5] numa: Move numa implementation to common code

2020-11-18 Thread Atish Patra
ARM64 numa implementation is generic enough that RISC-V can reuse that
implementation with very minor cosmetic changes. This will help both
ARM64 and RISC-V in terms of maintanace and feature improvement

Move the numa implementation code to common directory so that both ISAs
can reuse this. This doesn't introduce any function changes for ARM64.

Signed-off-by: Atish Patra 
Acked-by: Jonathan Cameron 
Tested-by: Jonathan Cameron 
Acked-by: Catalin Marinas 
---
 arch/arm64/Kconfig|  1 +
 arch/arm64/include/asm/numa.h | 48 +
 arch/arm64/mm/Makefile|  1 -
 drivers/base/Kconfig  |  6 +++
 drivers/base/Makefile |  1 +
 .../mm/numa.c => drivers/base/arch_numa.c |  0
 include/asm-generic/numa.h| 52 +++
 7 files changed, 61 insertions(+), 48 deletions(-)
 rename arch/arm64/mm/numa.c => drivers/base/arch_numa.c (100%)
 create mode 100644 include/asm-generic/numa.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1515f6f153a0..4ebef80274fd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -990,6 +990,7 @@ config HOTPLUG_CPU
 # Common NUMA Features
 config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
+   select GENERIC_ARCH_NUMA
select ACPI_NUMA if ACPI
select OF_NUMA
help
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index ffc1dcdf1871..8c8cf4297cc3 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -3,52 +3,6 @@
 #define __ASM_NUMA_H
 
 #include 
-
-#ifdef CONFIG_NUMA
-
-#define NR_NODE_MEMBLKS(MAX_NUMNODES * 2)
-
-int __node_distance(int from, int to);
-#define node_distance(a, b) __node_distance(a, b)
-
-extern nodemask_t numa_nodes_parsed __initdata;
-
-extern bool numa_off;
-
-/* Mappings between node number and cpus on that node. */
-extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
-void numa_clear_node(unsigned int cpu);
-
-#ifdef CONFIG_DEBUG_PER_CPU_MAPS
-const struct cpumask *cpumask_of_node(int node);
-#else
-/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
-static inline const struct cpumask *cpumask_of_node(int node)
-{
-   if (node == NUMA_NO_NODE)
-   return cpu_all_mask;
-
-   return node_to_cpumask_map[node];
-}
-#endif
-
-void __init arch_numa_init(void);
-int __init numa_add_memblk(int nodeid, u64 start, u64 end);
-void __init numa_set_distance(int from, int to, int distance);
-void __init numa_free_distance(void);
-void __init early_map_cpu_to_node(unsigned int cpu, int nid);
-void numa_store_cpu_info(unsigned int cpu);
-void numa_add_cpu(unsigned int cpu);
-void numa_remove_cpu(unsigned int cpu);
-
-#else  /* CONFIG_NUMA */
-
-static inline void numa_store_cpu_info(unsigned int cpu) { }
-static inline void numa_add_cpu(unsigned int cpu) { }
-static inline void numa_remove_cpu(unsigned int cpu) { }
-static inline void arch_numa_init(void) { }
-static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
-
-#endif /* CONFIG_NUMA */
+#include 
 
 #endif /* __ASM_NUMA_H */
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index 5ead3c3de3b6..cd60e4fed78f 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -6,7 +6,6 @@ obj-y   := dma-mapping.o extable.o 
fault.o init.o \
 obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
 obj-$(CONFIG_PTDUMP_CORE)  += ptdump.o
 obj-$(CONFIG_PTDUMP_DEBUGFS)   += ptdump_debugfs.o
-obj-$(CONFIG_NUMA) += numa.o
 obj-$(CONFIG_DEBUG_VIRTUAL)+= physaddr.o
 obj-$(CONFIG_ARM64_MTE)+= mteswap.o
 KASAN_SANITIZE_physaddr.o  += n
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 8d7001712062..c5956c8845cc 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -210,4 +210,10 @@ config GENERIC_ARCH_TOPOLOGY
  appropriate scaling, sysfs interface for reading capacity values at
  runtime.
 
+config GENERIC_ARCH_NUMA
+   bool
+   help
+ Enable support for generic NUMA implementation. Currently, RISC-V
+ and ARM64 uses it.
+
 endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 41369fc7004f..7d65ea07de65 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_PINCTRL) += pinctrl.o
 obj-$(CONFIG_DEV_COREDUMP) += devcoredump.o
 obj-$(CONFIG_GENERIC_MSI_IRQ_DOMAIN) += platform-msi.o
 obj-$(CONFIG_GENERIC_ARCH_TOPOLOGY) += arch_topology.o
+obj-$(CONFIG_GENERIC_ARCH_NUMA) += arch_numa.o
 
 obj-y  += test/
 
diff --git a/arch/arm64/mm/numa.c b/drivers/base/arch_numa.c
similarity index 100%
rename from arch/arm64/mm/numa.c
rename to drivers/base/arch_numa.c
diff --git a/include/asm-generic/numa.h b/include/asm-generic/numa.h
new file mode 100644
index ..1a3ad6d29833
--- /dev/null
+

[PATCH v5 4/5] riscv: Add support pte_protnone and pmd_protnone if CONFIG_NUMA_BALANCING

2020-11-18 Thread Atish Patra
From: Greentime Hu 

These two functions are used to distinguish between PROT_NONENUMA
protections and hinting fault protections.

Signed-off-by: Greentime Hu 
Reviewed-by: Anup Patel 
Reviewed-by: Palmer Dabbelt 
---
 arch/riscv/include/asm/pgtable.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index a0f8a86236e8..64aba4f7a0ed 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -187,6 +187,11 @@ static inline unsigned long pmd_page_vaddr(pmd_t pmd)
return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
 }
 
+static inline pte_t pmd_pte(pmd_t pmd)
+{
+   return __pte(pmd_val(pmd));
+}
+
 /* Yields the page frame number (PFN) of a page table entry */
 static inline unsigned long pte_pfn(pte_t pte)
 {
@@ -290,6 +295,21 @@ static inline pte_t pte_mkhuge(pte_t pte)
return pte;
 }
 
+#ifdef CONFIG_NUMA_BALANCING
+/*
+ * See the comment in include/asm-generic/pgtable.h
+ */
+static inline int pte_protnone(pte_t pte)
+{
+   return (pte_val(pte) & (_PAGE_PRESENT | _PAGE_PROT_NONE)) == 
_PAGE_PROT_NONE;
+}
+
+static inline int pmd_protnone(pmd_t pmd)
+{
+   return pte_protnone(pmd_pte(pmd));
+}
+#endif
+
 /* Modify page protection bits */
 static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
 {
-- 
2.25.1



[PATCH v5 0/5] Unify NUMA implementation between ARM64 & RISC-V

2020-11-18 Thread Atish Patra
This series attempts to move the ARM64 numa implementation to common
code so that RISC-V can leverage that as well instead of reimplementing
it again.

RISC-V specific bits are based on initial work done by Greentime Hu [1] but
modified to reuse the common implementation to avoid duplication.

[1] https://lkml.org/lkml/2020/1/10/233

This series has been tested on qemu with numa enabled for both RISC-V & ARM64.
It would be great if somebody can test it on numa capable ARM64 hardware 
platforms.
This patch series doesn't modify the maintainers list for the common code 
(arch_numa)
as I am not sure if somebody from ARM64 community or Greg should take up the
maintainership. Ganapatrao was the original author of the arm64 version.
I would be happy to update that in the next revision once it is decided.

# numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3
node 0 size: 486 MB
node 0 free: 470 MB
node 1 cpus: 4 5 6 7
node 1 size: 424 MB
node 1 free: 408 MB
node distances:
node   0   1 
  0:  10  20 
  1:  20  10 
# numactl -show
policy: default
preferred node: current
physcpubind: 0 1 2 3 4 5 6 7 
cpubind: 0 1 
nodebind: 0 1 
membind: 0 1 

The patches are also available at
https://github.com/atishp04/linux/tree/5.11_numa_unified_v5

For RISC-V, the following qemu series is a pre-requisite(already available in 
upstream)
https://patchwork.kernel.org/project/qemu-devel/list/?series=303313

Testing:
RISC-V:
Tested in Qemu and 2 socket OmniXtend FPGA.

ARM64:
2 socket kunpeng920 (4 nodes around 250G a node)
Tested-by: Jonathan Cameron 

Changes from v4->v5:
1. Added by Acked-by & Reviewed-by tags.
2. Swapped patch 1 & 2 in v4 version.

Changes from v3->v4:
1. Removed redundant duplicate header.
2. Added Reviewed-by tags.

Changes from v2->v3:
1. Added Acked-by/Reviewed-by tags.
2. Replaced asm/acpi.h with linux/acpi.h
3. Defined arch_acpi_numa_init as static.

Changes from v1->v2:
1. Replaced ARM64 specific compile time protection with ACPI specific ones.
2. Dropped common pcibus_to_node changes. Added required changes in RISC-V. 
3. Fixed few typos.

Atish Patra (4):
arm64, numa: Change the numa init functions name to be generic
numa: Move numa implementation to common code
riscv: Separate memory init from paging init
riscv: Add numa support for riscv64 platform

Greentime Hu (1):
riscv: Add support pte_protnone and pmd_protnone if
CONFIG_NUMA_BALANCING

arch/arm64/Kconfig|  1 +
arch/arm64/include/asm/numa.h | 48 +
arch/arm64/kernel/acpi_numa.c | 12 -
arch/arm64/mm/Makefile|  1 -
arch/arm64/mm/init.c  |  4 +-
arch/riscv/Kconfig| 31 ++-
arch/riscv/include/asm/mmzone.h   | 13 +
arch/riscv/include/asm/numa.h |  8 +++
arch/riscv/include/asm/pci.h  | 14 +
arch/riscv/include/asm/pgtable.h  | 21 
arch/riscv/kernel/setup.c | 11 +++-
arch/riscv/kernel/smpboot.c   | 12 -
arch/riscv/mm/init.c  | 10 +++-
drivers/base/Kconfig  |  6 +++
drivers/base/Makefile |  1 +
.../mm/numa.c => drivers/base/arch_numa.c | 27 --
include/asm-generic/numa.h| 52 +++
17 files changed, 200 insertions(+), 72 deletions(-)
create mode 100644 arch/riscv/include/asm/mmzone.h
create mode 100644 arch/riscv/include/asm/numa.h
rename arch/arm64/mm/numa.c => drivers/base/arch_numa.c (96%)
create mode 100644 include/asm-generic/numa.h

--
2.25.1



Re: [RFC PATCH v2 3/4] RISC-V: Initial DTS for Microchip ICICLE board

2020-11-16 Thread Atish Patra
On Mon, Nov 16, 2020 at 6:15 PM Bin Meng  wrote:
>
> On Sat, Nov 14, 2020 at 4:29 AM Atish Patra  wrote:
> >
> > Add initial DTS for Microchip ICICLE board having only
> > essential devcies (clocks, sdhci, ethernet, serial, etc).
>
> typo: devices
>

Thanks. Will fix it.

> > The device tree is based on the U-Boot patch.
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/
> >
> > Signed-off-by: Atish Patra 
> > ---
> >  arch/riscv/boot/dts/Makefile  |   1 +
> >  arch/riscv/boot/dts/microchip/Makefile|   2 +
> >  .../microchip/microchip-mpfs-icicle-kit.dts   |  54 +++
> >  .../boot/dts/microchip/microchip-mpfs.dtsi| 342 ++
> >  4 files changed, 399 insertions(+)
> >  create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> >  create mode 100644 
> > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> >  create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> >
> > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> > index ca1f8cbd78c0..3ea94ea0a18a 100644
> > --- a/arch/riscv/boot/dts/Makefile
> > +++ b/arch/riscv/boot/dts/Makefile
> > @@ -1,5 +1,6 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  subdir-y += sifive
> >  subdir-y += kendryte
> > +subdir-y += microchip
> >
> >  obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
> > diff --git a/arch/riscv/boot/dts/microchip/Makefile 
> > b/arch/riscv/boot/dts/microchip/Makefile
> > new file mode 100644
> > index ..622b12771fd3
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts 
> > b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > new file mode 100644
> > index ..9a382ab0a799
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > @@ -0,0 +1,54 @@
> > +// SPDX-License-Identifier: GPL-2.0+
>
> Please make this dual-licensed, GPL or MIT.
> See 
> https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp/blob/master/recipes-kernel/linux/files/icicle-kit-es/icicle-kit-es-a000-microchip.dts
>

I had that originally. Checkpatch did not like that. I will revert it
and investigate the real cause for the checkpatch complaint.

> > +/* Copyright (c) 2020 Microchip Technology Inc */
> > +
> > +/dts-v1/;
> > +
> > +#include "microchip-mpfs.dtsi"
> > +
> > +/* Clock frequency (in Hz) of the rtcclk */
> > +#define RTCCLK_FREQ100
> > +
> > +/ {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +   model = "Microchip PolarFire-SoC Icicle Kit";
> > +   compatible = "microchip,mpfs-icicle-kit", "microchip,polarfire-soc";
> > +
> > +   chosen {
> > +   stdout-path = 
> > +   };
> > +
> > +   cpus {
> > +   timebase-frequency = ;
> > +   };
> > +
> > +   memory@8000 {
> > +   device_type = "memory";
> > +   reg = <0x0 0x8000 0x0 0x4000>;
> > +   clocks = < 26>;
> > +   };
> > +
> > +   soc {
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi 
> > b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > new file mode 100644
> > index ..63ac60f345d8
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > @@ -0,0 +1,342 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/* Copyright (c) 2020 Microchip Technology Inc */
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +   model = "Microchip PolarFire-SoC";
> > +   c

Re: [RFC PATCH v2 2/4] dt-bindings: riscv: microchip: Add YAML documentation for the PolarFire SoC

2020-11-16 Thread Atish Patra
On Mon, Nov 16, 2020 at 7:23 AM Rob Herring  wrote:
>
> On Fri, 13 Nov 2020 12:25:48 -0800, Atish Patra wrote:
> > Add YAML DT binding documentation for the Microchip PolarFire SoC.
> > It is documented at:
> >
> > https://www.microsemi.com/products/fpga-soc/polarfire-soc-icicle-quick-start-guide
> >
> > Signed-off-by: Atish Patra 
> > ---
> >  .../devicetree/bindings/riscv/microchip.yaml  | 27 +++
> >  1 file changed, 27 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml
> >
>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> ./Documentation/devicetree/bindings/riscv/microchip.yaml: $id: relative 
> path/filename doesn't match actual path or filename
> expected: http://devicetree.org/schemas/riscv/microchip.yaml#
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/riscv/sifive.yaml:
>  duplicate '$id' value 'http://devicetree.org/schemas/riscv/sifive.yaml#'
>
>

Thanks for catching this. It was a copy paste error. I will fix it next version.

> See https://patchwork.ozlabs.org/patch/1400088
>
> The base for the patch is generally the last rc1. Any dependencies
> should be noted.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit.
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


[RFC PATCH v2 2/4] dt-bindings: riscv: microchip: Add YAML documentation for the PolarFire SoC

2020-11-13 Thread Atish Patra
Add YAML DT binding documentation for the Microchip PolarFire SoC.
It is documented at:

https://www.microsemi.com/products/fpga-soc/polarfire-soc-icicle-quick-start-guide

Signed-off-by: Atish Patra 
---
 .../devicetree/bindings/riscv/microchip.yaml  | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml

diff --git a/Documentation/devicetree/bindings/riscv/microchip.yaml 
b/Documentation/devicetree/bindings/riscv/microchip.yaml
new file mode 100644
index ..9c227fee0b9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/microchip.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/sifive.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PolarFire SoC-based boards device tree bindings
+
+maintainers:
+  - Cyril Jean 
+
+description:
+  Microchip PolarFire SoC-based boards
+
+properties:
+  $nodename:
+const: '/'
+  compatible:
+items:
+  - enum:
+  - microchip,mpfs-icicle-kit
+  - const: microchip,polarfire-soc
+  - const: microchip,mpfs
+
+additionalProperties: true
+
+...
-- 
2.25.1



[RFC PATCH v2 1/4] RISC-V: Add Microchip PolarFire SoC kconfig option

2020-11-13 Thread Atish Patra
Add Microchip PolarFire kconfig option which selects SoC specific
and common drivers that is required for this SoC.

Signed-off-by: Atish Patra 
Reviewed-by: Bin Meng 
Reviewed-by: Anup Patel 
---
 arch/riscv/Kconfig.socs | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 8a55f6156661..148ab095966b 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -1,5 +1,12 @@
 menu "SoC selection"
 
+config SOC_MICROCHIP_POLARFIRE
+   bool "Microchip PolarFire SoCs"
+   select MCHP_CLK_PFSOC
+   select SIFIVE_PLIC
+   help
+ This enables support for Microchip PolarFire SoC platforms.
+
 config SOC_SIFIVE
bool "SiFive SoCs"
select SERIAL_SIFIVE if TTY
-- 
2.25.1



[RFC PATCH v2 3/4] RISC-V: Initial DTS for Microchip ICICLE board

2020-11-13 Thread Atish Patra
Add initial DTS for Microchip ICICLE board having only
essential devcies (clocks, sdhci, ethernet, serial, etc).
The device tree is based on the U-Boot patch.

https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/

Signed-off-by: Atish Patra 
---
 arch/riscv/boot/dts/Makefile  |   1 +
 arch/riscv/boot/dts/microchip/Makefile|   2 +
 .../microchip/microchip-mpfs-icicle-kit.dts   |  54 +++
 .../boot/dts/microchip/microchip-mpfs.dtsi| 342 ++
 4 files changed, 399 insertions(+)
 create mode 100644 arch/riscv/boot/dts/microchip/Makefile
 create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
 create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi

diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index ca1f8cbd78c0..3ea94ea0a18a 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 subdir-y += sifive
 subdir-y += kendryte
+subdir-y += microchip
 
 obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
diff --git a/arch/riscv/boot/dts/microchip/Makefile 
b/arch/riscv/boot/dts/microchip/Makefile
new file mode 100644
index ..622b12771fd3
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts 
b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
new file mode 100644
index ..9a382ab0a799
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (c) 2020 Microchip Technology Inc */
+
+/dts-v1/;
+
+#include "microchip-mpfs.dtsi"
+
+/* Clock frequency (in Hz) of the rtcclk */
+#define RTCCLK_FREQ100
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   model = "Microchip PolarFire-SoC Icicle Kit";
+   compatible = "microchip,mpfs-icicle-kit", "microchip,polarfire-soc";
+
+   chosen {
+   stdout-path = 
+   };
+
+   cpus {
+   timebase-frequency = ;
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x0 0x8000 0x0 0x4000>;
+   clocks = < 26>;
+   };
+
+   soc {
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi 
b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
new file mode 100644
index ..63ac60f345d8
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (c) 2020 Microchip Technology Inc */
+
+/dts-v1/;
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   model = "Microchip PolarFire-SoC";
+   compatible = "microchip,polarfire-soc";
+
+   chosen {
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   clock-frequency = <0>;
+   compatible = "sifive,rocket0", "riscv";
+   device_type = "cpu";
+   i-cache-block-size = <64>;
+   i-cache-sets = <128>;
+   i-cache-size = <16384>;
+   reg = <0>;
+   riscv,isa = "rv64imac";
+   status = "disabled";
+
+   cpu0_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+
+   cpu@1 {
+   clock-frequency = <0>;
+   compatible = "sifive,rocket0", "riscv";
+   d-cache-block-size = <64>;
+   d-cache-sets = <64>;
+   d-cache-size = <32768>;
+   d-tlb-sets = <1>;
+   d-tlb-size = <32>;
+   device_type = "cpu";
+   i-cache-block-size = <64>;
+   i-cache-sets = <64>;
+   i-cache-size = <32768>;
+   

[RFC PATCH v2 0/4] Add Microchip PolarFire Soc Support

2020-11-13 Thread Atish Patra
This series adds minimal support for Microchip Polar Fire Soc Icicle kit.
It is rebased on v5.10-rc3 and depends on clock support. 
Only MMC and ethernet drivers are enabled via this series.
The idea here is to add the foundational patches so that other drivers
can be added to on top of this. The device tree may change based on
feedback on bindings of individual driver support patches.

This series has been tested on Qemu and Polar Fire Soc Icicle kit.
The following qemu series is necessary to test it on Qemu.

The series can also be found at.
https://github.com/atishp04/linux/tree/polarfire_support_upstream_v2

I noticed the latest version of mmc driver[2] hangs on the board with
the latest clock driver. That's why, I have tested with the old clock
driver available in the above github repo.

[1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html
[2] https://www.spinics.net/lists/devicetree/msg383626.html

@Cyril: I have added you as the maintainer for this board as I am not sure
who else from Microchip should be the added to the maintainer list. Please
let me know and I can add the entry to the MAINTAINERS file in next version.

Changes from v1->v2:
1. Modified the DT to match the device tree in U-Boot.
2. Added both eMMC & SDcard entries in DT. However, SD card is only enabled
   as it allows larger storage option for linux distros.

Atish Patra (4):
RISC-V: Add Microchip PolarFire SoC kconfig option
dt-bindings: riscv: microchip: Add YAML documentation for the
PolarFire SoC
RISC-V: Initial DTS for Microchip ICICLE board
RISC-V: Enable Microchip PolarFire ICICLE SoC

.../devicetree/bindings/riscv/microchip.yaml  |  27 ++
arch/riscv/Kconfig.socs   |   7 +
arch/riscv/boot/dts/Makefile  |   1 +
arch/riscv/boot/dts/microchip/Makefile|   2 +
.../microchip/microchip-mpfs-icicle-kit.dts   |  54 +++
.../boot/dts/microchip/microchip-mpfs.dtsi| 342 ++
arch/riscv/configs/defconfig  |   4 +
7 files changed, 437 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml
create mode 100644 arch/riscv/boot/dts/microchip/Makefile
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi

--
2.25.1



[RFC PATCH v2 4/4] RISC-V: Enable Microchip PolarFire ICICLE SoC

2020-11-13 Thread Atish Patra
Enable Microchip PolarFire ICICLE soc config in defconfig.
It allows the default upstream kernel to boot on PolarFire ICICLE board.

Signed-off-by: Atish Patra 
Reviewed-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 arch/riscv/configs/defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index d222d353d86d..2660fa05451e 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -16,6 +16,7 @@ CONFIG_EXPERT=y
 CONFIG_BPF_SYSCALL=y
 CONFIG_SOC_SIFIVE=y
 CONFIG_SOC_VIRT=y
+CONFIG_SOC_MICROCHIP_POLARFIRE=y
 CONFIG_SMP=y
 CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
@@ -79,6 +80,9 @@ CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_UAS=y
+CONFIG_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_CADENCE=y
 CONFIG_MMC=y
 CONFIG_MMC_SPI=y
 CONFIG_RTC_CLASS=y
-- 
2.25.1



Re: [PATCH v4 2/5] arm64, numa: Change the numa init functions name to be generic

2020-11-06 Thread Atish Patra
On Fri, Nov 6, 2020 at 11:08 AM Catalin Marinas  wrote:
>
> On Fri, Nov 06, 2020 at 09:33:14AM -0800, Atish Patra wrote:
> > On Fri, Nov 6, 2020 at 9:14 AM Catalin Marinas  
> > wrote:
> > > On Mon, Oct 05, 2020 at 05:17:49PM -0700, Atish Patra wrote:
> > > > diff --git a/arch/arm64/kernel/acpi_numa.c 
> > > > b/arch/arm64/kernel/acpi_numa.c
> > > > index 7ff800045434..96502ff92af5 100644
> > > > --- a/arch/arm64/kernel/acpi_numa.c
> > > > +++ b/arch/arm64/kernel/acpi_numa.c
> > > > @@ -117,16 +117,3 @@ void __init acpi_numa_gicc_affinity_init(struct 
> > > > acpi_srat_gicc_affinity *pa)
> > > >
> > > >   node_set(node, numa_nodes_parsed);
> > > >  }
> > > > -
> > > > -int __init arm64_acpi_numa_init(void)
> > > > -{
> > > > - int ret;
> > > > -
> > > > - ret = acpi_numa_init();
> > > > - if (ret) {
> > > > - pr_info("Failed to initialise from firmware\n");
> > > > - return ret;
> > > > - }
> > > > -
> > > > - return srat_disabled() ? -EINVAL : 0;
> > > > -}
> > >
> > > I think it's better if arm64_acpi_numa_init() and arm64_numa_init()
> > > remained in the arm64 code. It's not really much code to be shared.
> >
> > RISC-V will probably support ACPI one day. The idea is to not to do
> > exercise again in future.
> > Moreover, there will be arch_numa_init which will be used by RISC-V
> > and there will be arm64_numa_init
> > used by arm64. However, if you feel strongly about it, I am happy to
> > move back those two functions to arm64.
>
> I don't have a strong view on this, only if there's a risk at some point
> of the implementations diverging (e.g. quirks). We can revisit it if
> that happens.
>

Sure. I seriously hope we don't have to deal with arch specific quirks
in future.

> It may be worth swapping patches 1 and 2 so that you don't have an
> arm64_* function in the core code after the first patch (more of a
> nitpick). Either way, feel free to add my ack on both patches:
>

Sure. I will swap 1 & 2 and resend the series.

> Acked-by: Catalin Marinas 

Thanks.

-- 
Regards,
Atish


Re: [PATCH v4 2/5] arm64, numa: Change the numa init functions name to be generic

2020-11-06 Thread Atish Patra
On Fri, Nov 6, 2020 at 9:14 AM Catalin Marinas  wrote:
>
> On Mon, Oct 05, 2020 at 05:17:49PM -0700, Atish Patra wrote:
> > diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> > index 7ff800045434..96502ff92af5 100644
> > --- a/arch/arm64/kernel/acpi_numa.c
> > +++ b/arch/arm64/kernel/acpi_numa.c
> > @@ -117,16 +117,3 @@ void __init acpi_numa_gicc_affinity_init(struct 
> > acpi_srat_gicc_affinity *pa)
> >
> >   node_set(node, numa_nodes_parsed);
> >  }
> > -
> > -int __init arm64_acpi_numa_init(void)
> > -{
> > - int ret;
> > -
> > - ret = acpi_numa_init();
> > - if (ret) {
> > - pr_info("Failed to initialise from firmware\n");
> > - return ret;
> > - }
> > -
> > - return srat_disabled() ? -EINVAL : 0;
> > -}
>
> I think it's better if arm64_acpi_numa_init() and arm64_numa_init()
> remained in the arm64 code. It's not really much code to be shared.
>

RISC-V will probably support ACPI one day. The idea is to not to do
exercise again in future.
Moreover, there will be arch_numa_init which will be used by RISC-V
and there will be arm64_numa_init
used by arm64. However, if you feel strongly about it, I am happy to
move back those two functions to arm64.

In case, we decide to go that route, can we define arm64_numa_init in
mm/init.c ?
Defining numa.c just for arm64_numa_init in arm64 may be an overkill.

> > diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
> > index 73f8b49d485c..74b4f2ddad70 100644
> > --- a/drivers/base/arch_numa.c
> > +++ b/drivers/base/arch_numa.c
> > @@ -13,7 +13,6 @@
> >  #include 
> >  #include 
> >
> > -#include 
> >  #include 
> >
> >  struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
> > @@ -444,16 +443,37 @@ static int __init dummy_numa_init(void)
> >   return 0;
> >  }
> >
> > +#ifdef CONFIG_ACPI_NUMA
> > +static int __init arch_acpi_numa_init(void)
> > +{
> > + int ret;
> > +
> > + ret = acpi_numa_init();
> > + if (ret) {
> > + pr_info("Failed to initialise from firmware\n");
> > + return ret;
> > + }
> > +
> > + return srat_disabled() ? -EINVAL : 0;
> > +}
> > +#else
> > +static int __init arch_acpi_numa_init(void)
> > +{
> > + return -EOPNOTSUPP;
> > +}
> > +
> > +#endif
> > +
> >  /**
> > - * arm64_numa_init() - Initialize NUMA
> > + * arch_numa_init() - Initialize NUMA
> >   *
> >   * Try each configured NUMA initialization method until one succeeds. The
> > - * last fallback is dummy single node config encomapssing whole memory.
> > + * last fallback is dummy single node config encompassing whole memory.
> >   */
> > -void __init arm64_numa_init(void)
> > +void __init arch_numa_init(void)
> >  {
> >   if (!numa_off) {
> > - if (!acpi_disabled && !numa_init(arm64_acpi_numa_init))
> > + if (!acpi_disabled && !numa_init(arch_acpi_numa_init))
> >   return;
> >   if (acpi_disabled && !numa_init(of_numa_init))
> >   return;
>
> Does riscv even have an acpi_disabled variable?
>
It is defined in "include/linux/acpi.h" which is included in arch_numa.c

> --
> Catalin
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


Re: [RFC PATCH 0/3] Add Microchip PolarFire Soc Support

2020-11-05 Thread Atish Patra
On Thu, Nov 5, 2020 at 11:14 PM Palmer Dabbelt  wrote:
>
> On Wed, 28 Oct 2020 16:27:56 PDT (-0700), Atish Patra wrote:
> > This series adds minimal support for Microchip Polar Fire Soc Icicle kit.
> > It is rebased on v5.10-rc1 and depends on clock support.
> > Only MMC and ethernet drivers are enabled via this series.
> > The idea here is to add the foundational patches so that other drivers
> > can be added to on top of this.
> >
> > This series has been tested on Qemu and Polar Fire Soc Icicle kit.
> > The following qemu series is necessary to test it on Qemu.
> >
> > The series can also be found at the following github repo.
> >
> > I noticed the latest version of mmc driver[2] hangs on the board with
> > the latest clock driver. That's why, I have tested with the old clock
> > driver available in the above github repo.
>
> OK, I guess that's why it's an RFC?
>

Yes. The latest clock/pcie driver did not work for me. I might have
missed something in DT.
The idea for RFC is so that anybody who wants to try the latest kernel
on a polarfire board
has a meaningful way to test it.

> > [1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html
> > [2] https://www.spinics.net/lists/devicetree/msg383626.html
>
> Looks like this one hasn't been merged yet.  IDK if something is broken with 
> my
> mail client but I'm not seeing any github repos.  If this depends on
> not-yet-merged drivers then it's certainly RFC material, but aside from the DT
> stuff (which should be straight-forward) it seems fine to me.
>

I think it makes sense to take this series once the clock driver is
merged at least.

> Since you posted this an an RFC I'm going to assume you're going to re-spin 
> it.
>

Yes. There are some feedbacks on DT which I will fix in v2.

> Thanks!
>
> >
> > Atish Patra (3):
> > RISC-V: Add Microchip PolarFire SoC kconfig option
> > RISC-V: Initial DTS for Microchip ICICLE board
> > RISC-V: Enable Microchip PolarFire ICICLE SoC
> >
> > arch/riscv/Kconfig.socs   |   7 +
> > arch/riscv/boot/dts/Makefile  |   1 +
> > arch/riscv/boot/dts/microchip/Makefile|   2 +
> > .../microchip/microchip-icicle-kit-a000.dts   | 313 ++
> > arch/riscv/configs/defconfig  |   4 +
> > 5 files changed, 327 insertions(+)
> > create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> > create mode 100644 
> > arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish


[PATCH v3 1/5] RISC-V: Move __start_kernel to .head.text

2020-11-04 Thread Atish Patra
Currently, __start_kernel is kept in _init while _start is in head section.
This may result in "relocation truncated to fit error" if _init section is
moved far from head. It also makes sense to keep entire head.S in one
section.

Keep __start_kernel in head section rather than _init.

Signed-off-by: Atish Patra 
---
 arch/riscv/kernel/head.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index 11e2a4fe66e0..45dbdae930bf 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -177,7 +177,6 @@ setup_trap_vector:
 
 END(_start)
 
-   __INIT
 ENTRY(_start_kernel)
/* Mask all interrupts */
csrw CSR_IE, zero
-- 
2.25.1



  1   2   3   4   5   6   7   8   9   10   >