Re: [PATCH 03/17] MIPS: loongson64: rename __node_data to node_data
在2024年7月16日七月 下午7:13，Mike Rapoport写道：
> From: "Mike Rapoport (Microsoft)"
>
> Make definition of node_data match other architectures.
> This will allow pulling declaration of node_data to the generic mm code in
> the following commit.
>
> Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jiaxun Yang
MIPS should go arch_numa at some point as well.
Thanks
- Jiaxun
> ---
> arch/mips/include/asm/mach-loongson64/mmzone.h | 4 ++--
> arch/mips/loongson64/numa.c| 8
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/mips/include/asm/mach-loongson64/mmzone.h
> b/arch/mips/include/asm/mach-loongson64/mmzone.h
> index a3d65d37b8b5..2effd5f8ed62 100644
> --- a/arch/mips/include/asm/mach-loongson64/mmzone.h
> +++ b/arch/mips/include/asm/mach-loongson64/mmzone.h
> @@ -14,9 +14,9 @@
> #define pa_to_nid(addr) (((addr) & 0xf000) >>
> NODE_ADDRSPACE_SHIFT)
> #define nid_to_addrbase(nid) ((unsigned long)(nid) <<
> NODE_ADDRSPACE_SHIFT)
>
> -extern struct pglist_data *__node_data[];
> +extern struct pglist_data *node_data[];
>
> -#define NODE_DATA(n) (__node_data[n])
> +#define NODE_DATA(n) (node_data[n])
>
> extern void __init prom_init_numa_memory(void);
>
> diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
> index 68dafd6d3e25..b50ce28d2741 100644
> --- a/arch/mips/loongson64/numa.c
> +++ b/arch/mips/loongson64/numa.c
> @@ -29,8 +29,8 @@
>
> unsigned char __node_distances[MAX_NUMNODES][MAX_NUMNODES];
> EXPORT_SYMBOL(__node_distances);
> -struct pglist_data *__node_data[MAX_NUMNODES];
> -EXPORT_SYMBOL(__node_data);
> +struct pglist_data *node_data[MAX_NUMNODES];
> +EXPORT_SYMBOL(node_data);
>
> cpumask_t __node_cpumask[MAX_NUMNODES];
> EXPORT_SYMBOL(__node_cpumask);
> @@ -107,7 +107,7 @@ static void __init node_mem_init(unsigned int node)
> tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
> if (tnid != node)
> pr_info("NODE_DATA(%d) on node %d\n", node, tnid);
> - __node_data[node] = nd;
> + node_data[node] = nd;
> NODE_DATA(node)->node_start_pfn = start_pfn;
> NODE_DATA(node)->node_spanned_pages = end_pfn - start_pfn;
>
> @@ -206,5 +206,5 @@ pg_data_t * __init arch_alloc_nodedata(int nid)
>
> void arch_refresh_nodedata(int nid, pg_data_t *pgdat)
> {
> - __node_data[nid] = pgdat;
> + node_data[nid] = pgdat;
> }
> --
> 2.43.0
--
- Jiaxun
Re: [PATCH v5 3/6] LoongArch: KVM: Add cpucfg area for kvm hypervisor
在2024年2月27日二月 上午3:14，maobibo写道： > On 2024/2/27 上午4:02, Jiaxun Yang wrote: >> >> >> 在2024年2月26日二月 上午8:04，maobibo写道： >>> On 2024/2/26 下午2:12, Huacai Chen wrote: >>>> On Mon, Feb 26, 2024 at 10:04 AM maobibo wrote: >>>>> >>>>> >>>>> >>>>> On 2024/2/24 下午5:13, Huacai Chen wrote: >>>>>> Hi, Bibo, >>>>>> >>>>>> On Thu, Feb 22, 2024 at 11:28 AM Bibo Mao wrote: >>>>>>> >>>>>>> Instruction cpucfg can be used to get processor features. And there >>>>>>> is trap exception when it is executed in VM mode, and also it is >>>>>>> to provide cpu features to VM. On real hardware cpucfg area 0 - 20 >>>>>>> is used. Here one specified area 0x4000 -- 0x40ff is used >>>>>>> for KVM hypervisor to privide PV features, and the area can be extended >>>>>>> for other hypervisors in future. This area will never be used for >>>>>>> real HW, it is only used by software. >>>>>> After reading and thinking, I find that the hypercall method which is >>>>>> used in our productive kernel is better than this cpucfg method. >>>>>> Because hypercall is more simple and straightforward, plus we don't >>>>>> worry about conflicting with the real hardware. >>>>> No, I do not think so. cpucfg is simper than hypercall, hypercall can >>>>> be in effect when system runs in guest mode. In some scenario like TCG >>>>> mode, hypercall is illegal intruction, however cpucfg can work. >>>> Nearly all architectures use hypercall except x86 for its historical >>> Only x86 support multiple hypervisors and there is multiple hypervisor >>> in x86 only. It is an advantage, not historical reason. >> >> I do believe that all those stuff should not be exposed to guest user space >> for security reasons. > Can you add PLV checking when cpucfg 0x4000-0x40FF is emulated? > if it is user mode return value is zero and it is kernel mode emulated > value will be returned. It can avoid information leaking. Please don’t do insane stuff here, applications are not expecting exception from cpucfg. > >> >> Also for different implementations of hypervisors they may have different >> PV features behavior, using hypcall to perform feature detection >> can pass more information to help us cope with hypervisor diversity. > How do different hypervisors can be detected firstly? On x86 MSR is > used for all hypervisors detection and on ARM64 hyperv used > acpi_gbl_FADT and kvm use smc forcely, host mode can execute smc > instruction without exception on ARM64. That’s hypcall ABI design choices, those information can come from firmware or privileged CSRs on LoongArch. > > I do not know why hypercall is better than cpucfg on LoongArch, cpucfg > is basic intruction however hypercall is not, it is part of LVZ feature. KVM can only work with LVZ right? > >>> >>>> reasons. If we use CPUCFG, then the hypervisor information is >>>> unnecessarily leaked to userspace, and this may be a security issue. >>>> Meanwhile, I don't think TCG mode needs PV features. >>> Besides PV features, there is other features different with real hw such >>> as virtio device, virtual interrupt controller. >> >> Those are *device* level information, they must be passed in firmware >> interfaces to keep processor emulation sane. > File arch/x86/hyperv/hv_apic.c can be referenced, apic features comes > from ms_hyperv.hints and HYPERV_CPUID_ENLIGHTMENT_INFO cpuid info, not > must be passed by firmware interface. That’s not KVM, that’s Hyper V. At Linux Kernel we enjoy the benefits of better modularity on device abstractions, please don’t break it. Thanks > > Regards > Bibo Mao >> >> Thanks >> >>> >>> Regards >>> Bibo Mao >>> >>>> >>>> I consulted with Jiaxun before, and maybe he can give some more comments. >>>> >>>>> >>>>> Extioi virtualization extension will be added later, cpucfg can be used >>>>> to get extioi features. It is unlikely that extioi driver depends on >>>>> PARA_VIRT macro if hypercall is used to get features. >>>> CPUCFG is per-core information, if we really need something about >>>> extioi, it should be in iocsr (LOONGARCH_IOCSR_FEATURES). >>>> >>>> >>>> Huacai >>>> >>>>> >>>&
Re: [PATCH v5 3/6] LoongArch: KVM: Add cpucfg area for kvm hypervisor
在2024年2月26日二月 上午8:04，maobibo写道：
> On 2024/2/26 下午2:12, Huacai Chen wrote:
>> On Mon, Feb 26, 2024 at 10:04 AM maobibo wrote:
>>>
>>>
>>>
>>> On 2024/2/24 下午5:13, Huacai Chen wrote:
Hi, Bibo,
On Thu, Feb 22, 2024 at 11:28 AM Bibo Mao wrote:
>
> Instruction cpucfg can be used to get processor features. And there
> is trap exception when it is executed in VM mode, and also it is
> to provide cpu features to VM. On real hardware cpucfg area 0 - 20
> is used. Here one specified area 0x4000 -- 0x40ff is used
> for KVM hypervisor to privide PV features, and the area can be extended
> for other hypervisors in future. This area will never be used for
> real HW, it is only used by software.
After reading and thinking, I find that the hypercall method which is
used in our productive kernel is better than this cpucfg method.
Because hypercall is more simple and straightforward, plus we don't
worry about conflicting with the real hardware.
>>> No, I do not think so. cpucfg is simper than hypercall, hypercall can
>>> be in effect when system runs in guest mode. In some scenario like TCG
>>> mode, hypercall is illegal intruction, however cpucfg can work.
>> Nearly all architectures use hypercall except x86 for its historical
> Only x86 support multiple hypervisors and there is multiple hypervisor
> in x86 only. It is an advantage, not historical reason.
I do believe that all those stuff should not be exposed to guest user space
for security reasons.
Also for different implementations of hypervisors they may have different
PV features behavior, using hypcall to perform feature detection
can pass more information to help us cope with hypervisor diversity.
>
>> reasons. If we use CPUCFG, then the hypervisor information is
>> unnecessarily leaked to userspace, and this may be a security issue.
>> Meanwhile, I don't think TCG mode needs PV features.
> Besides PV features, there is other features different with real hw such
> as virtio device, virtual interrupt controller.
Those are *device* level information, they must be passed in firmware
interfaces to keep processor emulation sane.
Thanks
>
> Regards
> Bibo Mao
>
>>
>> I consulted with Jiaxun before, and maybe he can give some more comments.
>>
>>>
>>> Extioi virtualization extension will be added later, cpucfg can be used
>>> to get extioi features. It is unlikely that extioi driver depends on
>>> PARA_VIRT macro if hypercall is used to get features.
>> CPUCFG is per-core information, if we really need something about
>> extioi, it should be in iocsr (LOONGARCH_IOCSR_FEATURES).
>>
>>
>> Huacai
>>
>>>
>>> Regards
>>> Bibo Mao
>>>
Huacai
>
> Signed-off-by: Bibo Mao
> ---
>arch/loongarch/include/asm/inst.h | 1 +
>arch/loongarch/include/asm/loongarch.h | 10 ++
>arch/loongarch/kvm/exit.c | 46 +-
>3 files changed, 41 insertions(+), 16 deletions(-)
>
> diff --git a/arch/loongarch/include/asm/inst.h
> b/arch/loongarch/include/asm/inst.h
> index d8f637f9e400..ad120f924905 100644
> --- a/arch/loongarch/include/asm/inst.h
> +++ b/arch/loongarch/include/asm/inst.h
> @@ -67,6 +67,7 @@ enum reg2_op {
> revhd_op= 0x11,
> extwh_op= 0x16,
> extwb_op= 0x17,
> + cpucfg_op = 0x1b,
> iocsrrdb_op = 0x19200,
> iocsrrdh_op = 0x19201,
> iocsrrdw_op = 0x19202,
> diff --git a/arch/loongarch/include/asm/loongarch.h
> b/arch/loongarch/include/asm/loongarch.h
> index 46366e783c84..a1d22e8b6f94 100644
> --- a/arch/loongarch/include/asm/loongarch.h
> +++ b/arch/loongarch/include/asm/loongarch.h
> @@ -158,6 +158,16 @@
>#define CPUCFG48_VFPU_CG BIT(2)
>#define CPUCFG48_RAM_CG BIT(3)
>
> +/*
> + * cpucfg index area: 0x4000 -- 0x40ff
> + * SW emulation for KVM hypervirsor
> + */
> +#define CPUCFG_KVM_BASE0x4000UL
> +#define CPUCFG_KVM_SIZE0x100
> +#define CPUCFG_KVM_SIG CPUCFG_KVM_BASE
> +#define KVM_SIGNATURE "KVM\0"
> +#define CPUCFG_KVM_FEATURE (CPUCFG_KVM_BASE + 4)
> +
>#ifndef __ASSEMBLY__
>
>/* CSR */
> diff --git a/arch/loongarch/kvm/exit.c b/arch/loongarch/kvm/exit.c
> index 923bbca9bd22..6a38fd59d86d 100644
> --- a/arch/loongarch/kvm/exit.c
> +++ b/arch/loongarch/kvm/exit.c
> @@ -206,10 +206,37 @@ int kvm_emu_idle(struct kvm_vcpu *vcpu)
> return EMULATE_DONE;
>}
>
> -static int kvm_trap_handle_gspr(struct kvm_vcpu *vcpu)
> +static int kvm_emu_cpucfg(struct kvm_vcpu *vcpu, larch_inst inst)
>{
> int rd, rj;
> unsigned
Re: [PATCH] mips: kdump: Crash kernel should be able to see old memories
在 2021/4/19 18:56, Youling Tang 写道:
From: Huacai Chen
kexec-tools use mem=X@Y to pass usable memories to crash kernel, but in
commit a94e4f24ec836c8984f83959 ("MIPS: init: Drop boot_mem_map") all
BIOS passed memories are removed by early_parse_mem(). I think this is
reasonable for a normal kernel but not for a crash kernel, because a
crash kernel should be able to see all old memories, even though it is
not supposed to use them.
Fixes: a94e4f24ec836c8984f83959 ("MIPS: init: Drop boot_mem_map")
Signed-off-by: Huacai Chen
Signed-off-by: Youling Tang
---
arch/mips/kernel/setup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index b86e241..ac90d3b 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -351,8 +351,10 @@ static int __init early_parse_mem(char *p)
*/
if (usermem == 0) {
usermem = 1;
+#ifndef CONFIG_CRASH_DUMP
Why depend on a config instead of a runtime variable?
Btw as you are fixing my commit please keep me CCed.
Thanks.
- Jiaxun
Re: [PATCH] MIPS: Fix cmdline "mem=" parameter parsing
在 2021/4/19 18:50, Youling Tang 写道: This problem may only occur on NUMA platforms. When machine start with the "mem=" parameter on Loongson64, it cannot boot. When parsing the "mem=" parameter, first remove all RAM, and then add memory through memblock_add(), which causes the newly added memory to be located on MAX_NUMNODES. The solution is to add the current "mem=" parameter range to the memory area of the corresponding node, instead of adding all of it to the MAX_NUMNODES node area. Get the node number corresponding to the "mem=" parameter range through pa_to_nid(), and then add it to the corresponding node through memblock_add_node(). Signed-off-by: Jinyang He Signed-off-by: Youling Tang --- arch/mips/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 279be01..b86e241 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -359,7 +359,7 @@ static int __init early_parse_mem(char *p) if (*p == '@') start = memparse(p + 1, ); - memblock_add(start, size); + memblock_add_node(start, size, pa_to_nid(start)); pa_to_nid is not available for all platforms. Thanks. - Jiaxun return 0; }
Re: [PATCH] MIPS: Loongson64: Add Loongson-2K1000 reset support
On Wed, Apr 14, 2021, at 9:26 AM, Qing Zhang wrote:
> Add power management register operations to support reboot and poweroff.
>
> Signed-off-by: Qing Zhang
No that's not what we intended to do.
Please add a devicetree node for pm block.
Thanks
> ---
> .../include/asm/mach-loongson64/loongson.h| 8 ++
> arch/mips/loongson64/reset.c | 28 ---
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/arch/mips/include/asm/mach-loongson64/loongson.h
> b/arch/mips/include/asm/mach-loongson64/loongson.h
> index f7c3ab6d724e..9d254a7b438a 100644
> --- a/arch/mips/include/asm/mach-loongson64/loongson.h
> +++ b/arch/mips/include/asm/mach-loongson64/loongson.h
> @@ -263,4 +263,12 @@ extern u64 loongson_freqctrl[MAX_PACKAGES];
> #define LOONGSON_PCIMAP_WIN(WIN, ADDR) \
> ADDR)>>26) & LOONGSON_PCIMAP_PCIMAP_LO0) << ((WIN)*6))
>
> +/* Loongson-2K1000 Power management related registers */
> +#define PM1_STS 0x0C /* Power Management1 Status Register */
> +#define PM1_CNT 0x14 /* Power Management 1 Control Register */
> +#define RST_CNT 0x30 /* Reset Control Register */
> +#define SLP_TYP GENMASK(12, 10) /* Sleep Enable */
> +#define SLP_EN BIT(13) /* Soft Off */
> +#define ACPI_OFF0x7000
> +
> #endif /* __ASM_MACH_LOONGSON64_LOONGSON_H */
> diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c
> index 3bb8a1ed9348..b4348bf50538 100644
> --- a/arch/mips/loongson64/reset.c
> +++ b/arch/mips/loongson64/reset.c
> @@ -18,9 +18,16 @@
> static void loongson_restart(char *command)
> {
>
> - void (*fw_restart)(void) = (void *)loongson_sysconf.restart_addr;
> + if ((read_c0_prid() & PRID_IMP_MASK) == PRID_IMP_LOONGSON_64R) {
> + unsigned long base;
>
> - fw_restart();
> + base = CKSEG1ADDR(LOONGSON_REG_BASE) + ACPI_OFF;
> + writel(1, (void *)(base + RST_CNT));
> + } else {
> + void (*fw_restart)(void) = (void
> *)loongson_sysconf.restart_addr;
> +
> + fw_restart();
> + }
> while (1) {
> if (cpu_wait)
> cpu_wait();
> @@ -29,9 +36,22 @@ static void loongson_restart(char *command)
>
> static void loongson_poweroff(void)
> {
> - void (*fw_poweroff)(void) = (void *)loongson_sysconf.poweroff_addr;
>
> - fw_poweroff();
> + if ((read_c0_prid() & PRID_IMP_MASK) == PRID_IMP_LOONGSON_64R) {
> + unsigned long base;
> + unsigned int acpi_ctrl;
> +
> + base = CKSEG1ADDR(LOONGSON_REG_BASE) + ACPI_OFF;
> + acpi_ctrl = readl((void *)(base + PM1_STS));
> + acpi_ctrl &= 0x;
> + writel(acpi_ctrl, (void *)(base + PM1_STS));
> + acpi_ctrl = SLP_EN | SLP_TYP;
> + writel(acpi_ctrl, (void *)(base + PM1_CNT));
> + } else {
> + void (*fw_poweroff)(void) = (void
> *)loongson_sysconf.poweroff_addr;
> +
> + fw_poweroff();
> + }
> while (1) {
> if (cpu_wait)
> cpu_wait();
> --
> 2.31.0
>
>
--
- Jiaxun
Re: [PATCH] MIPS: Loongson64: enable CONFIG_USB_SERIAL_PL2303
On Mon, Mar 29, 2021, at 3:15 PM, Qing Zhang wrote: > When using the Loongson-3A4000 machine for serial port debugging, > there is no /dev/ttyUSB* output, which makes the serial port unavailable, > For convenience, we open this configuration. > > zhangqing@loongson-pc:~$ cat /sys/firmware/lefi/boardinfo > Board Info > Manufacturer : THTF > Board Name: THTF-LS3A4000-7A1000-ML4A > Family: LOONGSON3 > > BIOS Info > Vendor: ZD tech > Version : ZD tech-V2.1.1 > ROM Size : 4 KB > Release Date : 2020-06-29 > > zhangqing@loongson-pc:~$ lsusb > Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 005 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse > Bus 005 Device 002: ID 0c45:760b Microdia USB Keyboard > Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 003 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > Signed-off-by: Qing Zhang Please, don't add random stuff to defconfig. Carry it locally in your config as the device doesn't come with the borad, it's your accessory. Thanks. -- - Jiaxun
Re: [PATCH v4 2/7] MIPS: Loongson64: Distinguish firmware dependencies DTB/LEFI
On Wed, Mar 10, 2021, at 6:57 PM, Oleksij Rempel wrote:
> Hi,
>
> Am 10.03.21 um 08:56 schrieb Qing Zhang:
> > Add DTB boot support, only support Loongson-2K1000 processor
> > for now, determine whether to use the built-in DTB or the DTB
> > from the firmware by checking the range of CKSEG0 and XKPHYS.
> > loongson_fw_interface will be used in the future.
> >
> > Signed-off-by: Jiaxun Yang
> > Signed-off-by: Qing Zhang
> > Tested-by: Ming Wang
> > ---
> >
> > v3-v4: Standard submission of information
> >Fix error handling
> >
> > .../include/asm/mach-loongson64/boot_param.h | 6 ++
> > arch/mips/include/asm/mach-loongson64/loongson.h | 3 ++-
> > arch/mips/loongson64/env.c | 13 -
> > arch/mips/loongson64/init.c | 16 ++--
> > 4 files changed, 34 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h
> > b/arch/mips/include/asm/mach-loongson64/boot_param.h
> > index 4592841b6b0c..43737401dc06 100644
> > --- a/arch/mips/include/asm/mach-loongson64/boot_param.h
> > +++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
> > @@ -198,7 +198,13 @@ enum loongson_bridge_type {
> > VIRTUAL = 3
> > };
> >
> > +enum loongson_fw_interface {
> > + LOONGSON_LEFI,
> > + LOONGSON_DTB,
> > +};
> > +
> > struct loongson_system_configuration {
> > + enum loongson_fw_interface fw_interface;
> > u32 nr_cpus;
> > u32 nr_nodes;
> > int cores_per_node;
> > diff --git a/arch/mips/include/asm/mach-loongson64/loongson.h
> > b/arch/mips/include/asm/mach-loongson64/loongson.h
> > index ac1c20e172a2..3f885fa26ba6 100644
> > --- a/arch/mips/include/asm/mach-loongson64/loongson.h
> > +++ b/arch/mips/include/asm/mach-loongson64/loongson.h
> > @@ -23,7 +23,8 @@ extern u32 memsize, highmemsize;
> > extern const struct plat_smp_ops loongson3_smp_ops;
> >
> > /* loongson-specific command line, env and memory initialization */
> > -extern void __init prom_init_env(void);
> > +extern void __init prom_dtb_init_env(void);
> > +extern void __init prom_lefi_init_env(void);
> > extern void __init szmem(unsigned int node);
> > extern void *loongson_fdt_blob;
> >
> > diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
> > index 51a5d050a94c..e7d3a06175e3 100644
> > --- a/arch/mips/loongson64/env.c
> > +++ b/arch/mips/loongson64/env.c
> > @@ -43,7 +43,18 @@ const char *get_system_type(void)
> > return "Generic Loongson64 System";
> > }
> >
> > -void __init prom_init_env(void)
> > +
> > +void __init prom_dtb_init_env(void)
> > +{
> > + if ((fw_arg2 < CKSEG0 || fw_arg2 > CKSEG1)
> > + && (fw_arg2 < XKPHYS || fw_arg2 > XKSEG))
> > +
> > + loongson_fdt_blob = __dtb_loongson64_2core_2k1000_begin;
> > + else
> > + loongson_fdt_blob = (void *)fw_arg2;
> > +}
> > +
> > +void __init prom_lefi_init_env(void)
> > {
> > struct boot_params *boot_p;
> > struct loongson_params *loongson_p;
> > diff --git a/arch/mips/loongson64/init.c b/arch/mips/loongson64/init.c
> > index cfa788bca871..ed280b73bf89 100644
> > --- a/arch/mips/loongson64/init.c
> > +++ b/arch/mips/loongson64/init.c
> > @@ -52,6 +52,10 @@ void __init szmem(unsigned int node)
> > static unsigned long num_physpages;
> > u64 node_id, node_psize, start_pfn, end_pfn, mem_start, mem_size;
> >
> > + /* Otherwise come from DTB */
> > + if (loongson_sysconf.fw_interface != LOONGSON_LEFI)
> > + return;
> > +
> > /* Parse memory information and activate */
> > for (i = 0; i < loongson_memmap->nr_map; i++) {
> > node_id = loongson_memmap->map[i].node_id;
> > @@ -94,12 +98,20 @@ static void __init prom_init_memory(void)
> > void __init prom_init(void)
> > {
> > fw_init_cmdline();
> > - prom_init_env();
> > +
> > + if (fw_arg2 == 0 || (fdt_magic(fw_arg2) == FDT_MAGIC)) {
> > + loongson_sysconf.fw_interface = LOONGSON_DTB;
> > + prom_dtb_init_env();
> > + } else {
> > + loongson_sysconf.fw_interface = LOONGSON_LEFI;
> > + prom_lefi_init_env();
> > + }
>
> Is it possible to make it compatible with MIPS UHI boot protocol? So
> boot loaders will be able to
> handle Loongson kernel images as any other MIPS ker
Re: [PATCH v4 3/7] MIPS: Loongson64: Add support for the Loongson-2K1000 to get cpu_clock_freq
On Wed, Mar 10, 2021, at 5:37 PM, zhangqing wrote: > > > On 03/10/2021 04:50 PM, Sergei Shtylyov wrote: > > Hello! > > > >You don't seem to need this initializer. > Hi,Sergei > > Thanks for your suggestion, > clk will not be affected by others when it is defined until the value is > obtained, > =NULL can be deleted, but I think it seems to have no effect. Please do reasonable change only. Thanks. - Jiaxun > > Thanks, > Qing > > > > > > -- - Jiaxun
Re: [PATCH v4 6/7] dt-bindings: interrupt-controller: Add Loongson-2K1000 LIOINTC
On Wed, Mar 10, 2021, at 3:56 PM, Qing Zhang wrote: > Add liointc-2.0 properties support, so update the maxItems and description. > > Signed-off-by: Jiaxun Yang ^ I have nothing todo with this patch so please drop me for this one :-) > Signed-off-by: Qing Zhang > Tested-by: Ming Wang > --- > > v3-v4: Standard submission of information ^ It's called commit message. > > .../bindings/interrupt-controller/loongson,liointc.yaml| 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml > > b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml > index f38e0113f360..5280cf60a9a7 100644 > --- > a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml > +++ > b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml > @@ -10,9 +10,9 @@ maintainers: >- Jiaxun Yang > > description: | > - This interrupt controller is found in the Loongson-3 family of chips > as the primary > - package interrupt controller which can route local I/O interrupt to > interrupt lines > - of cores. > + This interrupt controller is found in the Loongson-3 family of chips > and > + Loongson-2K1000 chip, as the primary package interrupt controller > which > + can route local I/O interrupt to interrupt lines of cores. > > allOf: >- $ref: /schemas/interrupt-controller.yaml# > @@ -22,6 +22,7 @@ properties: > oneOf: >- const: loongson,liointc-1.0 >- const: loongson,liointc-1.0a > + - const: loongson,liointc-2.0 > >reg: > maxItems: 1 ^ Please document multiple reg prop change as well. Thanks. - Jiaxun > -- > 2.20.1 > > -- - Jiaxun
Re: [PATCH 2/2] MIPS: Loongson64: Move loongson_system_configuration to loongson.h
在 2021/3/8 17:49, Thomas Bogendoerfer 写道: On Sat, Mar 06, 2021 at 06:55:41PM +0800, Jiaxun Yang wrote: On Sat, Mar 6, 2021, at 5:53 PM, Thomas Bogendoerfer wrote: [...] Just to understand you, you want arch/mips/include/asm/loongson/2ef arch/mips/include/asm/loongson/32 arch/mips/include/asm/loongson/64 Yeah it looks reasonable but from my point of view doing these movement brings no actual benefit :-( oh it does for sure. There will no more build errors for non loogson configs for things like #include It should be loongson64_regs.h then because it will not work for loongson either. And it will be clear, which of the 3 loongson.h is used. Which then gives chances for even more cleanups. Ahh, got your point. Probably we should rename all these loongson.h as they should be indepedent. Thanks. - Jiaxun Thomas.
Re: [PATCH 2/2] MIPS: Loongson64: Move loongson_system_configuration to loongson.h
On Sat, Mar 6, 2021, at 5:53 PM, Thomas Bogendoerfer wrote: > On Sat, Mar 06, 2021 at 05:00:15PM +0800, Jiaxun Yang wrote: > > > > > > On Sat, Mar 6, 2021, at 4:03 PM, Thomas Bogendoerfer wrote: > > > On Thu, Mar 04, 2021 at 07:00:57PM +0800, Qing Zhang wrote: > > > > The purpose of separating loongson_system_configuration from > > > > boot_param.h > > > > is to keep the other structure consistent with the firmware. > > > > > > > > Signed-off-by: Jiaxun Yang > > > > Signed-off-by: Qing Zhang > > > > --- > > > > .../include/asm/mach-loongson64/boot_param.h | 18 -- > > > > .../include/asm/mach-loongson64/loongson.h | 18 ++ > > > > > > as you are already touching mach-loongson64 files... > > > > > > Is there a chance you clean up that up even further ? My goal is to > > > have only files in mach- files, which have an mach-generic > > > counterpart. Everything else should go to its own directory. So in > > > case of loongson something > > > > > > like > > > > > > arch/mips/include/asm/loongsonfor common stuff > > > arch/mips/include/asm/loongson/32 > > > arch/mips/include/asm/loongson/64 > > > > Hi Thomas > > > > I'm object to this idea as loongson32/2ef/64 have nothing in common. > > at least they share the name loongson, so having > > arch/mips/include/asm/loongson > > sounds like a good move. > > And seeing > > diff -u mach-loongson2ef/ mach-loongson64/loongson.h | diffstat > loongson.h | 137 > + > 1 file changed, 30 insertions(+), 107 deletions(-) > > wc mach-loongson2ef/loongson.h > 318 963 11278 mach-loongson2ef/loongson.h > > so there is something to shared. To me it looks like 2ef could be merged > into 64, but that's nothing I'm wanting. Hmm there are duplications in loongson.h just because we didn't clean them up when splitting loongson2ef out of loongson64. > > Just to understand you, you want > > arch/mips/include/asm/loongson/2ef > arch/mips/include/asm/loongson/32 > arch/mips/include/asm/loongson/64 Yeah it looks reasonable but from my point of view doing these movement brings no actual benefit :-( Thanks. - Jiaxun > > ? > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea.[ RFC1925, 2.3 ] > -- - Jiaxun
Re: [PATCH 2/2] MIPS: Loongson64: Move loongson_system_configuration to loongson.h
On Sat, Mar 6, 2021, at 4:03 PM, Thomas Bogendoerfer wrote: > On Thu, Mar 04, 2021 at 07:00:57PM +0800, Qing Zhang wrote: > > The purpose of separating loongson_system_configuration from boot_param.h > > is to keep the other structure consistent with the firmware. > > > > Signed-off-by: Jiaxun Yang > > Signed-off-by: Qing Zhang > > --- > > .../include/asm/mach-loongson64/boot_param.h | 18 -- > > .../include/asm/mach-loongson64/loongson.h | 18 ++ > > as you are already touching mach-loongson64 files... > > Is there a chance you clean up that up even further ? My goal is to > have only files in mach- files, which have an mach-generic > counterpart. Everything else should go to its own directory. So in > case of loongson something > > like > > arch/mips/include/asm/loongsonfor common stuff > arch/mips/include/asm/loongson/32 > arch/mips/include/asm/loongson/64 Hi Thomas I'm object to this idea as loongson32/2ef/64 have nothing in common. They're different cores and different SoC designed by different team with different booting protocol. Maybe it's possible to merge loongson32 into generic platform but my LS1C borad is broken... Thanks. - Jiaxun > > Comments ? > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea.[ RFC1925, 2.3 ] > -- - Jiaxun
Re: [PATCH] MIPS: Support large stack.
在 2021/3/5 11:12, HongJieDeng 写道: From: Hongjie Deng We need more stack space, xori/ori no longer apply when _THREAD_MASK exceeds 16 bits Signed-off-by: Hongjie Deng --- arch/mips/include/asm/stackframe.h | 8 arch/mips/kernel/genex.S | 6 ++ 2 files changed, 14 insertions(+) diff --git a/arch/mips/include/asm/stackframe.h b/arch/mips/include/asm/stackframe.h index aa430a6..6ebc39f 100644 --- a/arch/mips/include/asm/stackframe.h +++ b/arch/mips/include/asm/stackframe.h @@ -278,8 +278,16 @@ sll k0, 3 /* extract cu0 bit */ bltzk0, 9f +#if_THREAD_MASK < (1 << 16 - 1) ori $28, sp, _THREAD_MASK xori$28, _THREAD_MASK +#else + li $28, _THREAD_MASK + or $28, sp, $28 + li $24, _THREAD_MASK + xor $28, $28, $24 Hi Hongjie, li breaks MIPS64, please try PTR_LI instead. Also loading immediate cost a lot on MIPS, you may save a unnecessary li by: + PTR_LI v1, _THREAD_MASK + or gp, sp, v1 + xor gp, gp, v1 Also clobber v0/v1 seems much more reasonable than $24 here +#endif + #ifdef CONFIG_CPU_CAVIUM_OCTEON .setmips64 pref0, 0($28) /* Prefetch the current pointer */ diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S index bcce32a..5ea4fe4 100644 --- a/arch/mips/kernel/genex.S +++ b/arch/mips/kernel/genex.S @@ -662,8 +662,14 @@ isrdhwr: #endif MTC0k0, CP0_EPC /* I hope three instructions between MTC0 and ERET are enough... */ +#if_THREAD_MASK < (1 << 16 - 1) ori k1, _THREAD_MASK xorik1, _THREAD_MASK +#else + li $24 ,_THREAD_MASK + or k1, k1, $24 + xor k1, k1, $24 +#endif Ditto. Actually another possible solution could be `.set at=v1` around it and let aeembler to decide if it needs a extra register. Thanks. - Jiaxun LONG_L v1, TI_TP_VALUE(k1) .setpush .setarch=r4000
Re: [PATCH 2/2] MIPS: Loongson64: Move loongson_system_configuration to loongson.h
在 2021/3/4 下午7:00, Qing Zhang 写道:
The purpose of separating loongson_system_configuration from boot_param.h
is to keep the other structure consistent with the firmware.
Signed-off-by: Jiaxun Yang
Signed-off-by: Qing Zhang
Acked-by: Jiaxun Yang
- Jiaxun
---
.../include/asm/mach-loongson64/boot_param.h | 18 --
.../include/asm/mach-loongson64/loongson.h | 18 ++
drivers/irqchip/irq-loongson-liointc.c | 2 +-
3 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h
b/arch/mips/include/asm/mach-loongson64/boot_param.h
index 1c1cdf57137e..035b1a69e2d0 100644
--- a/arch/mips/include/asm/mach-loongson64/boot_param.h
+++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
@@ -198,24 +198,6 @@ enum loongson_bridge_type {
VIRTUAL = 3
};
-struct loongson_system_configuration {
- u32 nr_cpus;
- u32 nr_nodes;
- int cores_per_node;
- int cores_per_package;
- u16 boot_cpu_id;
- u16 reserved_cpus_mask;
- enum loongson_cpu_type cputype;
- enum loongson_bridge_type bridgetype;
- u64 restart_addr;
- u64 poweroff_addr;
- u64 suspend_addr;
- u64 vgabios_addr;
- u32 dma_mask_bits;
- u64 workarounds;
- void (*early_config)(void);
-};
-
extern struct efi_memory_map_loongson *loongson_memmap;
extern struct loongson_system_configuration loongson_sysconf;
diff --git a/arch/mips/include/asm/mach-loongson64/loongson.h b/arch/mips/include/asm/mach-loongson64/loongson.h
index ac1c20e172a2..6189deb188cf 100644
--- a/arch/mips/include/asm/mach-loongson64/loongson.h
+++ b/arch/mips/include/asm/mach-loongson64/loongson.h
@@ -12,6 +12,24 @@
#include
#include
+/* machine-specific boot configuration */
+struct loongson_system_configuration {
+ u32 nr_cpus;
+ u32 nr_nodes;
+ int cores_per_node;
+ int cores_per_package;
+ u16 boot_cpu_id;
+ u16 reserved_cpus_mask;
+ enum loongson_cpu_type cputype;
+ enum loongson_bridge_type bridgetype;
+ u64 restart_addr;
+ u64 poweroff_addr;
+ u64 suspend_addr;
+ u64 vgabios_addr;
+ u32 dma_mask_bits;
+ u64 workarounds;
+ void (*early_config)(void);
+};
/* machine-specific reboot/halt operation */
extern void mach_prepare_reboot(void);
diff --git a/drivers/irqchip/irq-loongson-liointc.c
b/drivers/irqchip/irq-loongson-liointc.c
index 09b91b81851c..249566a23cc4 100644
--- a/drivers/irqchip/irq-loongson-liointc.c
+++ b/drivers/irqchip/irq-loongson-liointc.c
@@ -16,7 +16,7 @@
#include
#include
-#include
+#include
#define LIOINTC_CHIP_IRQ 32
#define LIOINTC_NUM_PARENT 4
Re: [PATCH 1/2] MIPS: Loongson64: Remove unused sysconf members
在 2021/3/4 下午7:00, Qing Zhang 写道:
We don't need them anymore, They are uniform on all Loongson64 systems
and have been fixed in DeviceTree.loongson3_platform_init is replaced
with DTS + driver.
Signed-off-by: Jiaxun Yang
Signed-off-by: Qing Zhang
Acked-by: Jiaxun Yang
Hmm, why it comes with my sign-off?
I assue it's my patch somewhere off the tree?
Thanks.
- Jiaxun
---
.../include/asm/mach-loongson64/boot_param.h | 9
arch/mips/loongson64/Makefile | 2 +-
arch/mips/loongson64/env.c| 20 -
arch/mips/loongson64/platform.c | 42 ---
4 files changed, 1 insertion(+), 72 deletions(-)
delete mode 100644 arch/mips/loongson64/platform.c
diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h
b/arch/mips/include/asm/mach-loongson64/boot_param.h
index 4592841b6b0c..1c1cdf57137e 100644
--- a/arch/mips/include/asm/mach-loongson64/boot_param.h
+++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
@@ -207,20 +207,11 @@ struct loongson_system_configuration {
u16 reserved_cpus_mask;
enum loongson_cpu_type cputype;
enum loongson_bridge_type bridgetype;
- u64 ht_control_base;
- u64 pci_mem_start_addr;
- u64 pci_mem_end_addr;
- u64 pci_io_base;
u64 restart_addr;
u64 poweroff_addr;
u64 suspend_addr;
u64 vgabios_addr;
u32 dma_mask_bits;
- char ecname[32];
- u32 nr_uarts;
- struct uart_device uarts[MAX_UARTS];
- u32 nr_sensors;
- struct sensor_device sensors[MAX_SENSORS];
u64 workarounds;
void (*early_config)(void);
};
diff --git a/arch/mips/loongson64/Makefile b/arch/mips/loongson64/Makefile
index cc76944b1a9d..e806280bbb85 100644
--- a/arch/mips/loongson64/Makefile
+++ b/arch/mips/loongson64/Makefile
@@ -2,7 +2,7 @@
#
# Makefile for Loongson-3 family machines
#
-obj-$(CONFIG_MACH_LOONGSON64) += cop2-ex.o platform.o dma.o \
+obj-$(CONFIG_MACH_LOONGSON64) += cop2-ex.o dma.o \
setup.o init.o env.o time.o reset.o \
obj-$(CONFIG_SMP) += smp.o
diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
index 51a5d050a94c..1821d461b606 100644
--- a/arch/mips/loongson64/env.c
+++ b/arch/mips/loongson64/env.c
@@ -95,7 +95,6 @@ void __init prom_init_env(void)
loongson_freqctrl[1] = 0x900010001fe001d0;
loongson_freqctrl[2] = 0x900020001fe001d0;
loongson_freqctrl[3] = 0x900030001fe001d0;
- loongson_sysconf.ht_control_base = 0x9EFDFB00;
loongson_sysconf.workarounds = WORKAROUND_CPUFREQ;
break;
case Legacy_3B:
@@ -118,7 +117,6 @@ void __init prom_init_env(void)
loongson_freqctrl[1] = 0x900020001fe001d0;
loongson_freqctrl[2] = 0x900040001fe001d0;
loongson_freqctrl[3] = 0x900060001fe001d0;
- loongson_sysconf.ht_control_base = 0x90001EFDFB00;
loongson_sysconf.workarounds = WORKAROUND_CPUHOTPLUG;
break;
default:
@@ -136,9 +134,6 @@ void __init prom_init_env(void)
loongson_sysconf.cores_per_node - 1) /
loongson_sysconf.cores_per_node;
- loongson_sysconf.pci_mem_start_addr = eirq_source->pci_mem_start_addr;
- loongson_sysconf.pci_mem_end_addr = eirq_source->pci_mem_end_addr;
- loongson_sysconf.pci_io_base = eirq_source->pci_io_start_addr;
loongson_sysconf.dma_mask_bits = eirq_source->dma_mask_bits;
if (loongson_sysconf.dma_mask_bits < 32 ||
loongson_sysconf.dma_mask_bits > 64)
@@ -153,23 +148,8 @@ void __init prom_init_env(void)
loongson_sysconf.poweroff_addr, loongson_sysconf.restart_addr,
loongson_sysconf.vgabios_addr);
- memset(loongson_sysconf.ecname, 0, 32);
- if (esys->has_ec)
- memcpy(loongson_sysconf.ecname, esys->ec_name, 32);
loongson_sysconf.workarounds |= esys->workarounds;
- loongson_sysconf.nr_uarts = esys->nr_uarts;
- if (esys->nr_uarts < 1 || esys->nr_uarts > MAX_UARTS)
- loongson_sysconf.nr_uarts = 1;
- memcpy(loongson_sysconf.uarts, esys->uarts,
- sizeof(struct uart_device) * loongson_sysconf.nr_uarts);
-
- loongson_sysconf.nr_sensors = esys->nr_sensors;
- if (loongson_sysconf.nr_sensors > MAX_SENSORS)
- loongson_sysconf.nr_sensors = 0;
- if (loongson_sysconf.nr_sensors)
- memcpy(loongson_sysconf.sensors, esys->sensors,
- sizeof(struct sensor_device) *
loongson_sysconf.nr_sensors);
pr_info("CpuClock = %u\n", cpu_clock_freq);
/* Read the ID of PCI host bridge to detect bridge type */
diff --git a/arch/mips/loongson64/platform.c b/arch/mips/loongson64/platform.c
deleted file mode 10
Re: [PATCH] MIPS: Add comment about CONFIG_MIPS32_O32 in loongson3_defconfig when build with Clang
在 2021/3/5 上午7:08, Maciej W. Rozycki 写道: On Thu, 4 Mar 2021, Tiezhu Yang wrote: This is a known bug [2] with Clang, as Simon Atanasyan said, "There is no plan on support O32 for MIPS64 due to lack of resources". Huh? Is that a joke? From the o32 psABI's point of view a MIPS64 CPU is exactly the same as a MIPS32 one (for whatever ISA revision), so there's nothing to support there really other than the CPU/ISA name. Clang treat MIPS32 as a different backend so we may need some extra effort TBH it is a toolchain issue and kernel workaround seems bogus. From my point view we can "s/mips64r2/mips32r2" when doing syscall checks to workaround clang issue instead of disable it for kernel. Thanks. - Jiaxun As much as I dislike all the hacks the Clang community seems to come up with for the shortcomings of their tool there has to be a saner workaround available rather than forcibly disabling support for the o32 ABI with CONFIG_64BIT kernels, but the report is missing the compiler invocation line triggering the issue (V=1 perhaps?), which should be included with any commit description anyway, so I can't suggest anything based on the limited information provided. Maciej
Re: [PATCH 1/2] MIPS: Remove KVM_GUEST support
在 2021/3/1 下午11:29, Thomas Bogendoerfer 写道: KVM_GUEST is broken and unmaintained, so let's remove it. Signed-off-by: Thomas Bogendoerfer Reviewed-by: Jiaxun Yang I'll prepare a patch for KVM side removal. Thanks. - Jiaxun
Re: [PATCH RFC] MIPS: Remove detect_memory_region()
在 2021/2/26 上午9:37, Jinyang He 写道:
On 02/24/2021 11:40 PM, Jiaxun Yang wrote:
On Wed, Feb 24, 2021, at 9:02 PM, Jinyang He wrote:
detect_memory_region() was committed by Commit 4d9f77d25268 ("MIPS: add
detect_memory_region()"). Then it was equipped by Commit dd63b00804a5
("MIPS: ralink: make use of the new memory detection code") and
Commit 9b75733b7b5e ("MIPS: ath79: make use of the new memory detection
code"). Its code is based on early ath79 platform code.
What puzzles me is that how memcmp() detect the memory region. If
`break`
was touched, the function could make sense. That means memcmp() should
return zero. Otherwise, the loop will be end by size > sz_max.
I have tested detect_memory_region() on Loongson64 3A3000. On our
design,
kseg0 low 256MB maps real memory and kseg0 high 256MB maps IO/PCI. The
function runs and last stopped on kseg1 where is uncached. In this
process
memcmp also returned non-zero when detected kseg0 high 256MB. Then I
did
another thing. memcpy first and test memcmp then (after &_end). It
works
well on 3A3000 but badly on 3A4000. Maybe because kseg0 high 256MB maps
IO/PCI and it is dangerous to write like write memory.
At last, read memory from where is not memory region may always
return 0.
(Or trigger exception.) This function have been used several years and
seems no error occur. Maybe it's a fallback way.
That is not true for other platforms like ath79 or mtk.
They'll wrap around or return 0x for out of boundary accessing.
Loongson does not apply to this case as it have special "Address Window"
design to accurately describe address regions.
Any access beyond described windows will be handled by MC and return
0 or random stuff.
Again, please don't make changes because you can.
Thanks.
- Jiaxun
Hi, Jiaxun,
Thank you for answering this puzzle for me in detail.
Assume that the machine has 8MB real memory and dm address is (base +
3M).
When size = 8MB, there will be a phenomenon of `wrap around`, the actual
content of (dm + 8M + 3M) is content of (dm + 3M), so it will trigger
`break`, right? At this time, the kernel will add 8M to the memory.
Hi Jingyang,
How can you boot kernel with 8M memory in present days ;-)
(Ohh with respect to Nintendo64 developer who had proven it's possible)
For what I can say, detect_memory_region exists because many devices
doesn't have a way to pass memory size information from bootloader to
kernel. Or their bootloader even don't care about memory size.
Kernel needs it to get memory size correctly. Although it seems fragile.
That's life, we must accept imperfect past and don't repeat it in future.
Thanks.
- Jiaxun
Thanks,
Jinyang
Re: [PATCH RFC] MIPS: Remove detect_memory_region()
On Wed, Feb 24, 2021, at 9:02 PM, Jinyang He wrote:
> detect_memory_region() was committed by Commit 4d9f77d25268 ("MIPS: add
> detect_memory_region()"). Then it was equipped by Commit dd63b00804a5
> ("MIPS: ralink: make use of the new memory detection code") and
> Commit 9b75733b7b5e ("MIPS: ath79: make use of the new memory detection
> code"). Its code is based on early ath79 platform code.
>
> What puzzles me is that how memcmp() detect the memory region. If `break`
> was touched, the function could make sense. That means memcmp() should
> return zero. Otherwise, the loop will be end by size > sz_max.
>
> I have tested detect_memory_region() on Loongson64 3A3000. On our design,
> kseg0 low 256MB maps real memory and kseg0 high 256MB maps IO/PCI. The
> function runs and last stopped on kseg1 where is uncached. In this process
> memcmp also returned non-zero when detected kseg0 high 256MB. Then I did
> another thing. memcpy first and test memcmp then (after &_end). It works
> well on 3A3000 but badly on 3A4000. Maybe because kseg0 high 256MB maps
> IO/PCI and it is dangerous to write like write memory.
>
> At last, read memory from where is not memory region may always return 0.
> (Or trigger exception.) This function have been used several years and
> seems no error occur. Maybe it's a fallback way.
That is not true for other platforms like ath79 or mtk.
They'll wrap around or return 0x for out of boundary accessing.
Loongson does not apply to this case as it have special "Address Window"
design to accurately describe address regions.
Any access beyond described windows will be handled by MC and return 0 or
random stuff.
Again, please don't make changes because you can.
Thanks.
- Jiaxun
Re: [PATCH 4/6] MIPS: Loongson64: Add 2K1000 early_printk_port
On Tue, Feb 9, 2021, at 5:32 PM, Qing Zhang wrote: > Distinguish between 3A series CPU and 2K1000 CPU UART0. > > Signed-off-by: Jiaxun Yang > Signed-off-by: Qing Zhang > Signed-off-by: Xingxing Su Personally I don't like this kind of quirk. Probably we should use earlycon as Arm later. - Jiaxun > --- > arch/mips/loongson64/init.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/mips/loongson64/init.c b/arch/mips/loongson64/init.c > index 8bef1ebab72d..a8ad02d8d088 100644 > --- a/arch/mips/loongson64/init.c > +++ b/arch/mips/loongson64/init.c > @@ -120,7 +120,10 @@ void __init prom_init(void) > #endif > > /* Hardcode to CPU UART 0 */ > - setup_8250_early_printk_port(TO_UNCAC(LOONGSON_REG_BASE + 0x1e0), 0, > 1024); > + if ((read_c0_prid() & PRID_IMP_MASK) == PRID_IMP_LOONGSON_64R) > + setup_8250_early_printk_port(TO_UNCAC(LOONGSON_REG_BASE), 0, > 1024); > + else > + setup_8250_early_printk_port(TO_UNCAC(LOONGSON_REG_BASE + > 0x1e0), 0, 1024); > > register_smp_ops(_smp_ops); > board_nmi_handler_setup = mips_nmi_setup; > -- > 2.20.1 > > -- - Jiaxun
Re: [PATCH 5/6] irqchip/loongson-liointc: irqchip add 2.0 version.
On Tue, Feb 9, 2021, at 5:32 PM, Qing Zhang wrote:
> Add IO interrupt controller support for Loongson 2k1000, different
> from the 3a series is that 2K1000 has 64 interrupt sources, 0-31
> correspond to the device tree liointc0 device node, and the other
> correspond to liointc1 node.
>
> Signed-off-by: Jiaxun Yang
> Signed-off-by: Qing Zhang
> Signed-off-by: Xingxing Su
You should document dt binding changes.
Thanks
- Jiaxun
> ---
> drivers/irqchip/irq-loongson-liointc.c | 55 +-
> 1 file changed, 46 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/irqchip/irq-loongson-liointc.c
> b/drivers/irqchip/irq-loongson-liointc.c
> index 9ed1bc473663..496e73bde597 100644
> --- a/drivers/irqchip/irq-loongson-liointc.c
> +++ b/drivers/irqchip/irq-loongson-liointc.c
> @@ -20,6 +20,7 @@
>
> #define LIOINTC_CHIP_IRQ 32
> #define LIOINTC_NUM_PARENT 4
> +#define LIOINTC_NUM_CORES4
>
> #define LIOINTC_INTC_CHIP_START 0x20
>
> @@ -42,6 +43,7 @@ struct liointc_handler_data {
> struct liointc_priv {
> struct irq_chip_generic *gc;
> struct liointc_handler_data handler[LIOINTC_NUM_PARENT];
> + void __iomem*core_isr[LIOINTC_NUM_CORES];
> u8 map_cache[LIOINTC_CHIP_IRQ];
> boolhas_lpc_irq_errata;
> };
> @@ -51,11 +53,12 @@ static void liointc_chained_handle_irq(struct
> irq_desc *desc)
> struct liointc_handler_data *handler =
> irq_desc_get_handler_data(desc);
> struct irq_chip *chip = irq_desc_get_chip(desc);
> struct irq_chip_generic *gc = handler->priv->gc;
> + int core = get_ebase_cpunum() % LIOINTC_NUM_CORES;
> u32 pending;
>
> chained_irq_enter(chip, desc);
>
> - pending = readl(gc->reg_base + LIOINTC_REG_INTC_STATUS);
> + pending = readl(handler->priv->core_isr[core]);
>
> if (!pending) {
> /* Always blame LPC IRQ if we have that bug */
> @@ -141,6 +144,15 @@ static void liointc_resume(struct irq_chip_generic *gc)
> }
>
> static const char * const parent_names[] = {"int0", "int1", "int2", "int3"};
> +static const char * const core_reg_names[] = {"isr0", "isr1", "isr2",
> "isr3"};
> +
> +static void __iomem *liointc_get_reg_byname(struct device_node *node,
> + const char *name)
> +{
> + int index = of_property_match_string(node, "reg-names", name);
> +
> + return of_iomap(node, index);
> +}
>
> int __init liointc_of_init(struct device_node *node,
> struct device_node *parent)
> @@ -159,10 +171,28 @@ int __init liointc_of_init(struct device_node *node,
> if (!priv)
> return -ENOMEM;
>
> - base = of_iomap(node, 0);
> - if (!base) {
> - err = -ENODEV;
> - goto out_free_priv;
> + if (of_device_is_compatible(node, "loongson,liointc-2.0")) {
> + base = liointc_get_reg_byname(node, "main");
> + if (!base) {
> + err = -ENODEV;
> + goto out_free_priv;
> + }
> + for (i = 0; i < LIOINTC_NUM_CORES; i++) {
> + priv->core_isr[i] =
> + liointc_get_reg_byname(node, core_reg_names[i]);
> + }
> + if (!priv->core_isr[0]) {
> + err = -ENODEV;
> + goto out_iounmap_base;
> + }
> + } else {
> + base = of_iomap(node, 0);
> + if (!base) {
> + err = -ENODEV;
> + goto out_free_priv;
> + }
> + for (i = 0; i < LIOINTC_NUM_CORES; i++)
> + priv->core_isr[i] = base + LIOINTC_REG_INTC_STATUS;
> }
>
> for (i = 0; i < LIOINTC_NUM_PARENT; i++) {
> @@ -172,7 +202,7 @@ int __init liointc_of_init(struct device_node *node,
> }
> if (!have_parent) {
> err = -ENODEV;
> - goto out_iounmap;
> + goto out_iounmap_isr;
> }
>
> sz = of_property_read_variable_u32_array(node,
> @@ -183,7 +213,7 @@ int __init liointc_of_init(struct device_node *node,
> if (sz < 4) {
> pr_err("loongson-liointc: No parent_int_map\n");
> err = -ENODEV;
> - goto out_iounmap;
> + goto out_iounmap_isr;
> }
>
> for (i = 0; i < LIOINTC_
Re: [PATCH] MIPS: Make check condition for SDBBP consistent with EJTAG spec
On Tue, Feb 9, 2021, at 12:32 AM, Jiaxun Yang wrote: > > > On Mon, Feb 8, 2021, at 9:14 PM, Tiezhu Yang wrote: > > According to MIPS EJTAG Specification [1], a Debug Breakpoint > > exception occurs when an SDBBP instruction is executed, the > > CP0_DEBUG bit DBp indicates that a Debug Breakpoint exception > > occurred, just check bit DBp for SDBBP is more accurate. > > > > [1] http://www.t-es-t.hu/download/mips/md00047f.pdf > > > > Signed-off-by: Tiezhu Yang > > --- > > arch/mips/kernel/genex.S | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S > > index bcce32a..6336826 100644 > > --- a/arch/mips/kernel/genex.S > > +++ b/arch/mips/kernel/genex.S > > @@ -349,8 +349,8 @@ NESTED(ejtag_debug_handler, PT_SIZE, sp) > > MTC0k0, CP0_DESAVE > > mfc0k0, CP0_DEBUG > > > > - sll k0, k0, 30 # Check for SDBBP. > > - bgezk0, ejtag_return > > + andik0, k0, 0x2 # Check for SDBBP. > > + beqzk0, ejtag_return > > You'd better define a marco for it to prevent further confusion. > > Btw I'm curious about how do kernel receive EJTAG exception? > In my understanding there are only two possible EJTAG exception vectors, > 0xbfc00480 and DSEG one. Both of them are reachable by kernel. ^ not > How do this piece of code work? > > Thanks. > > - Jiaxun > > > > > #ifdef CONFIG_SMP > > 1: PTR_LA k0, ejtag_debug_buffer_spinlock > > -- > > 2.1.0 > > > > > > -- > - Jiaxun > -- - Jiaxun
Re: [PATCH] MIPS: Make check condition for SDBBP consistent with EJTAG spec
On Mon, Feb 8, 2021, at 9:14 PM, Tiezhu Yang wrote: > According to MIPS EJTAG Specification [1], a Debug Breakpoint > exception occurs when an SDBBP instruction is executed, the > CP0_DEBUG bit DBp indicates that a Debug Breakpoint exception > occurred, just check bit DBp for SDBBP is more accurate. > > [1] http://www.t-es-t.hu/download/mips/md00047f.pdf > > Signed-off-by: Tiezhu Yang > --- > arch/mips/kernel/genex.S | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S > index bcce32a..6336826 100644 > --- a/arch/mips/kernel/genex.S > +++ b/arch/mips/kernel/genex.S > @@ -349,8 +349,8 @@ NESTED(ejtag_debug_handler, PT_SIZE, sp) > MTC0k0, CP0_DESAVE > mfc0k0, CP0_DEBUG > > - sll k0, k0, 30 # Check for SDBBP. > - bgezk0, ejtag_return > + andik0, k0, 0x2 # Check for SDBBP. > + beqzk0, ejtag_return You'd better define a marco for it to prevent further confusion. Btw I'm curious about how do kernel receive EJTAG exception? In my understanding there are only two possible EJTAG exception vectors, 0xbfc00480 and DSEG one. Both of them are reachable by kernel. How do this piece of code work? Thanks. - Jiaxun > > #ifdef CONFIG_SMP > 1: PTR_LA k0, ejtag_debug_buffer_spinlock > -- > 2.1.0 > > -- - Jiaxun
Re: [PATCH 1/3] MIPS: ftrace: Fix N32 save registers
On Mon, Feb 1, 2021, at 9:12 AM, Jinyang He wrote: > On 01/31/2021 06:38 PM, Jiaxun Yang wrote: > > > > > On Sun, Jan 31, 2021, at 4:14 PM, Jinyang He wrote: > >> CONFIG_64BIT is confusing. N32 also pass parameters by a0~a7. > > Do we have NEW kernel build? > > CONFIG_64BIT assumed N64 as kernel ABI. > > > > > > -Jiaxun > Hi, Jiaxun, > > Thank you for your reply, and now I know. Before that, I saw the macro > from arch/mips/include/asm/regdef.h and thought it needed to be modified > here. But that seems have no sence. > Please ignore this patch. I guess that's for uapi consideration. Thanks. - Jiaxun > > Thanks, > Jinyang > > >> Signed-off-by: Jinyang He > >> --- > >> arch/mips/kernel/mcount.S | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/mips/kernel/mcount.S b/arch/mips/kernel/mcount.S > >> index cff52b2..808257a 100644 > >> --- a/arch/mips/kernel/mcount.S > >> +++ b/arch/mips/kernel/mcount.S > >> @@ -27,7 +27,7 @@ > >>PTR_S a1, PT_R5(sp) > >>PTR_S a2, PT_R6(sp) > >>PTR_S a3, PT_R7(sp) > >> -#ifdef CONFIG_64BIT > >> +#if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 > >>PTR_S a4, PT_R8(sp) > >>PTR_S a5, PT_R9(sp) > >>PTR_S a6, PT_R10(sp) > >> @@ -42,7 +42,7 @@ > >>PTR_L a1, PT_R5(sp) > >>PTR_L a2, PT_R6(sp) > >>PTR_L a3, PT_R7(sp) > >> -#ifdef CONFIG_64BIT > >> +#if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 > >>PTR_L a4, PT_R8(sp) > >>PTR_L a5, PT_R9(sp) > >>PTR_L a6, PT_R10(sp) > >> -- > >> 2.1.0 > >> > >> > > -- - Jiaxun
Re: [PATCH 1/3] MIPS: ftrace: Fix N32 save registers
On Sun, Jan 31, 2021, at 4:14 PM, Jinyang He wrote: > CONFIG_64BIT is confusing. N32 also pass parameters by a0~a7. Do we have NEW kernel build? CONFIG_64BIT assumed N64 as kernel ABI. -Jiaxun > > Signed-off-by: Jinyang He > --- > arch/mips/kernel/mcount.S | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/kernel/mcount.S b/arch/mips/kernel/mcount.S > index cff52b2..808257a 100644 > --- a/arch/mips/kernel/mcount.S > +++ b/arch/mips/kernel/mcount.S > @@ -27,7 +27,7 @@ > PTR_S a1, PT_R5(sp) > PTR_S a2, PT_R6(sp) > PTR_S a3, PT_R7(sp) > -#ifdef CONFIG_64BIT > +#if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 > PTR_S a4, PT_R8(sp) > PTR_S a5, PT_R9(sp) > PTR_S a6, PT_R10(sp) > @@ -42,7 +42,7 @@ > PTR_L a1, PT_R5(sp) > PTR_L a2, PT_R6(sp) > PTR_L a3, PT_R7(sp) > -#ifdef CONFIG_64BIT > +#if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 > PTR_L a4, PT_R8(sp) > PTR_L a5, PT_R9(sp) > PTR_L a6, PT_R10(sp) > -- > 2.1.0 > > -- - Jiaxun
Re: [PATCH RFC 0/4] Fix arm64 crash for accessing unmapped IO port regions (reboot)
在 2021/1/16 上午12:58, John Garry 写道: This is a reboot of my original series to address the problem of drivers for legacy ISA devices accessing unmapped IO port regions on arm64 systems and causing the system to crash. There was another recent report of such an issue [0], and some old ones [1] and [2] for reference. The background is that many systems do not include PCI host controllers, or they do and controller probe may have failed. For these cases, no IO ports are mapped. However, loading drivers for legacy ISA devices can crash the system as there is nothing to stop them accessing those IO ports (which have not been io remap'ed). My original solution tried to keep the kernel alive in these situations by rejecting logical PIO access to PCI IO regions until PCI IO port regions have been mapped. This series goes one step further, by just reserving the complete legacy IO port range in 0x0--0x for arm64. The motivation for doing this is to make the request_region() calls for those drivers fail, like this: root@ubuntu:/home/john# insmod mk712.ko [ 3415.575800] mk712: unable to get IO region insmod: ERROR: could not insert module mk712.ko: No such device Otherwise, in theory, those drivers could initiate rogue accesses to mapped IO port regions for other devices and cause corruptions or side-effects. Indeed, those drivers should not be allowed to access IO ports at all in such a system. As a secondary defence, for broken drivers who do not call request_region(), IO port accesses in range 0--0x will be ignored, again preserving the system. I am sending as an RFC as I am not sure of any problem with reserving first 0x1 of IO space like this. There is reserve= commandline argument, which does allow this already. Hi John, Is it ok with ACPI? I'm not really familiar with ACPI on arm64 but my impression is ACPI would use legacy I/O ports to communicate with kbd controller, EC and power management facilities. We'd better have a method to detect if ISA bus is not present on the system instead of reserve them unconditionally. Thanks. - Jiaxun For reference, here's how /proc/ioports looks on my arm64 system with this change: root@ubuntu:/home/john# more /proc/ioports 0001-0001 : PCI Bus 0002:f8 0001-00010fff : PCI Bus 0002:f9 0001-00010007 : 0002:f9:00.0 0001-00010007 : serial 00010008-0001000f : 0002:f9:00.1 00010008-0001000f : serial 00010010-00010017 : 0002:f9:00.2 00010018-0001001f : 0002:f9:00.2 0002-0002 : PCI Bus 0004:88 0003-0003 : PCI Bus 0005:78 0004-0004 : PCI Bus 0006:c0 0005-0005 : PCI Bus 0007:90 0006-0006 : PCI Bus 000a:10 0007-0007 : PCI Bus 000c:20 0008-0008 : PCI Bus 000d:30 [0] https://lore.kernel.org/linux-input/20210112055129.7840-1-song.bao@hisilicon.com/T/#mf86445470160c44ac110e9d200b09245169dc5b6 [1] https://lore.kernel.org/linux-pci/56f209a9.4040...@huawei.com [2] https://lore.kernel.org/linux-arm-kernel/e6995b4a-184a-d8d4-f4d4-9ce75d8f4...@huawei.com/ Difference since v4: https://lore.kernel.org/linux-pci/1560262374-67875-1-git-send-email-john.ga...@huawei.com/ - Reserve legacy ISA region John Garry (4): arm64: io: Introduce IO_SPACE_BASE asm-generic/io.h: Add IO_SPACE_BASE kernel/resource: Make ioport_resource.start configurable logic_pio: Warn on and discard accesses to addresses below IO_SPACE_BASE arch/arm64/include/asm/io.h | 1 + include/asm-generic/io.h| 4 include/linux/logic_pio.h | 5 + kernel/resource.c | 2 +- lib/logic_pio.c | 20 ++-- 5 files changed, 25 insertions(+), 7 deletions(-)
Re: [PATCH] mips: cacheinfo: Remove unnecessary increment of level
在 2021/1/16 下午4:40, Souptick Joarder 写道:
kernel test robot throws below warning ->
arch/mips/kernel/cacheinfo.c:112:3: warning: Variable 'level' is
modified but its new value is never used. [unreadVariable]
Remove unnecessary increment of level at the end.
Reported-by: kernel test robot
Signed-off-by: Souptick Joarder
Reviewed-by: Jiaxun Yang
---
arch/mips/kernel/cacheinfo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/kernel/cacheinfo.c b/arch/mips/kernel/cacheinfo.c
index 5f9d0eb..c858ae3 100644
--- a/arch/mips/kernel/cacheinfo.c
+++ b/arch/mips/kernel/cacheinfo.c
@@ -109,7 +109,6 @@ static int __populate_cache_leaves(unsigned int cpu)
if (c->tcache.waysize) {
populate_cache(tcache, this_leaf, level, CACHE_TYPE_UNIFIED);
- level++;
}
this_cpu_ci->cpu_map_populated = true;
Re: [PATCH 0/4] MIPS: process: Some fixes and improvements about get_frame_info()
在 2021/1/12 下午8:29, Jinyang He 写道: Not familiar with microMIPS. Not test on microMIPS. Hi Jinyang, I was messing around QEMU microMIPS and found kernel stuck at loading init process after applied your patches :-( Thanks. - Jiaxun Jinyang He (4): MIPS: process: Reorder header files MIPS: microMIPS: Fix the judgment of mm_jr16_op and mm_jalr_op MIPS: Fix get_frame_info() handing of function size MIPS: Add is_jr_ra_ins() to end the loop early arch/mips/kernel/process.c | 92 +++--- 1 file changed, 62 insertions(+), 30 deletions(-)
Re: [PATCH mips-next 1/2] MIPS: module: optimize module relocations processing
在 2021/1/16 下午11:02, Alexander Lobakin 写道:
For now, module relocation functions are implemented as an array
of handlers of type reloc_handler_t.
Convert that array into a single switch-case function to:
- remove unused arguments;
- change the return type of simple handlers to void;
- remove the array and don't use any data at all;
- avoid using indirect calls;
- allow the compiler to inline and greatly optimize
the relocation function[s].
The result on MIPS32 R2 with GCC 10.2 -O2 is:
scripts/bloat-o-meter -c arch/mips/kernel/__module.o arch/mips/kernel/module.o
add/remove: 1/11 grow/shrink: 1/0 up/down: 876/-1436 (-560)
Function old new delta
apply_relocate 4561148+692
apply_r_mips_pc- 184+184
apply_r_mips_none 8 - -8
apply_r_mips_32 16 - -16
apply_r_mips_64 76 - -76
apply_r_mips_highest 88 - -88
apply_r_mips_higher 108 --108
apply_r_mips_26 132 --132
apply_r_mips_pc26160 --160
apply_r_mips_pc21160 --160
apply_r_mips_pc16160 --160
apply_r_mips_hi16172 --172
apply_r_mips_lo16356 --356
Total: Before=2608, After=2048, chg -21.47%
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Data old new delta
Total: Before=12, After=12, chg +0.00%
add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-248 (-248)
RO Data old new delta
reloc_handlers 248 --248
Total: Before=248, After=0, chg -100.00%
All functions were collapsed into a single one that is called
directly by $(srctree)/kernel/module.c.
Signed-off-by: Alexander Lobakin
Reviewed-by: Jiaxun Yang
---
arch/mips/kernel/module.c | 109 ++
1 file changed, 52 insertions(+), 57 deletions(-)
diff --git a/arch/mips/kernel/module.c b/arch/mips/kernel/module.c
index 3c0c3d1260c1..14f46d17500a 100644
--- a/arch/mips/kernel/module.c
+++ b/arch/mips/kernel/module.c
@@ -40,22 +40,13 @@ void *module_alloc(unsigned long size)
}
#endif
-static int apply_r_mips_none(struct module *me, u32 *location,
-u32 base, Elf_Addr v, bool rela)
-{
- return 0;
-}
-
-static int apply_r_mips_32(struct module *me, u32 *location,
- u32 base, Elf_Addr v, bool rela)
+static void apply_r_mips_32(u32 *location, u32 base, Elf_Addr v)
{
*location = base + v;
-
- return 0;
}
-static int apply_r_mips_26(struct module *me, u32 *location,
- u32 base, Elf_Addr v, bool rela)
+static int apply_r_mips_26(struct module *me, u32 *location, u32 base,
+ Elf_Addr v)
{
if (v % 4) {
pr_err("module %s: dangerous R_MIPS_26 relocation\n",
@@ -75,8 +66,8 @@ static int apply_r_mips_26(struct module *me, u32 *location,
return 0;
}
-static int apply_r_mips_hi16(struct module *me, u32 *location,
-u32 base, Elf_Addr v, bool rela)
+static int apply_r_mips_hi16(struct module *me, u32 *location, Elf_Addr v,
+bool rela)
{
struct mips_hi16 *n;
@@ -217,26 +208,25 @@ static int apply_r_mips_pc(struct module *me, u32 *location, u32 base,
return 0;
}
-static int apply_r_mips_pc16(struct module *me, u32 *location,
-u32 base, Elf_Addr v, bool rela)
+static int apply_r_mips_pc16(struct module *me, u32 *location, u32 base,
+Elf_Addr v)
{
return apply_r_mips_pc(me, location, base, v, 16);
}
-static int apply_r_mips_pc21(struct module *me, u32 *location,
-u32 base, Elf_Addr v, bool rela)
+static int apply_r_mips_pc21(struct module *me, u32 *location, u32 base,
+Elf_Addr v)
{
return apply_r_mips_pc(me, location, base, v, 21);
}
-static int apply_r_mips_pc26(struct module *me, u32 *location,
-u32 base, Elf_Addr v, bool rela)
+static int apply_r_mips_pc26(struct module *me, u32 *location, u32 base,
+Elf_Addr v)
{
return apply_r_mips_pc(me, location, base, v, 26);
}
-static int apply_r_mips_64(struct module *me, u32 *location,
- u32 base, Elf_Addr v, bool rela)
+static int apply_r_mips_64(u32 *location, Elf_Addr v, bool rela)
{
if (WARN_ON(!rela))
return -EINVAL;
@@ -246,8 +236,7 @@ static int apply
[PATCH fixes v4] platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634
Newer ideapads (e.g.: Yoga 14s, 720S 14) come with ELAN0634 touchpad do not
use EC to switch touchpad.
Reading VPCCMD_R_TOUCHPAD will return zero thus touchpad may be blocked
unexpectedly.
Writing VPCCMD_W_TOUCHPAD may cause a spurious key press.
Add has_touchpad_switch to workaround these machines.
Signed-off-by: Jiaxun Yang
Cc: sta...@vger.kernel.org # 5.4+
--
v2: Specify touchpad to ELAN0634
v3: Stupid missing ! in v2
v4: Correct acpi_dev_present usage (Hans)
---
drivers/platform/x86/ideapad-laptop.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 7598cd46cf60..5b81bafa5c16 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -92,6 +92,7 @@ struct ideapad_private {
struct dentry *debug;
unsigned long cfg;
bool has_hw_rfkill_switch;
+ bool has_touchpad_switch;
const char *fnesc_guid;
};
@@ -535,7 +536,9 @@ static umode_t ideapad_is_visible(struct kobject *kobj,
} else if (attr == _attr_fn_lock.attr) {
supported = acpi_has_method(priv->adev->handle, "HALS") &&
acpi_has_method(priv->adev->handle, "SALS");
- } else
+ } else if (attr == _attr_touchpad.attr)
+ supported = priv->has_touchpad_switch;
+ else
supported = true;
return supported ? attr->mode : 0;
@@ -867,6 +870,9 @@ static void ideapad_sync_touchpad_state(struct
ideapad_private *priv)
{
unsigned long value;
+ if (!priv->has_touchpad_switch)
+ return;
+
/* Without reading from EC touchpad LED doesn't switch state */
if (!read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, )) {
/* Some IdeaPads don't really turn off touchpad - they only
@@ -989,6 +995,9 @@ static int ideapad_acpi_add(struct platform_device *pdev)
priv->platform_device = pdev;
priv->has_hw_rfkill_switch = dmi_check_system(hw_rfkill_list);
+ /* Most ideapads with ELAN0634 touchpad don't use EC touchpad switch */
+ priv->has_touchpad_switch = !acpi_dev_present("ELAN0634", NULL, -1);
+
ret = ideapad_sysfs_init(priv);
if (ret)
return ret;
@@ -1006,6 +1015,10 @@ static int ideapad_acpi_add(struct platform_device *pdev)
if (!priv->has_hw_rfkill_switch)
write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1);
+ /* The same for Touchpad */
+ if (!priv->has_touchpad_switch)
+ write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1);
+
for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
if (test_bit(ideapad_rfk_data[i].cfgbit, >cfg))
ideapad_register_rfkill(priv, i);
--
2.30.0
Re: [PATCH] MIPS: zboot: Avoid endless loop in clear BSS.
On Wed, Jan 6, 2021, at 8:47 AM, Jinyang He wrote:
> Commit 2ee1503e546f ("MIPS: zboot: head.S clean up").
>
> After .noreorder removed, clear BSS fall into endless loop. The bne
> instruction will add nop to the delay slot at compile time. So a0
> register will not increment by 4. Fix it and clear BSS from _edata
> to (_end - 1).
Oops, my fault.
My QEMU based local test setup somehow never really tested zboot.
Reviewed-by: Jiaxun Yang
Thanks!
- Jiaxun
>
> Signed-off-by: Jinyang He
> ---
> arch/mips/boot/compressed/head.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/mips/boot/compressed/head.S
> b/arch/mips/boot/compressed/head.S
> index 070b2fb..5795d0a 100644
> --- a/arch/mips/boot/compressed/head.S
> +++ b/arch/mips/boot/compressed/head.S
> @@ -26,8 +26,8 @@
> PTR_LA a0, _edata
> PTR_LA a2, _end
> 1: sw zero, 0(a0)
> + addiu a0, a0, 4
> bne a2, a0, 1b
> - addiu a0, a0, 4
>
> PTR_LA a0, (.heap) /* heap address */
> PTR_LA sp, (.stack + 8192) /* stack address */
> --
> 2.1.0
>
>
--
- Jiaxun
[PATCH v2 2/2] platform/x86: ideapad-laptop: DYTC Platform profile support
Add support to ideapad-laptop for Lenovo platforms that have DYTC
version 5 support or newer to use the platform profile feature.
Mostly based on Mark Pearson 's thinkpad-acpi
work but massaged to fit ideapad driver.
Note that different from ThinkPads, IdeaPads's Thermal Hotkey won't
trigger profile switch itself, we'll leave it for userspace programs.
Tested on Lenovo Yoga-14S ARE Chinese Edition.
Signed-off-by: Jiaxun Yang
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/ideapad-laptop.c | 289 ++
2 files changed, 290 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 91e6176cdfbd..8059143c21bb 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -624,6 +624,7 @@ config IDEAPAD_LAPTOP
depends on BACKLIGHT_CLASS_DEVICE
depends on ACPI_VIDEO || ACPI_VIDEO = n
depends on ACPI_WMI || ACPI_WMI = n
+ depends on ACPI_PLATFORM_PROFILE
select INPUT_SPARSEKMAP
help
This is a driver for Lenovo IdeaPad netbooks contains drivers for
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 7598cd46cf60..5512367c604a 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,6 +78,13 @@ enum {
VPCCMD_W_BL_POWER = 0x33,
};
+struct ideapad_dytc_priv {
+ enum platform_profile_option current_profile;
+ struct platform_profile_handler pprof;
+ struct mutex mutex;
+ struct ideapad_private *priv;
+};
+
struct ideapad_rfk_priv {
int dev;
struct ideapad_private *priv;
@@ -89,6 +97,7 @@ struct ideapad_private {
struct platform_device *platform_device;
struct input_dev *inputdev;
struct backlight_device *blightdev;
+ struct ideapad_dytc_priv *dytc;
struct dentry *debug;
unsigned long cfg;
bool has_hw_rfkill_switch;
@@ -136,6 +145,28 @@ static int method_int1(acpi_handle handle, char *method,
int cmd)
return ACPI_FAILURE(status) ? -1 : 0;
}
+static int method_dytc(acpi_handle handle, int cmd, int *ret)
+{
+ acpi_status status;
+ unsigned long long result;
+ struct acpi_object_list params;
+ union acpi_object in_obj;
+
+ params.count = 1;
+ params.pointer = _obj;
+ in_obj.type = ACPI_TYPE_INTEGER;
+ in_obj.integer.value = cmd;
+
+ status = acpi_evaluate_integer(handle, "DYTC", , );
+
+ if (ACPI_FAILURE(status)) {
+ *ret = -1;
+ return -1;
+ }
+ *ret = result;
+ return 0;
+}
+
static int method_vpcr(acpi_handle handle, int cmd, int *ret)
{
acpi_status status;
@@ -546,6 +577,257 @@ static const struct attribute_group
ideapad_attribute_group = {
.attrs = ideapad_attributes
};
+/*
+ * DYTC Platform profile
+ */
+#define DYTC_CMD_QUERY0 /* To get DYTC status - enable/revision */
+#define DYTC_CMD_SET 1 /* To enable/disable IC function mode */
+#define DYTC_CMD_GET 2 /* To get current IC function and mode */
+#define DYTC_CMD_RESET0x1ff /* To reset back to default */
+
+#define DYTC_QUERY_ENABLE_BIT 8 /* Bit8 - 0 = disabled, 1 = enabled */
+#define DYTC_QUERY_SUBREV_BIT 16 /* Bits 16 - 27 - sub revision */
+#define DYTC_QUERY_REV_BIT28 /* Bits 28 - 31 - revision */
+
+#define DYTC_GET_FUNCTION_BIT 8 /* Bits 8-11 - function setting */
+#define DYTC_GET_MODE_BIT 12 /* Bits 12-15 - mode setting */
+
+#define DYTC_SET_FUNCTION_BIT 12 /* Bits 12-15 - function setting */
+#define DYTC_SET_MODE_BIT 16 /* Bits 16-19 - mode setting */
+#define DYTC_SET_VALID_BIT20 /* Bit 20 - 1 = on, 0 = off */
+
+#define DYTC_FUNCTION_STD 0 /* Function = 0, standard mode */
+#define DYTC_FUNCTION_CQL 1 /* Function = 1, lap mode */
+#define DYTC_FUNCTION_MMC 11 /* Function = 11, desk mode */
+
+#define DYTC_MODE_PERFORM 2 /* High power mode aka performance */
+#define DYTC_MODE_QUIET 3 /* Low power mode aka quiet */
+#define DYTC_MODE_BALANCE 0xF /* Default mode aka balanced */
+
+#define DYTC_SET_COMMAND(function, mode, on) \
+ (DYTC_CMD_SET | (function) << DYTC_SET_FUNCTION_BIT | \
+(mode) << DYTC_SET_MODE_BIT | \
+(on) << DYTC_SET_VALID_BIT)
+
+#define DYTC_DISABLE_CQL DYTC_SET_COMMAND(DYTC_FUNCTION_CQL,
DYTC_MODE_BALANCE, 0)
+
+#define DYTC_ENABLE_CQL DYTC_SET_COMMAND(DYTC_FUNCTION_CQL, DYTC_MODE_BALANCE,
1)
+
+static int convert_dytc_to_profile(int dytcmode, enum platform_profile_option
*profile)
+{
+ switch (dytcmode) {
+ case DYTC_MODE_QUIET:
+ *profile = PLATFORM_PROFILE_LOW_POWER;
+ break;
+ case DYTC_MODE_BALANCE:
+ *profile = PLATFORM_PROFILE_BAL
[PATCH v2 1/2] ACPI: platform-profile: Introduce object pointers to callbacks
Add a object pointer to handler callbacks to avoid having
global variables everywhere.
Signed-off-by: Jiaxun Yang
Suggested-by: Hans de Goede
---
drivers/acpi/platform_profile.c | 4 ++--
include/linux/platform_profile.h | 6 --
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/platform_profile.c b/drivers/acpi/platform_profile.c
index 91be50a32cc8..bb4d7b0fe2ac 100644
--- a/drivers/acpi/platform_profile.c
+++ b/drivers/acpi/platform_profile.c
@@ -64,7 +64,7 @@ static ssize_t platform_profile_show(struct device *dev,
return -ENODEV;
}
- err = cur_profile->profile_get();
+ err = cur_profile->profile_get(cur_profile, );
mutex_unlock(_lock);
if (err)
return err;
@@ -104,7 +104,7 @@ static ssize_t platform_profile_store(struct device *dev,
return -EOPNOTSUPP;
}
- err = cur_profile->profile_set(i);
+ err = cur_profile->profile_set(cur_profile, i);
mutex_unlock(_lock);
if (err)
return err;
diff --git a/include/linux/platform_profile.h b/include/linux/platform_profile.h
index 3623d7108421..43f4583b5259 100644
--- a/include/linux/platform_profile.h
+++ b/include/linux/platform_profile.h
@@ -28,8 +28,10 @@ enum platform_profile_option {
struct platform_profile_handler {
unsigned long choices[BITS_TO_LONGS(PLATFORM_PROFILE_LAST)];
- int (*profile_get)(enum platform_profile_option *profile);
- int (*profile_set)(enum platform_profile_option profile);
+ int (*profile_get)(struct platform_profile_handler *pprof,
+ enum platform_profile_option *profile);
+ int (*profile_set)(struct platform_profile_handler *pprof,
+ enum platform_profile_option profile);
};
int platform_profile_register(const struct platform_profile_handler *pprof);
--
2.30.0
[PATCH v2 0/2] IdeaPad platform profile support
Tested on Lenovo Yoga-14S ARE Chinese Edition. v2: Use another private data approach (Hans) Jiaxun Yang (2): ACPI: platform-profile: Introduce object pointers to callbacks platform/x86: ideapad-laptop: DYTC Platform profile support drivers/acpi/platform_profile.c | 4 +- drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/ideapad-laptop.c | 289 ++ include/linux/platform_profile.h | 6 +- 4 files changed, 296 insertions(+), 4 deletions(-) -- 2.30.0
Re: [PATCH mips-next 2/4] MIPS: vmlinux.lds.S: add ".rel.dyn" to DISCARDS
在 2021/1/5 下午3:39, Fāng-ruì Sòng 写道: On Mon, Jan 4, 2021 at 4:21 AM Alexander Lobakin wrote: GCC somehow manages to place some of the symbols from main.c into .rel.dyn section: mips-alpine-linux-musl-ld: warning: orphan section `.rel.dyn' from `init/main.o' being placed in section `.rel.dyn' I couldn't catch up the exact symbol, but seems like it's harmless to discard it from the final vmlinux as kernel doesn't use or support dynamic relocations. Misc: sort DISCARDS section entries alphabetically. Signed-off-by: Alexander Lobakin --- arch/mips/kernel/vmlinux.lds.S | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S index 83e27a181206..1c3c2e903062 100644 --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -221,9 +221,10 @@ SECTIONS /* ABI crap starts here */ *(.MIPS.abiflags) *(.MIPS.options) + *(.eh_frame) *(.options) *(.pdr) *(.reginfo) - *(.eh_frame) + *(.rel.dyn) } } -- 2.30.0 (I don't know why I am on the CC list since I know little about mips... Anyway, I know the LLD linker's behavior in case that was the intention... ) I think it'd be good to know the reason why these dynamic relocations are produced and fix the root cause. arch/x86/kernel/vmlinux.lds.S asserts no dynamic relocation: ASSERT(SIZEOF(.rela.dyn) == 0, "Unexpected run-time relocations (.rela) detected!") Hi all, Runtime .rela can't be avoided as MIPS kernel can't be built with fPIC. Our relocatable kernel uses another approach, fixup dynamic relocations at boot time. abicalls simply gave us too much overhead on PIC code, which is unacceptable for kernel. In my local tests, PIC kernel reduced unix bench results for around 30%. For MIPS Release6 and afterwards, we may utilize new pcrel instructions to reduce overhead but for older ISA I don't have any idea. Thanks. - Jiaxun
Re: [External] Re: [PATCH 0/2] IdeaPad platform profile support
在 2021/1/5 上午5:58, Mark Pearson 写道: On 04/01/2021 15:58, Hans de Goede wrote: Hi, On 1/4/21 9:33 PM, Rafael J. Wysocki wrote: On Mon, Jan 4, 2021 at 3:36 PM Hans de Goede wrote: Hi, On 1/1/21 1:56 PM, Jiaxun Yang wrote: Tested on Lenovo Yoga-14SARE Chinese Edition. [...] Just for my understanding of what happens nextplease correct me if I have anything wrong: - platform_profile gets pulled from ACPI for 5.11 - platform_profile gets updated to add this data/pointer implementation and goes into 5.12. Hi all, Another approach could be just let all the patch go through pdx86 tree and with pointer part acked by Rafael as it's unlikely to have merge conflicts. Jiaxun, let me know if you're happy with following up on that based on Hans suggestions, If you are pushed for time let me know and I'll happily help out/implement/test as required. I sadly don't have any ideapads but very happy to support your efforts any way I can. I'm happy with Hans suggestion, will send v2 for it later. I've been ask Lenovo engineers about DYTC and other ideapad ACPI stuff on Lenovo China forum[1], but moderator here told me Lenovo won't invest any Linux effort on their consumer product line :-( Is it possible to publish a DYTC specification or documents to help us further understand these mechanisms? I'm tired of reading disassembly AML and code to figure out these internals. - Can we get the x86 portion done at the same time or does that end up going to 5.13? I had been looking at the ideapad_laptop.c patch and have some concerns there as Jiaxun's patch is essentially a duplicate of what I implemented in thinkpad_acpi.c which doesn't seem to be ideal (especially as there is a V6 version of DYTC coming out this year). I haven't had time to look at code to consider better alternatives though... It may be worthy to share these code but I'm comfort to have this duplication as I'm unsure about the future of DYTC. Will DYTC for thinkpads always coherent with DYTC for ideapads? Thanks. [1]: https://club.lenovo.com.cn/thread-5980431-1-1.html - Jiaxun Mark
Re: [PATCH 1/3] MIPS: kernel: Support extracting off-line stack traces from user-space with perf
在 2021/1/4 下午6:59, Peter Zijlstra 写道:
On Tue, Dec 29, 2020 at 08:55:59PM +0800, Tiezhu Yang wrote:
+u64 perf_reg_abi(struct task_struct *tsk)
+{
+ if (test_tsk_thread_flag(tsk, TIF_32BIT_REGS))
+ return PERF_SAMPLE_REGS_ABI_32;
+ else
+ return PERF_SAMPLE_REGS_ABI_64;
+}
So we recently changed this on x86 to not rely on TIF flags. IIRC the
problem is that on x86 you can change the mode of a task without the
kernel being aware of it. Is something like that possible on MIPS as
well?
Hi all,
In MIPS world it's impossible to raise a thread to 64bit without kernel
aware.
Without STATUS.UX set it will trigger reserved instruction exception
when trying
to run 64bit instructions.
However it may be possible to run with 32bit ABI without TIF_32BIT_REGS
if user
program didn't get ELF ABI right. I think that's out of our current
consideration.
The thing x86 does today is look at it's pt_regs state to determine the
actual state.
It is possible to look at pt_regs Status.UX bit on MIPS. But it seems
unnecessary
as user can't change it.
Thanks.
- Jiaxun
[PATCH fixes v3] platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634
Newer ideapads (e.g.: Yoga 14s, 720S 14) come with ELAN0634 touchpad do not
use EC to switch touchpad.
Reading VPCCMD_R_TOUCHPAD will return zero thus touchpad may be blocked
unexpectedly.
Writing VPCCMD_W_TOUCHPAD may cause a spurious key press.
Add has_touchpad_switch to workaround these machines.
Signed-off-by: Jiaxun Yang
Cc: sta...@vger.kernel.org # 5.4+
--
v2: Specify touchpad to ELAN0634
v3: Stupid missing ! in v2
---
drivers/platform/x86/ideapad-laptop.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 7598cd46cf60..427970b3b0da 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -92,6 +92,7 @@ struct ideapad_private {
struct dentry *debug;
unsigned long cfg;
bool has_hw_rfkill_switch;
+ bool has_touchpad_switch;
const char *fnesc_guid;
};
@@ -535,7 +536,9 @@ static umode_t ideapad_is_visible(struct kobject *kobj,
} else if (attr == _attr_fn_lock.attr) {
supported = acpi_has_method(priv->adev->handle, "HALS") &&
acpi_has_method(priv->adev->handle, "SALS");
- } else
+ } else if (attr == _attr_touchpad.attr)
+ supported = priv->has_touchpad_switch;
+ else
supported = true;
return supported ? attr->mode : 0;
@@ -867,6 +870,9 @@ static void ideapad_sync_touchpad_state(struct
ideapad_private *priv)
{
unsigned long value;
+ if (!priv->has_touchpad_switch)
+ return;
+
/* Without reading from EC touchpad LED doesn't switch state */
if (!read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, )) {
/* Some IdeaPads don't really turn off touchpad - they only
@@ -989,6 +995,9 @@ static int ideapad_acpi_add(struct platform_device *pdev)
priv->platform_device = pdev;
priv->has_hw_rfkill_switch = dmi_check_system(hw_rfkill_list);
+ /* Most ideapads with ELAN0634 touchpad don't use EC touchpad switch */
+ priv->has_touchpad_switch = !acpi_dev_present("PNP0C50", "ELAN0634",
-1);
+
ret = ideapad_sysfs_init(priv);
if (ret)
return ret;
@@ -1006,6 +1015,10 @@ static int ideapad_acpi_add(struct platform_device *pdev)
if (!priv->has_hw_rfkill_switch)
write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1);
+ /* The same for Touchpad */
+ if (!priv->has_touchpad_switch)
+ write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1);
+
for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
if (test_bit(ideapad_rfk_data[i].cfgbit, >cfg))
ideapad_register_rfkill(priv, i);
--
2.30.0
[PATCH fixes v2] platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634
Newer ideapads (e.g.: Yoga 14s, 720S 14) come with ELAN0634 touchpad do not
use EC to switch touchpad.
Reading VPCCMD_R_TOUCHPAD will return zero thus touchpad may be blocked
unexpectedly.
Writing VPCCMD_W_TOUCHPAD may cause a spurious key press.
Add has_touchpad_switch to workaround these machines.
Signed-off-by: Jiaxun Yang
Cc: sta...@vger.kernel.org # 5.4+
--
v2: Specify touchpad to ELAN0634
---
drivers/platform/x86/ideapad-laptop.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 7598cd46cf60..3bd29eb956d2 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -92,6 +92,7 @@ struct ideapad_private {
struct dentry *debug;
unsigned long cfg;
bool has_hw_rfkill_switch;
+ bool has_touchpad_switch;
const char *fnesc_guid;
};
@@ -535,7 +536,9 @@ static umode_t ideapad_is_visible(struct kobject *kobj,
} else if (attr == _attr_fn_lock.attr) {
supported = acpi_has_method(priv->adev->handle, "HALS") &&
acpi_has_method(priv->adev->handle, "SALS");
- } else
+ } else if (attr == _attr_touchpad.attr)
+ supported = priv->has_touchpad_switch;
+ else
supported = true;
return supported ? attr->mode : 0;
@@ -867,6 +870,9 @@ static void ideapad_sync_touchpad_state(struct
ideapad_private *priv)
{
unsigned long value;
+ if (!priv->has_touchpad_switch)
+ return;
+
/* Without reading from EC touchpad LED doesn't switch state */
if (!read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, )) {
/* Some IdeaPads don't really turn off touchpad - they only
@@ -989,6 +995,9 @@ static int ideapad_acpi_add(struct platform_device *pdev)
priv->platform_device = pdev;
priv->has_hw_rfkill_switch = dmi_check_system(hw_rfkill_list);
+ /* Most ideapads with ELAN0634 touchpad don't use EC touchpad switch */
+ priv->has_touchpad_switch = acpi_dev_present("PNP0C50", "ELAN0634", -1);
+
ret = ideapad_sysfs_init(priv);
if (ret)
return ret;
@@ -1006,6 +1015,10 @@ static int ideapad_acpi_add(struct platform_device *pdev)
if (!priv->has_hw_rfkill_switch)
write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1);
+ /* The same for Touchpad */
+ if (!priv->has_touchpad_switch)
+ write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1);
+
for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
if (test_bit(ideapad_rfk_data[i].cfgbit, >cfg))
ideapad_register_rfkill(priv, i);
--
2.30.0
Re: [PATCH] platform/x86: ideapad-laptop: Add has_touchpad_switch
在 2021/1/2 上午1:09, Barnabás Pőcze 写道: Hi 2021. január 1., péntek 17:08 keltezéssel, Jiaxun Yang írta: [...] @@ -1006,6 +1018,10 @@ static int ideapad_acpi_add(struct platform_device *pdev) if (!priv->has_hw_rfkill_switch) write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1); + /* The same for Touchpad */ + if (!priv->has_touchpad_switch) + write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1); + Shouldn't it be the other way around: `if (priv->has_touchpad_switch)`? It is to prevent accidentally disable touchpad on machines that do have EC switch, so it's intentional. [...] Sorry, but the explanation not fully clear to me. The commit message seems to indicate that some models "do not use EC to switch touchpad", and I take that means that reading from VPCCMD_R_TOUCHPAD will not reflect the actual state of the touchpad and writing to VPCCMD_W_TOUCHPAD will not change the state of the touchpad. I'm just trying to prevent removing functionality on machines that touchpad can be controlled by EC but also equipped I2C HID touchpad. At least users will have a functional touchpad after that. But then why do you still write to VPCCMD_W_TOUCHPAD on devices where supposedly this does not have any effect (at least not the desired one)? And the part of the code I made my comment about only runs on machines on which the touchpad supposedly cannot be controlled by the EC. What am I missing? And there is the other problem: on some machines, this patch removes working functionality. Yeah that's a problem. I just don't want to repeat the story of rfkill whitelist, it ends up with countless machine to be added. Maybe I should specify HID of touchpad as well. Two machines that known to be problematic all have ELAN0634 touchpad. Thanks. - Jiaxun Regards, Barnabás Pőcze
Re: [PATCH] platform/x86: ideapad-laptop: Add has_touchpad_switch
On Fri, Jan 1, 2021, at 10:20 PM, Barnabás Pőcze wrote:
> Hi
>
>
> 2021. január 1., péntek 7:11 keltezéssel, Jiaxun Yang írta:
>
> > Newer ideapads (e.g.: Yoga 14s, 720S 14) comes with I2C HID
> > Touchpad and do not use EC to switch touchpad. Reading VPCCMD_R_TOUCHPAD
> > will return zero thus touchpad may be blocked. Writing VPCCMD_W_TOUCHPAD
> > may cause a spurious key press.
> >
> > Add has_touchpad_switch to workaround these machines.
> >
> > Signed-off-by: Jiaxun Yang
> > Cc: sta...@vger.kernel.org # 5.4+
>
> Interestingly, the Lenovo Yoga 540-14IKB 80X8 has an HID-over-I2C touchpad,
> and yet it can be controlled by reading/writing the appropriate EC registers.
>
>
> > ---
> > drivers/platform/x86/ideapad-laptop.c | 18 +-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/x86/ideapad-laptop.c
> > b/drivers/platform/x86/ideapad-laptop.c
> > index 7598cd46cf60..b6a4db37d0fc 100644
> > --- a/drivers/platform/x86/ideapad-laptop.c
> > +++ b/drivers/platform/x86/ideapad-laptop.c
> > @@ -92,6 +92,7 @@ struct ideapad_private {
> > struct dentry *debug;
> > unsigned long cfg;
> > bool has_hw_rfkill_switch;
> > + bool has_touchpad_switch;
> > const char *fnesc_guid;
> > };
> >
> > @@ -535,7 +536,9 @@ static umode_t ideapad_is_visible(struct kobject *kobj,
> > } else if (attr == _attr_fn_lock.attr) {
> > supported = acpi_has_method(priv->adev->handle, "HALS") &&
> > acpi_has_method(priv->adev->handle, "SALS");
> > - } else
> > + } else if (attr == _attr_touchpad.attr)
> > + supported = priv->has_touchpad_switch;
> > + else
> > supported = true;
> >
> > return supported ? attr->mode : 0;
> > @@ -867,6 +870,9 @@ static void ideapad_sync_touchpad_state(struct
> > ideapad_private *priv)
> > {
> > unsigned long value;
> >
> > + if (!priv->has_touchpad_switch)
> > + return;
> > +
> > /* Without reading from EC touchpad LED doesn't switch state */
> > if (!read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, )) {
> > /* Some IdeaPads don't really turn off touchpad - they only
> > @@ -989,6 +995,12 @@ static int ideapad_acpi_add(struct platform_device
> > *pdev)
> > priv->platform_device = pdev;
> > priv->has_hw_rfkill_switch = dmi_check_system(hw_rfkill_list);
> >
> > + /* Most ideapads with I2C HID don't use EC touchpad switch */
> > + if (acpi_dev_present("PNP0C50", NULL, -1))
> > + priv->has_touchpad_switch = false;
> > + else
> > + priv->has_touchpad_switch = true;
> > +
>
> `priv->has_touchpad_switch = !acpi_dev_present(...)`
> ?
Will fix.
>
>
> > ret = ideapad_sysfs_init(priv);
> > if (ret)
> > return ret;
> > @@ -1006,6 +1018,10 @@ static int ideapad_acpi_add(struct platform_device
> > *pdev)
> > if (!priv->has_hw_rfkill_switch)
> > write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1);
> >
> > + /* The same for Touchpad */
> > + if (!priv->has_touchpad_switch)
> > + write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1);
> > +
>
> Shouldn't it be the other way around: `if (priv->has_touchpad_switch)`?
It is to prevent accidentally disable touchpad on machines that do have EC
switch,
so it's intentional.
Thanks.
- Jiaxun
>
>
>
> > for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
> > if (test_bit(ideapad_rfk_data[i].cfgbit, >cfg))
> > ideapad_register_rfkill(priv, i);
> > --
> > 2.30.0
>
>
> Regards,
> Barnabás Pőcze
>
--
- Jiaxun
[PATCH 0/2] IdeaPad platform profile support
Tested on Lenovo Yoga-14SARE Chinese Edition. Jiaxun Yang (2): ACPI: platform-profile: Introduce data parameter to handler platform/x86: ideapad-laptop: DYTC Platform profile support drivers/acpi/platform_profile.c | 4 +- drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/ideapad-laptop.c | 281 ++ include/linux/platform_profile.h | 5 +- 4 files changed, 287 insertions(+), 4 deletions(-) -- 2.30.0
[PATCH 1/2] ACPI: platform-profile: Introduce data parameter to handler
Add a data parameter to handler callbacks to avoid having
global variables everywhere.
Signed-off-by: Jiaxun Yang
---
drivers/acpi/platform_profile.c | 4 ++--
include/linux/platform_profile.h | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/platform_profile.c b/drivers/acpi/platform_profile.c
index 91be50a32cc8..60072f6e032d 100644
--- a/drivers/acpi/platform_profile.c
+++ b/drivers/acpi/platform_profile.c
@@ -64,7 +64,7 @@ static ssize_t platform_profile_show(struct device *dev,
return -ENODEV;
}
- err = cur_profile->profile_get();
+ err = cur_profile->profile_get(cur_profile->data, );
mutex_unlock(_lock);
if (err)
return err;
@@ -104,7 +104,7 @@ static ssize_t platform_profile_store(struct device *dev,
return -EOPNOTSUPP;
}
- err = cur_profile->profile_set(i);
+ err = cur_profile->profile_set(cur_profile->data, i);
mutex_unlock(_lock);
if (err)
return err;
diff --git a/include/linux/platform_profile.h b/include/linux/platform_profile.h
index 3623d7108421..272faf55875d 100644
--- a/include/linux/platform_profile.h
+++ b/include/linux/platform_profile.h
@@ -27,9 +27,10 @@ enum platform_profile_option {
};
struct platform_profile_handler {
+ void *data;
unsigned long choices[BITS_TO_LONGS(PLATFORM_PROFILE_LAST)];
- int (*profile_get)(enum platform_profile_option *profile);
- int (*profile_set)(enum platform_profile_option profile);
+ int (*profile_get)(void *data, enum platform_profile_option *profile);
+ int (*profile_set)(void *data, enum platform_profile_option profile);
};
int platform_profile_register(const struct platform_profile_handler *pprof);
--
2.30.0
[PATCH 2/2] platform/x86: ideapad-laptop: DYTC Platform profile support
Add support to ideapad-laptop for Lenovo platforms that have DYTC
version 5 support or newer to use the platform profile feature.
Mostly based on Mark Pearson 's thinkpad-acpi
work but massaged to fit ideapad driver.
Note that different from ThinkPads, IdeaPads's Thermal Hotkey won't
trigger profile wwitch itself, we'll leave it for userspace programs.
Tested on Lenovo Yoga-14SARE Chinese Edition.
Signed-off-by: Jiaxun Yang
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/ideapad-laptop.c | 281 ++
2 files changed, 282 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 91e6176cdfbd..8059143c21bb 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -624,6 +624,7 @@ config IDEAPAD_LAPTOP
depends on BACKLIGHT_CLASS_DEVICE
depends on ACPI_VIDEO || ACPI_VIDEO = n
depends on ACPI_WMI || ACPI_WMI = n
+ depends on ACPI_PLATFORM_PROFILE
select INPUT_SPARSEKMAP
help
This is a driver for Lenovo IdeaPad netbooks contains drivers for
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 7598cd46cf60..8e91b813e623 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,6 +78,12 @@ enum {
VPCCMD_W_BL_POWER = 0x33,
};
+struct ideapad_dytc_priv {
+ enum platform_profile_option current_profile;
+ struct platform_profile_handler handler;
+ struct mutex mutex;
+};
+
struct ideapad_rfk_priv {
int dev;
struct ideapad_private *priv;
@@ -89,6 +96,7 @@ struct ideapad_private {
struct platform_device *platform_device;
struct input_dev *inputdev;
struct backlight_device *blightdev;
+ struct ideapad_dytc_priv *dytc;
struct dentry *debug;
unsigned long cfg;
bool has_hw_rfkill_switch;
@@ -136,6 +144,28 @@ static int method_int1(acpi_handle handle, char *method,
int cmd)
return ACPI_FAILURE(status) ? -1 : 0;
}
+static int method_dytc(acpi_handle handle, int cmd, int *ret)
+{
+ acpi_status status;
+ unsigned long long result;
+ struct acpi_object_list params;
+ union acpi_object in_obj;
+
+ params.count = 1;
+ params.pointer = _obj;
+ in_obj.type = ACPI_TYPE_INTEGER;
+ in_obj.integer.value = cmd;
+
+ status = acpi_evaluate_integer(handle, "DYTC", , );
+
+ if (ACPI_FAILURE(status)) {
+ *ret = -1;
+ return -1;
+ }
+ *ret = result;
+ return 0;
+}
+
static int method_vpcr(acpi_handle handle, int cmd, int *ret)
{
acpi_status status;
@@ -546,6 +576,250 @@ static const struct attribute_group
ideapad_attribute_group = {
.attrs = ideapad_attributes
};
+/*
+ * DYTC Platform profile
+ */
+#define DYTC_CMD_QUERY0 /* To get DYTC status - enable/revision */
+#define DYTC_CMD_SET 1 /* To enable/disable IC function mode */
+#define DYTC_CMD_GET 2 /* To get current IC function and mode */
+#define DYTC_CMD_RESET0x1ff /* To reset back to default */
+
+#define DYTC_QUERY_ENABLE_BIT 8 /* Bit8 - 0 = disabled, 1 = enabled */
+#define DYTC_QUERY_SUBREV_BIT 16 /* Bits 16 - 27 - sub revision */
+#define DYTC_QUERY_REV_BIT28 /* Bits 28 - 31 - revision */
+
+#define DYTC_GET_FUNCTION_BIT 8 /* Bits 8-11 - function setting */
+#define DYTC_GET_MODE_BIT 12 /* Bits 12-15 - mode setting */
+
+#define DYTC_SET_FUNCTION_BIT 12 /* Bits 12-15 - function setting */
+#define DYTC_SET_MODE_BIT 16 /* Bits 16-19 - mode setting */
+#define DYTC_SET_VALID_BIT20 /* Bit 20 - 1 = on, 0 = off */
+
+#define DYTC_FUNCTION_STD 0 /* Function = 0, standard mode */
+#define DYTC_FUNCTION_CQL 1 /* Function = 1, lap mode */
+#define DYTC_FUNCTION_MMC 11 /* Function = 11, desk mode */
+
+#define DYTC_MODE_PERFORM 2 /* High power mode aka performance */
+#define DYTC_MODE_QUIET 3 /* Low power mode aka quiet */
+#define DYTC_MODE_BALANCE 0xF /* Default mode aka balanced */
+
+#define DYTC_SET_COMMAND(function, mode, on) \
+ (DYTC_CMD_SET | (function) << DYTC_SET_FUNCTION_BIT | \
+(mode) << DYTC_SET_MODE_BIT | \
+(on) << DYTC_SET_VALID_BIT)
+
+#define DYTC_DISABLE_CQL DYTC_SET_COMMAND(DYTC_FUNCTION_CQL,
DYTC_MODE_BALANCE, 0)
+
+#define DYTC_ENABLE_CQL DYTC_SET_COMMAND(DYTC_FUNCTION_CQL, DYTC_MODE_BALANCE,
1)
+
+static int convert_dytc_to_profile(int dytcmode, enum platform_profile_option
*profile)
+{
+ switch (dytcmode) {
+ case DYTC_MODE_QUIET:
+ *profile = PLATFORM_PROFILE_LOW_POWER;
+ break;
+ case DYTC_MODE_BALANCE:
+ *profile = PLATFORM_PROFILE_BALANCED;
+ break;
+
[PATCH] platform/x86: ideapad-laptop: Add has_touchpad_switch
Newer ideapads (e.g.: Yoga 14s, 720S 14) comes with I2C HID
Touchpad and do not use EC to switch touchpad. Reading VPCCMD_R_TOUCHPAD
will return zero thus touchpad may be blocked. Writing VPCCMD_W_TOUCHPAD
may cause a spurious key press.
Add has_touchpad_switch to workaround these machines.
Signed-off-by: Jiaxun Yang
Cc: sta...@vger.kernel.org # 5.4+
---
drivers/platform/x86/ideapad-laptop.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 7598cd46cf60..b6a4db37d0fc 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -92,6 +92,7 @@ struct ideapad_private {
struct dentry *debug;
unsigned long cfg;
bool has_hw_rfkill_switch;
+ bool has_touchpad_switch;
const char *fnesc_guid;
};
@@ -535,7 +536,9 @@ static umode_t ideapad_is_visible(struct kobject *kobj,
} else if (attr == _attr_fn_lock.attr) {
supported = acpi_has_method(priv->adev->handle, "HALS") &&
acpi_has_method(priv->adev->handle, "SALS");
- } else
+ } else if (attr == _attr_touchpad.attr)
+ supported = priv->has_touchpad_switch;
+ else
supported = true;
return supported ? attr->mode : 0;
@@ -867,6 +870,9 @@ static void ideapad_sync_touchpad_state(struct
ideapad_private *priv)
{
unsigned long value;
+ if (!priv->has_touchpad_switch)
+ return;
+
/* Without reading from EC touchpad LED doesn't switch state */
if (!read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, )) {
/* Some IdeaPads don't really turn off touchpad - they only
@@ -989,6 +995,12 @@ static int ideapad_acpi_add(struct platform_device *pdev)
priv->platform_device = pdev;
priv->has_hw_rfkill_switch = dmi_check_system(hw_rfkill_list);
+ /* Most ideapads with I2C HID don't use EC touchpad switch */
+ if (acpi_dev_present("PNP0C50", NULL, -1))
+ priv->has_touchpad_switch = false;
+ else
+ priv->has_touchpad_switch = true;
+
ret = ideapad_sysfs_init(priv);
if (ret)
return ret;
@@ -1006,6 +1018,10 @@ static int ideapad_acpi_add(struct platform_device *pdev)
if (!priv->has_hw_rfkill_switch)
write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1);
+ /* The same for Touchpad */
+ if (!priv->has_touchpad_switch)
+ write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1);
+
for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
if (test_bit(ideapad_rfk_data[i].cfgbit, >cfg))
ideapad_register_rfkill(priv, i);
--
2.30.0
Re: [PATCH 1/3] MIPS: Add vulnerabilities infrastructure
在 2020/12/31 23:38, WANG Xuerui 写道:
Hi Jiaxun,
Overall a nice step towards a more conformant arch/mips! Some nits
below though.
On 12/30/20 11:23 AM, Jiaxun Yang wrote:
Add infrastructure to display CPU vulnerabilities.
As most MIPS CPU vendors are dead today and we can't confirm
vulnerabilities states with them, we'll display vulnerabilities
as "Unknown" by default and override them in cpu-probe.c
Add trailing period.
Signed-off-by: Jiaxun Yang
---
arch/mips/Kconfig | 1 +
arch/mips/include/asm/cpu-info.h | 5
arch/mips/include/asm/cpu.h | 7 +
arch/mips/kernel/Makefile | 2 +-
arch/mips/kernel/vulnbl.c | 46
5 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/kernel/vulnbl.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ef5b2a177b1b..524053b8f769 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -24,6 +24,7 @@ config MIPS
select GENERIC_CLOCKEVENTS
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
+ select GENERIC_CPU_VULNERABILITIES
select GENERIC_GETTIMEOFDAY
select GENERIC_IOMAP
select GENERIC_IRQ_PROBE
diff --git a/arch/mips/include/asm/cpu-info.h
b/arch/mips/include/asm/cpu-info.h
index a600670d00e9..1a964dbfc0a8 100644
--- a/arch/mips/include/asm/cpu-info.h
+++ b/arch/mips/include/asm/cpu-info.h
@@ -106,6 +106,11 @@ struct cpuinfo_mips {
unsigned int guestid_mask;
unsigned int guestid_cache;
+ /* Vulnerabilities */
+ unsigned int vulnerabilities; /* Vulnerabilities states
that we known */
+ unsigned int vulnerable; /* Vulnerabilities affated */
+ unsigned int mitigations; /* Mitigations */
Could you make the field names a little clearer? Like "known_mask",
"affected_mask" and "mitigated_mask"?
Also I wonder if removing the first mask is okay, since if a bit is
neither "affected" nor "mitigated" then it must belong to the
"unknown" case.
Actually we have no way to mitigate them in kernel for now :-(
+
#ifdef CONFIG_CPU_LOONGSON3_CPUCFG_EMULATION
/* CPUCFG data for this CPU, synthesized at probe time.
*
diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index f5b04e8f6061..3414c9f5464e 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -447,4 +447,11 @@ enum cpu_type_enum {
#define MIPS_ASE_LOONGSON_EXT 0x2000 /* Loongson EXTensions */
#define MIPS_ASE_LOONGSON_EXT2 0x4000 /* Loongson EXTensions
R2 */
+/*
+ * CPU security vulnerabilities
+ */
+#define MIPS_VULNBL_MELTDOWN BIT(0)
+#define MIPS_VULNBL_SPECTRE_V1 BIT(1)
+#define MIPS_VULNBL_SPECTRE_V2 BIT(2)
Looking at the arch/x86 vulnerabilities code, I tend to think that
"VULNBL" is not (rather ugly) shorthand for "vulnerability", but
"vulnerability blacklist" (!), because they have "VULNWL" for
apparently "whitelist". So I suggest writing out "VULNERABILITY" fully
for clarity.
+
#endif /* _ASM_CPU_H */
diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index 13a26d254829..39abc8ead5e0 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -8,7 +8,7 @@ extra-y := head.o vmlinux.lds
obj-y += cmpxchg.o cpu-probe.o branch.o elf.o entry.o
genex.o idle.o irq.o \
process.o prom.o ptrace.o reset.o setup.o signal.o \
syscall.o time.o topology.o traps.o unaligned.o watch.o \
- vdso.o cacheinfo.o
+ vdso.o cacheinfo.o vulnbl.o
ifdef CONFIG_FUNCTION_TRACER
CFLAGS_REMOVE_ftrace.o = -pg
diff --git a/arch/mips/kernel/vulnbl.c b/arch/mips/kernel/vulnbl.c
new file mode 100644
index ..fc73da6214fe
--- /dev/null
+++ b/arch/mips/kernel/vulnbl.c
Same with this filename.
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020, Jiaxun Yang
+ * MIPS CPU vulnerabilities
+ */
+
+#include
+
+#include
+#include
+
+ssize_t cpu_show_meltdown(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_MELTDOWN))
+ return sprintf(buf, "Unknown\n");
+
+ if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_MELTDOWN))
+ return sprintf(buf, "Not affected\n");
+
+ return sprintf(buf, "Affected\n");
Be consistent with other arches and use "Vulnerable"?
+}
+
+ssize_t cpu_show_spectre_v1(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_SPECTRE_V1))
+ return sprintf(buf, "Unknown\n");
+
+ if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_SPECTRE_V1))
+ return sprintf(b
Re: [PATCH 3/3] MIPS: cpu-probe: Vulnerabilities for Loongson cores
在 2020/12/31 23:43, WANG Xuerui 写道:
Hi Jiaxun,
On 12/30/20 11:23 AM, Jiaxun Yang wrote:
Loongson64C is known to be vulnerable to meltdown according to
PoC from Rui Wang .
Loongson64G defended these side-channel attack by silicon.
"Loongson64G mitigated it in hardware"?
Signed-off-by: Jiaxun Yang
---
arch/mips/kernel/cpu-probe.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 2460783dbdb1..24b21f51353c 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -2092,6 +2092,8 @@ static inline void cpu_probe_loongson(struct
cpuinfo_mips *c, unsigned int cpu)
c->ases |= (MIPS_ASE_LOONGSON_MMI | MIPS_ASE_LOONGSON_CAM |
MIPS_ASE_LOONGSON_EXT | MIPS_ASE_LOONGSON_EXT2);
c->ases &= ~MIPS_ASE_VZ; /* VZ of Loongson-3A2000/3000 is
incomplete */
+ c->vulnerabilities |= MIPS_VULNBL_MELTDOWN;
+ c->vulnerable |= MIPS_VULNBL_MELTDOWN;
break;
case PRID_IMP_LOONGSON_64G:
c->cputype = CPU_LOONGSON64;
@@ -2100,6 +2102,8 @@ static inline void cpu_probe_loongson(struct
cpuinfo_mips *c, unsigned int cpu)
set_isa(c, MIPS_CPU_ISA_M64R2);
decode_cpucfg(c);
c->writecombine = _CACHE_UNCACHED_ACCELERATED;
+ c->vulnerabilities |= MIPS_VULNBL_MELTDOWN |
+ MIPS_VULNBL_SPECTRE_V1 | MIPS_VULNBL_SPECTRE_V2;
Of course you forgot to set the "mitigated" mask... Oh wait.
Hi Xuerui,
Actually it belongs to not affected category as there is no action
to take in kernel.
It seems the "mitigated" mask in the 1st patch is never used, so
either code there or here must be amended.
Yes, it's just a place holder for future kernel mitigations~
Or I should leave it until we find out these mitigations?
Thanks.
- Jiaxun
break;
default:
panic("Unknown Loongson Processor ID!");
[PATCH v3] MIPS: zboot: head.S clean up
.cprestore is removed as we don't expect Position Independent zboot ELF. .noreorder is also removed and rest instructions are massaged to improve readability. t9 register is used for indirect jump as MIPS ABI requirement. start label is removed as it already defined in LEAF. Reported-by: Paul Cercueil Signed-off-by: Jiaxun Yang -- v2: Remove start label (paul) --- arch/mips/boot/compressed/head.S | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/arch/mips/boot/compressed/head.S b/arch/mips/boot/compressed/head.S index 409cb483a9ff..070b2fbabae4 100644 --- a/arch/mips/boot/compressed/head.S +++ b/arch/mips/boot/compressed/head.S @@ -15,10 +15,7 @@ #include #include - .set noreorder - .cprestore LEAF(start) -start: /* Save boot rom start args */ moves0, a0 moves1, a1 @@ -35,21 +32,20 @@ start: PTR_LA a0, (.heap) /* heap address */ PTR_LA sp, (.stack + 8192) /* stack address */ - PTR_LA ra, 2f - PTR_LA k0, decompress_kernel - jr k0 -nop + PTR_LA t9, decompress_kernel + jalrt9 + 2: movea0, s0 movea1, s1 movea2, s2 movea3, s3 - PTR_LI k0, KERNEL_ENTRY - jr k0 -nop + PTR_LI t9, KERNEL_ENTRY + jalrt9 + 3: b 3b -nop + END(start) .comm .heap,BOOT_HEAP_SIZE,4 -- 2.30.0
Re: [PATCH v2] MIPS: zboot: head.S clean up
在 2020/12/30 上午11:08, Jiaxun Yang 写道: .cprestore is removed as we don't expect Position Independent zboot ELF. .noreorder is also removed and rest instructions are massaged to improve readability. t9 register is used for indirect jump as MIPS ABI requirement. start label is removed as it already defined in LEAF. Reported-by: Paul Cercueil Signed-off-by: Jiaxun Yang -- v2: Remove start label (paul) --- arch/mips/boot/compressed/head.S | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/arch/mips/boot/compressed/head.S b/arch/mips/boot/compressed/head.S index 409cb483a9ff..977218c90bc8 100644 --- a/arch/mips/boot/compressed/head.S +++ b/arch/mips/boot/compressed/head.S @@ -15,8 +15,6 @@ #include #include - .set noreorder - .cprestore LEAF(start) start: Oops, it's still here, sorry for the noise. Thanks - Jiaxun /* Save boot rom start args */ @@ -35,21 +33,20 @@ start: PTR_LA a0, (.heap) /* heap address */ PTR_LA sp, (.stack + 8192) /* stack address */ - PTR_LA ra, 2f - PTR_LA k0, decompress_kernel - jr k0 -nop + PTR_LA t9, decompress_kernel + jalrt9 + 2: movea0, s0 movea1, s1 movea2, s2 movea3, s3 - PTR_LI k0, KERNEL_ENTRY - jr k0 -nop + PTR_LI t9, KERNEL_ENTRY + jalrt9 + 3: b 3b -nop + END(start) .comm .heap,BOOT_HEAP_SIZE,4
[PATCH 2/2] MIPS: Loongson64: Set cluster for cores
cluster is required for cacheinfo to set shared_cpu_map correctly. Signed-off-by: Jiaxun Yang Reviewed-by: Tiezhu Yang Tested-by: Tiezhu Yang --- arch/mips/loongson64/smp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c index e744e1bee49e..fae3a97d853c 100644 --- a/arch/mips/loongson64/smp.c +++ b/arch/mips/loongson64/smp.c @@ -403,6 +403,8 @@ static void __init loongson3_smp_setup(void) __cpu_number_map[i] = num; __cpu_logical_map[num] = i; set_cpu_possible(num, true); + /* Loongson processors are always grouped by 4 */ + cpu_set_cluster(_data[num], i / 4); num++; } i++; -- 2.30.0
[PATCH RESEND 1/2] MIPS: cacheinfo: Add missing VCache
Victim Cache is defined by Loongson as per-core unified
private Cache.
Add this into cacheinfo and make cache levels selfincrement
instead of hardcode levels.
Signed-off-by: Jiaxun Yang
Reviewed-by: Tiezhu Yang
Tested-by: Tiezhu Yang
---
arch/mips/kernel/cacheinfo.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/arch/mips/kernel/cacheinfo.c b/arch/mips/kernel/cacheinfo.c
index 47312c529410..83548331ee94 100644
--- a/arch/mips/kernel/cacheinfo.c
+++ b/arch/mips/kernel/cacheinfo.c
@@ -35,6 +35,11 @@ static int __init_cache_level(unsigned int cpu)
leaves += (c->icache.waysize) ? 2 : 1;
+ if (c->vcache.waysize) {
+ levels++;
+ leaves++;
+ }
+
if (c->scache.waysize) {
levels++;
leaves++;
@@ -74,25 +79,38 @@ static int __populate_cache_leaves(unsigned int cpu)
struct cpuinfo_mips *c = _cpu_data;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
struct cacheinfo *this_leaf = this_cpu_ci->info_list;
+ int level = 1;
if (c->icache.waysize) {
- /* L1 caches are per core */
+ /* D/I caches are per core */
fill_cpumask_siblings(cpu, _leaf->shared_cpu_map);
- populate_cache(dcache, this_leaf, 1, CACHE_TYPE_DATA);
+ populate_cache(dcache, this_leaf, level, CACHE_TYPE_DATA);
fill_cpumask_siblings(cpu, _leaf->shared_cpu_map);
- populate_cache(icache, this_leaf, 1, CACHE_TYPE_INST);
+ populate_cache(icache, this_leaf, level, CACHE_TYPE_INST);
+ level++;
} else {
- populate_cache(dcache, this_leaf, 1, CACHE_TYPE_UNIFIED);
+ populate_cache(dcache, this_leaf, level, CACHE_TYPE_UNIFIED);
+ level++;
+ }
+
+ if (c->vcache.waysize) {
+ /* Vcache is per core as well */
+ fill_cpumask_siblings(cpu, _leaf->shared_cpu_map);
+ populate_cache(vcache, this_leaf, level, CACHE_TYPE_UNIFIED);
+ level++;
}
if (c->scache.waysize) {
- /* L2 cache is per cluster */
+ /* Scache is per cluster */
fill_cpumask_cluster(cpu, _leaf->shared_cpu_map);
- populate_cache(scache, this_leaf, 2, CACHE_TYPE_UNIFIED);
+ populate_cache(scache, this_leaf, level, CACHE_TYPE_UNIFIED);
+ level++;
}
- if (c->tcache.waysize)
- populate_cache(tcache, this_leaf, 3, CACHE_TYPE_UNIFIED);
+ if (c->tcache.waysize) {
+ populate_cache(tcache, this_leaf, level, CACHE_TYPE_UNIFIED);
+ level++;
+ }
this_cpu_ci->cpu_map_populated = true;
--
2.30.0
[PATCH 1/3] MIPS: Add vulnerabilities infrastructure
Add infrastructure to display CPU vulnerabilities.
As most MIPS CPU vendors are dead today and we can't confirm
vulnerabilities states with them, we'll display vulnerabilities
as "Unknown" by default and override them in cpu-probe.c
Signed-off-by: Jiaxun Yang
---
arch/mips/Kconfig| 1 +
arch/mips/include/asm/cpu-info.h | 5
arch/mips/include/asm/cpu.h | 7 +
arch/mips/kernel/Makefile| 2 +-
arch/mips/kernel/vulnbl.c| 46
5 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/kernel/vulnbl.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ef5b2a177b1b..524053b8f769 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -24,6 +24,7 @@ config MIPS
select GENERIC_CLOCKEVENTS
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
+ select GENERIC_CPU_VULNERABILITIES
select GENERIC_GETTIMEOFDAY
select GENERIC_IOMAP
select GENERIC_IRQ_PROBE
diff --git a/arch/mips/include/asm/cpu-info.h b/arch/mips/include/asm/cpu-info.h
index a600670d00e9..1a964dbfc0a8 100644
--- a/arch/mips/include/asm/cpu-info.h
+++ b/arch/mips/include/asm/cpu-info.h
@@ -106,6 +106,11 @@ struct cpuinfo_mips {
unsigned intguestid_mask;
unsigned intguestid_cache;
+ /* Vulnerabilities */
+ unsigned intvulnerabilities; /* Vulnerabilities states that
we known */
+ unsigned intvulnerable; /* Vulnerabilities affated */
+ unsigned intmitigations; /* Mitigations */
+
#ifdef CONFIG_CPU_LOONGSON3_CPUCFG_EMULATION
/* CPUCFG data for this CPU, synthesized at probe time.
*
diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index f5b04e8f6061..3414c9f5464e 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -447,4 +447,11 @@ enum cpu_type_enum {
#define MIPS_ASE_LOONGSON_EXT 0x2000 /* Loongson EXTensions */
#define MIPS_ASE_LOONGSON_EXT2 0x4000 /* Loongson EXTensions R2 */
+/*
+ * CPU security vulnerabilities
+ */
+#define MIPS_VULNBL_MELTDOWN BIT(0)
+#define MIPS_VULNBL_SPECTRE_V1 BIT(1)
+#define MIPS_VULNBL_SPECTRE_V2 BIT(2)
+
#endif /* _ASM_CPU_H */
diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index 13a26d254829..39abc8ead5e0 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -8,7 +8,7 @@ extra-y := head.o vmlinux.lds
obj-y += cmpxchg.o cpu-probe.o branch.o elf.o entry.o genex.o idle.o
irq.o \
process.o prom.o ptrace.o reset.o setup.o signal.o \
syscall.o time.o topology.o traps.o unaligned.o watch.o \
- vdso.o cacheinfo.o
+ vdso.o cacheinfo.o vulnbl.o
ifdef CONFIG_FUNCTION_TRACER
CFLAGS_REMOVE_ftrace.o = -pg
diff --git a/arch/mips/kernel/vulnbl.c b/arch/mips/kernel/vulnbl.c
new file mode 100644
index ..fc73da6214fe
--- /dev/null
+++ b/arch/mips/kernel/vulnbl.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020, Jiaxun Yang
+ * MIPS CPU vulnerabilities
+ */
+
+#include
+
+#include
+#include
+
+ssize_t cpu_show_meltdown(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_MELTDOWN))
+ return sprintf(buf, "Unknown\n");
+
+ if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_MELTDOWN))
+ return sprintf(buf, "Not affected\n");
+
+ return sprintf(buf, "Affected\n");
+}
+
+ssize_t cpu_show_spectre_v1(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_SPECTRE_V1))
+ return sprintf(buf, "Unknown\n");
+
+ if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_SPECTRE_V1))
+ return sprintf(buf, "Not affected\n");
+
+ return sprintf(buf, "Affected\n");
+}
+
+ssize_t cpu_show_spectre_v2(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_SPECTRE_V2))
+ return sprintf(buf, "Unknown\n");
+
+ if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_SPECTRE_V2))
+ return sprintf(buf, "Not affected\n");
+
+ return sprintf(buf, "Affected\n");
+}
--
2.30.0
[PATCH 3/3] MIPS: cpu-probe: Vulnerabilities for Loongson cores
Loongson64C is known to be vulnerable to meltdown according to
PoC from Rui Wang .
Loongson64G defended these side-channel attack by silicon.
Signed-off-by: Jiaxun Yang
---
arch/mips/kernel/cpu-probe.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 2460783dbdb1..24b21f51353c 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -2092,6 +2092,8 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips
*c, unsigned int cpu)
c->ases |= (MIPS_ASE_LOONGSON_MMI | MIPS_ASE_LOONGSON_CAM |
MIPS_ASE_LOONGSON_EXT | MIPS_ASE_LOONGSON_EXT2);
c->ases &= ~MIPS_ASE_VZ; /* VZ of Loongson-3A2000/3000 is
incomplete */
+ c->vulnerabilities |= MIPS_VULNBL_MELTDOWN;
+ c->vulnerable |= MIPS_VULNBL_MELTDOWN;
break;
case PRID_IMP_LOONGSON_64G:
c->cputype = CPU_LOONGSON64;
@@ -2100,6 +2102,8 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips
*c, unsigned int cpu)
set_isa(c, MIPS_CPU_ISA_M64R2);
decode_cpucfg(c);
c->writecombine = _CACHE_UNCACHED_ACCELERATED;
+ c->vulnerabilities |= MIPS_VULNBL_MELTDOWN |
+ MIPS_VULNBL_SPECTRE_V1 | MIPS_VULNBL_SPECTRE_V2;
break;
default:
panic("Unknown Loongson Processor ID!");
--
2.30.0
[PATCH 2/3] MIPS: cpu-probe: Vulnerabilities for MIPS cores
Accorading to MIPS's announcement[1], only P5600 and P6600 is
affected by spectre v1 and v2, other cores are not affected.
So we mark vulnerabilities states for MIPS cores as known and
set P5600 and P6600 as vulnerable.
[1]:
https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/
Signed-off-by: Jiaxun Yang
---
arch/mips/kernel/cpu-probe.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 03adeed58efb..2460783dbdb1 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -1688,6 +1688,9 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips
*c, unsigned int cpu)
static inline void cpu_probe_mips(struct cpuinfo_mips *c, unsigned int cpu)
{
c->writecombine = _CACHE_UNCACHED_ACCELERATED;
+ c->vulnerabilities |= MIPS_VULNBL_MELTDOWN |
+ MIPS_VULNBL_SPECTRE_V1 | MIPS_VULNBL_SPECTRE_V2;
+
switch (c->processor_id & PRID_IMP_MASK) {
case PRID_IMP_QEMU_GENERIC:
c->writecombine = _CACHE_UNCACHED;
@@ -1794,10 +1797,12 @@ static inline void cpu_probe_mips(struct cpuinfo_mips
*c, unsigned int cpu)
case PRID_IMP_P5600:
c->cputype = CPU_P5600;
__cpu_name[cpu] = "MIPS P5600";
+ c->vulnerable |= MIPS_VULNBL_SPECTRE_V1 |
MIPS_VULNBL_SPECTRE_V2;
break;
case PRID_IMP_P6600:
c->cputype = CPU_P6600;
__cpu_name[cpu] = "MIPS P6600";
+ c->vulnerable |= MIPS_VULNBL_SPECTRE_V1 |
MIPS_VULNBL_SPECTRE_V2;
break;
case PRID_IMP_I6400:
c->cputype = CPU_I6400;
--
2.30.0
[PATCH v2] MIPS: zboot: head.S clean up
.cprestore is removed as we don't expect Position Independent zboot ELF. .noreorder is also removed and rest instructions are massaged to improve readability. t9 register is used for indirect jump as MIPS ABI requirement. start label is removed as it already defined in LEAF. Reported-by: Paul Cercueil Signed-off-by: Jiaxun Yang -- v2: Remove start label (paul) --- arch/mips/boot/compressed/head.S | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/arch/mips/boot/compressed/head.S b/arch/mips/boot/compressed/head.S index 409cb483a9ff..977218c90bc8 100644 --- a/arch/mips/boot/compressed/head.S +++ b/arch/mips/boot/compressed/head.S @@ -15,8 +15,6 @@ #include #include - .set noreorder - .cprestore LEAF(start) start: /* Save boot rom start args */ @@ -35,21 +33,20 @@ start: PTR_LA a0, (.heap) /* heap address */ PTR_LA sp, (.stack + 8192) /* stack address */ - PTR_LA ra, 2f - PTR_LA k0, decompress_kernel - jr k0 -nop + PTR_LA t9, decompress_kernel + jalrt9 + 2: movea0, s0 movea1, s1 movea2, s2 movea3, s3 - PTR_LI k0, KERNEL_ENTRY - jr k0 -nop + PTR_LI t9, KERNEL_ENTRY + jalrt9 + 3: b 3b -nop + END(start) .comm .heap,BOOT_HEAP_SIZE,4 -- 2.30.0
Re: [PATCH v4 2/4] spi: ls7a: Add YAML schemas
在 2020/12/25 下午6:35, Qing Zhang 写道:
Switch the DT binding to a YAML schema to enable the DT validation.
Signed-off-by: Qing Zhang
---
v4: fix warnings/errors about running 'make dt_binding_check'
---
.../devicetree/bindings/spi/loongson,spi-ls7a.yaml | 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
diff --git a/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
new file mode 100644
index 000..8cc9bc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/loongson,spi-ls7a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS7A PCH SPI Controller
+
+maintainers:
+ - Qing Zhang
+
+description: |
+ This controller can be found in Loongson-3 systems with LS7A PCH.
+
+properties:
+ compatible:
+const: loongson,ls7a-spi
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - num-chipselects
num-chipselects never parsed in code?
Thanks.
- Jiaxun
+
+additionalProperties: false
+
+examples:
+ - |
+pci {
+#address-cells = <3>;
+#size-cells = <2>;
+
+spi@16,0 {
+compatible = "pci0014,7a0b.0",
+"pci0014,7a0b",
+"pciclass088000",
+"pciclass0800";
+
+reg = <0xb000 0x0 0x0 0x0 0x0>;
+num-chipselects = <0>;
+};
+};
+
+...
Re: [PATCH] MIPS: zboot: head.S clean up
On Mon, Dec 21, 2020, at 10:09 PM, Paul Cercueil wrote: > Hi Jiaxun, > > Le lun. 21 déc. 2020 à 21:00, Jiaxun Yang a > écrit : > > .cprestore is removed as we don't except Position Independent > > zboot ELF. > > > > .noreorder is also removed and rest instructions is massaged > > to improve readability. > > > > t9 register is used to indirect jump as MIPS ABI requirement. > > > > Reported-by: Paul Cercueil > > Signed-off-by: Jiaxun Yang > > --- > > arch/mips/boot/compressed/head.S | 17 +++-- > > 1 file changed, 7 insertions(+), 10 deletions(-) > > > > diff --git a/arch/mips/boot/compressed/head.S > > b/arch/mips/boot/compressed/head.S > > index 409cb483a9ff..977218c90bc8 100644 > > --- a/arch/mips/boot/compressed/head.S > > +++ b/arch/mips/boot/compressed/head.S > > @@ -15,8 +15,6 @@ > > #include > > #include > > > > - .set noreorder > > - .cprestore > > LEAF(start) > > start: > > You can also remove the 'start' label, since it's declared inside the > LEAF() macro as well. GNU's assembler won't mind, but LLVM will choke > on that. Thanks, will do in v2! I was trying to catch you on IRC but failed every time when it comes to my mind :-( > > Cheers, > -Paul > - Jiaxun
[PATCH] MIPS: zboot: head.S clean up
.cprestore is removed as we don't except Position Independent zboot ELF. .noreorder is also removed and rest instructions is massaged to improve readability. t9 register is used to indirect jump as MIPS ABI requirement. Reported-by: Paul Cercueil Signed-off-by: Jiaxun Yang --- arch/mips/boot/compressed/head.S | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/arch/mips/boot/compressed/head.S b/arch/mips/boot/compressed/head.S index 409cb483a9ff..977218c90bc8 100644 --- a/arch/mips/boot/compressed/head.S +++ b/arch/mips/boot/compressed/head.S @@ -15,8 +15,6 @@ #include #include - .set noreorder - .cprestore LEAF(start) start: /* Save boot rom start args */ @@ -35,21 +33,20 @@ start: PTR_LA a0, (.heap) /* heap address */ PTR_LA sp, (.stack + 8192) /* stack address */ - PTR_LA ra, 2f - PTR_LA k0, decompress_kernel - jr k0 -nop + PTR_LA t9, decompress_kernel + jalrt9 + 2: movea0, s0 movea1, s1 movea2, s2 movea3, s3 - PTR_LI k0, KERNEL_ENTRY - jr k0 -nop + PTR_LI t9, KERNEL_ENTRY + jalrt9 + 3: b 3b -nop + END(start) .comm .heap,BOOT_HEAP_SIZE,4 -- 2.29.2
Re: [QUESTION] support perf record --call-graph dwarf for mips
在 2020/12/16 下午6:05, Tiezhu Yang 写道: Hi, In the current upstream mainline kernel, perf record --call-graph dwarf is not supported for architecture mips64. I find the following related patches about this feature by David Daney and Archer Yan in Sep 2019. AFAIK ddaney left Cavium at 2018 and Wave Computing Shanghai is defuncted... Feel free to take over if you like, there is no licenses issue, just remember to credit others properly. - Jiaxun [1/2] Support mips unwinding and dwarf-regs https://lore.kernel.org/patchwork/patch/1126521/ [2/2] Support extracting off-line stack traces from user-space with perf https://lore.kernel.org/patchwork/patch/1126520/ Is this a work in progress? Could you please give me some feedback? Thank you for your help. Thanks, Tiezhu
Re: Re: [PATCH] drivers: rtc: retire RTC_DRV_GOLDFISH
于 2020年12月9日 GMT+08:00 上午6:28:11, Roman Kiryanov 写到: >On Sat, Nov 14, 2020 at 1:48 AM Jiaxun Yang wrote: >> Thus I do think it shouldn't be retired as for now. If nobody comes in >> I'd also willing to maintain > >Hi Jiaxun and Hancai, > >I sent a patch to add you to MAINTAINERS for goldfish-rtc. Could you >please ack there? Hi Roman, My patch modifying Maintainers had been accepted by rtc tree. Thanks. - Jiaxun > >Regards, >Roman.
Re: [PATCH v2 3/4] MIPS: Loongson64: DTS: Add SPI support to LS7A
在 2020/12/8 15:44, Qing Zhang 写道:
add spi and amd node support.
Hi Qing,
Thanks for your patch.
What is AMD node?
Also given that different boards may have different flash, is it a wise
idea to hardcode here?
Thanks.
- Jiaxun
Signed-off-by: Qing Zhang
---
v2:
- Add spi about pci device DT
---
arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
index f99a7a1..ab8836b 100644
--- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
@@ -405,6 +405,26 @@
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 39
IRQ_TYPE_LEVEL_HIGH>;
};
+
+ spi@16,0 {
+ compatible = "pci0014,7a0b.0",
+ "pci0014,7a0b",
+ "pciclass088000",
+ "pciclass0880";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <0xb000 0x0 0x0 0x0 0x0>;
+ num-chipselects = <0>;
+ spiflash: s25fl016k@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible
="spansion,s25fl016k","jedec,spi-nor";
+ spi-max-frequency=<5000>;
+ reg=<0>;
+ };
+ };
};
isa {
Re: [PATCH v2 2/4] spi: Add devicetree bindings documentation for Loongson SPI
在 2020/12/8 15:44, Qing Zhang 写道:
Add spi-ls7a binding documentation.
Signed-off-by: Qing Zhang
---
Documentation/devicetree/bindings/spi/spi-ls7a.txt | 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-ls7a.txt
Hi Qing,
Please use dt schema instead.
Thanks.
- Jiaxun
diff --git a/Documentation/devicetree/bindings/spi/spi-ls7a.txt
b/Documentation/devicetree/bindings/spi/spi-ls7a.txt
new file mode 100644
index 000..56247b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-ls7a.txt
@@ -0,0 +1,31 @@
+Binding for LOONGSON LS7A SPI controller
+
+Required properties:
+- compatible: should be
"pci0014,7a0b.0","pci0014,7a0b","pciclass088000","pciclass0880".
+- reg: reference IEEE Std 1275-1994.
+- #address-cells: <1>, as required by generic SPI binding.
+- #size-cells: <0>, also as required by generic SPI binding.
+- #interrupts: No hardware interrupt.
+
+Child nodes as per the generic SPI binding.
+
+Example:
+
+ spi@16,0 {
+ compatible = "pci0014,7a0b.0",
+ "pci0014,7a0b",
+ "pciclass088000",
+ "pciclass0880";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xb000 0x0 0x0 0x0 0x0>;
+ num-chipselects = <0>;
+ spiflash: s25fl016k@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible
="spansion,s25fl016k","jedec,spi-nor";
+ spi-max-frequency=<5000>;
+ reg=<0>;
+ };
+ };
[PATCH 0/3] MIPS: Add vulnerabilities
Add vulnerabilities display for MIPS. Jiaxun Yang (3): MIPS: Add vulnerabilities infrastructure MIPS: cpu-probe: Vulnerabilities for MIPS cores MIPS: cpu-probe: Vulnerabilities for Loongson cores arch/mips/Kconfig| 1 + arch/mips/include/asm/cpu-info.h | 5 arch/mips/include/asm/cpu.h | 7 + arch/mips/kernel/Makefile| 2 +- arch/mips/kernel/cpu-probe.c | 9 +++ arch/mips/kernel/vulnbl.c| 46 6 files changed, 69 insertions(+), 1 deletion(-) create mode 100644 arch/mips/kernel/vulnbl.c -- 2.29.2
Re: [PATCH] MIPS: Loongson64: Fix up reserving kernel memory range
于 2020年11月25日 GMT+08:00 下午6:11:02, Jinyang He 写到:
>Reserve memory from &_text to &_end. Otherwise if kernel address
>was modified, the memory range of start_pfn to kernel_start_pfn
>would be reserved. Then we could not use this range.
I suspect you meant to make use lower memory after relocation?
Reviewed-by: Jiaxun Yang
Thanks.
- Jiaxun
>
>Signed-off-by: Jinyang He
>---
> arch/mips/loongson64/numa.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
>index 509b360..c6f0c48 100644
>--- a/arch/mips/loongson64/numa.c
>+++ b/arch/mips/loongson64/numa.c
>@@ -151,6 +151,9 @@ static void __init node_mem_init(unsigned int node)
> NODE_DATA(node)->node_spanned_pages = end_pfn - start_pfn;
>
> if (node == 0) {
>+ /* kernel start address */
>+ unsigned long kernel_start_pfn = PFN_DOWN(__pa_symbol(&_text));
>+
> /* kernel end address */
> unsigned long kernel_end_pfn = PFN_UP(__pa_symbol(&_end));
>
>@@ -158,8 +161,8 @@ static void __init node_mem_init(unsigned int node)
> max_low_pfn = end_pfn;
>
> /* Reserve the kernel text/data/bss */
>- memblock_reserve(start_pfn << PAGE_SHIFT,
>- ((kernel_end_pfn - start_pfn) << PAGE_SHIFT));
>+ memblock_reserve(kernel_start_pfn << PAGE_SHIFT,
>+ ((kernel_end_pfn - kernel_start_pfn) <<
>PAGE_SHIFT));
>
> /* Reserve 0xfe00~0x for RS780E integrated GPU */
> if (node_end_pfn(0) >= (0x >> PAGE_SHIFT))
Re: [PATCH 2/2] MIPS: Add fix_range_node after parse "mem=" parameter
于 2020年12月3日 GMT+08:00 下午4:57:47, Jinyang He 写到:
>This problem may only occur on NUMA platforms. When machine start
>with the "mem=" parameter on Loongson64, it cannot boot. When parsing the
>"mem=" parameter, first all the RAM was removed, and then the memory was
>not added by memblock_add_node(), which caused the newly added memory to
>be on MAX_NUMNODES. The key to solve this problem is to fix these memory
>nodes through memblock_set_node() before bootmem_init() or earlier. So
>it would be better to fix it before check_kernel_sections_mem().
>The check_kernel_sections_mem() will check whether the current RAM can be
>used by the kernel. If this fix is added after that, it will do a redundant
>memblock_add operation. Adding the fixup_region_node() function can also
>provide a reference for future platforms using NUMA when encountering
>such problems.
Hi Jingyang,
Is it possible to do it when parsing cmdline to avoid this kind of fixup?
Thanks.
- Jiaxun
>
>Signed-off-by: Jinyang He
>---
> arch/mips/include/asm/bootinfo.h | 1 +
> arch/mips/kernel/setup.c | 6 +-
> arch/mips/loongson64/numa.c | 11 +++
> 3 files changed, 17 insertions(+), 1 deletion(-)
>
>diff --git a/arch/mips/include/asm/bootinfo.h
>b/arch/mips/include/asm/bootinfo.h
>index aa03b12..ddc17b1 100644
>--- a/arch/mips/include/asm/bootinfo.h
>+++ b/arch/mips/include/asm/bootinfo.h
>@@ -91,6 +91,7 @@ const char *get_system_type(void);
> extern unsigned long mips_machtype;
>
> extern void detect_memory_region(phys_addr_t start, phys_addr_t sz_min,
> phys_addr_t sz_max);
>+extern void fixup_region_node(void);
>
> extern void prom_init(void);
> extern void prom_free_prom_memory(void);
>diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>index b3a711e..fe93882 100644
>--- a/arch/mips/kernel/setup.c
>+++ b/arch/mips/kernel/setup.c
>@@ -110,6 +110,8 @@ void __init detect_memory_region(phys_addr_t start,
>phys_addr_t sz_min, phys_add
> memblock_add(start, size);
> }
>
>+void __weak fixup_region_node(void) {}
>+
> /*
> * Manage initrd
> */
>@@ -631,8 +633,10 @@ static void __init arch_mem_init(char **cmdline_p)
>
> parse_early_param();
>
>- if (usermem)
>+ if (usermem) {
> pr_info("User-defined physical RAM map overwrite\n");
>+ fixup_region_node();
>+ }
>
> check_kernel_sections_mem();
>
>diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
>index c6f0c48..d8661cc 100644
>--- a/arch/mips/loongson64/numa.c
>+++ b/arch/mips/loongson64/numa.c
>@@ -220,6 +220,17 @@ void __init mem_init(void)
> mem_init_print_info(NULL);
> }
>
>+void __init fixup_region_node(void)
>+{
>+ phys_addr_t start, end;
>+ u64 i;
>+
>+ for_each_mem_range(i, , ) {
>+ memblock_set_node(start, end - start,
>+, pa_to_nid(start));
>+ }
>+}
>+
> /* All PCI device belongs to logical Node-0 */
> int pcibus_to_node(struct pci_bus *bus)
> {
Re: [PATCH v2 2/2] MIPS: Loongson64: Add KASLR support
在 2020/11/25 下午6:07, Jinyang He 写道:
Provide a weak plat_get_fdt() in relocate.c in case some platform enable
USE_OF while plat_get_fdt() is useless.
1MB RELOCATION_TABLE_SIZE is small for Loongson64 because too many
instructions should be relocated. 2MB is enough in present.
Add KASLR support for Loongson64.
KASLR(kernel address space layout randomization)
To enable KASLR on Loongson64:
First, make loongson3_defconfig.
Then, enable CONFIG_RELOCATABLE and CONFIG_RANDOMIZE_BASE.
Finally, compile the kernel.
To test KASLR on Loongson64:
Start machine with KASLR kernel.
The first time:
# cat /proc/iomem
0020-0eff : System RAM
02f3-03895e9f : Kernel code
03895ea0-03bc7fff : Kernel data
03e3-04f43f7f : Kernel bss
The second time:
# cat /proc/iomem
0020-0eff : System RAM
022f-02c55e9f : Kernel code
02c55ea0-02f87fff : Kernel data
031f-04303f7f : Kernel bss
We see that code, data and bss sections become randomize.
Signed-off-by: Jinyang He
---
v2:
- Define weak plat_get_fdt() in relocate.c
- Add default RELOCATION_TABLE_SIZE for Loongson64
arch/mips/Kconfig | 5 -
arch/mips/kernel/relocate.c | 7 +++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0f638bf..44a47ad 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -488,6 +488,7 @@ config MACH_LOONGSON64
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_ZBOOT
+ select SYS_SUPPORTS_RELOCATABLE
select ZONE_DMA32
select NUMA
select SMP
@@ -2778,7 +2779,8 @@ config RELOCATABLE
depends on CPU_MIPS32_R2 || CPU_MIPS64_R2 || \
CPU_MIPS32_R5 || CPU_MIPS64_R5 || \
CPU_MIPS32_R6 || CPU_MIPS64_R6 || \
- CPU_P5600 || CAVIUM_OCTEON_SOC
+ CPU_P5600 || CAVIUM_OCTEON_SOC || \
+ CPU_LOONGSON64
help
This builds a kernel image that retains relocation information
so it can be loaded someplace besides the default 1MB.
@@ -2789,6 +2791,7 @@ config RELOCATION_TABLE_SIZE
hex "Relocation table size"
depends on RELOCATABLE
range 0x0 0x0100
+ default "0x0020" if CPU_LOONGSON64
default "0x0010"
Not relevant to the patch but how would we now if the reloc table is to
small?
Is it possible to have a kind of checking script?
Thanks.
- Jiaxun
help
A table of relocation data will be appended to the kernel binary
diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
index 8561c7a..57bdd276 100644
--- a/arch/mips/kernel/relocate.c
+++ b/arch/mips/kernel/relocate.c
@@ -294,6 +294,13 @@ static inline int __init relocation_addr_valid(void
*loc_new)
return 1;
}
+#if defined(CONFIG_USE_OF)
+void __weak *plat_get_fdt(void)
+{
+ return NULL;
+}
+#endif
+
void *__init relocate_kernel(void)
{
void *loc_new;
Re: [PATCH] MIPS: KASLR: Fix sync_icache() trapped in loop when synci_step is zero
在 2020/12/2 下午6:39, Thomas Bogendoerfer 写道: On Wed, Dec 02, 2020 at 11:00:05AM +0800, Jinyang He wrote: Reading synci_step by using rdhwr instruction may return zero if no cache need be synchronized. On the one hand, to make sure all load operation and store operation finished we do __sync() for every platform. On the other hand, some platform need operate synci one time although step is zero. Should this be someting like: Avoid endless loop, if no synci is needed ? diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c index 57bdd276..47aeb33 100644 --- a/arch/mips/kernel/relocate.c +++ b/arch/mips/kernel/relocate.c @@ -64,7 +64,7 @@ static void __init sync_icache(void *kbase, unsigned long kernel_length) : "r" (kbase)); kbase += step; - } while (kbase < kend); + } while (step && kbase < kend); why not do a if (step == 0) return; before entering the loop ? According to MIPS32PRA no synci is needed, if stepi value is zero. Thomas. PS: Does anybody know a reason, why this code doesn't use an old fashioned dache/icache flushing, which might be slower but would work also on legecy cores ? I thought that's because legacy flush requires much more cares. You'll have to probe cache ways sets and line size to do so. However relocation happens very early, even before cache probe. Thanks. - Jiaxun
Re: [PATCH 2/2] MIPS: Select ARCH_KEEP_MEMBLOCK to enable sysfs memblock debug
在 2020/12/3 上午11:19, Tiezhu Yang 写道: In the current code, CONFIG_ARCH_KEEP_MEMBLOCK is not set for MIPS arch, memblock_discard() will discard memory and reserved arrays if they were allocated, select ARCH_KEEP_MEMBLOCK to give a chance to track "memory" and "reserved" memblocks after early boot, with this patch, we can see the following two sysfs interfaces under DEBUG_FS. /sys/kernel/debug/memblock/memory /sys/kernel/debug/memblock/reserved Is this really necessary? memblock data is not really necessary after boot for non-debug purpose. Given that MIPS is widely used in embedded systems which doesn't have much memory, keeping unused data after boot is kinda unconvincing. If you intend to debug that please do it locally. Thanks. - Jiaxun Signed-off-by: Tiezhu Yang --- arch/mips/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 44a47ad..f65da197 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -9,6 +9,7 @@ config MIPS select ARCH_HAS_PTE_SPECIAL if !(32BIT && CPU_HAS_RIXI) select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_KEEP_MEMBLOCK select ARCH_SUPPORTS_UPROBES select ARCH_USE_BUILTIN_BSWAP select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
Re: [PATCH 2/3] MIPS: Loongson64: DTS: Add SPI support to LS3A
在 2020/11/23 17:19, Qing Zhang 写道:
The LS3A SPI module is now supported, enable it.
Signed-off-by: Qing Zhang
---
arch/mips/boot/dts/loongson/loongson64c-package.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/mips/boot/dts/loongson/loongson64c-package.dtsi
b/arch/mips/boot/dts/loongson/loongson64c-package.dtsi
index 5bb876a..2025c5a 100644
--- a/arch/mips/boot/dts/loongson/loongson64c-package.dtsi
+++ b/arch/mips/boot/dts/loongson/loongson64c-package.dtsi
@@ -60,5 +60,12 @@
interrupt-parent = <>;
no-loopback-test;
};
+
+spi: spi@1fe00220 {
+compatible = "loongson,loongson-spi";
You have to add dt schema document..
Also I'd sugguest you to name it as loongson,pci-spi to avoid collision.
Loongson-1 MCUs do have MMIO SPI controller with similiar register layout.
Thanks
- Jiaxun
+reg=<0 0x1fe00220 0x11>;
+#address-cells = <1>;
+#size-cells = <0>;
+ };
};
};
Re: [PATCH] stmmac: pci: Add support for LS7A bridge chip
Hi Lizhi,
You didn't send the patch to any mail list, is this intentional?
在 2020/11/23 18:03, lizhi01 写道:
Add gmac driver to support LS7A bridge chip.
Signed-off-by: lizhi01
---
arch/mips/configs/loongson3_defconfig | 4 +-
drivers/net/ethernet/stmicro/stmmac/Kconfig| 8 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
.../net/ethernet/stmicro/stmmac/dwmac-loongson.c | 194 +
4 files changed, 206 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
diff --git a/arch/mips/configs/loongson3_defconfig
b/arch/mips/configs/loongson3_defconfig
index 38a817e..2e8d2be 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -225,7 +225,9 @@ CONFIG_R8169=y
# CONFIG_NET_VENDOR_SILAN is not set
# CONFIG_NET_VENDOR_SIS is not set
# CONFIG_NET_VENDOR_SMSC is not set
-# CONFIG_NET_VENDOR_STMICRO is not set
+CONFIG_NET_VENDOR_STMICR=y
+CONFIG_STMMAC_ETH=y
+CONFIG_DWMAC_LOONGSON=y
# CONFIG_NET_VENDOR_SUN is not set
# CONFIG_NET_VENDOR_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 53f14c5..30117cb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -230,6 +230,14 @@ config DWMAC_INTEL
This selects the Intel platform specific bus support for the
stmmac driver. This driver is used for Intel Quark/EHL/TGL.
+config DWMAC_LOONGSON
+ tristate "Intel GMAC support"
+ depends on STMMAC_ETH && PCI
+ depends on COMMON_CLK
+ help
+ This selects the Intel platform specific bus support for the
+ stmmac driver.
Intel ???
+
config STMMAC_PCI
tristate "STMMAC PCI bus support"
depends on STMMAC_ETH && PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 24e6145..11ea4569 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -34,4 +34,5 @@ dwmac-altr-socfpga-objs := altr_tse_pcs.o dwmac-socfpga.o
obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
obj-$(CONFIG_DWMAC_INTEL) += dwmac-intel.o
+obj-$(CONFIG_DWMAC_LOONGSON) += dwmac-loongson.o
stmmac-pci-objs:= stmmac_pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
new file mode 100644
index 000..765412e
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2020, Loongson Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "stmmac.h"
+
+struct stmmac_pci_info {
+ int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
+};
+
+static void common_default_data(struct plat_stmmacenet_data *plat)
+{
+ plat->clk_csr = 2;
+ plat->has_gmac = 1;
+ plat->force_sf_dma_mode = 1;
+
+ plat->mdio_bus_data->needs_reset = true;
+
+ plat->multicast_filter_bins = HASH_TABLE_SIZE;
+
+ plat->unicast_filter_entries = 1;
+
+ plat->maxmtu = JUMBO_LEN;
+
+ plat->tx_queues_to_use = 1;
+ plat->rx_queues_to_use = 1;
+
+ plat->tx_queues_cfg[0].use_prio = false;
+ plat->rx_queues_cfg[0].use_prio = false;
+
+ plat->rx_queues_cfg[0].pkt_route = 0x0;
+}
+
+static int loongson_default_data(struct pci_dev *pdev, struct
plat_stmmacenet_data *plat)
+{
+ common_default_data(plat);
+
+ plat->bus_id = pci_dev_id(pdev);
+ plat->phy_addr = -1;
+ plat->interface = PHY_INTERFACE_MODE_GMII;
+
+ plat->dma_cfg->pbl = 32;
+ plat->dma_cfg->pblx8 = true;
+
+ plat->multicast_filter_bins = 256;
+
+ return 0;
+}
You can merge common and Loongson config as the driver is solely used by
Loongson.
The callback is not necessary as well...
+
+static const struct stmmac_pci_info loongson_pci_info = {
+ .setup = loongson_default_data,
+};
+
+static int loongson_gmac_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
+{
+ struct stmmac_pci_info *info = (struct stmmac_pci_info
*)id->driver_data;
+ struct plat_stmmacenet_data *plat;
+ struct stmmac_resources res;
+ int ret, i, lpi_irq;
+ struct device_node *np;
+
+ plat = devm_kzalloc(>dev, sizeof(struct plat_stmmacenet_data),
GFP_KERNEL);
+ if (!plat)
+ return -ENOMEM;
+
+ plat->mdio_bus_data = devm_kzalloc(>dev, sizeof(struct
stmmac_mdio_bus_data), GFP_KERNEL);
+ if (!plat->mdio_bus_data) {
+ kfree(plat);
+ return -ENOMEM;
+ }
+
+ plat->dma_cfg = devm_kzalloc(>dev, sizeof(struct stmmac_dma_cfg),
GFP_KERNEL);
+ if (!plat->dma_cfg) {
+
[PATCH 0/2] Preserve goldfish rtc
Link: https://lore.kernel.org/lkml/x6+wgmuccpu2l...@kroah.com/ Cc: che...@lemote.com Cc: gre...@linuxfoundation.org Jiaxun Yang (2): rtc: goldfish: Remove GOLDFISH dependency MAINTAINERS: Set myself as Goldfish RTC maintainer MAINTAINERS | 2 +- drivers/rtc/Kconfig | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) -- 2.29.2
[PATCH 1/2] rtc: goldfish: Remove GOLDFISH dependency
Goldfish platform is covered with dust. However the goldfish-rtc had been used as virtualized RTC in QEMU for RISC-V virt hw and MIPS loongson3-virt hw, thus we can drop other parts of goldfish but leave goldfish-rtc here. Signed-off-by: Jiaxun Yang --- drivers/rtc/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 65ad9d0b47ab..f784b52381b1 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -1935,7 +1935,6 @@ config RTC_DRV_HID_SENSOR_TIME config RTC_DRV_GOLDFISH tristate "Goldfish Real Time Clock" depends on OF && HAS_IOMEM - depends on GOLDFISH || COMPILE_TEST help Say yes to enable RTC driver for the Goldfish based virtual platform. -- 2.29.2
[PATCH 2/2] MAINTAINERS: Set myself as Goldfish RTC maintainer
While Gildfish platform is dusted, the RTC driver remains valuable for us. I'm volunteering to maintain goldfish RTC driver onward. Signed-off-by: Jiaxun Yang Cc: Miodrag Dinic --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e73636b75f29..b576544264e6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1168,7 +1168,7 @@ F: Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.tx F: drivers/irqchip/irq-goldfish-pic.c ANDROID GOLDFISH RTC DRIVER -M: Miodrag Dinic +M: Jiaxun Yang S: Supported F: Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt F: drivers/rtc/rtc-goldfish.c -- 2.29.2
Re: Re: [PATCH] drivers: rtc: retire RTC_DRV_GOLDFISH
在 2020/11/14 下午4:15, Greg KH 写道: + qemu-riscv list and QEMU device maintainers of goldfish_rtc On Sat, Nov 14, 2020 at 04:06:24PM +0800, 陈华才 wrote: Hi, All, Goldfish RTC works well on MIPS, and QEMU RISC-V emulator use Goldfish as well, so I think we should keep it in kernel. But does anyone actually use it for anything? Having something in qemu is nice, but not required if it doesn't provide something that is already there for other virtual devices, right? Hi all, Both QEMU MIPS loongson3-virt and riscv virt machine are using goldfish_rtc as sole RTC device, it have been hardcoded in QEMU for a long while and sudden drop in kernel would break these machines. RTC is essential for virt machines to keep time synchronized with host. Given that it is the simplest RTC implementation for now, it won't give us much maintenance overhead. Thus I do think it shouldn't be retired as for now. If nobody comes in I'd also willing to maintain it. Thanks - Jiaxun thanks, greg k-h
Re: [PATCH] MIPS: Loongson64: Add read_persistent_clock64()
于 2020年11月13日 GMT+08:00 上午11:41:01, Tiezhu Yang 写到: >On 11/13/2020 10:21 AM, Jiaxun Yang wrote: >> >> >> 在 2020/11/12 20:03, Tiezhu Yang 写道: >>> On 11/12/2020 06:09 PM, Jiaxun Yang wrote: >>>> >>>> >>>> 在 2020/11/12 18:04, Jiaxun Yang 写道: >>>>> Hi Tiezhu, >>>>> >>>>> 在 2020/11/12 16:29, Tiezhu Yang 写道: >>>>>> Add read_persistent_clock64() to read the time from the battery >>>>>> backed >>>>>> persistent clock. With this patch, we can fix the wrong time issue >>>>>> due >>>>>> to the system clock is not consistent with hardware clock after >>>>>> resume >>>>>> from sleep state S3 (suspend to RAM), at the same time, the system >>>>>> time >>>>>> can be right instead of "Thu Jan 1 08:00:00 CST 1970" without rtc >>>>>> driver. >>>>>> >>>>>> start_kernel() >>>>>>timekeeping_init() >>>>>> read_persistent_wall_and_boot_offset() >>>>>>read_persistent_clock64() >>>>>> >>>>>> timekeeping_resume() >>>>>>read_persistent_clock64() >>>>>> >>>>>> timekeeping_suspend() >>>>>>read_persistent_clock64() >>>>> >>>>> It is highly discoraged to do anything with bridgetype, which isn't >>>>> probed via >>>>> devicetree. >>>>> >>>>> Please check if you can deal with that inside RTC framework, or >>>>> make it as >>>>> a part of RTC driver (e.g. set up a callback). >>>>> >>>>> Also you should submit RTC driver at first if you intend to >>>>> complete LS7A support. >>>> >>>> Oops, >>>> Just dig it deeper, I guess simply select RTC_HCTOSYS would solve >>>> the issue. >>>> We're trying very hard to decouple all the drivers and conponents, >>>> DeviceTree for all! >>> >>> +cc WANG Xuerui >>> >>> Hi Jiaxun, >>> >>> Thanks for your reply. >>> >>> Xuerui has already submitted the patch of LS7A rtc driver [1], >>> but not yet been merged into the mainline kernel, I discussed >>> with him early today. >>> >>> Do you mean that read_persistent_clock64() can call the function >>> like rtc_read_time() defined in rtc driver? >> >> I do think select RTC_HCTOSYS after getting RTC driver applied can help. > >Yes, I agree. > >> What's your point to have read_persistent_clock64 for Loongson64? > >(1) Currently, the LS7A RTC driver has not been merged into the >mainline kernel, read_persistent_clock64() is useful in the following >call path: > >start_kernel() >timekeeping_init() > read_persistent_wall_and_boot_offset() >read_persistent_clock64() > >(2) When the LS7A RTC driver is merged into the mainline kernel >some time later, if RTC_HCTOSYS and RTC_DRV_LS2X are not set, >read_persistent_clock64() is also useful unless RTC_HCTOSYS >and RTC_DRV_LS2X are set by default in Kconfig instead of >loongson3_defconfig. > >So I think read_persistent_clock64() looks like a backup function. Still can't understand why this kind of backup is necessary. If you wish to help please help with the RTC driver. Duplication is not the way we work. Please try to learn common solutions, all others are doing so. Thanks - Jiaxun > >> >> Thanks >> >> - Jiaxun >> >>> >>> Thanks, >>> Tiezhu >>> >>> [1] >>> https://patchwork.kernel.org/project/linux-mips/patch/20200923075845.360974-2-...@xen0n.name/ >>> >>>> >>>>> >>>>> Thanks. >>>>> >>>>> - Jiaxun >>>>> >>>>>> >>>>>> Signed-off-by: Yinglu Yang >>>>>> Signed-off-by: Tiezhu Yang >>>>>> --- >>>>>>
Re: [PATCH] MIPS: reserve the memblock right after the kernel
Hi all, 在 2020/11/11 22:52, Serge Semin 写道: Hello Alexander On Tue, Nov 10, 2020 at 11:29:50AM +0100, Alexander Sverdlin wrote: 2) The check_kernel_sections_mem() method can be removed. But it should be done carefully. We at least need to try to find all the platforms, which rely on its functionality. It have been more than 10 years since introducing this this check, but I believe there must be a reason at the time. Also currently we have some unmaintained platform and it's impossible to test on them for us. For Cavium's issue, I believe removing the page rounding can help. I'd suggest keep this method but remove the rounding part, also leave a warning or kernel taint when out of boundary kernel image is detected. Thanks. - Jiaxun -Sergey -- Best regards, Alexander Sverdlin.
Re: [PATCH] MIPS: Loongson64: Add read_persistent_clock64()
在 2020/11/12 20:03, Tiezhu Yang 写道: On 11/12/2020 06:09 PM, Jiaxun Yang wrote: 在 2020/11/12 18:04, Jiaxun Yang 写道: Hi Tiezhu, 在 2020/11/12 16:29, Tiezhu Yang 写道: Add read_persistent_clock64() to read the time from the battery backed persistent clock. With this patch, we can fix the wrong time issue due to the system clock is not consistent with hardware clock after resume from sleep state S3 (suspend to RAM), at the same time, the system time can be right instead of "Thu Jan 1 08:00:00 CST 1970" without rtc driver. start_kernel() timekeeping_init() read_persistent_wall_and_boot_offset() read_persistent_clock64() timekeeping_resume() read_persistent_clock64() timekeeping_suspend() read_persistent_clock64() It is highly discoraged to do anything with bridgetype, which isn't probed via devicetree. Please check if you can deal with that inside RTC framework, or make it as a part of RTC driver (e.g. set up a callback). Also you should submit RTC driver at first if you intend to complete LS7A support. Oops, Just dig it deeper, I guess simply select RTC_HCTOSYS would solve the issue. We're trying very hard to decouple all the drivers and conponents, DeviceTree for all! +cc WANG Xuerui Hi Jiaxun, Thanks for your reply. Xuerui has already submitted the patch of LS7A rtc driver [1], but not yet been merged into the mainline kernel, I discussed with him early today. Do you mean that read_persistent_clock64() can call the function like rtc_read_time() defined in rtc driver? I do think select RTC_HCTOSYS after getting RTC driver applied can help. What's your point to have read_persistent_clock64 for Loongson64? Thanks - Jiaxun Thanks, Tiezhu [1] https://patchwork.kernel.org/project/linux-mips/patch/20200923075845.360974-2-...@xen0n.name/ Thanks. - Jiaxun Signed-off-by: Yinglu Yang Signed-off-by: Tiezhu Yang ---
Re: [PATCH] MIPS: Loongson64: Add read_persistent_clock64()
在 2020/11/12 18:04, Jiaxun Yang 写道: Hi Tiezhu, 在 2020/11/12 16:29, Tiezhu Yang 写道: Add read_persistent_clock64() to read the time from the battery backed persistent clock. With this patch, we can fix the wrong time issue due to the system clock is not consistent with hardware clock after resume from sleep state S3 (suspend to RAM), at the same time, the system time can be right instead of "Thu Jan 1 08:00:00 CST 1970" without rtc driver. start_kernel() timekeeping_init() read_persistent_wall_and_boot_offset() read_persistent_clock64() timekeeping_resume() read_persistent_clock64() timekeeping_suspend() read_persistent_clock64() It is highly discoraged to do anything with bridgetype, which isn't probed via devicetree. Please check if you can deal with that inside RTC framework, or make it as a part of RTC driver (e.g. set up a callback). Also you should submit RTC driver at first if you intend to complete LS7A support. Oops, Just dig it deeper, I guess simply select RTC_HCTOSYS would solve the issue. We're trying very hard to decouple all the drivers and conponents, DeviceTree for all! Thanks. - Jiaxun Signed-off-by: Yinglu Yang Signed-off-by: Tiezhu Yang ---
Re: [PATCH] MIPS: Loongson64: Add read_persistent_clock64()
Hi Tiezhu,
在 2020/11/12 16:29, Tiezhu Yang 写道:
Add read_persistent_clock64() to read the time from the battery backed
persistent clock. With this patch, we can fix the wrong time issue due
to the system clock is not consistent with hardware clock after resume
from sleep state S3 (suspend to RAM), at the same time, the system time
can be right instead of "Thu Jan 1 08:00:00 CST 1970" without rtc driver.
start_kernel()
timekeeping_init()
read_persistent_wall_and_boot_offset()
read_persistent_clock64()
timekeeping_resume()
read_persistent_clock64()
timekeeping_suspend()
read_persistent_clock64()
It is highly discoraged to do anything with bridgetype, which isn't
probed via
devicetree.
Please check if you can deal with that inside RTC framework, or make it as
a part of RTC driver (e.g. set up a callback).
Also you should submit RTC driver at first if you intend to complete
LS7A support.
Thanks.
- Jiaxun
Signed-off-by: Yinglu Yang
Signed-off-by: Tiezhu Yang
---
arch/mips/include/asm/mach-loongson64/loongson.h | 20 +
arch/mips/loongson64/time.c | 28 +++-
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/mach-loongson64/loongson.h
b/arch/mips/include/asm/mach-loongson64/loongson.h
index fde1b75..448289e 100644
--- a/arch/mips/include/asm/mach-loongson64/loongson.h
+++ b/arch/mips/include/asm/mach-loongson64/loongson.h
@@ -238,4 +238,24 @@ extern u64 loongson_freqctrl[MAX_PACKAGES];
#define LOONGSON_PCIMAP_WIN(WIN, ADDR)\
ADDR)>>26) & LOONGSON_PCIMAP_PCIMAP_LO0) << ((WIN)*6))
+/* LS7A RTC */
+#define LS7A_MISC_REG_BASE 0x1008
+#define LS7A_RTC_ADDR_OFFSET 0x50100
+#define LS7A_RTC_SYS_TOYREAD0_OFFSET 0x2c
+#define LS7A_RTC_SYS_TOYREAD1_OFFSET 0x30
+#define LS7A_RTC_REG_BASE (LS7A_MISC_REG_BASE +
LS7A_RTC_ADDR_OFFSET)
+#define LS7A_RTC_SYS_TOYREAD0_ADDR (LS7A_RTC_REG_BASE +
LS7A_RTC_SYS_TOYREAD0_OFFSET)
+#define LS7A_RTC_SYS_TOYREAD1_ADDR (LS7A_RTC_REG_BASE +
LS7A_RTC_SYS_TOYREAD1_OFFSET)
+#define LS7A_RTC_TOY_MON_MASK GENMASK(31, 26)
+#define LS7A_RTC_TOY_MON_SHIFT 26
+#define LS7A_RTC_TOY_DAY_MASK GENMASK(25, 21)
+#define LS7A_RTC_TOY_DAY_SHIFT 21
+#define LS7A_RTC_TOY_HOUR_MASK GENMASK(20, 16)
+#define LS7A_RTC_TOY_HOUR_SHIFT16
+#define LS7A_RTC_TOY_MIN_MASK GENMASK(15, 10)
+#define LS7A_RTC_TOY_MIN_SHIFT 10
+#define LS7A_RTC_TOY_SEC_MASK GENMASK(9, 4)
+#define LS7A_RTC_TOY_SEC_SHIFT 4
+#define LS7A_RTC_YEAR_BASE 1900
+
#endif /* __ASM_MACH_LOONGSON64_LOONGSON_H */
diff --git a/arch/mips/loongson64/time.c b/arch/mips/loongson64/time.c
index 91e842b..7f3095546 100644
--- a/arch/mips/loongson64/time.c
+++ b/arch/mips/loongson64/time.c
@@ -9,7 +9,7 @@
#include
#include
-
+#include
#include
void __init plat_time_init(void)
@@ -21,3 +21,29 @@ void __init plat_time_init(void)
setup_hpet_timer();
#endif
}
+
+static time64_t ls7a_get_rtc_time(void)
+{
+ unsigned int year, mon, day, hour, min, sec;
+ unsigned int value;
+
+ value = readl((void __iomem *)TO_UNCAC(LS7A_RTC_SYS_TOYREAD0_ADDR));
+ sec = (value & LS7A_RTC_TOY_SEC_MASK) >> LS7A_RTC_TOY_SEC_SHIFT;
+ min = (value & LS7A_RTC_TOY_MIN_MASK) >> LS7A_RTC_TOY_MIN_SHIFT;
+ hour = (value & LS7A_RTC_TOY_HOUR_MASK) >> LS7A_RTC_TOY_HOUR_SHIFT;
+ day = (value & LS7A_RTC_TOY_DAY_MASK) >> LS7A_RTC_TOY_DAY_SHIFT;
+ mon = (value & LS7A_RTC_TOY_MON_MASK) >> LS7A_RTC_TOY_MON_SHIFT;
+ year = readl((void __iomem *)TO_UNCAC(LS7A_RTC_SYS_TOYREAD1_ADDR));
+
+ return mktime64(year + LS7A_RTC_YEAR_BASE, mon, day, hour, min, sec);
+}
+
+void read_persistent_clock64(struct timespec64 *ts)
+{
+ if (loongson_sysconf.bridgetype == LS7A)
+ ts->tv_sec = ls7a_get_rtc_time();
+ else
+ ts->tv_sec = mc146818_get_cmos_time();
+
+ ts->tv_nsec = 0;
+}
Re: [PATCH v3 5/6] MIPS: Loongson64: SMP: Fix up play_dead jump indicator
在 2020/11/4 14:31, Jinyang He 写道: Hi, all, On 11/03/2020 03:12 PM, Tiezhu Yang wrote: In play_dead function, the whole 64-bit PC mailbox was used as a indicator to determine if the master core had written boot jump information. However, after we introduced CSR mailsend, the hardware will not guarante an atomic write for the 64-bit PC mailbox. Thus we have to use the lower 32-bit which is written at the last as the jump indicator instead. Signed-off-by: Lu Zeng Signed-off-by: Jun Yi Signed-off-by: Tiezhu Yang --- v2: No changes v3: Update the commit message and comment arch/mips/loongson64/smp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c index 736e98d..aa0cd72 100644 --- a/arch/mips/loongson64/smp.c +++ b/arch/mips/loongson64/smp.c @@ -764,9 +764,10 @@ static void loongson3_type3_play_dead(int *state_addr) "1: li %[count], 0x100 \n" /* wait for init loop */ "2: bnez %[count], 2b \n" /* limit mailbox access */ " addiu %[count], -1 \n" - " ld %[initfunc], 0x20(%[base]) \n" /* get PC via mailbox */ I have some confusion here. Play_dead CPUs is always brought up by cpu_up(). On Loongson64, it calls loongson3_boot_secondary(). The value of startargs[0] is the address of smp_bootstrap() which is in CKSEG0 and a constant after the kernel is compiled. That means its value likes 0x8... and only the low 32bit is useful. As "lw" is sign-extended, could we replace "ld" with "lw" simply? Hi Jinyang, I'd prefer not to do so. In future we may have kernel running in other spaces, (e.g. xkphys), and there is no reason to add a barrier on that without actual benefit. I had check PMON firmware and it's also loading the full 64-bit address. Also to keep consistent, mailbox writing part needs to be refined to match the behavior of reading. Otherwise other readers will be confused. Thus leaving it as is looks much more reasonable. Thanks. - Jiaxun Thanks, Jinyang + " lw %[initfunc], 0x20(%[base]) \n" /* check lower 32-bit as jump indicator */ " beqz %[initfunc], 1b \n" " nop \n" + " ld %[initfunc], 0x20(%[base]) \n" /* get PC (whole 64-bit) via mailbox */ " ld $sp, 0x28(%[base]) \n" /* get SP via mailbox */ " ld $gp, 0x30(%[base]) \n" /* get GP via mailbox */ " ld $a1, 0x38(%[base]) \n"
Re: [PATCH RESEND 1/2] MIPS: cacheinfo: Add missing VCache
在 2020/8/22 0:55, Thomas Bogendoerfer 写道:
On Thu, Aug 20, 2020 at 08:42:49AM +0800, Jiaxun Yang wrote:
Victim Cache is defined by Loongson as per-core unified
private Cache.
Add this into cacheinfo and make cache levels selfincrement
instead of hardcode levels.
Signed-off-by: Jiaxun Yang
---
arch/mips/kernel/cacheinfo.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/arch/mips/kernel/cacheinfo.c b/arch/mips/kernel/cacheinfo.c
index 47312c529410..83548331ee94 100644
--- a/arch/mips/kernel/cacheinfo.c
+++ b/arch/mips/kernel/cacheinfo.c
@@ -35,6 +35,11 @@ static int __init_cache_level(unsigned int cpu)
leaves += (c->icache.waysize) ? 2 : 1;
+ if (c->vcache.waysize) {
+ levels++;
+ leaves++;
+ }
+
if (c->scache.waysize) {
levels++;
leaves++;
@@ -74,25 +79,38 @@ static int __populate_cache_leaves(unsigned int cpu)
struct cpuinfo_mips *c = _cpu_data;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
struct cacheinfo *this_leaf = this_cpu_ci->info_list;
+ int level = 1;
if (c->icache.waysize) {
- /* L1 caches are per core */
+ /* D/I caches are per core */
fill_cpumask_siblings(cpu, _leaf->shared_cpu_map);
- populate_cache(dcache, this_leaf, 1, CACHE_TYPE_DATA);
+ populate_cache(dcache, this_leaf, level, CACHE_TYPE_DATA);
fill_cpumask_siblings(cpu, _leaf->shared_cpu_map);
- populate_cache(icache, this_leaf, 1, CACHE_TYPE_INST);
+ populate_cache(icache, this_leaf, level, CACHE_TYPE_INST);
+ level++;
} else {
- populate_cache(dcache, this_leaf, 1, CACHE_TYPE_UNIFIED);
+ populate_cache(dcache, this_leaf, level, CACHE_TYPE_UNIFIED);
+ level++;
+ }
+
+ if (c->vcache.waysize) {
why can't we insert vcache as level 4 and leave the rest of the file
alone ?
Hi Thomas,
Oops I forgot this patch.
Because VCache is physicaly placed between Scache and I/D Cache as per
core chahe, it will confuse userspace program otherwise.
Also I do think the level should be continues.
Thanks
- Jiaxun
Thomas.
Re: [PATCH v2 6/6] MIPS: Loongson64: Move decode_cpucfg() to loongson_regs.h
在 2020/11/3 11:15, Tiezhu Yang 写道:
Since decode_cpucfg() is only used for Loongson64, just move
it to loongson_regs.h to avoid the pollution of common code
with #ifdef CONFIG_CPU_LOONGSON64.
Signed-off-by: Tiezhu Yang
Hi all,
Don't know if it's a good idea to move this piece of code around...
Also I do think loongson_regs.h should be a common header while
cpucfg_decode won't be reused else where.
But I do respect Thomas's decision if it's necessary.
Thanks
- Jiaxun
---
v2: No changes
.../include/asm/mach-loongson64/loongson_regs.h| 24 +
arch/mips/kernel/cpu-probe.c | 31 +-
2 files changed, 25 insertions(+), 30 deletions(-)
diff --git a/arch/mips/include/asm/mach-loongson64/loongson_regs.h
b/arch/mips/include/asm/mach-loongson64/loongson_regs.h
index 1659935..2d469d6 100644
--- a/arch/mips/include/asm/mach-loongson64/loongson_regs.h
+++ b/arch/mips/include/asm/mach-loongson64/loongson_regs.h
@@ -129,6 +129,30 @@ static inline u32 read_cpucfg(u32 reg)
#define LOONGSON_CFG7_GCCAEQRPBIT(0)
#define LOONGSON_CFG7_UCAWINP BIT(1)
+static inline void decode_cpucfg(struct cpuinfo_mips *c)
+{
+ u32 cfg1 = read_cpucfg(LOONGSON_CFG1);
+ u32 cfg2 = read_cpucfg(LOONGSON_CFG2);
+ u32 cfg3 = read_cpucfg(LOONGSON_CFG3);
+
+ if (cfg1 & LOONGSON_CFG1_MMI)
+ c->ases |= MIPS_ASE_LOONGSON_MMI;
+
+ if (cfg2 & LOONGSON_CFG2_LEXT1)
+ c->ases |= MIPS_ASE_LOONGSON_EXT;
+
+ if (cfg2 & LOONGSON_CFG2_LEXT2)
+ c->ases |= MIPS_ASE_LOONGSON_EXT2;
+
+ if (cfg2 & LOONGSON_CFG2_LSPW) {
+ c->options |= MIPS_CPU_LDPTE;
+ c->guest.options |= MIPS_CPU_LDPTE;
+ }
+
+ if (cfg3 & LOONGSON_CFG3_LCAMP)
+ c->ases |= MIPS_ASE_LOONGSON_CAM;
+}
+
static inline bool cpu_has_csr(void)
{
if (cpu_has_cfg())
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index e685369..1fa2c8b 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -31,6 +31,7 @@
#include "fpu-probe.h"
#include
+#include
/* Hardware capabilities */
unsigned int elf_hwcap __read_mostly;
@@ -1692,33 +1693,6 @@ static inline void cpu_probe_cavium(struct cpuinfo_mips
*c, unsigned int cpu)
}
}
-#ifdef CONFIG_CPU_LOONGSON64
-#include
-
-static inline void decode_cpucfg(struct cpuinfo_mips *c)
-{
- u32 cfg1 = read_cpucfg(LOONGSON_CFG1);
- u32 cfg2 = read_cpucfg(LOONGSON_CFG2);
- u32 cfg3 = read_cpucfg(LOONGSON_CFG3);
-
- if (cfg1 & LOONGSON_CFG1_MMI)
- c->ases |= MIPS_ASE_LOONGSON_MMI;
-
- if (cfg2 & LOONGSON_CFG2_LEXT1)
- c->ases |= MIPS_ASE_LOONGSON_EXT;
-
- if (cfg2 & LOONGSON_CFG2_LEXT2)
- c->ases |= MIPS_ASE_LOONGSON_EXT2;
-
- if (cfg2 & LOONGSON_CFG2_LSPW) {
- c->options |= MIPS_CPU_LDPTE;
- c->guest.options |= MIPS_CPU_LDPTE;
- }
-
- if (cfg3 & LOONGSON_CFG3_LCAMP)
- c->ases |= MIPS_ASE_LOONGSON_CAM;
-}
-
static inline void cpu_probe_loongson(struct cpuinfo_mips *c, unsigned int
cpu)
{
decode_configs(c);
@@ -1787,9 +1761,6 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips
*c, unsigned int cpu)
break;
}
}
-#else
-static inline void cpu_probe_loongson(struct cpuinfo_mips *c, unsigned int
cpu) { }
-#endif
static inline void cpu_probe_ingenic(struct cpuinfo_mips *c, unsigned int cpu)
{
Re: [PATCH v2 5/6] MIPS: Loongson64: Make sure the PC address is correct when 3A4000+ CPU hotplug
在 2020/11/3 11:15, Tiezhu Yang 写道: In loongson3_type3_play_dead(), in order to make sure the PC address is correct, use lw to read the low 32 bits first, if the result is not zero, then use ld to read the whole 64 bits, otherwise there maybe exists atomic problem due to write high 32 bits first and then low 32 bits, like this: high 32 bits (write done) -- only read high 32-bits which is wrong low 32 bits (not yet write done) This problem is especially for Loongson 3A4000+ CPU due to using Mail_Send register which can only send 32 bits data one time. Although it is hard to reproduce, we can do something at the software level to avoid the risks for 3A4000+ CPU, this change has no influence on the other Loongson CPUs. Signed-off-by: Lu Zeng Signed-off-by: Jun Yi Signed-off-by: Tiezhu Yang Hi Tiezhu, Sorry that I didn't look this patch carefully in previous rev, here's my comments, Firstly the commit message and code comment looks bogus... I'd prefer --- MIPS: Loongson64: SMP: Fix up play_dead jump indicator In play_dead function, the whole 64-bit PC mailbox was used as a indicator to determine if the master core had written boot jump information. However, after we introduced CSR mailsend, the 64-bit PC mailbox won't be written atomicly. Thus we have to use the lower 32-bit, which will be written at the last, as the jump indicator instead. -- Thanks. --- v2: No changes arch/mips/loongson64/smp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c index 736e98d..e32b46e 100644 --- a/arch/mips/loongson64/smp.c +++ b/arch/mips/loongson64/smp.c @@ -764,9 +764,10 @@ static void loongson3_type3_play_dead(int *state_addr) "1: li%[count], 0x100 \n" /* wait for init loop */ "2: bnez %[count], 2b\n" /* limit mailbox access */ " addiu %[count], -1\n" - " ld%[initfunc], 0x20(%[base]) \n" /* get PC via mailbox */ + " lw%[initfunc], 0x20(%[base]) \n" /* get PC (low 32 bits) via mailbox */ Here you can comment as "Check jump indicator (lower 32-bit of PC mailbox)" Thanks. - Jiaxun " beqz %[initfunc], 1b \n" " nop \n" + " ld%[initfunc], 0x20(%[base]) \n" /* get PC (whole 64 bits) via mailbox */ " ld$sp, 0x28(%[base]) \n" /* get SP via mailbox */ " ld$gp, 0x30(%[base]) \n" /* get GP via mailbox */ " ld$a1, 0x38(%[base]) \n"
Re: [PATCH 1/6] MIPS: Loongson64: Do not write the read only field LPA of CP0_CONFIG3
在 2020/10/30 20:13, Jiaxun Yang 写道: 在 2020/10/30 14:22, Tiezhu Yang 写道: On 10/30/2020 12:00 PM, Jiaxun Yang wrote: 在 2020/10/29 16:02, Tiezhu Yang 写道: The field LPA of CP0_CONFIG3 register is read only for Loongson64, so the write operations are meaningless, remove them. Signed-off-by: Tiezhu Yang --- arch/mips/include/asm/mach-loongson64/kernel-entry-init.h | 8 arch/mips/loongson64/numa.c | 3 --- 2 files changed, 11 deletions(-) Hi Tiezhu, AFAIK it's not read only on 3A1000. Have you check with hardware guys? Hi Jiaxun, Yes, I checked it before send this patch, the field LPA of CP0_CONFIG3 on 3A1000 is also read only, we can see the related description in the chapter 3.22 of Loongson_3A1000_cpu_user_2. On page 36, it said: "能否写ELPA位依赖于Config3寄存器的LPA域 。当Config3的LPA位为0时， PageGrain的ELPA位被置位。" Don't know if it matters. @Huacai, Any comments? Do you know why it exists here? Confirmed by another rev of the manual that it's only a tip for implementer. I guess my assumption was wrong. LPA should be read-only though. Thanks - Jiaxun Thanks - Jiaxun
Re: [PATCH 1/6] MIPS: Loongson64: Do not write the read only field LPA of CP0_CONFIG3
在 2020/10/30 14:22, Tiezhu Yang 写道: On 10/30/2020 12:00 PM, Jiaxun Yang wrote: 在 2020/10/29 16:02, Tiezhu Yang 写道: The field LPA of CP0_CONFIG3 register is read only for Loongson64, so the write operations are meaningless, remove them. Signed-off-by: Tiezhu Yang --- arch/mips/include/asm/mach-loongson64/kernel-entry-init.h | 8 arch/mips/loongson64/numa.c | 3 --- 2 files changed, 11 deletions(-) Hi Tiezhu, AFAIK it's not read only on 3A1000. Have you check with hardware guys? Hi Jiaxun, Yes, I checked it before send this patch, the field LPA of CP0_CONFIG3 on 3A1000 is also read only, we can see the related description in the chapter 3.22 of Loongson_3A1000_cpu_user_2. On page 36, it said: "能否写ELPA位依赖于Config3寄存器的LPA域 。当Config3的LPA位为0时， PageGrain的ELPA位被置位。" Don't know if it matters. @Huacai, Any comments? Do you know why it exists here? Thanks - Jiaxun
Re: [PATCH 4/6] MIPS: Loongson64: Add Mail_Send support for 3A4000+ CPU
在 2020/10/29 16:02, Tiezhu Yang 写道:
Loongson 3A4000+ CPU has per-core Mail_Send register to send mail,
there is no need to maintain register address of each core and node,
just simply specify cpu number.
Signed-off-by: Lu Zeng
Signed-off-by: Jianmin Lv
Signed-off-by: Tiezhu Yang
---
.../include/asm/mach-loongson64/loongson_regs.h| 10 +++
arch/mips/loongson64/smp.c | 75 +-
2 files changed, 68 insertions(+), 17 deletions(-)
diff --git a/arch/mips/include/asm/mach-loongson64/loongson_regs.h
b/arch/mips/include/asm/mach-loongson64/loongson_regs.h
index 83dbb9f..1659935 100644
--- a/arch/mips/include/asm/mach-loongson64/loongson_regs.h
+++ b/arch/mips/include/asm/mach-loongson64/loongson_regs.h
@@ -227,6 +227,16 @@ static inline void csr_writeq(u64 val, u32 reg)
#define CSR_IPI_SEND_CPU_SHIFT16
#define CSR_IPI_SEND_BLOCKBIT(31)
+#define LOONGSON_CSR_MAIL_BUF0 0x1020
+#define LOONGSON_CSR_MAIL_SEND 0x1048
+#define CSR_MAIL_SEND_BLOCKBIT_ULL(31)
+#define CSR_MAIL_SEND_BOX_LOW(box) (box << 1)
+#define CSR_MAIL_SEND_BOX_HIGH(box)((box << 1) + 1)
+#define CSR_MAIL_SEND_BOX_SHIFT2
+#define CSR_MAIL_SEND_CPU_SHIFT16
+#define CSR_MAIL_SEND_BUF_SHIFT32
+#define CSR_MAIL_SEND_H32_MASK 0xULL
+
static inline u64 drdtime(void)
{
int rID = 0;
diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c
index 7d58853..33597d2 100644
--- a/arch/mips/loongson64/smp.c
+++ b/arch/mips/loongson64/smp.c
@@ -54,6 +54,26 @@ static uint32_t core0_c0count[NR_CPUS];
u32 (*ipi_read_clear)(int cpu);
void (*ipi_write_action)(int cpu, u32 action);
+/* send mail via Mail_Send register for 3A4000+ CPU */
+static void csr_mail_send(uint64_t data, int cpu, int mailbox)
+{
+ uint64_t val;
+
+ /* send high 32 bits */
+ val = CSR_MAIL_SEND_BLOCK;
+ val |= (CSR_MAIL_SEND_BOX_HIGH(mailbox) << CSR_MAIL_SEND_BOX_SHIFT);
+ val |= (cpu << CSR_MAIL_SEND_CPU_SHIFT);
+ val |= (data & CSR_MAIL_SEND_H32_MASK);
+ csr_writeq(val, LOONGSON_CSR_MAIL_SEND);
+
+ /* send low 32 bits */
+ val = CSR_MAIL_SEND_BLOCK;
+ val |= (CSR_MAIL_SEND_BOX_LOW(mailbox) << CSR_MAIL_SEND_BOX_SHIFT);
+ val |= (cpu << CSR_MAIL_SEND_CPU_SHIFT);
+ val |= (data << CSR_MAIL_SEND_BUF_SHIFT);
+ csr_writeq(val, LOONGSON_CSR_MAIL_SEND);
+};
+
static u32 csr_ipi_read_clear(int cpu)
{
u32 action;
@@ -348,7 +368,10 @@ static void loongson3_init_secondary(void)
/* Set interrupt mask, but don't enable */
change_c0_status(ST0_IM, imask);
- loongson3_ipi_write32(0x, ipi_en0_regs[cpu_logical_map(cpu)]);
+ if (cpu_has_csr() && csr_readl(LOONGSON_CSR_FEATURES) &
LOONGSON_CSRF_IPI)
+ csr_writel(0x, LOONGSON_CSR_IPI_EN);
Hi Tiezhu,
Feature cheking is duplicated. could you please abstract them to
callbacks and set
them in csr_ipi probe?
e.g.
ipi_write_enable
+ else
+ loongson3_ipi_write32(0x,
ipi_en0_regs[cpu_logical_map(cpu)]);
per_cpu(cpu_state, cpu) = CPU_ONLINE;
cpu_set_core(_data[cpu],
@@ -380,8 +403,12 @@ static void loongson3_smp_finish(void)
write_c0_compare(read_c0_count() + mips_hpt_frequency/HZ);
local_irq_enable();
- loongson3_ipi_write64(0,
- ipi_mailbox_buf[cpu_logical_map(cpu)] + 0x0);
+
+ if (cpu_has_csr() && csr_readl(LOONGSON_CSR_FEATURES) &
LOONGSON_CSRF_IPI)
+ csr_writel(0, LOONGSON_CSR_MAIL_BUF0);
+ else
+ loongson3_ipi_write64(0, ipi_mailbox_buf[cpu_logical_map(cpu)]
+ 0x0);
+
ditto here,
ipi_write_buf
pr_info("CPU#%d finished, CP0_ST=%x\n",
smp_processor_id(), read_c0_status());
}
@@ -414,12 +441,18 @@ static void __init loongson3_smp_setup(void)
}
csr_ipi_probe();
- ipi_set0_regs_init();
- ipi_clear0_regs_init();
- ipi_status0_regs_init();
- ipi_en0_regs_init();
- ipi_mailbox_buf_init();
- loongson3_ipi_write32(0x, ipi_en0_regs[cpu_logical_map(0)]);
+
+ if (cpu_has_csr() && csr_readl(LOONGSON_CSR_FEATURES) &
LOONGSON_CSRF_IPI) {
+ csr_writel(0x, LOONGSON_CSR_IPI_EN);
+ } else {
+ ipi_set0_regs_init();
+ ipi_clear0_regs_init();
+ ipi_status0_regs_init();
+ ipi_en0_regs_init();
+ ipi_mailbox_buf_init();
+ loongson3_ipi_write32(0x,
ipi_en0_regs[cpu_logical_map(0)]);
+ }
+
cpu_set_core(_data[0],
cpu_logical_map(0) % loongson_sysconf.cores_per_package);
cpu_data[0].package = cpu_logical_map(0) /
loongson_sysconf.cores_per_package;
@@ -452,14 +485,22 @@ static int loongson3_boot_secondary(int cpu, struct
task_struct *idle)
Re: [PATCH 1/6] MIPS: Loongson64: Do not write the read only field LPA of CP0_CONFIG3
在 2020/10/29 16:02, Tiezhu Yang 写道: The field LPA of CP0_CONFIG3 register is read only for Loongson64, so the write operations are meaningless, remove them. Signed-off-by: Tiezhu Yang --- arch/mips/include/asm/mach-loongson64/kernel-entry-init.h | 8 arch/mips/loongson64/numa.c | 3 --- 2 files changed, 11 deletions(-) Hi Tiezhu, AFAIK it's not read only on 3A1000. Have you check with hardware guys? Thanks. - Jiaxun
Re: [PATCH v2 3/4 RESEND] MIPS: Loongson64: Add /proc/boardinfo
于 2020年10月12日 GMT+08:00 下午8:02:25, Tiezhu Yang 写到:
>On 10/12/2020 06:38 PM, Thomas Bogendoerfer wrote:
>> On Sun, Oct 11, 2020 at 07:47:53AM +0800, Tiezhu Yang wrote:
>>> Add /proc/boardinfo to get mainboard and BIOS info easily on the Loongson
>>> platform, this is useful to point out the current used mainboard type and
>>> BIOS version when there exists problems related with hardware or firmware.
>>>
>>> E.g. with this patch:
>>>
>>> [loongson@linux ~]$ cat /proc/boardinfo
>>> Board Info
>>> Manufacturer: LEMOTE
>>> Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc
>>> Family : LOONGSON3
>>>
>>> BIOS Info
>>> Vendor : Kunlun
>>> Version : Kunlun-A1901-V4.1.3-20200414093938
>>> ROM Size: 4 KB
>>> Release Date: 2020-04-14
>> Why does Loongson64 need this extra file no other architecture or MIPS
>> platform need ? Do others provide this information via a different method ?
>> If yes, why can't Loongson64 do the same ?
>
>Hi Thomas,
>
>This is related with the implementation of firmware.
>
>Using dmidecode command can get the similar info if there exists SMBIOS
>in firmware, but the fact is there is no SMBIOS on some machines, we can
>see nothing when execute dmidecode, like this:
>
>[root@linux loongson]# dmidecode
># dmidecode 2.12
># No SMBIOS nor DMI entry point found, sorry.
>
>The following three structures are already defined in the interface
>specification about firmware and kernel on the Loongson platform,
>this is common requirement and specific for Loongson64, so add a
>new boardinfo.c file in arch/mips/loongson64.
>
>arch/mips/include/asm/mach-loongson64/boot_param.h
>struct interface_info {
> u16 vers; /* version of the specificition */
> u16 size;
> u8 flag;
> char description[64];
>} __packed;
>
>struct board_devices {
> char name[64];/* hold the device name */
> u32 num_resources; /* number of device_resource */
> /* for each device's resource */
> struct resource_loongson resource[MAX_RESOURCE_NUMBER];
> /* arch specific additions */
> struct archdev_data archdata;
>};
>
>struct loongson_special_attribute {
> u16 vers; /* version of this special */
> char special_name[64]; /* special_atribute_name */
> u32 loongson_special_type; /* type of special device */
> /* for each device's resource */
> struct resource_loongson resource[MAX_RESOURCE_NUMBER];
>};
Hi Tiezhu,
Through I don't think touching top level of proc would be a good idea. It's all
about API consistency.
If you intend to provide user an interface then I guess /sys/firmware/lefi
like what DMI did or somewhere less critical is better.
There is no guarantee that Loongson64 device would come with LEFI,
although it's mandatory for now.
Thanks.
- Jiaxun
>
>Thanks,
>Tiezhu
>
>>
>> Thomas.
>>
Re: [PATCH 2/3] MIPS: Loongson64: Clean up numa.c
在 2020/10/9 下午6:57, Tiezhu Yang 写道:
(1) Replace nid_to_addroffset() with nid_to_addrbase() and then remove the
related useless code.
(2) Since end_pfn = start_pfn + node_psize, use "node_psize" instead of
"end_pfn - start_pfn" to avoid the redundant calculation.
(3) After commit 6fbde6b492df ("MIPS: Loongson64: Move files to the
top-level directory"), CONFIG_ZONE_DMA32 is always set for Loongson64
due to MACH_LOONGSON64 selects ZONE_DMA32, so no need to use ifdef any
more, just remove it.
Signed-off-by: Tiezhu Yang
Reviewed-by: Jiaxun Yang
---
arch/mips/include/asm/mach-loongson64/mmzone.h | 6 +-
arch/mips/loongson64/numa.c| 29 +++---
2 files changed, 4 insertions(+), 31 deletions(-)
diff --git a/arch/mips/include/asm/mach-loongson64/mmzone.h
b/arch/mips/include/asm/mach-loongson64/mmzone.h
index 3a25dbd..c3f0f7a 100644
--- a/arch/mips/include/asm/mach-loongson64/mmzone.h
+++ b/arch/mips/include/asm/mach-loongson64/mmzone.h
@@ -11,13 +11,9 @@
#include
#define NODE_ADDRSPACE_SHIFT 44
-#define NODE0_ADDRSPACE_OFFSET 0xUL
-#define NODE1_ADDRSPACE_OFFSET 0x1000UL
-#define NODE2_ADDRSPACE_OFFSET 0x2000UL
-#define NODE3_ADDRSPACE_OFFSET 0x3000UL
#define pa_to_nid(addr) (((addr) & 0xf000) >> NODE_ADDRSPACE_SHIFT)
-#define nid_to_addrbase(nid) ((nid) << NODE_ADDRSPACE_SHIFT)
+#define nid_to_addrbase(nid) ((unsigned long)(nid) << NODE_ADDRSPACE_SHIFT)
extern struct pglist_data *__node_data[];
diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
index ea8bb1b..cf9459f 100644
--- a/arch/mips/loongson64/numa.c
+++ b/arch/mips/loongson64/numa.c
@@ -98,27 +98,6 @@ static void __init init_topology_matrix(void)
}
}
-static unsigned long nid_to_addroffset(unsigned int nid)
-{
- unsigned long result;
- switch (nid) {
- case 0:
- default:
- result = NODE0_ADDRSPACE_OFFSET;
- break;
- case 1:
- result = NODE1_ADDRSPACE_OFFSET;
- break;
- case 2:
- result = NODE2_ADDRSPACE_OFFSET;
- break;
- case 3:
- result = NODE3_ADDRSPACE_OFFSET;
- break;
- }
- return result;
-}
-
static void __init szmem(unsigned int node)
{
u32 i, mem_type;
@@ -146,7 +125,7 @@ static void __init szmem(unsigned int node)
pr_info(" start_pfn:0x%llx, end_pfn:0x%llx,
num_physpages:0x%lx\n",
start_pfn, end_pfn, num_physpages);
memblock_add_node(PFN_PHYS(start_pfn),
- PFN_PHYS(end_pfn - start_pfn), node);
+ PFN_PHYS(node_psize), node);
break;
case SYSTEM_RAM_HIGH:
start_pfn = ((node_id << 44) + mem_start) >> PAGE_SHIFT;
@@ -158,7 +137,7 @@ static void __init szmem(unsigned int node)
pr_info(" start_pfn:0x%llx, end_pfn:0x%llx,
num_physpages:0x%lx\n",
start_pfn, end_pfn, num_physpages);
memblock_add_node(PFN_PHYS(start_pfn),
- PFN_PHYS(end_pfn - start_pfn), node);
+ PFN_PHYS(node_psize), node);
break;
case SYSTEM_RAM_RESERVED:
pr_info("Node%d: mem_type:%d, mem_start:0x%llx,
mem_size:0x%llx MB\n",
@@ -175,7 +154,7 @@ static void __init node_mem_init(unsigned int node)
unsigned long node_addrspace_offset;
unsigned long start_pfn, end_pfn;
- node_addrspace_offset = nid_to_addroffset(node);
+ node_addrspace_offset = nid_to_addrbase(node);
pr_info("Node%d's addrspace_offset is 0x%lx\n",
node, node_addrspace_offset);
@@ -242,9 +221,7 @@ void __init paging_init(void)
unsigned long zones_size[MAX_NR_ZONES] = {0, };
pagetable_init();
-#ifdef CONFIG_ZONE_DMA32
zones_size[ZONE_DMA32] = MAX_DMA32_PFN;
-#endif
zones_size[ZONE_NORMAL] = max_low_pfn;
free_area_init(zones_size);
}
Re: [PATCH 3/3] MIPS: Loongson64: Add /proc/boardinfo
在 2020/10/9 下午6:57, Tiezhu Yang 写道: Add /proc/boardinfo to get mainboard and BIOS info easily on the Loongson platform, this is useful to point out the current used mainboard type and BIOS version when there exists problems related with hardware or firmware. Hi Tiezhu, You're touching Kernel userspace API and I believe it should be documented. Also linux-api list should be informed. Also I'd like to know if it's really useful for mainline kernel. For user who wants to check board information, dmidecode is already useful enough. Thanks. - Jiaxun E.g. with this patch: [loongson@linux ~]$ cat /proc/boardinfo Board Info Manufacturer: LEMOTE Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc Family : LOONGSON3 BIOS Info Vendor : Kunlun Version : Kunlun-A1901-V4.1.3-20200414093938 ROM Size: 4 KB Release Date: 2020-04-14 Signed-off-by: Tiezhu Yang ---
Re: [PATCH v2] MIPS: replace add_memory_region with memblock
在 2020/10/8 23:20, Serge Semin 写道: [...] - add_memory_region(LOONGSON_HIGHMEM_START, - highmemsize << 20, BOOT_MEM_RAM); - - add_memory_region(LOONGSON_PCI_MEM_END + 1, LOONGSON_HIGHMEM_START - - LOONGSON_PCI_MEM_END - 1, BOOT_MEM_RESERVED); - + memblock_add(LOONGSON_HIGHMEM_START, highmemsize << 20); The same question. Is it ok to discard the [LOONGSON_PCI_MEM_END+1:LOONGSON_HIGHMEM_START-LOONGSON_PCI_MEM_END-1] region removal operation? Hi all, I can confirm this reservation can be removed. It was used to ensure HIGHMEM won't overlap PCI MMIO region when firmware was unreliable. But I do think we shouldn't care this case as an unreliable firmware shouldn't ship with any devices for end users. Also it won't affect display of /proc/iomem, now we're on age of DeviceTree :-) Thanks. - Jiaxun -Sergey #endif /* !CONFIG_64BIT */ }
Re: [PATCH] MIPS: cevt-r4k: Enable intimer for Loongson64 CPUs with extimer
于 2020年10月2日 GMT+08:00 下午9:27:21, Thomas Bogendoerfer
写到:
>On Wed, Sep 23, 2020 at 07:02:54PM +0800, Jiaxun Yang wrote:
>>
>> +#ifdef CONFIG_CPU_LOONGSON64
>> +static int c0_compare_int_enable(struct clock_event_device *cd)
>> +{
>> +if (cpu_has_extimer)
>> +set_c0_config6(LOONGSON_CONF6_INTIMER);
>
>why are you not simply do this in loognson64 board setup code and avoid
>the whole cluttering of #ifdef CONFIG_CPU_LOONGSON64 over common code ?
Because I'm going to add extimer support later that require dynamic switch of
cevt-r4k.
This callback is required.
Thanks.
- Jiaxun
>
>Thomas.
>
Re: [PATCH 1/2] mips: Add strong UC ordering config
在 2020/9/20 19:00, Serge Semin 写道:
In accordance with [1, 2] memory transactions using CCA=2 (Uncached
Cacheability and Coherency Attribute) are always strongly ordered. This
means the younger memory accesses using CCA=2 are never allowed to be
executed before older memory accesses using CCA=2 (no bypassing is
allowed), and Loads and Stores using CCA=2 are never speculative. It is
expected by the specification that the rest of the system maintains these
properties for processor initiated uncached accesses. So the system IO
interconnect doesn't reorder uncached transactions once they have left the
processor subsystem. Taking into account these properties and what [3]
says about the relaxed IO-accessors we can infer that normal Loads and
Stores from/to CCA=2 memory and without any additional execution barriers
will fully comply with the {read,write}X_relaxed() methods requirements.
Let's convert then currently generated relaxed IO-accessors to being pure
Loads and Stores. Seeing the commit 3d474dacae72 ("MIPS: Enforce strong
ordering for MMIO accessors") and commit 8b656253a7a4 ("MIPS: Provide
actually relaxed MMIO accessors") have already made a preparation in the
corresponding macro, we can do that just by replacing the "barrier"
parameter utilization with the "relax" one. Note the "barrier" macro
argument can be removed, since it isn't fully used anyway other than being
always assigned to 1.
Of course it would be fullish to believe that all the available MIPS-based
CPUs completely follow the denoted specification, especially considering
how old the architecture is. Instead we introduced a dedicated kernel
config, which when enabled will convert the relaxed IO-accessors to being
pure Loads and Stores without any additional barriers around. So if some
CPU supports the strongly ordered UC memory access, it can enable that
config and use a fully optimized relaxed IO-methods. For instance,
Baikal-T1 architecture support code will do that.
[1] MIPS Coherence Protocol Specification, Document Number: MD00605,
Revision 01.01. September 14, 2015, 4.2 Execution Order Behavior,
p. 33
[2] MIPS Coherence Protocol Specification, Document Number: MD00605,
Revision 01.01. September 14, 2015, 4.8.1 IO Device Access, p. 58
[3] "LINUX KERNEL MEMORY BARRIERS", Documentation/memory-barriers.txt,
Section "KERNEL I/O BARRIER EFFECTS"
Signed-off-by: Serge Semin
Cc: Maciej W. Rozycki
Reviewed-by: Jiaxun Yang
Based on #mipslinus discussions, I suspect this option can be selected by
most modern MIPS processors including all IMG/MTI cores,
Ingenic and Loongson.
Thanks.
- Jiaxun
---
arch/mips/Kconfig | 8
arch/mips/include/asm/io.h | 20 ++--
2 files changed, 18 insertions(+), 10 deletions(-)
Re: [PATCH] perf annotate mips: Add perf arch instructions annotate handlers
在 2020/9/23 18:56, Peng Fan 写道:
From: Dengcheng Zhu
Support the MIPS architecture using the ins_ops association
method. With this patch, perf-annotate can work well on MIPS.
Testing it with a perf.data file collected on a mips machine:
$./perf annotate -i perf.data
: Disassembly of section .text:
:
: 000be6a0 :
: get_next_seq():
0.00 : be6a0: lw v0,0(a0)
0.00 : be6a4: daddiu sp,sp,-128
0.00 : be6a8: ld a7,72(a0)
0.00 : be6ac: gssqs5,s4,80(sp)
0.00 : be6b0: gssqs1,s0,48(sp)
0.00 : be6b4: gssqs8,gp,112(sp)
0.00 : be6b8: gssqs7,s6,96(sp)
0.00 : be6bc: gssqs3,s2,64(sp)
0.00 : be6c0: sd a3,0(sp)
0.00 : be6c4: moves0,a0
0.00 : be6c8: sd v0,32(sp)
0.00 : be6cc: sd a5,8(sp)
0.00 : be6d0: sd zero,8(a0)
0.00 : be6d4: sd a6,16(sp)
0.00 : be6d8: ld s2,48(a0)
8.53 : be6dc: ld s1,40(a0)
9.42 : be6e0: ld v1,32(a0)
0.00 : be6e4: nop
0.00 : be6e8: ld s4,24(a0)
0.00 : be6ec: ld s5,16(a0)
0.00 : be6f0: sd a7,40(sp)
10.11 : be6f4: ld s6,64(a0)
...
The original patch link is:
https://lore.kernel.org/patchwork/patch/1180480/
Signed-off-by: Dengcheng Zhu
Signed-off-by: Peng Fan
---
Add "bgtzl", "bltzl", "bgezl", "blezl", "beql"
and "bnel", remove "bgtzal", "blezal", "beqzal",
"bnezal" and "jialc". Because these five can not
be found in the instruction manual.
Hi Peng Fan,
These instructions do exist in MIPS Release 6.
Please see MD00086-2B-MIPS32BIS-AFP-6.06[1].
Also I'd sugguest you to note your changes in commit
message instead of comments, Like:
```
Signed-off-by: Dengcheng Zhu
Signed-off-by: Peng Fan
[fanp...@loongson.cn: Add missing "bgtzl", "bltzl",
"bgezl", "blezl", "beql" and "bnel" for pre-R6 processors]
```
Thanks.
[1]:
https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00086-2B-MIPS32BIS-AFP-6.06.pdf
- Jiaxun
tools/perf/arch/mips/Build | 2 +-
tools/perf/arch/mips/annotate/instructions.c | 41
tools/perf/util/annotate.c | 8 ++
3 files changed, 50 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/arch/mips/annotate/instructions.c
diff --git a/tools/perf/arch/mips/Build b/tools/perf/arch/mips/Build
index 1bb8bf6..e4e5f33 100644
--- a/tools/perf/arch/mips/Build
+++ b/tools/perf/arch/mips/Build
@@ -1 +1 @@
-# empty
+perf-y += util/
diff --git a/tools/perf/arch/mips/annotate/instructions.c
b/tools/perf/arch/mips/annotate/instructions.c
new file mode 100644
index 000..8fae8a1
--- /dev/null
+++ b/tools/perf/arch/mips/annotate/instructions.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0
+
+static
+struct ins_ops *mips__associate_ins_ops(struct arch *arch, const char *name)
+{
+ struct ins_ops *ops = NULL;
+
+ if (!strncmp(name, "bal", 3) ||
+ !strncmp(name, "bgezal", 6) ||
+ !strncmp(name, "bltzal", 6) ||
+ !strncmp(name, "bgtzl", 5) ||
+ !strncmp(name, "bltzl", 5) ||
+ !strncmp(name, "bgezl", 5) ||
+ !strncmp(name, "blezl", 5) ||
+ !strncmp(name, "beql", 4) ||
+ !strncmp(name, "bnel", 4) ||
+ !strncmp(name, "jal", 3))
+ ops = _ops;
+ else if (!strncmp(name, "jr", 2))
+ ops = _ops;
+ else if (name[0] == 'j' || name[0] == 'b')
+ ops = _ops;
+ else
+ return NULL;
+
+ arch__associate_ins_ops(arch, name, ops);
+
+ return ops;
+}
+
+static
+int mips__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
+{
+ if (!arch->initialized) {
+ arch->associate_instruction_ops = mips__associate_ins_ops;
+ arch->initialized = true;
+ arch->objdump.comment_char = '#';
+ }
+
+ return 0;
+}
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 0a1fcf7..80a4a3d 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -152,6 +152,7 @@ static int arch__associate_ins_ops(struct arch* arch, const
char *name, struct i
#include "arch/arm/annotate/instructions.c"
#include "arch/arm64/annotate/instructions.c"
#include "arch/csky/annotate/instructions.c"
+#include "arch/mips/annotate/instructions.c"
#include "arch/x86/annotate/instructions.c"
#include "arch/powerpc/annotate/instructions.c"
#include "arch/s390/annotate/instructions.c"
@@ -175,6 +176,13 @@ static struct arch architectures[] = {
.init = csky__annotate_init,
},
{
+ .name = "mips",
+ .init = mips__annotate_init,
+ .objdump = {
+
[PATCH] MIPS: Convert cpuinfo options field to bitops based
options field of cpuinfo_mips was a single variable, it means we can never have more than 64 options, while the diversity of MIPS decided there will be more options. Convert options to bitops based so we don't have to worry number of options anymore. Signed-off-by: Jiaxun Yang --- arch/mips/include/asm/cpu-features.h | 48 ++-- arch/mips/include/asm/cpu-info.h | 22 +- arch/mips/include/asm/cpu.h | 142 +- arch/mips/kernel/cpu-probe.c | 371 --- arch/mips/kernel/proc.c | 2 +- arch/mips/kernel/watch.c | 2 +- arch/mips/loongson64/cpucfg-emul.c | 6 +- arch/mips/mm/c-octeon.c | 6 +- arch/mips/mm/c-r4k.c | 37 +-- arch/mips/mm/sc-mips.c | 2 +- arch/mips/mm/tlbex.c | 2 +- 11 files changed, 364 insertions(+), 276 deletions(-) diff --git a/arch/mips/include/asm/cpu-features.h b/arch/mips/include/asm/cpu-features.h index aec458eee2a5..70666773591f 100644 --- a/arch/mips/include/asm/cpu-features.h +++ b/arch/mips/include/asm/cpu-features.h @@ -16,7 +16,7 @@ #define __ase(ase) (cpu_data[0].ases & (ase)) #define __isa(isa) (cpu_data[0].isa_level & (isa)) -#define __opt(opt) (cpu_data[0].options & (opt)) +#define __opt(opt) (test_cpu_opt(_cpu_data, opt)) /* * Check if MIPS_ISA_REV is >= isa *and* an option or ASE is detected during @@ -129,8 +129,8 @@ /* Don't override `cpu_has_fpu' to 1 or the "nofpu" option won't work. */ #ifndef cpu_has_fpu # ifdef CONFIG_MIPS_FP_SUPPORT -# define cpu_has_fpu (current_cpu_data.options & MIPS_CPU_FPU) -# define raw_cpu_has_fpu (raw_current_cpu_data.options & MIPS_CPU_FPU) +# define cpu_has_fpu test_cpu_opt(_cpu_data, MIPS_CPU_FPU) +# define raw_cpu_has_fpu test_cpu_opt(_current_cpu_data, MIPS_CPU_FPU) # else # define cpu_has_fpu 0 # define raw_cpu_has_fpu 0 @@ -652,6 +652,9 @@ /* * Guest capabilities */ + +#define __gopt(opt)(test_cpu_gopt(_cpu_data, opt)) + #ifndef cpu_guest_has_conf1 #define cpu_guest_has_conf1(cpu_data[0].guest.conf & (1 << 1)) #endif @@ -674,31 +677,31 @@ #define cpu_guest_has_conf7(cpu_data[0].guest.conf & (1 << 7)) #endif #ifndef cpu_guest_has_fpu -#define cpu_guest_has_fpu (cpu_data[0].guest.options & MIPS_CPU_FPU) +#define cpu_guest_has_fpu __gopt(MIPS_CPU_FPU) #endif #ifndef cpu_guest_has_watch -#define cpu_guest_has_watch(cpu_data[0].guest.options & MIPS_CPU_WATCH) +#define cpu_guest_has_watch__gopt(MIPS_CPU_WATCH) #endif #ifndef cpu_guest_has_contextconfig -#define cpu_guest_has_contextconfig (cpu_data[0].guest.options & MIPS_CPU_CTXTC) +#define cpu_guest_has_contextconfig __gopt(MIPS_CPU_CTXTC) #endif #ifndef cpu_guest_has_segments -#define cpu_guest_has_segments (cpu_data[0].guest.options & MIPS_CPU_SEGMENTS) +#define cpu_guest_has_segments __gopt(MIPS_CPU_SEGMENTS) #endif #ifndef cpu_guest_has_badinstr -#define cpu_guest_has_badinstr (cpu_data[0].guest.options & MIPS_CPU_BADINSTR) +#define cpu_guest_has_badinstr __gopt(MIPS_CPU_BADINSTR) #endif #ifndef cpu_guest_has_badinstrp -#define cpu_guest_has_badinstrp(cpu_data[0].guest.options & MIPS_CPU_BADINSTRP) +#define cpu_guest_has_badinstrp__gopt(MIPS_CPU_BADINSTRP) #endif #ifndef cpu_guest_has_htw -#define cpu_guest_has_htw (cpu_data[0].guest.options & MIPS_CPU_HTW) +#define cpu_guest_has_htw __gopt(MIPS_CPU_HTW) #endif #ifndef cpu_guest_has_ldpte -#define cpu_guest_has_ldpte(cpu_data[0].guest.options & MIPS_CPU_LDPTE) +#define cpu_guest_has_ldpte__gopt(MIPS_CPU_LDPTE) #endif #ifndef cpu_guest_has_mvh -#define cpu_guest_has_mvh (cpu_data[0].guest.options & MIPS_CPU_MVH) +#define cpu_guest_has_mvh __gopt(MIPS_CPU_MVH) #endif #ifndef cpu_guest_has_msa #define cpu_guest_has_msa (cpu_data[0].guest.ases & MIPS_ASE_MSA) @@ -707,38 +710,41 @@ #define cpu_guest_has_kscr(n) (cpu_data[0].guest.kscratch_mask & (1u << (n))) #endif #ifndef cpu_guest_has_rw_llb -#define cpu_guest_has_rw_llb (cpu_has_mips_r6 || (cpu_data[0].guest.options & MIPS_CPU_RW_LLB)) +#define cpu_guest_has_rw_llb (cpu_has_mips_r6 || __gopt(MIPS_CPU_RW_LLB)) #endif #ifndef cpu_guest_has_perf -#define cpu_guest_has_perf (cpu_data[0].guest.options & MIPS_CPU_PERF) +#define cpu_guest_has_perf __gopt(MIPS_CPU_PERF) #endif #ifndef cpu_guest_has_maar -#define cpu_guest_has_maar (cpu_data[0].guest.options & MIPS_CPU_MAAR) +#define cpu_guest_has_maar __gopt(MIPS_CPU_MAAR) #endif #ifndef cpu_guest_has_userlocal -#define cpu_guest_has_userlocal(cpu_data[0].guest.options & MIPS_CPU_ULRI) +#define cpu_guest_has_userlocal__gopt(MIPS_CPU_ULRI) #endif /* * G
[PATCH] MIPS: cevt-r4k: Enable intimer for Loongson64 CPUs with extimer
Loongson64C and Loongson64G have extimer feature, which is a
timer sharing Cause.TI with cevt-r4k (named intimer).
To ensure the cevt-r4k's usability, we need to add a callback for
clock device to switch intimer.
Signed-off-by: Jiaxun Yang
---
arch/mips/include/asm/cpu-features.h | 4
arch/mips/include/asm/cpu.h | 1 +
arch/mips/kernel/cevt-r4k.c | 25 +
arch/mips/kernel/cpu-probe.c | 6 +-
4 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/cpu-features.h
b/arch/mips/include/asm/cpu-features.h
index 78cf7e300f12..aec458eee2a5 100644
--- a/arch/mips/include/asm/cpu-features.h
+++ b/arch/mips/include/asm/cpu-features.h
@@ -576,6 +576,10 @@
# define cpu_has_gsexcex __opt(MIPS_CPU_GSEXCEX)
#endif
+#ifndef cpu_has_extimer
+# define cpu_has_extimer __opt(MIPS_CPU_EXTIMER)
+#endif
+
#ifdef CONFIG_SMP
/*
* Some systems share FTLB RAMs between threads within a core (siblings in
diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index 388a82f28a87..854e1b44254b 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -429,6 +429,7 @@ enum cpu_type_enum {
#define MIPS_CPU_MAC_2008_ONLY BIT_ULL(60) /* CPU Only support MAC2008
Fused multiply-add instruction */
#define MIPS_CPU_FTLBPAREX BIT_ULL(61) /* CPU has FTLB parity
exception */
#define MIPS_CPU_GSEXCEX BIT_ULL(62) /* CPU has GSExc exception */
+#define MIPS_CPU_EXTIMER BIT_ULL(63) /* CPU has External Timer
(Loongson) */
/*
* CPU ASE encodings
diff --git a/arch/mips/kernel/cevt-r4k.c b/arch/mips/kernel/cevt-r4k.c
index 995ad9e69ded..fae49e9215b4 100644
--- a/arch/mips/kernel/cevt-r4k.c
+++ b/arch/mips/kernel/cevt-r4k.c
@@ -15,6 +15,8 @@
#include
#include
+#include
+#include
static int mips_next_event(unsigned long delta,
struct clock_event_device *evt)
@@ -294,6 +296,24 @@ core_initcall(r4k_register_cpufreq_notifier);
#endif /* !CONFIG_CPU_FREQ */
+#ifdef CONFIG_CPU_LOONGSON64
+static int c0_compare_int_enable(struct clock_event_device *cd)
+{
+ if (cpu_has_extimer)
+ set_c0_config6(LOONGSON_CONF6_INTIMER);
+
+ return 0;
+}
+
+static int c0_compare_int_disable(struct clock_event_device *cd)
+{
+ if (cpu_has_extimer)
+ clear_c0_config6(LOONGSON_CONF6_INTIMER);
+
+ return 0;
+}
+#endif
+
int r4k_clockevent_init(void)
{
unsigned long flags = IRQF_PERCPU | IRQF_TIMER | IRQF_SHARED;
@@ -329,6 +349,11 @@ int r4k_clockevent_init(void)
cd->set_next_event = mips_next_event;
cd->event_handler = mips_event_handler;
+#ifdef CONFIG_CPU_LOONGSON64
+ cd->set_state_oneshot = c0_compare_int_enable;
+ cd->set_state_shutdown = c0_compare_int_disable;
+#endif
+
clockevents_config_and_register(cd, mips_hpt_frequency, min_delta,
0x7fff);
if (cp0_timer_irq_installed)
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 6be23f205e74..4f1e9ef2644e 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -2030,6 +2030,9 @@ static inline void decode_cpucfg(struct cpuinfo_mips *c)
if (cfg2 & LOONGSON_CFG2_LEXT2)
c->ases |= MIPS_ASE_LOONGSON_EXT2;
+ if (cfg2 & LOONGSON_CFG2_LLFTP)
+ c->options |= MIPS_CPU_EXTIMER;
+
if (cfg2 & LOONGSON_CFG2_LSPW) {
c->options |= MIPS_CPU_LDPTE;
c->guest.options |= MIPS_CPU_LDPTE;
@@ -2088,7 +2091,8 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips
*c, unsigned int cpu)
* Also some early Loongson-3A2000 had wrong TLB type in Config
* register, we correct it here.
*/
- c->options |= MIPS_CPU_FTLB | MIPS_CPU_TLBINV | MIPS_CPU_LDPTE;
+ c->options |= MIPS_CPU_FTLB | MIPS_CPU_TLBINV | MIPS_CPU_LDPTE |
+ MIPS_CPU_EXTIMER;
c->writecombine = _CACHE_UNCACHED_ACCELERATED;
c->ases |= (MIPS_ASE_LOONGSON_MMI | MIPS_ASE_LOONGSON_CAM |
MIPS_ASE_LOONGSON_EXT | MIPS_ASE_LOONGSON_EXT2);
--
2.28.0
[PATCH] MIPS: Loongson2ef: Disable Loongson MMI instructions
It was missed when I was forking Loongson2ef from Loongson64 but
should be applied to Loongson2ef as march=loongson2f
will also enable Loongson MMI in GCC-9+.
Signed-off-by: Jiaxun Yang
Fixes: 71e2f4dd5a65 ("MIPS: Fork loongson2ef from loongson64")
Reported-by: Thomas Bogendoerfer
Cc: sta...@vger.kernel.org # v5.8+
---
arch/mips/loongson2ef/Platform | 4
1 file changed, 4 insertions(+)
diff --git a/arch/mips/loongson2ef/Platform b/arch/mips/loongson2ef/Platform
index 4ab55f1123a0..ae023b9a1c51 100644
--- a/arch/mips/loongson2ef/Platform
+++ b/arch/mips/loongson2ef/Platform
@@ -44,6 +44,10 @@ ifdef CONFIG_CPU_LOONGSON2F_WORKAROUNDS
endif
endif
+# Some -march= flags enable MMI instructions, and GCC complains about that
+# support being enabled alongside -msoft-float. Thus explicitly disable MMI.
+cflags-y += $(call cc-option,-mno-loongson-mmi)
+
#
# Loongson Machines' Support
#
--
2.28.0
Re: [PATCH] MIPS: kexec: Add crashkernel=YM handling
于 2020年9月19日 GMT+08:00 下午4:29:39, Youling Tang 写到:
>
>
>On 09/19/2020 03:02 PM, Jiaxun Yang wrote:
>>
>> 于 2020年9月19日 GMT+08:00 上午9:55:46, Youling Tang 写到:
>>> When the kernel crashkernel parameter is specified with just a size,
>>> we are supposed to allocate a region from RAM to store the crashkernel.
>>> However, MIPS merely reserves physical address zero with no checking
>>> that there is even RAM there.
>>>
>>> Fix this by lifting similar code from x86, importing it to MIPS with the
>>> MIPS specific parameters added. In the absence of any platform specific
>>> information, we allocate the crashkernel region from the first 512MB of
>>> physical memory (limited to CKSEG0 or KSEG0 address range).
>>>
>>> When X is not specified, crash_base defaults to 0 (crashkernel=YM@XM).
>>>
>>> E.g. without this patch:
>>>
>>> The environment as follows:
>>> [0.00] MIPS: machine is loongson,loongson64c-4core-ls7a
>>> ...
>>> [0.00] Kernel command line: root=/dev/sda2 crashkernel=96M ...
>>>
>>> The warning as follows:
>>> [0.00] Invalid memory region reserved for crash kernel
>>>
>>> And the iomem as follows:
>>> 0020-0eff : System RAM
>>> 0020-00b47f87 : Kernel code
>>> 00b47f88-00df : Kernel data
>>> 00e6-01f73c7f : Kernel bss
>>> 1a00-1bff : pci@1a00
>>> ...
>>>
>>> With this patch:
>>>
>>> After increasing crash_base <= 0 handling.
>>>
>>> And the iomem as follows:
>>> 0020-0eff : System RAM
>>> 0020-00b47f87 : Kernel code
>>> 00b47f88-00df : Kernel data
>>> 00e6-01f73c7f : Kernel bss
>>> 0400-09ff : Crash kernel
>>> 1a00-1bff : pci@1a00
>>> ...
>>>
>>> Signed-off-by: Youling Tang
>>> ---
>>> arch/mips/kernel/setup.c | 24 +---
>>> 1 file changed, 21 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>>> index bf5f5ac..59a88ea 100644
>>> --- a/arch/mips/kernel/setup.c
>>> +++ b/arch/mips/kernel/setup.c
>>> @@ -477,6 +477,11 @@ early_param("elfcorehdr", early_parse_elfcorehdr);
>>> #endif
>>>
>>> #ifdef CONFIG_KEXEC
>>> +
>>> +/* 64M alignment for crash kernel regions */
>>> +#define CRASH_ALIGNSZ_64M
>>> +#define CRASH_ADDR_MAX SZ_512M
>> Hi Youling
>>
>> How do you determine the alignment requirement?
>>
>> Can we relax it?
>>
>> Thanks.
>>
>> - Jiaxun
>Hi Jiaxun
>
>Only when XM is not specified, 64M alignment is specified.
>
>After the capture kernel is configured with CRASH_DUMP, PHYSICAL_START
>defaults to 0x0x8400 (64M). The kexec -p operation will
>succeed only when the reserved Crash kernel start address is consistent
>with PHYSICAL_START.
>
>The description of PHYSICAL_START in arch/mips/Kconfig:2996 is as follows:
>This gives the CKSEG0 or KSEG0 address where the kernel is loaded.If you
>plan to use kernel for capturing the crash dump change this value to start
>of the reserved region (the "X" value as specified in the
>"crashkernel=YM@XM"
>command line boot parameter passed to the panic-ed kernel).
Thanks for your explanation~
That makes sense.
- Jiaxun
>
>Thanks,
>
>- Youling
[...]
Re: [PATCH] MIPS: kexec: Add crashkernel=YM handling
于 2020年9月19日 GMT+08:00 上午9:55:46, Youling Tang 写到:
>When the kernel crashkernel parameter is specified with just a size,
>we are supposed to allocate a region from RAM to store the crashkernel.
>However, MIPS merely reserves physical address zero with no checking
>that there is even RAM there.
>
>Fix this by lifting similar code from x86, importing it to MIPS with the
>MIPS specific parameters added. In the absence of any platform specific
>information, we allocate the crashkernel region from the first 512MB of
>physical memory (limited to CKSEG0 or KSEG0 address range).
>
>When X is not specified, crash_base defaults to 0 (crashkernel=YM@XM).
>
>E.g. without this patch:
>
>The environment as follows:
>[0.00] MIPS: machine is loongson,loongson64c-4core-ls7a
>...
>[0.00] Kernel command line: root=/dev/sda2 crashkernel=96M ...
>
>The warning as follows:
>[0.00] Invalid memory region reserved for crash kernel
>
>And the iomem as follows:
>0020-0eff : System RAM
> 0020-00b47f87 : Kernel code
> 00b47f88-00df : Kernel data
> 00e6-01f73c7f : Kernel bss
>1a00-1bff : pci@1a00
>...
>
>With this patch:
>
>After increasing crash_base <= 0 handling.
>
>And the iomem as follows:
>0020-0eff : System RAM
> 0020-00b47f87 : Kernel code
> 00b47f88-00df : Kernel data
> 00e6-01f73c7f : Kernel bss
> 0400-09ff : Crash kernel
>1a00-1bff : pci@1a00
>...
>
>Signed-off-by: Youling Tang
>---
> arch/mips/kernel/setup.c | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
>diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>index bf5f5ac..59a88ea 100644
>--- a/arch/mips/kernel/setup.c
>+++ b/arch/mips/kernel/setup.c
>@@ -477,6 +477,11 @@ early_param("elfcorehdr", early_parse_elfcorehdr);
> #endif
>
> #ifdef CONFIG_KEXEC
>+
>+/* 64M alignment for crash kernel regions */
>+#define CRASH_ALIGN SZ_64M
>+#define CRASH_ADDR_MAXSZ_512M
Hi Youling
How do you determine the alignment requirement?
Can we relax it?
Thanks.
- Jiaxun
>+
> static void __init mips_parse_crashkernel(void)
> {
> unsigned long long total_mem;
>@@ -489,9 +494,22 @@ static void __init mips_parse_crashkernel(void)
> if (ret != 0 || crash_size <= 0)
> return;
>
>- if (!memblock_find_in_range(crash_base, crash_base + crash_size,
>crash_size, 1)) {
>- pr_warn("Invalid memory region reserved for crash kernel\n");
>- return;
>+ if (crash_base <= 0) {
>+ crash_base = memblock_find_in_range(CRASH_ALIGN, CRASH_ADDR_MAX,
>+ crash_size,
>CRASH_ALIGN);
>+ if (!crash_base) {
>+ pr_warn("crashkernel reservation failed - No suitable
>area found.\n");
>+ return;
>+ }
>+ } else {
>+ unsigned long long start;
>+
>+ start = memblock_find_in_range(crash_base, crash_base +
>crash_size,
>+ crash_size, 1);
>+ if (start != crash_base) {
>+ pr_warn("Invalid memory region reserved for crash
>kernel\n");
>+ return;
>+ }
> }
>
> crashk_res.start = crash_base;
