* [PATCH v2 2/4] Partially revert "KVM: Pass kvm_init()'s opaque param to additional arch funcs"
From: Chao Gao @ 2022-01-18 6:44 UTC (permalink / raw)
To: kvm, seanjc, pbonzini, kevin.tian, tglx
Cc: x86, Wanpeng Li, David Hildenbrand, Paul Walmsley, linux-mips,
Paul Mackerras, H. Peter Anvin, Alexander Gordeev,
Claudio Imbrenda, Will Deacon, Maciej S. Szmigiero, linux-s390,
Janosch Frank, Marc Zyngier, Joerg Roedel, Huacai Chen,
linux-riscv, kvmarm, Dave Hansen, Aleksandar Markovic,
Ingo Molnar, Catalin Marinas, Palmer Dabbelt,
Christian Borntraeger, Chao Gao, Ravi Bangoria, Albert Ou,
Vasily Gorbik, Suzuki K Poulose, Heiko Carstens, Nicholas Piggin,
Borislav Petkov, Cédric Le Goater, Atish Patra,
Alexandru Elisei, linux-arm-kernel, Jim Mattson,
Thomas Bogendoerfer, Fabiano Rosas, Nick Desaulniers,
linux-kernel, Bharata B Rao, James Morse, kvm-riscv, Anup Patel,
Vitaly Kuznetsov, linuxppc-dev
In-Reply-To: <20220118064430.3882337-1-chao.gao@intel.com>
This partially reverts commit b99040853738 ("KVM: Pass kvm_init()'s opaque
param to additional arch funcs") remove opaque from
kvm_arch_check_processor_compat because no one uses this opaque now.
Address conflicts for ARM (due to file movement) and manually handle RISC-V
which comes after the commit.
And changes about kvm_arch_hardware_setup() in original commit are still
needed so they are not reverted.
Signed-off-by: Chao Gao <chao.gao@intel.com>
---
arch/arm64/kvm/arm.c | 2 +-
arch/mips/kvm/mips.c | 2 +-
arch/powerpc/kvm/powerpc.c | 2 +-
arch/riscv/kvm/main.c | 2 +-
arch/s390/kvm/kvm-s390.c | 2 +-
arch/x86/kvm/x86.c | 2 +-
include/linux/kvm_host.h | 2 +-
virt/kvm/kvm_main.c | 16 +++-------------
8 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 868109cf96b4..92ab3d5516ce 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -73,7 +73,7 @@ int kvm_arch_hardware_setup(void *opaque)
return 0;
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
return 0;
}
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index e59cb6246f76..c5dc4fe53bfc 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -140,7 +140,7 @@ int kvm_arch_hardware_setup(void *opaque)
return 0;
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
return 0;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 2ad0ccd202d5..30c817f3fa0c 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -423,7 +423,7 @@ int kvm_arch_hardware_setup(void *opaque)
return 0;
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
return kvmppc_core_check_processor_compat();
}
diff --git a/arch/riscv/kvm/main.c b/arch/riscv/kvm/main.c
index 2e5ca43c8c49..992877e78393 100644
--- a/arch/riscv/kvm/main.c
+++ b/arch/riscv/kvm/main.c
@@ -20,7 +20,7 @@ long kvm_arch_dev_ioctl(struct file *filp,
return -EINVAL;
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
return 0;
}
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 9c6d45d0d345..99c70d881cb6 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -252,7 +252,7 @@ int kvm_arch_hardware_enable(void)
return 0;
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
return 0;
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f8bc1948a8b5..6f3bf78afb29 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11470,7 +11470,7 @@ void kvm_arch_hardware_unsetup(void)
static_call(kvm_x86_hardware_unsetup)();
}
-int kvm_arch_check_processor_compat(void *opaque)
+int kvm_arch_check_processor_compat(void)
{
struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 3c47b146851a..a51e9ab520fc 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1310,7 +1310,7 @@ int kvm_arch_hardware_enable(void);
void kvm_arch_hardware_disable(void);
int kvm_arch_hardware_setup(void *opaque);
void kvm_arch_hardware_unsetup(void);
-int kvm_arch_check_processor_compat(void *opaque);
+int kvm_arch_check_processor_compat(void);
int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu);
bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu);
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 6e8e9d36f382..148f7169b431 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -5603,22 +5603,14 @@ struct kvm_vcpu * __percpu *kvm_get_running_vcpus(void)
return &kvm_running_vcpu;
}
-struct kvm_cpu_compat_check {
- void *opaque;
- int *ret;
-};
-
-static void check_processor_compat(void *data)
+static void check_processor_compat(void *rtn)
{
- struct kvm_cpu_compat_check *c = data;
-
- *c->ret = kvm_arch_check_processor_compat(c->opaque);
+ *(int *)rtn = kvm_arch_check_processor_compat();
}
int kvm_init(void *opaque, unsigned vcpu_size, unsigned vcpu_align,
struct module *module)
{
- struct kvm_cpu_compat_check c;
int r;
int cpu;
@@ -5646,10 +5638,8 @@ int kvm_init(void *opaque, unsigned vcpu_size, unsigned vcpu_align,
if (r < 0)
goto out_free_1;
- c.ret = &r;
- c.opaque = opaque;
for_each_online_cpu(cpu) {
- smp_call_function_single(cpu, check_processor_compat, &c, 1);
+ smp_call_function_single(cpu, check_processor_compat, &r, 1);
if (r < 0)
goto out_free_2;
}
--
2.25.1
^ permalink raw reply related
* [PATCH] drivers/macintosh/ams: remove unneeded result variable
From: cgel.zte @ 2022-01-18 7:52 UTC (permalink / raw)
To: benh; +Cc: CGEL ZTE, Zeal Robot, linuxppc-dev, linux-kernel, Minghao Chi
From: Minghao Chi <chi.minghao@zte.com.cn>
Return value from i2c_add_driver() directly instead
of taking this in another redundant variable.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: CGEL ZTE <cgel.zte@gmail.com>
---
drivers/macintosh/ams/ams-i2c.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/macintosh/ams/ams-i2c.c b/drivers/macintosh/ams/ams-i2c.c
index 21271b2e9259..d2f0cde6f9c7 100644
--- a/drivers/macintosh/ams/ams-i2c.c
+++ b/drivers/macintosh/ams/ams-i2c.c
@@ -256,8 +256,6 @@ static void ams_i2c_exit(void)
int __init ams_i2c_init(struct device_node *np)
{
- int result;
-
/* Set implementation stuff */
ams_info.of_node = np;
ams_info.exit = ams_i2c_exit;
@@ -266,7 +264,5 @@ int __init ams_i2c_init(struct device_node *np)
ams_info.clear_irq = ams_i2c_clear_irq;
ams_info.bustype = BUS_I2C;
- result = i2c_add_driver(&ams_i2c_driver);
-
- return result;
+ return i2c_add_driver(&ams_i2c_driver);
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 2/3] vstatus: Add user space API definitions for VSTATUS, NOKERNINFO and TIOCSTAT
From: Arnd Bergmann @ 2022-01-18 8:08 UTC (permalink / raw)
To: Walt Drummond
Cc: Rich Felker, linux-ia64, Linux-sh list,
open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
Max Filippov, Paul Mackerras, sparclinux, Alexander Gordeev, ar,
linux-arch, linux-s390, Vasily Gorbik, Helge Deller,
Yoshinori Sato, Matt Turner, Christian Borntraeger,
open list:TENSILICA XTENSA PORT (xtensa), Arnd Bergmann,
Heiko Carstens, Ivan Kokshaysky, Richard Henderson, Chris Zankel,
Thomas Bogendoerfer, Parisc List, Linux Kernel Mailing List,
alpha, linuxppc-dev, David S. Miller
In-Reply-To: <20220118044323.765038-2-walt@drummond.us>
On Tue, Jan 18, 2022 at 5:43 AM Walt Drummond <walt@drummond.us> wrote:
> diff --git a/include/uapi/asm-generic/ioctls.h b/include/uapi/asm-generic/ioctls.h
> index cdc9f4ca8c27..eafb662d6a0e 100644
> --- a/include/uapi/asm-generic/ioctls.h
> +++ b/include/uapi/asm-generic/ioctls.h
> @@ -97,6 +97,7 @@
>
> #define TIOCMIWAIT 0x545C /* wait for a change on serial input line(s) */
> #define TIOCGICOUNT 0x545D /* read serial port inline interrupt counts */
> +#define TIOCSTAT 0x545E /* display process group stats on tty */
>
> /*
> * Some arches already define FIOQSIZE due to a historical
I don't see any advantage in using the old-style ioctl command definitions
here, and looking through the history of this file, all recent additions used
the now normal _IOWR() style macros, so please use those as well.
Arnd
^ permalink raw reply
* Re: [PATCH net 1/4] net/fsl: xgmac_mdio: Add workaround for erratum A-009885
From: Tobias Waldekranz @ 2022-01-18 8:40 UTC (permalink / raw)
To: davem, kuba
Cc: devicetree, madalin.bucur, robh+dt, paulus, linuxppc-dev, netdev
In-Reply-To: <20220116211529.25604-2-tobias@waldekranz.com>
On Sun, Jan 16, 2022 at 22:15, Tobias Waldekranz <tobias@waldekranz.com> wrote:
> Once an MDIO read transaction is initiated, we must read back the data
> register within 16 MDC cycles after the transaction completes. Outside
> of this window, reads may return corrupt data.
>
> Therefore, disable local interrupts in the critical section, to
> maximize the probability that we can satisfy this requirement.
>
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Fixes: d55ad2967d89 ("powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan")
^ permalink raw reply
* Re: [PATCH net 3/4] powerpc/fsl/dts: Enable WA for erratum A-009885 on fman3l MDIO buses
From: Tobias Waldekranz @ 2022-01-18 8:41 UTC (permalink / raw)
To: davem, kuba
Cc: devicetree, madalin.bucur, robh+dt, paulus, linuxppc-dev, netdev
In-Reply-To: <20220116211529.25604-4-tobias@waldekranz.com>
On Sun, Jan 16, 2022 at 22:15, Tobias Waldekranz <tobias@waldekranz.com> wrote:
> This block is used in (at least) T1024 and T1040, including their
> variants like T1023 etc.
>
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Fixes: d55ad2967d89 ("powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan")
^ permalink raw reply
* Re: [RFC PATCH 3/3] powerpc/pseries/vas: Use migration_in_progress to disable DLPAR
From: Haren Myneni @ 2022-01-18 9:28 UTC (permalink / raw)
To: Nathan Lynch, mpe, linuxppc-dev, npiggin
In-Reply-To: <871r1aurk9.fsf@li-e15d104c-2135-11b2-a85c-d7ef17e56be6.ibm.com>
On Fri, 2022-01-14 at 11:59 -0600, Nathan Lynch wrote:
> Haren Myneni <haren@linux.ibm.com> writes:
>
> > Before migration starts, all secondary CPUs will be offline which
> > can invoke VAS DLPAR event.
>
> I don't understand this statement, so I can't evaluate the patch. The
> current LPM implementation does not offline any CPUs.
Thanks for your comment. My mistake..
VAS notifier with of_reconfig_notifier_register() is called during
migration for other events. VAS notifier has a bug (
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-December/238333.html
) and will fix it:
if ((action == OF_RECONFIG_ATTACH_NODE) ||
(action == OF_RECONFIG_DETACH_NODE))
intserv = of_get_property(dn, "ibm,ppc-interrupt-server#s",
&len);
As the current LPM notifier does not freeze the system, thought of
ignoring DLPAR CPU hotplug event with this migration_in_progress flag.
I will fix this as well and repost DLPAR NXGZIP series.
Thanks
Haren
^ permalink raw reply
* Re: [PATCH v4] powerpc/mce: Avoid using irq_work_queue() in realmode
From: kernel test robot @ 2022-01-18 11:14 UTC (permalink / raw)
To: Ganesh Goudar, linuxppc-dev, mpe
Cc: Ganesh Goudar, kbuild-all, mahesh, npiggin, dja
In-Reply-To: <20220117083217.330110-1-ganeshgr@linux.ibm.com>
Hi Ganesh,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.16 next-20220118]
[cannot apply to scottwood/next mpe/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Ganesh-Goudar/powerpc-mce-Avoid-using-irq_work_queue-in-realmode/20220117-163425
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc64-randconfig-c024-20220116 (https://download.01.org/0day-ci/archive/20220118/202201181831.VB3r6wzz-lkp@intel.com/config)
compiler: powerpc64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/bb8f4e786eb9c838daad7a6187dcd59040ff2771
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Ganesh-Goudar/powerpc-mce-Avoid-using-irq_work_queue-in-realmode/20220117-163425
git checkout bb8f4e786eb9c838daad7a6187dcd59040ff2771
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=powerpc SHELL=/bin/bash arch/powerpc/platforms/pseries/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
arch/powerpc/platforms/pseries/ras.c: In function 'mce_handle_error':
>> arch/powerpc/platforms/pseries/ras.c:715:23: error: unused variable 'msr' [-Werror=unused-variable]
715 | unsigned long msr;
| ^~~
cc1: all warnings being treated as errors
vim +/msr +715 arch/powerpc/platforms/pseries/ras.c
a43c1590426c44 Mahesh Salgaonkar 2018-09-11 709
4ff753feab0212 Ganesh Goudar 2020-07-24 710 static int mce_handle_error(struct pt_regs *regs, struct rtas_error_log *errp)
4ff753feab0212 Ganesh Goudar 2020-07-24 711 {
4ff753feab0212 Ganesh Goudar 2020-07-24 712 struct pseries_errorlog *pseries_log;
4ff753feab0212 Ganesh Goudar 2020-07-24 713 struct pseries_mc_errorlog *mce_log = NULL;
4ff753feab0212 Ganesh Goudar 2020-07-24 714 int disposition = rtas_error_disposition(errp);
74c3354bc1d89d Nicholas Piggin 2021-02-07 @715 unsigned long msr;
4ff753feab0212 Ganesh Goudar 2020-07-24 716 u8 error_type;
4ff753feab0212 Ganesh Goudar 2020-07-24 717
4ff753feab0212 Ganesh Goudar 2020-07-24 718 if (!rtas_error_extended(errp))
4ff753feab0212 Ganesh Goudar 2020-07-24 719 goto out;
4ff753feab0212 Ganesh Goudar 2020-07-24 720
4ff753feab0212 Ganesh Goudar 2020-07-24 721 pseries_log = get_pseries_errorlog(errp, PSERIES_ELOG_SECT_ID_MCE);
4ff753feab0212 Ganesh Goudar 2020-07-24 722 if (!pseries_log)
4ff753feab0212 Ganesh Goudar 2020-07-24 723 goto out;
4ff753feab0212 Ganesh Goudar 2020-07-24 724
4ff753feab0212 Ganesh Goudar 2020-07-24 725 mce_log = (struct pseries_mc_errorlog *)pseries_log->data;
4ff753feab0212 Ganesh Goudar 2020-07-24 726 error_type = mce_log->error_type;
4ff753feab0212 Ganesh Goudar 2020-07-24 727
4ff753feab0212 Ganesh Goudar 2020-07-24 728 disposition = mce_handle_err_realmode(disposition, error_type);
4ff753feab0212 Ganesh Goudar 2020-07-24 729 out:
4ff753feab0212 Ganesh Goudar 2020-07-24 730 disposition = mce_handle_err_virtmode(regs, errp, mce_log,
4ff753feab0212 Ganesh Goudar 2020-07-24 731 disposition);
9ca766f9891d23 Nicholas Piggin 2019-08-02 732 return disposition;
7f177f9810ada8 Ganesh Goudar 2019-04-15 733 }
7f177f9810ada8 Ganesh Goudar 2019-04-15 734
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Please backport b6b0d883bbb8 to v5.10
From: Michael Ellerman @ 2022-01-18 12:44 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman, linuxppc-dev
Hi Greg,
Could you please backport:
b6b0d883bbb8 ("powerpc/pseries: Get entry and uaccess flush required bits from H_GET_CPU_CHARACTERISTICS")
to the v5.10 stable kernel. Thanks.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/fsl: fix the schema check errors for fsl,tmu-calibration
From: David Heidelberg @ 2022-01-18 14:37 UTC (permalink / raw)
To: Rob Herring, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: devicetree, linuxppc-dev, ~okias/devicetree, linux-kernel
In-Reply-To: <20211029121733.46849-1-david@ixit.cz>
Hello, can I ask for review please? Thanks.
David Heidelberg
On Fri, Oct 29 2021 at 14:17:33 +0200, David Heidelberg <david@ixit.cz>
wrote:
> fsl,tmu-calibration is in u32-matrix format. Use matching property
> syntax.
> No functional changes. Fixes warnings as:
> $ make dtbs_check
> ...
> arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dt.yaml:
> tmu@30260000: fsl,tmu-calibration:0: Additional items are not allowed
> (1, 41, 2, 47, 3, 53, 4, 61, 5, 67, 6, 75, 7, 81, 8, 87, 9, 95, 10,
> 103, 11, 111
> , 65536, 27, 65537, 35, 65538, 43, 65539, 51, 65540, 59, 65541, 67,
> 65542, 75, 65543, 85, 65544, 93, 65545, 103, 65546, 112, 131072, 23,
> 131073, 35, 131074, 45, 131075, 55, 131076, 65, 131077, 75, 131078,
> 87, 13
> 1079, 99, 131080, 111, 196608, 21, 196609, 33, 196610, 45, 196611,
> 57, 196612, 69, 196613, 83, 196614, 95, 196615, 113 were unexpected)
> From schema:
> Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> ...
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 79
> +++++++++++----------
> arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 71 +++++++++---------
> 2 files changed, 76 insertions(+), 74 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
> b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
> index d552044c5afc..aa5152ca8120 100644
> --- a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
> @@ -367,45 +367,46 @@ tmu: tmu@f0000 {
> reg = <0xf0000 0x1000>;
> interrupts = <18 2 0 0>;
> fsl,tmu-range = <0xb0000 0xa0026 0x80048 0x30061>;
> - fsl,tmu-calibration = <0x00000000 0x0000000f
> - 0x00000001 0x00000017
> - 0x00000002 0x0000001e
> - 0x00000003 0x00000026
> - 0x00000004 0x0000002e
> - 0x00000005 0x00000035
> - 0x00000006 0x0000003d
> - 0x00000007 0x00000044
> - 0x00000008 0x0000004c
> - 0x00000009 0x00000053
> - 0x0000000a 0x0000005b
> - 0x0000000b 0x00000064
> -
> - 0x00010000 0x00000011
> - 0x00010001 0x0000001c
> - 0x00010002 0x00000024
> - 0x00010003 0x0000002b
> - 0x00010004 0x00000034
> - 0x00010005 0x00000039
> - 0x00010006 0x00000042
> - 0x00010007 0x0000004c
> - 0x00010008 0x00000051
> - 0x00010009 0x0000005a
> - 0x0001000a 0x00000063
> -
> - 0x00020000 0x00000013
> - 0x00020001 0x00000019
> - 0x00020002 0x00000024
> - 0x00020003 0x0000002c
> - 0x00020004 0x00000035
> - 0x00020005 0x0000003d
> - 0x00020006 0x00000046
> - 0x00020007 0x00000050
> - 0x00020008 0x00000059
> -
> - 0x00030000 0x00000002
> - 0x00030001 0x0000000d
> - 0x00030002 0x00000019
> - 0x00030003 0x00000024>;
> + fsl,tmu-calibration =
> + <0x00000000 0x0000000f>,
> + <0x00000001 0x00000017>,
> + <0x00000002 0x0000001e>,
> + <0x00000003 0x00000026>,
> + <0x00000004 0x0000002e>,
> + <0x00000005 0x00000035>,
> + <0x00000006 0x0000003d>,
> + <0x00000007 0x00000044>,
> + <0x00000008 0x0000004c>,
> + <0x00000009 0x00000053>,
> + <0x0000000a 0x0000005b>,
> + <0x0000000b 0x00000064>,
> +
> + <0x00010000 0x00000011>,
> + <0x00010001 0x0000001c>,
> + <0x00010002 0x00000024>,
> + <0x00010003 0x0000002b>,
> + <0x00010004 0x00000034>,
> + <0x00010005 0x00000039>,
> + <0x00010006 0x00000042>,
> + <0x00010007 0x0000004c>,
> + <0x00010008 0x00000051>,
> + <0x00010009 0x0000005a>,
> + <0x0001000a 0x00000063>,
> +
> + <0x00020000 0x00000013>,
> + <0x00020001 0x00000019>,
> + <0x00020002 0x00000024>,
> + <0x00020003 0x0000002c>,
> + <0x00020004 0x00000035>,
> + <0x00020005 0x0000003d>,
> + <0x00020006 0x00000046>,
> + <0x00020007 0x00000050>,
> + <0x00020008 0x00000059>,
> +
> + <0x00030000 0x00000002>,
> + <0x00030001 0x0000000d>,
> + <0x00030002 0x00000019>,
> + <0x00030003 0x00000024>;
> #thermal-sensor-cells = <1>;
> };
>
> diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> index f58eb820eb5e..27e6985d8bde 100644
> --- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> @@ -447,41 +447,42 @@ tmu: tmu@f0000 {
> reg = <0xf0000 0x1000>;
> interrupts = <18 2 0 0>;
> fsl,tmu-range = <0xa0000 0x90026 0x8004a 0x1006a>;
> - fsl,tmu-calibration = <0x00000000 0x00000025
> - 0x00000001 0x00000028
> - 0x00000002 0x0000002d
> - 0x00000003 0x00000031
> - 0x00000004 0x00000036
> - 0x00000005 0x0000003a
> - 0x00000006 0x00000040
> - 0x00000007 0x00000044
> - 0x00000008 0x0000004a
> - 0x00000009 0x0000004f
> - 0x0000000a 0x00000054
> -
> - 0x00010000 0x0000000d
> - 0x00010001 0x00000013
> - 0x00010002 0x00000019
> - 0x00010003 0x0000001f
> - 0x00010004 0x00000025
> - 0x00010005 0x0000002d
> - 0x00010006 0x00000033
> - 0x00010007 0x00000043
> - 0x00010008 0x0000004b
> - 0x00010009 0x00000053
> -
> - 0x00020000 0x00000010
> - 0x00020001 0x00000017
> - 0x00020002 0x0000001f
> - 0x00020003 0x00000029
> - 0x00020004 0x00000031
> - 0x00020005 0x0000003c
> - 0x00020006 0x00000042
> - 0x00020007 0x0000004d
> - 0x00020008 0x00000056
> -
> - 0x00030000 0x00000012
> - 0x00030001 0x0000001d>;
> + fsl,tmu-calibration =
> + <0x00000000 0x00000025>,
> + <0x00000001 0x00000028>,
> + <0x00000002 0x0000002d>,
> + <0x00000003 0x00000031>,
> + <0x00000004 0x00000036>,
> + <0x00000005 0x0000003a>,
> + <0x00000006 0x00000040>,
> + <0x00000007 0x00000044>,
> + <0x00000008 0x0000004a>,
> + <0x00000009 0x0000004f>,
> + <0x0000000a 0x00000054>,
> +
> + <0x00010000 0x0000000d>,
> + <0x00010001 0x00000013>,
> + <0x00010002 0x00000019>,
> + <0x00010003 0x0000001f>,
> + <0x00010004 0x00000025>,
> + <0x00010005 0x0000002d>,
> + <0x00010006 0x00000033>,
> + <0x00010007 0x00000043>,
> + <0x00010008 0x0000004b>,
> + <0x00010009 0x00000053>,
> +
> + <0x00020000 0x00000010>,
> + <0x00020001 0x00000017>,
> + <0x00020002 0x0000001f>,
> + <0x00020003 0x00000029>,
> + <0x00020004 0x00000031>,
> + <0x00020005 0x0000003c>,
> + <0x00020006 0x00000042>,
> + <0x00020007 0x0000004d>,
> + <0x00020008 0x00000056>,
> +
> + <0x00030000 0x00000012>,
> + <0x00030001 0x0000001d>;
> #thermal-sensor-cells = <1>;
> };
>
> --
> 2.33.0
>
^ permalink raw reply
* Re: Please backport b6b0d883bbb8 to v5.10
From: Greg Kroah-Hartman @ 2022-01-18 15:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, stable
In-Reply-To: <87lezd1ado.fsf@mpe.ellerman.id.au>
On Tue, Jan 18, 2022 at 11:44:35PM +1100, Michael Ellerman wrote:
> Hi Greg,
>
> Could you please backport:
>
> b6b0d883bbb8 ("powerpc/pseries: Get entry and uaccess flush required bits from H_GET_CPU_CHARACTERISTICS")
Do you really mean:
65c7d070850e ("powerpc/pseries: Get entry and uaccess flush required bits from H_GET_CPU_CHARACTERISTICS")
instead?
I can not find b6b0d883bbb8 in Linus's tree :(
> to the v5.10 stable kernel. Thanks.
Assuming the above is the correct id, I have backported that to 5.10
now, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/5] dt-bindings: tlv320aic31xx: Define PLL clock inputs
From: Mark Brown @ 2022-01-18 17:22 UTC (permalink / raw)
To: Ariel D'Alessandro
Cc: devicetree, alsa-devel, michael, kuninori.morimoto.gx, Xiubo.Lee,
tony, festevam, shengjiu.wang, tiwai, linux-kernel, lgirdwood,
nicoleotsuka, robh+dt, bcousson, perex, linux-omap, linuxppc-dev
In-Reply-To: <20220117132109.283365-3-ariel.dalessandro@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
On Mon, Jan 17, 2022 at 10:21:06AM -0300, Ariel D'Alessandro wrote:
> Add constants for the different PLL clock inputs in tlv320aic31xx.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
From: Dave Hansen @ 2022-01-18 17:28 UTC (permalink / raw)
To: Nicholas Piggin, Andrew Morton, Jonathan Corbet, linux-arm-kernel,
linux-doc, linux-kernel, linux-mm, linuxppc-dev, Kefeng Wang, x86
Cc: Matthew Wilcox, Catalin Marinas, Dave Hansen, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Paul Mackerras, Thomas Gleixner,
Will Deacon
In-Reply-To: <1642472965.lgfksp6krp.astroid@bobo.none>
On 1/17/22 6:46 PM, Nicholas Piggin wrote:
>> This all sounds very fragile to me. Every time a new architecture would
>> get added for huge vmalloc() support, the developer needs to know to go
>> find that architecture's module_alloc() and add this flag.
> This is documented in the Kconfig.
>
> #
> # Archs that select this would be capable of PMD-sized vmaps (i.e.,
> # arch_vmap_pmd_supported() returns true), and they must make no assumptions
> # that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag
> # can be used to prohibit arch-specific allocations from using hugepages to
> # help with this (e.g., modules may require it).
> #
> config HAVE_ARCH_HUGE_VMALLOC
> depends on HAVE_ARCH_HUGE_VMAP
> bool
>
> Is it really fair to say it's *very* fragile? Surely it's reasonable to
> read the (not very long) documentation ad understand the consequences for
> the arch code before enabling it.
Very fragile or not, I think folks are likely to get it wrong. It would
be nice to have it default *everyone* to safe and slow and make *sure*
they go look at the architecture modules code itself before enabling
this for modules.
Just from that Kconfig text, I don't think I'd know off the top of my
head what do do for x86, or what code I needed to go touch.
^ permalink raw reply
* Re: [PATCH v3] powerpc/papr_scm: Implement initial support for injecting smart errors
From: Ira Weiny @ 2022-01-18 17:59 UTC (permalink / raw)
To: Vaibhav Jain
Cc: nvdimm, Shivaprasad G Bhat, Aneesh Kumar K . V, Dan Williams,
linuxppc-dev
In-Reply-To: <20220113120252.1145671-1-vaibhav@linux.ibm.com>
On Thu, Jan 13, 2022 at 05:32:52PM +0530, Vaibhav Jain wrote:
[snip]
>
> +/* Inject a smart error Add the dirty-shutdown-counter value to the pdsm */
> +static int papr_pdsm_smart_inject(struct papr_scm_priv *p,
> + union nd_pdsm_payload *payload)
> +{
> + int rc;
> + u32 supported_flags = 0;
> + u64 mask = 0, override = 0;
> +
> + /* Check for individual smart error flags and update mask and override */
> + if (payload->smart_inject.flags & PDSM_SMART_INJECT_HEALTH_FATAL) {
> + supported_flags |= PDSM_SMART_INJECT_HEALTH_FATAL;
> + mask |= PAPR_PMEM_HEALTH_FATAL;
> + override |= payload->smart_inject.fatal_enable ?
> + PAPR_PMEM_HEALTH_FATAL : 0;
> + }
> +
> + if (payload->smart_inject.flags & PDSM_SMART_INJECT_BAD_SHUTDOWN) {
> + supported_flags |= PDSM_SMART_INJECT_BAD_SHUTDOWN;
> + mask |= PAPR_PMEM_SHUTDOWN_DIRTY;
> + override |= payload->smart_inject.unsafe_shutdown_enable ?
> + PAPR_PMEM_SHUTDOWN_DIRTY : 0;
> + }
> +
I'm struggling to see why there is a need for both a flag and an 8 bit 'enable'
value?
Ira
^ permalink raw reply
* Re: [PATCH net 1/4] net/fsl: xgmac_mdio: Add workaround for erratum A-009885
From: Jakub Kicinski @ 2022-01-18 20:34 UTC (permalink / raw)
To: Andrew Lunn
Cc: devicetree, madalin.bucur, robh+dt, paulus, netdev, linuxppc-dev,
davem, Tobias Waldekranz
In-Reply-To: <YeV2idN2wPzrHI0n@lunn.ch>
On Mon, 17 Jan 2022 15:00:41 +0100 Andrew Lunn wrote:
> > Should I send a v2 even if nothing else
> > pops up, or is this more of a if-you're-sending-a-v2-anyway type of
> > comment?
>
> If you reply with a Fixes: patchwork will automagically append it like
> it does Reviewed-by, Tested-by etc.
That part is pretty finicky, it's supposed to work but when I apply
these I only get review tags from Andrew and a Fixes tag already
present on the last patch :(
A v2 with Fixes tags included in the posting would be best after all.
Thanks!
^ permalink raw reply
* [PATCH v2 net 3/4] powerpc/fsl/dts: Enable WA for erratum A-009885 on fman3l MDIO buses
From: Tobias Waldekranz @ 2022-01-18 21:50 UTC (permalink / raw)
To: davem, kuba
Cc: devicetree, netdev, Shruti Kanetkar, linux-kernel, Emil Medve,
Igal Liberman, Rob Herring, Paul Mackerras, Scott Wood,
linuxppc-dev
In-Reply-To: <20220118215054.2629314-1-tobias@waldekranz.com>
This block is used in (at least) T1024 and T1040, including their
variants like T1023 etc.
Fixes: d55ad2967d89 ("powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan")
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi
index c90702b04a53..48e5cd61599c 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi
@@ -79,6 +79,7 @@ mdio0: mdio@fc000 {
#size-cells = <0>;
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xfc000 0x1000>;
+ fsl,erratum-a009885;
};
xmdio0: mdio@fd000 {
@@ -86,6 +87,7 @@ xmdio0: mdio@fd000 {
#size-cells = <0>;
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xfd000 0x1000>;
+ fsl,erratum-a009885;
};
};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] powerpc: Fix virt_addr_valid() check
From: Kefeng Wang @ 2022-01-19 1:15 UTC (permalink / raw)
To: Christophe Leroy, Nicholas Piggin, Andrew Morton,
Benjamin Herrenschmidt, Kees Cook, Laura Abbott,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org, Mark Rutland, Michael Ellerman,
Paul Mackerras
In-Reply-To: <ca351bfc-3507-11ad-73f1-79ca772b55fd@csgroup.eu>
On 2022/1/11 14:04, Christophe Leroy wrote:
>
> Le 11/01/2022 à 05:37, Nicholas Piggin a écrit :
>> Excerpts from Kefeng Wang's message of January 8, 2022 9:58 pm:
>>> Hi PPC maintainers， ping..
>> Hmm. I might have confused myself about this. I'm going back and
>> trying to work out what I was thinking when I suggested it. This
>> works on 64e because vmalloc space is below the kernel linear map,
>> right?
>>
>> On 64s it is the other way around and it is still possible to enable
>> flatmem on 64s. Altough we might just not hit the problem there because
>> __pa() will not mask away the vmalloc offset for 64s so it will still
>> return something that's outside the pfn_valid range for flatmem. That's
>> very subtle though.
> That's the way it works on PPC32 at least, so for me it's not chocking
> to have it work the same way on PPC64s.
>
> The main issue here is the way __pa() works. On PPC32 __pa = va -
> PAGE_OFFSET, so it works correctly for any address.
> On PPC64, __pa() works by masking out the 2 top bits instead of
> substracting PAGE_OFFSET, so the test must add a verification that we
> really have the 2 top bits set at first. This is what (addr >=
> PAGE_OFFSET) does. Once this first test is done, we can perfectly rely
> on pfn_valid() just like PPC32, I see absolutely no point in an
> additionnal test checking the addr is below KERN_VIRT_START.
Hi Christophe and Nicholas， for ppc32， I think we need check the upper
limit,
eg, addr >= PAGE_OFFSET && addr < high_memory
arch/powerpc/mm/mem.c: high_memory = (void *) __va(max_low_pfn *
PAGE_SIZE);
for ppc32 max_low_pfn is the upper low memory pfn, and For ppc64,
high_memory is
the max memory pfn, it looks good too, correct me if I'm wrong, if the
above check
is ok, I will send a new v3, thanks.
>
>
>> The checks added to __pa actually don't prevent vmalloc memory from
>> being passed to it either on 64s, only a more basic test.
> That's correct. It is the role of pfn_valid() to check that.
>
> Christophe
>
>> I think 64s wants (addr >= PAGE_OFFSET && addr < KERN_VIRT_START) as
>> the condition. Could possibly add that check to __pa as well to
>> catch vmalloc addresses.
>>
>> Thanks,
>> Nick
>>
>>
^ permalink raw reply
* [PATCH] powerpc/process, kasan: Silence KASAN warnings in __get_wchan()
From: He Ying @ 2022-01-19 1:50 UTC (permalink / raw)
To: catalin.marinas, mpe, benh, paulus, npiggin, christophe.leroy,
sxwjean, peterz, keescook
Cc: linuxppc-dev, linux-kernel, heying24
The following KASAN warning was reported in our kernel.
BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
Read of size 4 at addr d216f958 by task ps/14437
CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
Call Trace:
[daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
[daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
[daa63908] [c035d6bc] kasan_report+0x1ac/0x218
[daa63948] [c00496e8] get_wchan+0x188/0x250
[daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
[daa63b98] [c0455ac8] proc_single_show+0x98/0x170
[daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
[daa63c38] [c03cb47c] seq_read+0x1dc/0x290
[daa63d68] [c037fc94] vfs_read+0x164/0x510
[daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
[daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
--- interrupt: c00 at 0x8fa8f4
LR = 0x8fa8cc
The buggy address belongs to the page:
page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
flags: 0x0()
raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
raw: 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
^
d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
After looking into this issue, I find the buggy address belongs
to the task stack region. It seems KASAN has something wrong.
I look into the code of __get_wchan in x86 architecture and
find the same issue has been resolved by the commit
f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to powerpc architecture too.
As Andrey Ryabinin said, get_wchan() is racy by design, it may
access volatile stack of running task, thus it may access
redzone in a stack frame and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Signed-off-by: He Ying <heying24@huawei.com>
---
arch/powerpc/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 984813a4d5dc..a75d20f23dac 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2160,12 +2160,12 @@ static unsigned long ___get_wchan(struct task_struct *p)
return 0;
do {
- sp = *(unsigned long *)sp;
+ sp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD) ||
task_is_running(p))
return 0;
if (count > 0) {
- ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
+ ip = READ_ONCE_NOCHECK(((unsigned long *)sp)[STACK_FRAME_LR_SAVE]);
if (!in_sched_functions(ip))
return ip;
}
--
2.17.1
^ permalink raw reply related
* [powerpc:fixes-test] BUILD SUCCESS aee101d7b95a03078945681dd7f7ea5e4a1e7686
From: kernel test robot @ 2022-01-19 2:56 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: aee101d7b95a03078945681dd7f7ea5e4a1e7686 powerpc/64s: Mask SRR0 before checking against the masked NIP
elapsed time: 725m
configs tested: 147
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20220117
mips randconfig-c004-20220117
sh defconfig
mips ar7_defconfig
sh ecovec24-romimage_defconfig
powerpc asp8347_defconfig
powerpc mpc834x_mds_defconfig
sh se7721_defconfig
m68k atari_defconfig
mips decstation_64_defconfig
sh sdk7786_defconfig
arm footbridge_defconfig
powerpc iss476-smp_defconfig
mips bcm47xx_defconfig
sh shmin_defconfig
h8300 h8300h-sim_defconfig
sh rsk7201_defconfig
arm cm_x300_defconfig
sh polaris_defconfig
openrisc or1klitex_defconfig
powerpc ep88xc_defconfig
powerpc rainier_defconfig
powerpc currituck_defconfig
arm qcom_defconfig
arm hisi_defconfig
riscv defconfig
m68k m5475evb_defconfig
sh secureedge5410_defconfig
sparc sparc32_defconfig
s390 defconfig
sh rts7751r2d1_defconfig
arm vf610m4_defconfig
alpha allyesconfig
arm imx_v6_v7_defconfig
arm tegra_defconfig
xtensa smp_lx200_defconfig
csky defconfig
powerpc allnoconfig
powerpc eiger_defconfig
sh magicpanelr2_defconfig
arm randconfig-c002-20220116
arm randconfig-c002-20220117
arm randconfig-c002-20220118
arm randconfig-c002-20220119
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
alpha defconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a016-20220117
x86_64 randconfig-a012-20220117
x86_64 randconfig-a013-20220117
x86_64 randconfig-a011-20220117
x86_64 randconfig-a014-20220117
x86_64 randconfig-a015-20220117
i386 randconfig-a012-20220117
i386 randconfig-a016-20220117
i386 randconfig-a014-20220117
i386 randconfig-a015-20220117
i386 randconfig-a011-20220117
i386 randconfig-a013-20220117
riscv randconfig-r042-20220117
arc randconfig-r043-20220116
arc randconfig-r043-20220117
s390 randconfig-r044-20220117
arc randconfig-r043-20220118
riscv randconfig-r042-20220119
s390 randconfig-r044-20220119
arc randconfig-r043-20220119
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
arm randconfig-c002-20220116
x86_64 randconfig-c007
arm randconfig-c002-20220118
riscv randconfig-c006-20220116
powerpc randconfig-c003-20220116
powerpc randconfig-c003-20220118
i386 randconfig-c001
s390 randconfig-c005-20220118
mips randconfig-c004-20220118
mips randconfig-c004-20220116
s390 randconfig-c005-20220116
riscv randconfig-c006-20220118
powerpc kilauea_defconfig
i386 allyesconfig
powerpc mpc834x_itxgp_defconfig
powerpc mpc5200_defconfig
arm lpc32xx_defconfig
mips pic32mzda_defconfig
mips omega2p_defconfig
mips bcm63xx_defconfig
x86_64 randconfig-a005-20220117
x86_64 randconfig-a004-20220117
x86_64 randconfig-a001-20220117
x86_64 randconfig-a006-20220117
x86_64 randconfig-a002-20220117
x86_64 randconfig-a003-20220117
i386 randconfig-a005-20220117
i386 randconfig-a001-20220117
i386 randconfig-a006-20220117
i386 randconfig-a004-20220117
i386 randconfig-a002-20220117
i386 randconfig-a003-20220117
i386 randconfig-a002
i386 randconfig-a006
i386 randconfig-a004
i386 randconfig-a011
i386 randconfig-a013
i386 randconfig-a015
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 00/16] Remove usage of the deprecated "pci-dma-compat.h" API
From: Martin K. Petersen @ 2022-01-19 4:06 UTC (permalink / raw)
To: sreekanth.reddy, mchehab, mdf, mpe, mporter, hch, bhelgaas,
airlied, Christophe JAILLET, benh, ink, davem, akpm, hao.wu,
vkoul, sathya.prakash, paulus, trix, arnd, yilun.xu,
suganath-prabu.subramani, alex.bou9, awalls, rth, mattst88
Cc: kernel-janitors, linux-scsi, Martin K . Petersen, linuxppc-dev,
linux-fpga, linux-pci, linux-kernel, dmaengine, linux-alpha,
sparclinux, MPT-FusionLinux.pdl, linux-media
In-Reply-To: <cover.1641500561.git.christophe.jaillet@wanadoo.fr>
On Thu, 6 Jan 2022 22:45:13 +0100, Christophe JAILLET wrote:
> This serie axes all the remaining usages of the deprecated "pci-dma-compat.h"
> API.
>
> All these patches have already been posted.
>
> They have been generated with a coccinelle script.
> The tricky parts are patches that use dma_alloc_coherent() because the correct
> GFP flag has to be used in place of the previous embedded GFP_ATOMIC.
>
> [...]
Applied to 5.17/scsi-queue, thanks!
[10/16] scsi: message: fusion: Remove usage of the deprecated "pci-dma-compat.h" API
https://git.kernel.org/mkp/scsi/c/b114dda6f2f1
[11/16] scsi: mptbase: Use dma_alloc_coherent() in 'mpt_alloc_fw_memory()'
https://git.kernel.org/mkp/scsi/c/2d50607260a6
[12/16] scsi: mptbase: Use dma_alloc_coherent()
https://git.kernel.org/mkp/scsi/c/5c5e6b6f61e0
[13/16] scsi: mptsas: Use dma_alloc_coherent() in mptsas_exp_repmanufacture_info()
https://git.kernel.org/mkp/scsi/c/7a960b3a5e37
[14/16] scsi: mptsas: Use dma_alloc_coherent()
https://git.kernel.org/mkp/scsi/c/76a334d756c5
[15/16] scsi: mptctl: Use dma_alloc_coherent()
https://git.kernel.org/mkp/scsi/c/706dc3b91989
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
From: Nicholas Piggin @ 2022-01-19 4:17 UTC (permalink / raw)
To: Andrew Morton, Jonathan Corbet, Dave Hansen, linux-arm-kernel,
linux-doc, linux-kernel, linux-mm, linuxppc-dev, Kefeng Wang, x86
Cc: Matthew Wilcox, Catalin Marinas, Dave Hansen, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Paul Mackerras, Thomas Gleixner,
Will Deacon
In-Reply-To: <4488d39f-0698-7bfd-b81c-1e609821818f@intel.com>
Excerpts from Dave Hansen's message of January 19, 2022 3:28 am:
> On 1/17/22 6:46 PM, Nicholas Piggin wrote:
>>> This all sounds very fragile to me. Every time a new architecture would
>>> get added for huge vmalloc() support, the developer needs to know to go
>>> find that architecture's module_alloc() and add this flag.
>> This is documented in the Kconfig.
>>
>> #
>> # Archs that select this would be capable of PMD-sized vmaps (i.e.,
>> # arch_vmap_pmd_supported() returns true), and they must make no assumptions
>> # that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag
>> # can be used to prohibit arch-specific allocations from using hugepages to
>> # help with this (e.g., modules may require it).
>> #
>> config HAVE_ARCH_HUGE_VMALLOC
>> depends on HAVE_ARCH_HUGE_VMAP
>> bool
>>
>> Is it really fair to say it's *very* fragile? Surely it's reasonable to
>> read the (not very long) documentation ad understand the consequences for
>> the arch code before enabling it.
>
> Very fragile or not, I think folks are likely to get it wrong. It would
> be nice to have it default *everyone* to safe and slow and make *sure*
It's not safe to enable though. That's the problem. If it was just
modules then you'd have a point but it could be anything.
> they go look at the architecture modules code itself before enabling
> this for modules.
This is required not just for modules for the whole arch code, it
has to be looked at and decided this will work.
> Just from that Kconfig text, I don't think I'd know off the top of my
> head what do do for x86, or what code I needed to go touch.
You have to make sure arch/x86 makes no assumptions that vmalloc memory
is backed by PAGE_SIZE ptes. If you can't do that then you shouldn't
enable the option. The option can not explain it any more because any
arch could do anything with its mappings. The module code is an example,
not the recipe.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix power_pmu_disable to call clear_pmi_irq_pending only if PMI is pending
From: Nicholas Piggin @ 2022-01-19 4:24 UTC (permalink / raw)
To: Athira Rajeev, mpe; +Cc: kjain, maddy, linuxppc-dev, rnsastry
In-Reply-To: <20220115072020.93524-1-atrajeev@linux.vnet.ibm.com>
Excerpts from Athira Rajeev's message of January 15, 2022 5:20 pm:
> Running selftest with CONFIG_PPC_IRQ_SOFT_MASK_DEBUG enabled in kernel
> triggered below warning:
>
> [ 172.851380] ------------[ cut here ]------------
> [ 172.851391] WARNING: CPU: 8 PID: 2901 at arch/powerpc/include/asm/hw_irq.h:246 power_pmu_disable+0x270/0x280
> [ 172.851402] Modules linked in: dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink sunrpc xfs libcrc32c pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse
> [ 172.851442] CPU: 8 PID: 2901 Comm: lost_exception_ Not tainted 5.16.0-rc5-03218-g798527287598 #2
> [ 172.851451] NIP: c00000000013d600 LR: c00000000013d5a4 CTR: c00000000013b180
> [ 172.851458] REGS: c000000017687860 TRAP: 0700 Not tainted (5.16.0-rc5-03218-g798527287598)
> [ 172.851465] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 48004884 XER: 20040000
> [ 172.851482] CFAR: c00000000013d5b4 IRQMASK: 1
> [ 172.851482] GPR00: c00000000013d5a4 c000000017687b00 c000000002a10600 0000000000000004
> [ 172.851482] GPR04: 0000000082004000 c0000008ba08f0a8 0000000000000000 00000008b7ed0000
> [ 172.851482] GPR08: 00000000446194f6 0000000000008000 c00000000013b118 c000000000d58e68
> [ 172.851482] GPR12: c00000000013d390 c00000001ec54a80 0000000000000000 0000000000000000
> [ 172.851482] GPR16: 0000000000000000 0000000000000000 c000000015d5c708 c0000000025396d0
> [ 172.851482] GPR20: 0000000000000000 0000000000000000 c00000000a3bbf40 0000000000000003
> [ 172.851482] GPR24: 0000000000000000 c0000008ba097400 c0000000161e0d00 c00000000a3bb600
> [ 172.851482] GPR28: c000000015d5c700 0000000000000001 0000000082384090 c0000008ba0020d8
> [ 172.851549] NIP [c00000000013d600] power_pmu_disable+0x270/0x280
> [ 172.851557] LR [c00000000013d5a4] power_pmu_disable+0x214/0x280
> [ 172.851565] Call Trace:
> [ 172.851568] [c000000017687b00] [c00000000013d5a4] power_pmu_disable+0x214/0x280 (unreliable)
> [ 172.851579] [c000000017687b40] [c0000000003403ac] perf_pmu_disable+0x4c/0x60
> [ 172.851588] [c000000017687b60] [c0000000003445e4] __perf_event_task_sched_out+0x1d4/0x660
> [ 172.851596] [c000000017687c50] [c000000000d1175c] __schedule+0xbcc/0x12a0
> [ 172.851602] [c000000017687d60] [c000000000d11ea8] schedule+0x78/0x140
> [ 172.851608] [c000000017687d90] [c0000000001a8080] sys_sched_yield+0x20/0x40
> [ 172.851615] [c000000017687db0] [c0000000000334dc] system_call_exception+0x18c/0x380
> [ 172.851622] [c000000017687e10] [c00000000000c74c] system_call_common+0xec/0x268
>
> The warning indicates that MSR_EE being set(interrupt enabled) when
> there was an overflown PMC detected. This could happen in
> power_pmu_disable since it runs under interrupt soft disable
> condition ( local_irq_save ) and not with interrupts hard disabled.
> commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear
> pending PMI before resetting an overflown PMC") intended to clear
> PMI pending bit in Paca when disabling the PMU. It could happen
> that PMC gets overflown while code is in power_pmu_disable
> callback function. Hence add a check to see if PMI pending bit
> is set in Paca before clearing it via clear_pmi_pending.
>
> Fixes: 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC")
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> Reported-by: Sachin Sant <sachinp@linux.ibm.com>
> Tested-by: Sachin Sant <sachinp@linux.ibm.com>
> ---
> Note: Address the warning reported here:
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-December/238190.html
> Patch is on top of powerpc/merge
>
> arch/powerpc/perf/core-book3s.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index a684901b6965..dfb0ea0f0df3 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -1327,9 +1327,10 @@ static void power_pmu_disable(struct pmu *pmu)
> * Otherwise provide a warning if there is PMI pending, but
> * no counter is found overflown.
> */
> - if (any_pmc_overflown(cpuhw))
> - clear_pmi_irq_pending();
> - else
> + if (any_pmc_overflown(cpuhw)) {
> + if (pmi_irq_pending())
> + clear_pmi_irq_pending();
And this works because MSR[EE] gets disabled by the masked interrupt
handler if we have a PMI irq pending, is that right?
Can I be a pain and just ask for a little comment there otherwise I'll
forget about it next time.
Thanks,
Nick
> + } else
> WARN_ON(pmi_irq_pending());
>
> val = mmcra = cpuhw->mmcr.mmcra;
> --
> 2.33.0
>
>
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix power_pmu_disable to call clear_pmi_irq_pending only if PMI is pending
From: Athira Rajeev @ 2022-01-19 6:47 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: maddy, linuxppc-dev, rnsastry, kajoljain
In-Reply-To: <1642566179.l0008zwdzw.astroid@bobo.none>
> On 19-Jan-2022, at 9:54 AM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Excerpts from Athira Rajeev's message of January 15, 2022 5:20 pm:
>> Running selftest with CONFIG_PPC_IRQ_SOFT_MASK_DEBUG enabled in kernel
>> triggered below warning:
>>
>> [ 172.851380] ------------[ cut here ]------------
>> [ 172.851391] WARNING: CPU: 8 PID: 2901 at arch/powerpc/include/asm/hw_irq.h:246 power_pmu_disable+0x270/0x280
>> [ 172.851402] Modules linked in: dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink sunrpc xfs libcrc32c pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse
>> [ 172.851442] CPU: 8 PID: 2901 Comm: lost_exception_ Not tainted 5.16.0-rc5-03218-g798527287598 #2
>> [ 172.851451] NIP: c00000000013d600 LR: c00000000013d5a4 CTR: c00000000013b180
>> [ 172.851458] REGS: c000000017687860 TRAP: 0700 Not tainted (5.16.0-rc5-03218-g798527287598)
>> [ 172.851465] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 48004884 XER: 20040000
>> [ 172.851482] CFAR: c00000000013d5b4 IRQMASK: 1
>> [ 172.851482] GPR00: c00000000013d5a4 c000000017687b00 c000000002a10600 0000000000000004
>> [ 172.851482] GPR04: 0000000082004000 c0000008ba08f0a8 0000000000000000 00000008b7ed0000
>> [ 172.851482] GPR08: 00000000446194f6 0000000000008000 c00000000013b118 c000000000d58e68
>> [ 172.851482] GPR12: c00000000013d390 c00000001ec54a80 0000000000000000 0000000000000000
>> [ 172.851482] GPR16: 0000000000000000 0000000000000000 c000000015d5c708 c0000000025396d0
>> [ 172.851482] GPR20: 0000000000000000 0000000000000000 c00000000a3bbf40 0000000000000003
>> [ 172.851482] GPR24: 0000000000000000 c0000008ba097400 c0000000161e0d00 c00000000a3bb600
>> [ 172.851482] GPR28: c000000015d5c700 0000000000000001 0000000082384090 c0000008ba0020d8
>> [ 172.851549] NIP [c00000000013d600] power_pmu_disable+0x270/0x280
>> [ 172.851557] LR [c00000000013d5a4] power_pmu_disable+0x214/0x280
>> [ 172.851565] Call Trace:
>> [ 172.851568] [c000000017687b00] [c00000000013d5a4] power_pmu_disable+0x214/0x280 (unreliable)
>> [ 172.851579] [c000000017687b40] [c0000000003403ac] perf_pmu_disable+0x4c/0x60
>> [ 172.851588] [c000000017687b60] [c0000000003445e4] __perf_event_task_sched_out+0x1d4/0x660
>> [ 172.851596] [c000000017687c50] [c000000000d1175c] __schedule+0xbcc/0x12a0
>> [ 172.851602] [c000000017687d60] [c000000000d11ea8] schedule+0x78/0x140
>> [ 172.851608] [c000000017687d90] [c0000000001a8080] sys_sched_yield+0x20/0x40
>> [ 172.851615] [c000000017687db0] [c0000000000334dc] system_call_exception+0x18c/0x380
>> [ 172.851622] [c000000017687e10] [c00000000000c74c] system_call_common+0xec/0x268
>>
>> The warning indicates that MSR_EE being set(interrupt enabled) when
>> there was an overflown PMC detected. This could happen in
>> power_pmu_disable since it runs under interrupt soft disable
>> condition ( local_irq_save ) and not with interrupts hard disabled.
>> commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear
>> pending PMI before resetting an overflown PMC") intended to clear
>> PMI pending bit in Paca when disabling the PMU. It could happen
>> that PMC gets overflown while code is in power_pmu_disable
>> callback function. Hence add a check to see if PMI pending bit
>> is set in Paca before clearing it via clear_pmi_pending.
>>
>> Fixes: 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC")
>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>> Reported-by: Sachin Sant <sachinp@linux.ibm.com>
>> Tested-by: Sachin Sant <sachinp@linux.ibm.com>
>> ---
>> Note: Address the warning reported here:
>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-December/238190.html
>> Patch is on top of powerpc/merge
>>
>> arch/powerpc/perf/core-book3s.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>> index a684901b6965..dfb0ea0f0df3 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -1327,9 +1327,10 @@ static void power_pmu_disable(struct pmu *pmu)
>> * Otherwise provide a warning if there is PMI pending, but
>> * no counter is found overflown.
>> */
>> - if (any_pmc_overflown(cpuhw))
>> - clear_pmi_irq_pending();
>> - else
>> + if (any_pmc_overflown(cpuhw)) {
>> + if (pmi_irq_pending())
>> + clear_pmi_irq_pending();
>
> And this works because MSR[EE] gets disabled by the masked interrupt
> handler if we have a PMI irq pending, is that right?
>
> Can I be a pain and just ask for a little comment there otherwise I'll
> forget about it next time.
Hi Nick,
Thanks for the review. Yes that’s right, if there is a PMI pending, MSR[EE] will be disabled by the handler.
I will add that in comment.
Thanks
Athira
>
> Thanks,
> Nick
>
>> + } else
>> WARN_ON(pmi_irq_pending());
>>
>> val = mmcra = cpuhw->mmcr.mmcra;
>> --
>> 2.33.0
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix task context setting for trace imc
From: Michael Ellerman @ 2022-01-19 10:56 UTC (permalink / raw)
To: Athira Rajeev; +Cc: kjain, maddy, linuxppc-dev, rnsastry
In-Reply-To: <20211124024600.18509-1-atrajeev@linux.vnet.ibm.com>
Athira Rajeev <atrajeev@linux.vnet.ibm.com> writes:
> Trace IMC (In-Memory collection counters) in powerpc is
> useful for application level profiling. For trace_imc,
> presently task context (task_ctx_nr) is set to
> perf_hw_context. But perf_hw_context is to be used for
> cpu PMU. So for trace_imc, even though it is per thread
> PMU, it is preferred to use sw_context inorder to be able
> to do application level monitoring. Hence change the
> task_ctx_nr to use perf_sw_context.
It's not a software event though, so this is not obviously correct.
Can you explain more why this is OK, I guess perf_sw_context is misnamed
these days? And can you add a comment in the code explaining why this
hardware PMU is using perf_sw_context.
cheers
> Fixes: 012ae244845f ("powerpc/perf: Trace imc PMU functions")
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/imc-pmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index e106909ff9c3..f3b3262bdf02 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -1457,7 +1457,7 @@ static int trace_imc_event_init(struct perf_event *event)
>
> event->hw.idx = -1;
>
> - event->pmu->task_ctx_nr = perf_hw_context;
> + event->pmu->task_ctx_nr = perf_sw_context;
> event->destroy = reset_global_refc;
> return 0;
> }
> --
> 2.33.0
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix power_pmu_wants_prompt_pmi to be defined only for CONFIG_PPC64
From: Michael Ellerman @ 2022-01-19 11:06 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: kjain, maddy, linuxppc-dev, npiggin, rnsastry
In-Reply-To: <20220114031355.87480-1-atrajeev@linux.vnet.ibm.com>
On Fri, 14 Jan 2022 08:43:55 +0530, Athira Rajeev wrote:
> power_pmu_wants_prompt_pmi is used to decide if PMI should
> be taken prompt. This is valid only for ppc64 and is used
> in CONFIG_PPC_BOOK3S_64 context. Hence include the function
> under config check for PPC64
>
> Fixes warning for 32-bit compilation:
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/perf: Fix power_pmu_wants_prompt_pmi to be defined only for CONFIG_PPC64
https://git.kernel.org/powerpc/c/429a64f6e91fbfe4912d17247c27d0d66767b1c2
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/time: Fix build failure due to do_hard_irq_enable() on PPC32
From: Michael Ellerman @ 2022-01-19 11:06 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel, Nicholas Piggin
In-Reply-To: <247e01e0e10f4dbc59b5ff89e81702eb1ee7641e.1641828571.git.christophe.leroy@csgroup.eu>
On Mon, 10 Jan 2022 15:29:53 +0000, Christophe Leroy wrote:
> CC arch/powerpc/kernel/time.o
> In file included from <command-line>:
> ./arch/powerpc/include/asm/hw_irq.h: In function 'do_hard_irq_enable':
> ././include/linux/compiler_types.h:335:45: error: call to '__compiletime_assert_35' declared with attribute error: BUILD_BUG failed
> 335 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> | ^
> ././include/linux/compiler_types.h:316:25: note: in definition of macro '__compiletime_assert'
> 316 | prefix ## suffix(); \
> | ^~~~~~
> ././include/linux/compiler_types.h:335:9: note: in expansion of macro '_compiletime_assert'
> 335 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> | ^~~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
> 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> | ^~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:59:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
> 59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> | ^~~~~~~~~~~~~~~~
> ./arch/powerpc/include/asm/hw_irq.h:483:9: note: in expansion of macro 'BUILD_BUG'
> 483 | BUILD_BUG();
> | ^~~~~~~~~
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/time: Fix build failure due to do_hard_irq_enable() on PPC32
https://git.kernel.org/powerpc/c/87b9d74fb0be80054c729e8d6a119ca0955cedf3
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox