* Re: [PATCH -next] tty: hvc: fix link error with CONFIG_SERIAL_CORE_CONSOLE=n
From: Greg KH @ 2020-09-19 5:40 UTC (permalink / raw)
To: Yang Yingliang; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <6100a6e7-641f-7e9b-b4a3-3834320d1bb1@huawei.com>
On Sat, Sep 19, 2020 at 10:48:41AM +0800, Yang Yingliang wrote:
>
> On 2020/9/18 19:17, Greg KH wrote:
> > On Fri, Sep 18, 2020 at 05:20:30PM +0800, Yang Yingliang wrote:
> > > Fix the link error by selecting SERIAL_CORE_CONSOLE.
> > >
> > > aarch64-linux-gnu-ld: drivers/tty/hvc/hvc_dcc.o: in function `dcc_early_write':
> > > hvc_dcc.c:(.text+0x164): undefined reference to `uart_console_write'
> > >
> > > Reported-by: Hulk Robot <hulkci@huawei.com>
> > > Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> > > ---
> > > drivers/tty/hvc/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
> > > index d1b27b0522a3..8d60e0ff67b4 100644
> > > --- a/drivers/tty/hvc/Kconfig
> > > +++ b/drivers/tty/hvc/Kconfig
> > > @@ -81,6 +81,7 @@ config HVC_DCC
> > > bool "ARM JTAG DCC console"
> > > depends on ARM || ARM64
> > > select HVC_DRIVER
> > > + select SERIAL_CORE_CONSOLE
> > > help
> > > This console uses the JTAG DCC on ARM to create a console under the HVC
> > > driver. This console is used through a JTAG only on ARM. If you don't have
> > > --
> > > 2.25.1
> > >
> > Same question here, what caused this problem to happen?
> Fixes: d1a1af2cdf19 ("hvc: dcc: Add earlycon support")
Great, can you resend with that added please?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h
From: Tony Ambardar @ 2020-09-19 4:15 UTC (permalink / raw)
To: Andreas Schwab
Cc: linux-arch, Arnd Bergmann, linux-kernel@vger.kernel.org,
Rosen Penev, Paul Mackerras, bpf, linuxppc-dev
In-Reply-To: <87h7rw321o.fsf@igel.home>
On Thu, 17 Sep 2020 at 07:34, Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Sep 17 2020, Arnd Bergmann wrote:
>
> > The errno man page says they are supposed to be synonyms,
> > and glibc defines it that way, while musl uses the numbers
> > from the kernel.
>
> glibc also uses whatever the kernel defines.
>
That's right, and from my investigation this isn't a libc issue. The
various libc flavours simply try to follow POSIX and the PPC ABI and
aren't doing anything wrong.
See errno.h for example (https://man7.org/linux/man-pages/man3/errno.3.html):
EDEADLK: Resource deadlock avoided (POSIX.1-2001).
EDEADLOCK: On most architectures, a synonym for EDEADLK. On some
architectures (e.g., Linux MIPS, PowerPC, SPARC), it is a separate
error code "File locking deadlock error".
The root cause is unique to the Linux PPC code in
arch/powerpc/include/uapi/asm/errno.h:
>/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>#ifndef _ASM_POWERPC_ERRNO_H
>#define _ASM_POWERPC_ERRNO_H
>
>#include <asm-generic/errno.h>
>
>#undef EDEADLOCK
>#define EDEADLOCK 58 /* File locking deadlock error */
>
>#endif /* _ASM_POWERPC_ERRNO_H */
It includes "<asm-generic/errno.h>" to pull in various definitions but
has the side-effect of redefining EDEADLOCK to a non-ABI value which
conflicts with the libc errno.h, as I outline in the patch
description. Other arches which also use different EDEADLOCK and
EDEADLK values (mips,sparc) do not do this. They define EDEADLOCK
*once*, with an ABI-consistent value, and don't have the same issue.
The problem goes back a ways (as Arnd points out), affecting current
stable and all LTS branches, so would be nice to get this sorted out.
I'm certainly interested if there's a better way than proposed in this
patch.
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 2a671167b5546321e2d2245aeb6f5a0e056a8f71
From: kernel test robot @ 2020-09-19 3:26 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 2a671167b5546321e2d2245aeb6f5a0e056a8f71 powerpc/pseries/iommu: Rename "direct window" to "dma window"
elapsed time: 879m
configs tested: 106
configs skipped: 2
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
m68k amiga_defconfig
ia64 alldefconfig
powerpc mpc832x_mds_defconfig
arm imx_v6_v7_defconfig
arm rpc_defconfig
arm u300_defconfig
c6x allyesconfig
sh se7750_defconfig
xtensa virt_defconfig
arm corgi_defconfig
sparc defconfig
arm colibri_pxa300_defconfig
mips maltasmvp_eva_defconfig
sh microdev_defconfig
powerpc tqm5200_defconfig
powerpc klondike_defconfig
arc haps_hs_defconfig
arm lpd270_defconfig
arm simpad_defconfig
mips ci20_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20200917
i386 randconfig-a006-20200917
i386 randconfig-a003-20200917
i386 randconfig-a001-20200917
i386 randconfig-a002-20200917
i386 randconfig-a005-20200917
i386 randconfig-a004-20200918
i386 randconfig-a001-20200918
i386 randconfig-a003-20200918
i386 randconfig-a006-20200918
i386 randconfig-a002-20200918
i386 randconfig-a005-20200918
x86_64 randconfig-a014-20200917
x86_64 randconfig-a011-20200917
x86_64 randconfig-a016-20200917
x86_64 randconfig-a012-20200917
x86_64 randconfig-a015-20200917
x86_64 randconfig-a013-20200917
x86_64 randconfig-a011-20200919
x86_64 randconfig-a012-20200919
i386 randconfig-a015-20200917
i386 randconfig-a014-20200917
i386 randconfig-a011-20200917
i386 randconfig-a013-20200917
i386 randconfig-a016-20200917
i386 randconfig-a012-20200917
i386 randconfig-a015-20200918
i386 randconfig-a011-20200918
i386 randconfig-a014-20200918
i386 randconfig-a013-20200918
i386 randconfig-a012-20200918
i386 randconfig-a016-20200918
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20200917
x86_64 randconfig-a004-20200917
x86_64 randconfig-a003-20200917
x86_64 randconfig-a002-20200917
x86_64 randconfig-a001-20200917
x86_64 randconfig-a005-20200917
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH] powerpc: Select HAVE_FUTEX_CMPXCHG
From: Samuel Holland @ 2020-09-19 3:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
linuxppc-dev
Cc: linux-kernel, Samuel Holland
On powerpc, access_ok() succeeds for the NULL pointer. This breaks the
dynamic check in futex_detect_cmpxchg(), which expects -EFAULT. As a
result, robust futex operations are not functional on powerpc.
Since the architecture's futex_atomic_cmpxchg_inatomic() implementation
requires no runtime feature detection, we can select HAVE_FUTEX_CMPXCHG
to skip futex_detect_cmpxchg() and enable the use of robust futexes.
Signed-off-by: Samuel Holland <samuel@sholland.org>
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index ad620637cbd1..5ad1deb0c669 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -196,6 +196,7 @@ config PPC
select HAVE_FUNCTION_ERROR_INJECTION
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
+ select HAVE_FUTEX_CMPXCHG
select HAVE_GCC_PLUGINS if GCC_VERSION >= 50200 # plugin support on gcc <= 5.1 is buggy on PPC
select HAVE_HW_BREAKPOINT if PERF_EVENTS && (PPC_BOOK3S || PPC_8xx)
select HAVE_IDE
--
2.26.2
^ permalink raw reply related
* Re: [PATCH -next] tty: hvc: fix link error with CONFIG_SERIAL_CORE_CONSOLE=n
From: Yang Yingliang @ 2020-09-19 2:48 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200918111708.GC2242974@kroah.com>
On 2020/9/18 19:17, Greg KH wrote:
> On Fri, Sep 18, 2020 at 05:20:30PM +0800, Yang Yingliang wrote:
>> Fix the link error by selecting SERIAL_CORE_CONSOLE.
>>
>> aarch64-linux-gnu-ld: drivers/tty/hvc/hvc_dcc.o: in function `dcc_early_write':
>> hvc_dcc.c:(.text+0x164): undefined reference to `uart_console_write'
>>
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>> ---
>> drivers/tty/hvc/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
>> index d1b27b0522a3..8d60e0ff67b4 100644
>> --- a/drivers/tty/hvc/Kconfig
>> +++ b/drivers/tty/hvc/Kconfig
>> @@ -81,6 +81,7 @@ config HVC_DCC
>> bool "ARM JTAG DCC console"
>> depends on ARM || ARM64
>> select HVC_DRIVER
>> + select SERIAL_CORE_CONSOLE
>> help
>> This console uses the JTAG DCC on ARM to create a console under the HVC
>> driver. This console is used through a JTAG only on ARM. If you don't have
>> --
>> 2.25.1
>>
> Same question here, what caused this problem to happen?
Fixes: d1a1af2cdf19 ("hvc: dcc: Add earlycon support")
>
> thanks,
>
> greg k-h
> .
^ permalink raw reply
* [PATCH -next v2] KVM: PPC: Book3S HV: XIVE: Convert to DEFINE_SHOW_ATTRIBUTE
From: Qinglang Miao @ 2020-09-19 1:29 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Benjamin Herrenschmidt
Cc: Qinglang Miao, linuxppc-dev, linux-kernel, kvm-ppc
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
---
v2: based on linux-next(20200917), and can be applied to
mainline cleanly now.
arch/powerpc/kvm/book3s_xive_native.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
index bdea91df1..d0c2db0e0 100644
--- a/arch/powerpc/kvm/book3s_xive_native.c
+++ b/arch/powerpc/kvm/book3s_xive_native.c
@@ -1227,17 +1227,7 @@ static int xive_native_debug_show(struct seq_file *m, void *private)
return 0;
}
-static int xive_native_debug_open(struct inode *inode, struct file *file)
-{
- return single_open(file, xive_native_debug_show, inode->i_private);
-}
-
-static const struct file_operations xive_native_debug_fops = {
- .open = xive_native_debug_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(xive_native_debug);
static void xive_native_debugfs_init(struct kvmppc_xive *xive)
{
--
2.23.0
^ permalink raw reply related
* [PATCH -next v2] powerpc/mm: ptdump: Convert to DEFINE_SHOW_ATTRIBUTE
From: Qinglang Miao @ 2020-09-19 1:29 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel, Qinglang Miao
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
---
v2: based on linux-next(20200917), and can be applied to
mainline cleanly now.
arch/powerpc/mm/ptdump/bats.c | 24 +++++++-----------------
arch/powerpc/mm/ptdump/hashpagetable.c | 12 +-----------
arch/powerpc/mm/ptdump/ptdump.c | 13 +------------
arch/powerpc/mm/ptdump/segment_regs.c | 12 +-----------
4 files changed, 10 insertions(+), 51 deletions(-)
diff --git a/arch/powerpc/mm/ptdump/bats.c b/arch/powerpc/mm/ptdump/bats.c
index e29b338d4..a24495e93 100644
--- a/arch/powerpc/mm/ptdump/bats.c
+++ b/arch/powerpc/mm/ptdump/bats.c
@@ -56,7 +56,7 @@ static void bat_show_601(struct seq_file *m, int idx, u32 lower, u32 upper)
#define BAT_SHOW_601(_m, _n, _l, _u) bat_show_601(_m, _n, mfspr(_l), mfspr(_u))
-static int bats_show_601(struct seq_file *m, void *v)
+static int bats_601_show(struct seq_file *m, void *v)
{
seq_puts(m, "---[ Block Address Translation ]---\n");
@@ -113,7 +113,7 @@ static void bat_show_603(struct seq_file *m, int idx, u32 lower, u32 upper, bool
#define BAT_SHOW_603(_m, _n, _l, _u, _d) bat_show_603(_m, _n, mfspr(_l), mfspr(_u), _d)
-static int bats_show_603(struct seq_file *m, void *v)
+static int bats_603_show(struct seq_file *m, void *v)
{
seq_puts(m, "---[ Instruction Block Address Translation ]---\n");
@@ -144,25 +144,15 @@ static int bats_show_603(struct seq_file *m, void *v)
return 0;
}
-static int bats_open(struct inode *inode, struct file *file)
-{
- if (IS_ENABLED(CONFIG_PPC_BOOK3S_601))
- return single_open(file, bats_show_601, NULL);
-
- return single_open(file, bats_show_603, NULL);
-}
-
-static const struct file_operations bats_fops = {
- .open = bats_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(bats_601);
+DEFINE_SHOW_ATTRIBUTE(bats_603);
static int __init bats_init(void)
{
debugfs_create_file("block_address_translation", 0400,
- powerpc_debugfs_root, NULL, &bats_fops);
+ powerpc_debugfs_root, NULL,
+ IS_ENABLED(CONFIG_PPC_BOOK3S_601) ?
+ &bats_601_fops : & bats_603_fops);
return 0;
}
device_initcall(bats_init);
diff --git a/arch/powerpc/mm/ptdump/hashpagetable.c b/arch/powerpc/mm/ptdump/hashpagetable.c
index ad6df9a2e..c7f824d29 100644
--- a/arch/powerpc/mm/ptdump/hashpagetable.c
+++ b/arch/powerpc/mm/ptdump/hashpagetable.c
@@ -526,17 +526,7 @@ static int ptdump_show(struct seq_file *m, void *v)
return 0;
}
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, NULL);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
static int ptdump_init(void)
{
diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
index aca354fb6..6bbf85ff2 100644
--- a/arch/powerpc/mm/ptdump/ptdump.c
+++ b/arch/powerpc/mm/ptdump/ptdump.c
@@ -413,18 +413,7 @@ static int ptdump_show(struct seq_file *m, void *v)
return 0;
}
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, NULL);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
static void build_pgtable_complete_mask(void)
{
diff --git a/arch/powerpc/mm/ptdump/segment_regs.c b/arch/powerpc/mm/ptdump/segment_regs.c
index dde2fe8de..9e870d44c 100644
--- a/arch/powerpc/mm/ptdump/segment_regs.c
+++ b/arch/powerpc/mm/ptdump/segment_regs.c
@@ -41,17 +41,7 @@ static int sr_show(struct seq_file *m, void *v)
return 0;
}
-static int sr_open(struct inode *inode, struct file *file)
-{
- return single_open(file, sr_show, NULL);
-}
-
-static const struct file_operations sr_fops = {
- .open = sr_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(sr);
static int __init sr_init(void)
{
--
2.23.0
^ permalink raw reply related
* Re: [PATCH -next] powerpc: Convert to DEFINE_SHOW_ATTRIBUTE
From: miaoqinglang @ 2020-09-19 1:27 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman
Cc: Greg Kroah-Hartman, linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <20200902045118.GD272502@thinks.paulus.ozlabs.org>
在 2020/9/2 12:51, Paul Mackerras 写道:
> On Thu, Jul 16, 2020 at 05:07:12PM +0800, Qinglang Miao wrote:
>> From: Chen Huang <chenhuang5@huawei.com>
>>
>> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>>
>> Signed-off-by: Chen Huang <chenhuang5@huawei.com>
>
> For the arch/powerpc/kvm part:
>
> Acked-by: Paul Mackerras <paulus@ozlabs.org>
>
> I expect Michael Ellerman will take the patch through his tree.
>
> Paul.
> .
Hi Michael and Paul,
I spilited this patch and resent them because I noticed that
<4d4901c6d7>(turn .read -> .read_iter) in linux-next has been reverted.
New patches are against linux-next(20200917), and they can
be applied to mainline cleanly now.
Thanks.
>
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS ace1986562a0814f179ecd2f1e648215ebc6625a
From: kernel test robot @ 2020-09-18 23:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: ace1986562a0814f179ecd2f1e648215ebc6625a Automatic merge of 'master', 'next' and 'fixes' (2020-09-18 21:04)
elapsed time: 724m
configs tested: 110
configs skipped: 2
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
powerpc akebono_defconfig
arc nsimosci_hs_smp_defconfig
powerpc rainier_defconfig
mips capcella_defconfig
powerpc kilauea_defconfig
arm imx_v6_v7_defconfig
powerpc mpc832x_mds_defconfig
arm rpc_defconfig
arm u300_defconfig
sh se7750_defconfig
xtensa virt_defconfig
arm corgi_defconfig
powerpc tqm5200_defconfig
powerpc klondike_defconfig
arc haps_hs_defconfig
arm lpd270_defconfig
arm simpad_defconfig
mips ci20_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20200917
i386 randconfig-a006-20200917
i386 randconfig-a003-20200917
i386 randconfig-a001-20200917
i386 randconfig-a002-20200917
i386 randconfig-a005-20200917
i386 randconfig-a004-20200918
i386 randconfig-a001-20200918
i386 randconfig-a003-20200918
i386 randconfig-a006-20200918
i386 randconfig-a002-20200918
i386 randconfig-a005-20200918
x86_64 randconfig-a014-20200917
x86_64 randconfig-a011-20200917
x86_64 randconfig-a016-20200917
x86_64 randconfig-a012-20200917
x86_64 randconfig-a015-20200917
x86_64 randconfig-a013-20200917
i386 randconfig-a015-20200917
i386 randconfig-a014-20200917
i386 randconfig-a011-20200917
i386 randconfig-a013-20200917
i386 randconfig-a016-20200917
i386 randconfig-a012-20200917
i386 randconfig-a015-20200918
i386 randconfig-a011-20200918
i386 randconfig-a014-20200918
i386 randconfig-a013-20200918
i386 randconfig-a012-20200918
i386 randconfig-a016-20200918
x86_64 randconfig-a004-20200918
x86_64 randconfig-a006-20200918
x86_64 randconfig-a003-20200918
x86_64 randconfig-a002-20200918
x86_64 randconfig-a005-20200918
x86_64 randconfig-a001-20200918
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20200917
x86_64 randconfig-a004-20200917
x86_64 randconfig-a003-20200917
x86_64 randconfig-a002-20200917
x86_64 randconfig-a001-20200917
x86_64 randconfig-a005-20200917
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 14/15] selftests/clone3: Avoid OS-defined clone_args
From: Kees Cook @ 2020-09-18 22:00 UTC (permalink / raw)
To: Christian Brauner
Cc: Thadeu Lima de Souza Cascardo, Will Drewry, linux-xtensa,
linux-kernel, Andy Lutomirski, Max Filippov, linux-arm-kernel,
linux-kselftest, linux-mips, linuxppc-dev, Christian Brauner
In-Reply-To: <20200915162528.x7admy45pdqsoke4@wittgenstein>
On Tue, Sep 15, 2020 at 06:25:28PM +0200, Christian Brauner wrote:
> On Sat, Sep 12, 2020 at 04:08:19AM -0700, Kees Cook wrote:
> > As the UAPI headers start to appear in distros, we need to avoid
> > outdated versions of struct clone_args to be able to test modern
> > features. Additionally pull in the syscall numbers correctly.
> >
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
>
> Hm, with this patch applied I'm getting:
>
> gcc -g -I../../../../usr/include/ clone3_set_tid.c /home/brauner/src/git/linux/linux/tools/testing/selftests/kselftest_harness.h /home/brauner/src/git/linux/linux/tools/testing/selftests/kselftest.h -lcap -o /home/brauner/src/git/linux/linux/tools/testing/selftests/clone3/clone3_set_tid
> In file included from clone3_set_tid.c:24:
> clone3_selftests.h:37:8: error: redefinition of ‘struct clone_args’
> 37 | struct clone_args {
> | ^~~~~~~~~~
> In file included from clone3_set_tid.c:12:
> /usr/include/linux/sched.h:92:8: note: originally defined here
> 92 | struct clone_args {
> | ^~~~~~~~~~
> make: *** [../lib.mk:140: /home/brauner/src/git/linux/linux/tools/testing/selftests/clone3/clone3_set_tid] Error 1
Hm, weird.
> One trick to avoid this could be:
>
> #ifndef CLONE_ARGS_SIZE_VER0
> #define CLONE_ARGS_SIZE_VER0 64 /* sizeof first published struct */
> #endif
>
> #ifndef CLONE_ARGS_SIZE_VER1
> #define CLONE_ARGS_SIZE_VER1 80 /* sizeof second published struct */
> #endif
>
> #ifndef CLONE_ARGS_SIZE_VER2
> #define CLONE_ARGS_SIZE_VER2 88 /* sizeof third published struct */
> #endif
>
> struct __clone_args {
> __aligned_u64 flags;
> __aligned_u64 pidfd;
> __aligned_u64 child_tid;
> __aligned_u64 parent_tid;
> __aligned_u64 exit_signal;
> __aligned_u64 stack;
> __aligned_u64 stack_size;
> __aligned_u64 tls;
> __aligned_u64 set_tid;
> __aligned_u64 set_tid_size;
> __aligned_u64 cgroup;
> };
>
> static pid_t sys_clone3(struct __clone_args *args, size_t size)
> {
> return syscall(__NR_clone3, args, size);
> }
Yeah, that has fewer down sides. I'll rework it.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 03/15] selftests/seccomp: mips: Define SYSCALL_NUM_SET macro
From: Kees Cook @ 2020-09-18 22:00 UTC (permalink / raw)
To: Christian Brauner
Cc: Thadeu Lima de Souza Cascardo, Will Drewry, linux-xtensa,
linux-kernel, Andy Lutomirski, Max Filippov, linux-arm-kernel,
linux-kselftest, linux-mips, linuxppc-dev, Christian Brauner
In-Reply-To: <20200915155546.ht4vo7nqswxrgymb@wittgenstein>
On Tue, Sep 15, 2020 at 05:55:46PM +0200, Christian Brauner wrote:
> On Sat, Sep 12, 2020 at 04:08:08AM -0700, Kees Cook wrote:
> > Remove the mips special-case in change_syscall().
> >
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> > tools/testing/selftests/seccomp/seccomp_bpf.c | 17 +++++++++--------
> > 1 file changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c b/tools/testing/selftests/seccomp/seccomp_bpf.c
> > index 1c83e743bfb1..02a9a6599746 100644
> > --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> > +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> > @@ -1742,6 +1742,13 @@ TEST_F(TRACE_poke, getpid_runs_normally)
> > # define ARCH_REGS struct pt_regs
> > # define SYSCALL_NUM(_regs) (_regs).regs[2]
> > # define SYSCALL_SYSCALL_NUM regs[4]
> > +# define SYSCALL_NUM_SET(_regs, _nr) \
> > + do { \
> > + if ((_regs).regs[2] == __NR_O32_Linux) \
> > + (_regs).regs[4] = _nr; \
> > + else \
> > + (_regs).regs[2] = _nr; \
> > + } while (0)
>
> I think that
>
> # define SYSCALL_NUM_SET(_regs, _nr) \
> do { \
> if (SYSCALL_NUM(_regs) == __NR_O32_Linux) \
> (_regs).regs[4] = _nr; \
> else \
> (_regs).regs[2] = _nr; \
> } while (0)
>
> would read better but that's just a matter of taste. :)
That's how I started originally, but when I realized that I'd have to
reorganize SYSCALL_NUM() too, it seem best to have minimal churn, so I
left it open coded here, since that's how it needs to be in the end.
> Looks good!
> Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Thanks for the reviews!
--
Kees Cook
^ permalink raw reply
* [powerpc:topic/irqs-off-activate-mm] BUILD SUCCESS a665eec0a22e11cdde708c1c256a465ebe768047
From: kernel test robot @ 2020-09-18 20:26 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/irqs-off-activate-mm
branch HEAD: a665eec0a22e11cdde708c1c256a465ebe768047 powerpc/64s/radix: Fix mm_cpumask trimming race vs kthread_use_mm
elapsed time: 722m
configs tested: 154
configs skipped: 2
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
riscv nommu_k210_defconfig
m68k amiga_defconfig
powerpc mpc832x_mds_defconfig
ia64 alldefconfig
riscv rv32_defconfig
arm imx_v6_v7_defconfig
arm rpc_defconfig
arm u300_defconfig
arm ebsa110_defconfig
sh edosk7760_defconfig
sparc64 alldefconfig
m68k multi_defconfig
sh edosk7705_defconfig
arm omap2plus_defconfig
m68k alldefconfig
mips malta_defconfig
arm pxa910_defconfig
mips vocore2_defconfig
nds32 alldefconfig
powerpc linkstation_defconfig
parisc generic-64bit_defconfig
arm pxa255-idp_defconfig
ia64 bigsur_defconfig
powerpc makalu_defconfig
arm pxa3xx_defconfig
powerpc mgcoge_defconfig
parisc generic-32bit_defconfig
m68k m5272c3_defconfig
sh magicpanelr2_defconfig
arm nhk8815_defconfig
sh se7750_defconfig
xtensa virt_defconfig
arm corgi_defconfig
arm at91_dt_defconfig
arm milbeaut_m10v_defconfig
arm am200epdkit_defconfig
arm iop32x_defconfig
mips decstation_r4k_defconfig
nios2 3c120_defconfig
powerpc pcm030_defconfig
sh sh7763rdp_defconfig
arm colibri_pxa300_defconfig
mips maltasmvp_eva_defconfig
sh microdev_defconfig
alpha defconfig
arm vt8500_v6_v7_defconfig
arm mv78xx0_defconfig
arm badge4_defconfig
mips loongson3_defconfig
m68k stmark2_defconfig
sh se7780_defconfig
powerpc tqm5200_defconfig
powerpc klondike_defconfig
arc haps_hs_defconfig
arm lpd270_defconfig
arm simpad_defconfig
mips ci20_defconfig
arm tegra_defconfig
mips nlm_xlr_defconfig
arm s3c2410_defconfig
arm moxart_defconfig
parisc alldefconfig
mips decstation_defconfig
powerpc cell_defconfig
arm mainstone_defconfig
powerpc holly_defconfig
microblaze defconfig
powerpc ksi8560_defconfig
powerpc ppa8548_defconfig
mips omega2p_defconfig
arm versatile_defconfig
arm mps2_defconfig
powerpc icon_defconfig
openrisc alldefconfig
sh sh7724_generic_defconfig
sh j2_defconfig
powerpc ppc64_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20200917
i386 randconfig-a006-20200917
i386 randconfig-a003-20200917
i386 randconfig-a001-20200917
i386 randconfig-a002-20200917
i386 randconfig-a005-20200917
x86_64 randconfig-a014-20200917
x86_64 randconfig-a011-20200917
x86_64 randconfig-a016-20200917
x86_64 randconfig-a012-20200917
x86_64 randconfig-a015-20200917
x86_64 randconfig-a013-20200917
i386 randconfig-a015-20200917
i386 randconfig-a014-20200917
i386 randconfig-a011-20200917
i386 randconfig-a013-20200917
i386 randconfig-a016-20200917
i386 randconfig-a012-20200917
i386 randconfig-a015-20200918
i386 randconfig-a011-20200918
i386 randconfig-a014-20200918
i386 randconfig-a013-20200918
i386 randconfig-a012-20200918
i386 randconfig-a016-20200918
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20200917
x86_64 randconfig-a004-20200917
x86_64 randconfig-a003-20200917
x86_64 randconfig-a002-20200917
x86_64 randconfig-a001-20200917
x86_64 randconfig-a005-20200917
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.9-5 tag
From: pr-tracker-bot @ 2020-09-18 19:04 UTC (permalink / raw)
To: Michael Ellerman
Cc: ego, aik, aneesh.kumar, linuxppc-dev, linux-kernel, vaibhav,
Linus Torvalds
In-Reply-To: <877dsr6ztr.fsf@mpe.ellerman.id.au>
The pull request you sent on Fri, 18 Sep 2020 22:20:48 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.9-5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5a55d36f715b01a00c1ad7127a73044c6f1c9668
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: dt-bindings: fsl_xcvr: Add document for XCVR
From: Rob Herring @ 2020-09-18 17:23 UTC (permalink / raw)
To: Viorel Suman (OSS)
Cc: devicetree, alsa-devel, Liam Girdwood, Matthias Schiffer,
Philipp Zabel, Timur Tabi, Xiubo Li, linux-kernel, Mark Brown,
linuxppc-dev, Takashi Iwai, Jaroslav Kysela, Nicolin Chen,
Rob Herring, NXP Linux Team, Viorel Suman, Viorel Suman,
Cosmin-Gabriel Samoila, Shengjiu Wang, Fabio Estevam
In-Reply-To: <1600247876-8013-3-git-send-email-viorel.suman@oss.nxp.com>
On Wed, 16 Sep 2020 12:17:56 +0300, Viorel Suman (OSS) wrote:
> From: Viorel Suman <viorel.suman@nxp.com>
>
> XCVR (Audio Transceiver) is a new IP module found on i.MX8MP.
>
> Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
> ---
> .../devicetree/bindings/sound/fsl,xcvr.yaml | 104 +++++++++++++++++++++
> 1 file changed, 104 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
Error: Documentation/devicetree/bindings/sound/fsl,xcvr.example.dts:29.30-31 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:342: Documentation/devicetree/bindings/sound/fsl,xcvr.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1366: dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1365072
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
From: Timur Tabi @ 2020-09-18 16:06 UTC (permalink / raw)
To: Viorel Suman (OSS), Nicolin Chen
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
Matthias Schiffer, Xiubo Li, Shengjiu Wang,
linuxppc-dev@lists.ozlabs.org, Takashi Iwai, Rob Herring,
Liam Girdwood, Viorel Suman, Mark Brown, dl-linux-imx,
Philipp Zabel, Cosmin-Gabriel Samoila, Jaroslav Kysela,
Fabio Estevam, linux-kernel@vger.kernel.org
In-Reply-To: <VI1PR0401MB2272659A8126D01D9A53F7C5923F0@VI1PR0401MB2272.eurprd04.prod.outlook.com>
On 9/18/20 9:21 AM, Viorel Suman (OSS) wrote:
>>> +static const u32 fsl_xcvr_earc_channels[] = { 1, 2, 8, 16, 32, }; /*
>>> +one bit 6, 12 ? */
>> What's the meaning of the comments?
> Just a thought noted as comment. HDMI2.1 spec defines 6- and 12-channels layout when
> one bit audio stream is transmitted - I was wandering how can this be enforced. Is a @todo like of comment.
Please don't add comments that other developers could never understand.
The text that you just wrote here would be a great starting point for a
better comment.
^ permalink raw reply
* RE: [PATCH 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
From: Viorel Suman (OSS) @ 2020-09-18 15:33 UTC (permalink / raw)
To: Mark Brown, Viorel Suman (OSS)
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
Matthias Schiffer, Timur Tabi, Xiubo Li, Shengjiu Wang,
linuxppc-dev@lists.ozlabs.org, Takashi Iwai, Liam Girdwood,
Nicolin Chen, Rob Herring, dl-linux-imx, Philipp Zabel,
Viorel Suman, Cosmin-Gabriel Samoila, Jaroslav Kysela,
Fabio Estevam, linux-kernel@vger.kernel.org
In-Reply-To: <20200918152004.GJ5703@sirena.org.uk>
> On Fri, Sep 18, 2020 at 03:02:39PM +0000, Viorel Suman (OSS) wrote:
>
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns. Doing this makes your messages much easier
> to read and reply to.
>
My bad, will do.
> > > > + regmap_read(regmap, FSL_XCVR_EXT_ISR, &isr);
> > > > + regmap_write(regmap, FSL_XCVR_EXT_ISR_CLR, isr);
>
> > > This will unconditionally clear any interrupts, even those we don't
> > > understand - it might be better to only clear bits that are
> > > supported so the IRQ core can complain if there's something unexpected
> showing up.
>
> > The ARM core registers itself in "fsl_xcvr_prepare" (the code below) just for a
> subset of all supported interrupts:
> > =====
> > ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_IER0,
> > FSL_XCVR_IRQ_EARC_ALL,
> FSL_XCVR_IRQ_EARC_ALL); =====
> > FSL_XCVR_IRQ_EARC_ALL - this mask represents all the interrupts we are
> > interested in and we handle in interrupt handler, But this is just a subset of all
> interrupts the M0+ core is able to assert. Not very intuitive, I think I need to
> reword it somehow.
>
> That's not the issue, the issue is that if we get into the ISR we just ack all the bits
> that are flagged by the hardware regardless of if we actually handled them. This
> won't work if there are ever systems that share the interrupt and it works
> against safety/debugging features that the interrupt has in case something goes
> wrong and we get spurious interrupts.
>
Thank you for explanation, will fix it in next version.
> > > > + if (isr & FSL_XCVR_IRQ_FIFO_UOFL_ERR)
> > > > + dev_dbg(dev, "RX/TX FIFO full/empty\n");
>
> > > Should this be dev_err()?
>
> > The interrupt may be asserted right before DMA starts to fill the TX FIFO if I
> recall correctly.
> > I've added it just to debug the IP behavior, will check and change it to err it in
> next version if it is the case.
>
> If it does come up normally then a comment or something to explain why this
> happens normally would probably be good.
Sure, ok.
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
From: Mark Brown @ 2020-09-18 15:20 UTC (permalink / raw)
To: Viorel Suman (OSS)
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
Matthias Schiffer, Timur Tabi, Xiubo Li, Shengjiu Wang,
linuxppc-dev@lists.ozlabs.org, Takashi Iwai, Liam Girdwood,
Nicolin Chen, Rob Herring, dl-linux-imx, Philipp Zabel,
Viorel Suman, Cosmin-Gabriel Samoila, Jaroslav Kysela,
Fabio Estevam, linux-kernel@vger.kernel.org
In-Reply-To: <VI1PR0401MB22726CC099099547A0502C27923F0@VI1PR0401MB2272.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]
On Fri, Sep 18, 2020 at 03:02:39PM +0000, Viorel Suman (OSS) wrote:
Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.
> > > + regmap_read(regmap, FSL_XCVR_EXT_ISR, &isr);
> > > + regmap_write(regmap, FSL_XCVR_EXT_ISR_CLR, isr);
> > This will unconditionally clear any interrupts, even those we don't understand - it
> > might be better to only clear bits that are supported so the IRQ core can
> > complain if there's something unexpected showing up.
> The ARM core registers itself in "fsl_xcvr_prepare" (the code below) just for a subset of all supported interrupts:
> =====
> ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_IER0,
> FSL_XCVR_IRQ_EARC_ALL, FSL_XCVR_IRQ_EARC_ALL);
> =====
> FSL_XCVR_IRQ_EARC_ALL - this mask represents all the interrupts we are interested in and we handle in interrupt handler,
> But this is just a subset of all interrupts the M0+ core is able to assert. Not very intuitive, I think I need to reword it somehow.
That's not the issue, the issue is that if we get into the ISR we just
ack all the bits that are flagged by the hardware regardless of if we
actually handled them. This won't work if there are ever systems that
share the interrupt and it works against safety/debugging features that
the interrupt has in case something goes wrong and we get spurious
interrupts.
> > > + if (isr & FSL_XCVR_IRQ_FIFO_UOFL_ERR)
> > > + dev_dbg(dev, "RX/TX FIFO full/empty\n");
> > Should this be dev_err()?
> The interrupt may be asserted right before DMA starts to fill the TX FIFO if I recall correctly.
> I've added it just to debug the IP behavior, will check and change it to err it in next version if it is the case.
If it does come up normally then a comment or something to explain why
this happens normally would probably be good.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Christoph Hellwig @ 2020-09-18 15:16 UTC (permalink / raw)
To: Al Viro
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390, linux-scsi,
x86, Arnd Bergmann, linux-block, io-uring, linux-arm-kernel,
Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200918135822.GZ3421308@ZenIV.linux.org.uk>
On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> Said that, why not provide a variant that would take an explicit
> "is it compat" argument and use it there? And have the normal
> one pass in_compat_syscall() to that...
That would help to not introduce a regression with this series yes.
But it wouldn't fix existing bugs when io_uring is used to access
read or write methods that use in_compat_syscall(). One example that
I recently ran into is drivers/scsi/sg.c.
^ permalink raw reply
* Re: [PATCH] ocxl: fix kconfig dependency warning for OCXL
From: Frederic Barrat @ 2020-09-18 15:12 UTC (permalink / raw)
To: Necip Fazil Yildiran; +Cc: gregkh, linux-kernel, jeho, paul, linuxppc-dev
In-Reply-To: <20200918094148.20525-1-fazilyildiran@gmail.com>
Le 18/09/2020 à 11:41, Necip Fazil Yildiran a écrit :
> When OCXL is enabled and HOTPLUG_PCI is disabled, it results in the
> following Kbuild warning:
>
> WARNING: unmet direct dependencies detected for HOTPLUG_PCI_POWERNV
> Depends on [n]: PCI [=y] && HOTPLUG_PCI [=n] && PPC_POWERNV [=y] && EEH [=y]
> Selected by [y]:
> - OCXL [=y] && PPC_POWERNV [=y] && PCI [=y] && EEH [=y]
>
> The reason is that OCXL selects HOTPLUG_PCI_POWERNV without depending on
> or selecting HOTPLUG_PCI while HOTPLUG_PCI_POWERNV is subordinate to
> HOTPLUG_PCI.
>
> HOTPLUG_PCI_POWERNV is a visible symbol with a set of dependencies.
> Selecting it will lead to overlooking its other dependencies as well.
>
> Let OCXL depend on HOTPLUG_PCI_POWERNV instead to avoid Kbuild issues.
>
> Fixes: 49ce94b8677c ("ocxl: Add PCI hotplug dependency to Kconfig")
> Signed-off-by: Necip Fazil Yildiran <fazilyildiran@gmail.com>
> ---
OK, that makes sense, thanks!
Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
> drivers/misc/ocxl/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/misc/ocxl/Kconfig b/drivers/misc/ocxl/Kconfig
> index 6551007a066c..947294f6d7f4 100644
> --- a/drivers/misc/ocxl/Kconfig
> +++ b/drivers/misc/ocxl/Kconfig
> @@ -9,9 +9,8 @@ config OCXL_BASE
>
> config OCXL
> tristate "OpenCAPI coherent accelerator support"
> - depends on PPC_POWERNV && PCI && EEH
> + depends on PPC_POWERNV && PCI && EEH && HOTPLUG_PCI_POWERNV
> select OCXL_BASE
> - select HOTPLUG_PCI_POWERNV
> default m
> help
> Select this option to enable the ocxl driver for Open
>
^ permalink raw reply
* RE: [PATCH 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
From: Viorel Suman (OSS) @ 2020-09-18 15:02 UTC (permalink / raw)
To: Mark Brown, Viorel Suman (OSS)
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
Matthias Schiffer, Timur Tabi, Xiubo Li, Shengjiu Wang,
linuxppc-dev@lists.ozlabs.org, Takashi Iwai, Liam Girdwood,
Nicolin Chen, Rob Herring, dl-linux-imx, Philipp Zabel,
Viorel Suman, Cosmin-Gabriel Samoila, Jaroslav Kysela,
Fabio Estevam, linux-kernel@vger.kernel.org
In-Reply-To: <20200917135306.GF4755@sirena.org.uk>
Hi Mark,
Thank you for your review.
> On Wed, Sep 16, 2020 at 12:17:55PM +0300, Viorel Suman (OSS) wrote:
> > +static int fsl_xcvr_load_firmware(struct fsl_xcvr *xcvr) {
> > + struct device *dev = &xcvr->pdev->dev;
> > + const struct firmware *fw;
> > + int ret = 0, rem, off, out, page = 0, size = FSL_XCVR_REG_OFFSET;
> > + u32 mask, val;
> > +
> > + ret = request_firmware(&fw, xcvr->fw_name, dev);
> > + if (ret) {
> > + dev_err(dev, "failed to request firmware.\n");
> > + return ret;
> > + }
> > +
> > + rem = fw->size;
>
> It would be good to see some explicit validation of the image size, at least
> printing an error message if the image is bigger than can be loaded. The code
> should be safe in that it won't overflow the device region it's writing to but it
> feels like it'd be better to tell people if we spot a problem rather than just silently
> truncating the file.
Make sense, will improve this part in the next version.
> > +static irqreturn_t irq0_isr(int irq, void *devid) {
> > + struct fsl_xcvr *xcvr = (struct fsl_xcvr *)devid;
> > + struct device *dev = &xcvr->pdev->dev;
> > + struct regmap *regmap = xcvr->regmap;
> > + void __iomem *reg_ctrl, *reg_buff;
> > + u32 isr, val, i;
> > +
> > + regmap_read(regmap, FSL_XCVR_EXT_ISR, &isr);
> > + regmap_write(regmap, FSL_XCVR_EXT_ISR_CLR, isr);
>
> This will unconditionally clear any interrupts, even those we don't understand - it
> might be better to only clear bits that are supported so the IRQ core can
> complain if there's something unexpected showing up.
The ARM core registers itself in "fsl_xcvr_prepare" (the code below) just for a subset of all supported interrupts:
=====
ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_IER0,
FSL_XCVR_IRQ_EARC_ALL, FSL_XCVR_IRQ_EARC_ALL);
=====
FSL_XCVR_IRQ_EARC_ALL - this mask represents all the interrupts we are interested in and we handle in interrupt handler,
But this is just a subset of all interrupts the M0+ core is able to assert. Not very intuitive, I think I need to reword it somehow.
> > + if (isr & FSL_XCVR_IRQ_FIFO_UOFL_ERR)
> > + dev_dbg(dev, "RX/TX FIFO full/empty\n");
>
> Should this be dev_err()?
The interrupt may be asserted right before DMA starts to fill the TX FIFO if I recall correctly.
I've added it just to debug the IP behavior, will check and change it to err it in next version if it is the case.
> > +static irqreturn_t irq1_isr(int irq, void *devid) {
> > + struct fsl_xcvr *xcvr = (struct fsl_xcvr *)devid;
> > + struct device *dev = &xcvr->pdev->dev;
> > +
> > + dev_dbg(dev, "irq[1]: %d\n", irq);
> > +
> > + return IRQ_HANDLED;
> > +}
>
> Is there any value in even requesting this and irq2 given the lack of meaningful
> handling?
No, will remove it in v2.
Thank you,
Viorel
^ permalink raw reply
* RE: [PATCH 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
From: Viorel Suman (OSS) @ 2020-09-18 14:21 UTC (permalink / raw)
To: Nicolin Chen, Viorel Suman (OSS)
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
Matthias Schiffer, Timur Tabi, Xiubo Li, Shengjiu Wang,
linuxppc-dev@lists.ozlabs.org, Takashi Iwai, Rob Herring,
Liam Girdwood, Viorel Suman, Mark Brown, dl-linux-imx,
Philipp Zabel, Cosmin-Gabriel Samoila, Jaroslav Kysela,
Fabio Estevam, linux-kernel@vger.kernel.org
In-Reply-To: <20200917071431.GA17970@Asurada-Nvidia>
Hi Nicolin,
Thank you for your review.
> > +static const u32 fsl_xcvr_earc_channels[] = { 1, 2, 8, 16, 32, }; /*
> > +one bit 6, 12 ? */
>
> What's the meaning of the comments?
Just a thought noted as comment. HDMI2.1 spec defines 6- and 12-channels layout when
one bit audio stream is transmitted - I was wandering how can this be enforced. Is a @todo like of comment.
>
> > +static const int fsl_xcvr_phy_arc_cfg[] = {
> > + FSL_XCVR_PHY_CTRL_ARC_MODE_SE_EN,
> FSL_XCVR_PHY_CTRL_ARC_MODE_CM_EN,
> > +};
>
> Nit: better be u32 vs. int?
Yes, will fix it in v2.
>
> > +/** phy: true => phy, false => pll */ static int
> > +fsl_xcvr_ai_write(struct fsl_xcvr *xcvr, u8 reg, u32 data, bool phy)
> > +{
> > + u32 val, idx, tidx;
> > +
> > + idx = BIT(phy ? 26 : 24);
> > + tidx = BIT(phy ? 27 : 25);
> > +
> > + regmap_write(xcvr->regmap, FSL_XCVR_PHY_AI_CTRL_CLR, 0xFF);
> > + regmap_write(xcvr->regmap, FSL_XCVR_PHY_AI_CTRL_SET, reg);
> > + regmap_write(xcvr->regmap, FSL_XCVR_PHY_AI_WDATA, data);
> > + regmap_write(xcvr->regmap, FSL_XCVR_PHY_AI_CTRL_TOG, idx);
> > +
> > + do {
> > + regmap_read(xcvr->regmap, FSL_XCVR_PHY_AI_CTRL, &val);
> > + } while ((val & idx) != ((val & tidx) >> 1));
>
> Might regmap_read_poll_timeout() be better? And it seems to poll intentionally
> with no sleep nor timeout -- would be nice to have a line of comments to explain
> why.
No particular reason to do it with no sleep or timeout here, will check and fix it in v2.
>
> > > +static int fsl_xcvr_runtime_resume(struct device *dev)
> > +{
> > + struct fsl_xcvr *xcvr = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + ret = clk_prepare_enable(xcvr->ipg_clk);
> > + if (ret) {
> > + dev_err(dev, "failed to start IPG clock.\n");
> > + return ret;
> > + }
> > +
> > + ret = clk_prepare_enable(xcvr->pll_ipg_clk);
> > + if (ret) {
> > + dev_err(dev, "failed to start PLL IPG clock.\n");
>
> Should it disable ipg_clk?
Yes, thank you, will fix in v2.
>
> > + return ret;
> > + }
> > +
> > + ret = clk_prepare_enable(xcvr->phy_clk);
> > + if (ret) {
> > + dev_err(dev, "failed to start PHY clock: %d\n", ret);
> > + clk_disable_unprepare(xcvr->ipg_clk);
>
> Should it disable pll_ipg_clk?
Yes, will fix in v2.
>
> > + return ret;
> > + }
> > +
> > + ret = clk_prepare_enable(xcvr->spba_clk);
> > + if (ret) {
> > + dev_err(dev, "failed to start SPBA clock.\n");
> > + clk_disable_unprepare(xcvr->phy_clk);
> > + clk_disable_unprepare(xcvr->ipg_clk);
>
> Ditto
Ok.
>
> > + return ret;
> > + }
> > +
> > + regcache_cache_only(xcvr->regmap, false);
> > + regcache_mark_dirty(xcvr->regmap);
> > + ret = regcache_sync(xcvr->regmap);
> > +
> > + if (ret) {
> > + dev_err(dev, "failed to sync regcache.\n");
> > + return ret;
>
> What about those clocks? Probably better to have some error-out labels at the
> end of the function?
Make sense, will fix in v2.
>
> > + }
> > +
> > + reset_control_assert(xcvr->reset);
> > + reset_control_deassert(xcvr->reset);
> > +
> > + ret = fsl_xcvr_load_firmware(xcvr);
> > + if (ret) {
> > + dev_err(dev, "failed to load firmware.\n");
> > + return ret;
>
> Ditto
>
> > + }
> > +
> > + /* Release M0+ reset */
> > + ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_CTRL,
> > + FSL_XCVR_EXT_CTRL_CORE_RESET, 0);
> > + if (ret < 0) {
> > + dev_err(dev, "M0+ core release failed: %d\n", ret);
> > + return ret;
>
> Ditto
>
> > + }
> > + mdelay(50);
>
> Any reason to use mdelay over msleep for a 50ms wait? May add a line of
> comments if mdelay is a must?
No particular reason, will fix it in v2.
Thank you,
Viorel
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Arnd Bergmann @ 2020-09-18 13:59 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-aio, open list:BROADCOM NVRAM DRIVER, David Howells,
Linux-MM, keyrings, sparclinux, linux-arch, linux-s390,
linux-scsi, the arch/x86 maintainers, linux-block, Al Viro,
io-uring, Linux ARM, Jens Axboe, Parisc List, Networking,
linux-kernel@vger.kernel.org, LSM List,
Linux FS-devel Mailing List, Andrew Morton, linuxppc-dev
In-Reply-To: <20200918134406.GA17064@lst.de>
On Fri, Sep 18, 2020 at 3:44 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Fri, Sep 18, 2020 at 02:40:12PM +0100, Al Viro wrote:
> > > /* Vector 0x110 is LINUX_32BIT_SYSCALL_TRAP */
> > > - return pt_regs_trap_type(current_pt_regs()) == 0x110;
> > > + return pt_regs_trap_type(current_pt_regs()) == 0x110 ||
> > > + (current->flags & PF_FORCE_COMPAT);
> >
> > Can't say I like that approach ;-/ Reasoning about the behaviour is much
> > harder when it's controlled like that - witness set_fs() shite...
>
> I don't particularly like it either. But do you have a better idea
> how to deal with io_uring vs compat tasks?
Do we need to worry about something other than the compat_iovec
struct for now? Regarding the code in io_import_iovec(), it would
seem that can easily be handled by exposing an internal helper.
Instead of
#ifdef CONFIG_COMPAT
if (req->ctx->compat)
return compat_import_iovec(rw, buf, sqe_len, UIO_FASTIOV,
iovec, iter);
#endif
return import_iovec(rw, buf, sqe_len, UIO_FASTIOV, iovec, iter);
This could do
__import_iovec(rw, buf, sqe_len, UIO_FASTIOV, iovec,
iter, req->ctx->compat);
With the normal import_iovec() becoming a trivial wrapper around
the same thing:
ssize_t import_iovec(int type, const struct iovec __user * uvector,
unsigned nr_segs, unsigned fast_segs,
struct iovec **iov, struct iov_iter *i)
{
return __import_iovec(type, uvector, nr_segs, fast_segs, iov,
i, in_compat_syscall());
}
Arnd
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Al Viro @ 2020-09-18 13:58 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, linux-arch, linux-s390, linux-scsi, x86,
Arnd Bergmann, linux-block, io-uring, linux-arm-kernel,
Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200918134406.GA17064@lst.de>
On Fri, Sep 18, 2020 at 03:44:06PM +0200, Christoph Hellwig wrote:
> On Fri, Sep 18, 2020 at 02:40:12PM +0100, Al Viro wrote:
> > > /* Vector 0x110 is LINUX_32BIT_SYSCALL_TRAP */
> > > - return pt_regs_trap_type(current_pt_regs()) == 0x110;
> > > + return pt_regs_trap_type(current_pt_regs()) == 0x110 ||
> > > + (current->flags & PF_FORCE_COMPAT);
> >
> > Can't say I like that approach ;-/ Reasoning about the behaviour is much
> > harder when it's controlled like that - witness set_fs() shite...
>
> I don't particularly like it either. But do you have a better idea
> how to deal with io_uring vs compat tasks?
<wry> git rm fs/io_uring.c would make a good starting point </wry>
Yes, I know it's not going to happen, but one can dream...
Said that, why not provide a variant that would take an explicit
"is it compat" argument and use it there? And have the normal
one pass in_compat_syscall() to that...
^ permalink raw reply
* Re: [PATCH 8/9] mm: remove compat_process_vm_{readv,writev}
From: Arnd Bergmann @ 2020-09-18 13:48 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-aio, open list:BROADCOM NVRAM DRIVER, David Howells,
Linux-MM, keyrings, sparclinux, linux-arch, linux-s390,
linux-scsi, the arch/x86 maintainers, linux-block, Alexander Viro,
io-uring, Linux ARM, Jens Axboe, Parisc List, Networking,
linux-kernel@vger.kernel.org, LSM List,
Linux FS-devel Mailing List, Andrew Morton, linuxppc-dev
In-Reply-To: <20200918124533.3487701-9-hch@lst.de>
On Fri, Sep 18, 2020 at 2:45 PM Christoph Hellwig <hch@lst.de> wrote:
>
> Now that import_iovec handles compat iovecs, the native syscalls
> can be used for the compat case as well.
>
> diff --git a/arch/x86/entry/syscall_x32.c b/arch/x86/entry/syscall_x32.c
> index a4840b9d50ad14..f2fe0a33bcfdd5 100644
> --- a/arch/x86/entry/syscall_x32.c
> +++ b/arch/x86/entry/syscall_x32.c
> @@ -17,6 +17,8 @@
> #define __x32_sys_getsockopt __x64_sys_getsockopt
> #define __x32_sys_setsockopt __x64_sys_setsockopt
> #define __x32_sys_vmsplice __x64_sys_vmsplice
> +#define __x32_sys_process_vm_readv __x64_sys_process_vm_readv
> +#define __x32_sys_process_vm_writev __x64_sys_process_vm_writev
>
> #define __SYSCALL_64(nr, sym)
>
I forgot this hack existed, and just sent a patch with subject "x86: add
__X32_COND_SYSCALL() macro" instead.
If I understand this right, the macros above should no longer be needed
once my patch gets merged.
Arnd
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Christoph Hellwig @ 2020-09-18 13:44 UTC (permalink / raw)
To: Al Viro
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390, linux-scsi,
x86, Arnd Bergmann, linux-block, io-uring, linux-arm-kernel,
Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200918134012.GY3421308@ZenIV.linux.org.uk>
On Fri, Sep 18, 2020 at 02:40:12PM +0100, Al Viro wrote:
> > /* Vector 0x110 is LINUX_32BIT_SYSCALL_TRAP */
> > - return pt_regs_trap_type(current_pt_regs()) == 0x110;
> > + return pt_regs_trap_type(current_pt_regs()) == 0x110 ||
> > + (current->flags & PF_FORCE_COMPAT);
>
> Can't say I like that approach ;-/ Reasoning about the behaviour is much
> harder when it's controlled like that - witness set_fs() shite...
I don't particularly like it either. But do you have a better idea
how to deal with io_uring vs compat tasks?
^ 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