Re: [PATCH 5.2 36/37] vhost: block speculation of translated descriptors
On Sat, Sep 14, 2019 at 02:54:11AM +0200, Stefan Lippers-Hollmann wrote: > Hi > > On 2019-09-13, Greg Kroah-Hartman wrote: > > From: Michael S. Tsirkin > > > > commit a89db445fbd7f1f8457b03759aa7343fa530ef6b upstream. > > > > iovec addresses coming from vhost are assumed to be > > pre-validated, but in fact can be speculated to a value > > out of range. > > > > Userspace address are later validated with array_index_nospec so we can > > be sure kernel info does not leak through these addresses, but vhost > > must also not leak userspace info outside the allowed memory table to > > guests. > > > > Following the defence in depth principle, make sure > > the address is not validated out of node range. > [...] > > This fails to compile as part of 5.2.15-rc1 on i386 (amd64 is fine), using > gcc 9.2.1. Reverting just this patch results in a successful build again. > > > --- a/drivers/vhost/vhost.c > > +++ b/drivers/vhost/vhost.c > > @@ -1965,8 +1965,10 @@ static int translate_desc(struct vhost_v > > _iov = iov + ret; > > size = node->size - addr + node->start; > > _iov->iov_len = min((u64)len - s, size); > > - _iov->iov_base = (void __user *)(unsigned long) > > - (node->userspace_addr + addr - node->start); > > + _iov->iov_base = (void __user *) > > + ((unsigned long)node->userspace_addr + > > +array_index_nospec((unsigned long)(addr - node->start), > > + node->size)); > > s += size; > > addr += size; > > ++ret; > > > > > > CC [M] drivers/vhost/vhost.o > In file included from /build/linux-5.2/include/linux/export.h:45, > from /build/linux-5.2/include/linux/linkage.h:7, > from /build/linux-5.2/include/linux/kernel.h:8, > from /build/linux-5.2/include/linux/list.h:9, > from /build/linux-5.2/include/linux/wait.h:7, > from /build/linux-5.2/include/linux/eventfd.h:13, > from /build/linux-5.2/drivers/vhost/vhost.c:13: > /build/linux-5.2/drivers/vhost/vhost.c: In function 'translate_desc': > /build/linux-5.2/include/linux/compiler.h:345:38: error: call to > '__compiletime_assert_1970' declared with attribute error: BUILD_BUG_ON > failed: sizeof(_s) > sizeof(long) > 345 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > | ^ > /build/linux-5.2/include/linux/compiler.h:326:4: note: in definition of macro > '__compiletime_assert' > 326 |prefix ## suffix();\ > |^~ > /build/linux-5.2/include/linux/compiler.h:345:2: note: in expansion of macro > '_compiletime_assert' > 345 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > | ^~~ > /build/linux-5.2/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) > | ^~ > /build/linux-5.2/include/linux/build_bug.h:50:2: note: in expansion of macro > 'BUILD_BUG_ON_MSG' >50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) > | ^~~~ > /build/linux-5.2/include/linux/nospec.h:56:2: note: in expansion of macro > 'BUILD_BUG_ON' >56 | BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \ > | ^~~~ > /build/linux-5.2/drivers/vhost/vhost.c:1970:5: note: in expansion of macro > 'array_index_nospec' > 1970 | array_index_nospec((unsigned long)(addr - node->start), > | ^~ > make[3]: *** [/build/linux-5.2/scripts/Makefile.build:285: > drivers/vhost/vhost.o] Error 1 > make[2]: *** [/build/linux-5.2/scripts/Makefile.build:489: drivers/vhost] > Error 2 > make[1]: *** [/build/linux-5.2/Makefile:1072: drivers] Error 2 > make: *** [/build/linux-5.2/Makefile:179: sub-make] Error 2 Do you have the same problem with Linus's tree right now? thanks, greg k-h
[PATCH] x86/nmi: remove the irqwork for long nmi handler duration warning
First, printk is NMI context safe now since the safe printk has been
implemented. The safe printk will help us to do such work in its irqwork.
Second, the NMI irqwork actually does not work if a NMI handler causes
watchdog timeout panic. The NMI irqwork have no chance to run in such
case, while the safe printk will flush its per-cpu buffer before panic.
Signed-off-by: Changbin Du
---
arch/x86/include/asm/nmi.h | 1 -
arch/x86/kernel/nmi.c | 20 +---
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/nmi.h b/arch/x86/include/asm/nmi.h
index 75ded1d13d98..9d5d949e662e 100644
--- a/arch/x86/include/asm/nmi.h
+++ b/arch/x86/include/asm/nmi.h
@@ -41,7 +41,6 @@ struct nmiaction {
struct list_headlist;
nmi_handler_t handler;
u64 max_duration;
- struct irq_work irq_work;
unsigned long flags;
const char *name;
};
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index 4df7705022b9..0fa51f80ad73 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -104,18 +104,22 @@ static int __init nmi_warning_debugfs(void)
}
fs_initcall(nmi_warning_debugfs);
-static void nmi_max_handler(struct irq_work *w)
+static void nmi_check_duration(struct nmiaction *action, u64 duration)
{
- struct nmiaction *a = container_of(w, struct nmiaction, irq_work);
int remainder_ns, decimal_msecs;
- u64 whole_msecs = READ_ONCE(a->max_duration);
+ u64 whole_msecs = READ_ONCE(action->max_duration);
+
+ if (duration < nmi_longest_ns || duration < action->max_duration)
+ return;
+
+ action->max_duration = duration;
remainder_ns = do_div(whole_msecs, (1000 * 1000));
decimal_msecs = remainder_ns / 1000;
printk_ratelimited(KERN_INFO
"INFO: NMI handler (%ps) took too long to run: %lld.%03d
msecs\n",
- a->handler, whole_msecs, decimal_msecs);
+ action->handler, whole_msecs, decimal_msecs);
}
static int nmi_handle(unsigned int type, struct pt_regs *regs)
@@ -142,11 +146,7 @@ static int nmi_handle(unsigned int type, struct pt_regs
*regs)
delta = sched_clock() - delta;
trace_nmi_handler(a->handler, (int)delta, thishandled);
- if (delta < nmi_longest_ns || delta < a->max_duration)
- continue;
-
- a->max_duration = delta;
- irq_work_queue(>irq_work);
+ nmi_check_duration(a, delta);
}
rcu_read_unlock();
@@ -164,8 +164,6 @@ int __register_nmi_handler(unsigned int type, struct
nmiaction *action)
if (!action->handler)
return -EINVAL;
- init_irq_work(>irq_work, nmi_max_handler);
-
raw_spin_lock_irqsave(>lock, flags);
/*
--
2.20.1
Re: [PATCH 4.4 0/9] 4.4.193-stable review
On Fri, 13 Sep 2019 at 09:08, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.193 release. > There are 9 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun 15 Sep 2019 01:03:32 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.193-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.4.193-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 0a1ee44c69166b2750a62fdb079320a396dff30c git describe: v4.4.192-10-g0a1ee44c6916 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.192-10-g0a1ee44c6916 No regressions (compared to build v4.4.192) No fixes (compared to build v4.4.192) Ran 20018 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * network-basic-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * kvm-unit-tests * ltp-pty-tests * install-android-platform-tools-r2600 * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * prep-tmp-disk * ssuite Summary kernel: 4.4.193-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.193-rc1-hikey-20190913-557 git commit: e289b20abbc0882c0710519376b654c0df71b784 git describe: 4.4.193-rc1-hikey-20190913-557 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.193-rc1-hikey-20190913-557 No regressions (compared to build 4.4.193-rc1-hikey-20190913-556) No fixes (compared to build 4.4.193-rc1-hikey-20190913-556) Ran 1536 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 5.2 00/37] 5.2.15-stable review
On Fri, 13 Sep 2019 at 09:21, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.2.15 release. > There are 37 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun 15 Sep 2019 01:03:32 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.15-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.2.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.2.15-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.2.y git commit: da2614d2744ab16514a2288de2039732935749d9 git describe: v5.2.14-38-gda2614d2744a Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.14-38-gda2614d2744a No regressions (compared to build v5.2.14) No fixes (compared to build v5.2.14) Ran 24151 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-commands-tests * ltp-containers-tests * ltp-cve-tests * ltp-dio-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * v4l2-compliance * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-fcntl-locktests-tests * network-basic-tests * perf * ltp-fs-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.19 000/190] 4.19.73-stable review
On Fri, 13 Sep 2019 at 09:11, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.73 release. > There are 190 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun 15 Sep 2019 01:03:32 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.73-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.19.73-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 490747a3f68a8ef2bba5b0cb5f29b896c02885c6 git describe: v4.19.72-191-g490747a3f68a Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.72-191-g490747a3f68a No regressions (compared to build v4.19.70) No fixes (compared to build v4.19.70) Ran 25136 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-fs-tests * network-basic-tests * ltp-open-posix-tests * kvm-unit-tests * ssuite * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
RE: [PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP node for ls1088a
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月12日 21:02
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
>
> Subject: Re: [PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP node for
> ls1088a
>
> On Tue, Sep 03, 2019 at 02:01:32AM +, Xiaowei Bao wrote:
> >
> >
> > > -Original Message-
> > > From: Andrew Murray
> > > Sent: 2019年9月2日 21:06
> > > To: Xiaowei Bao
> > > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > > Leo Li ; kis...@ti.com; lorenzo.pieral...@arm.com;
> M.h.
> > > Lian ; Mingkai Hu ; Roy
> > > Zang ; jingooh...@gmail.com;
> > > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> > > a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> > >
> > > Subject: Re: [PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP
> > > node for ls1088a
> > >
> > > On Mon, Sep 02, 2019 at 11:17:15AM +0800, Xiaowei Bao wrote:
> > > > Add PCIe EP node for ls1088a to support EP mode.
> > > >
> > > > Signed-off-by: Xiaowei Bao
> > > > ---
> > > > v2:
> > > > - Remove the pf-offset proparty.
> > > > v3:
> > > > - No change.
> > > >
> > > > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31
> > > ++
> > > > 1 file changed, 31 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > index c676d07..da246ab 100644
> > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > @@ -483,6 +483,17 @@
> > > > status = "disabled";
> > > > };
> > > >
> > > > + pcie_ep@340 {
> > > > + compatible =
> > > > "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > >
> > > Here you specify a fallback "fsl,ls-pcie-ep" that is removed by this
> > > series.
> > >
> > > Besides that, this looks OK.
> >
> > As explained, the "fsl,ls-pcie-ep" is needed, due to the u-boot will
> > fixup the status property base on this compatible, I think we reserve
> > this compatible is helpfully, if delate this compatible, I have to modify
> > the
> code of bootloader.
>
> I assume you mean that u-boot fixes up "fsl,ls-pcie-ep" *only* for ls1046a
> devices?
No, all Layerscape platform of NXP.
>
> Thanks,
>
> Andrew Murray
>
> >
> > Thanks
> > XIaowei
> >
> > >
> > > Thanks,
> > >
> > > Andrew Murray
> > >
> > > > + reg = <0x00 0x0340 0x0 0x0010
> > > > + 0x20 0x 0x8 0x>;
> > > > + reg-names = "regs", "addr_space";
> > > > + num-ib-windows = <24>;
> > > > + num-ob-windows = <128>;
> > > > + max-functions = /bits/ 8 <2>;
> > > > + status = "disabled";
> > > > + };
> > > > +
> > > > pcie@350 {
> > > > compatible = "fsl,ls1088a-pcie";
> > > > reg = <0x00 0x0350 0x0 0x0010 /*
> > > > controller
> > > registers */
> > > > @@ -508,6 +519,16 @@
> > > > status = "disabled";
> > > > };
> > > >
> > > > + pcie_ep@350 {
> > > > + compatible =
> > > > "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > > > + reg = <0x00 0x0350 0x0 0x0010
> > > > + 0x28 0x 0x8 0x>;
> > > > + reg-names = "regs", "addr_space";
> > > > + num-ib-windows = <6>;
> > > > + num-ob-windows = <8>;
> > > > + status = "disabled";
> > > > + };
> > > > +
> > > > pcie@360 {
> > > > compatible = "fsl,ls1088a-pcie";
> > > > reg = <0x00 0x0360 0x0 0x0010 /*
> > > > controller
> > > registers */
> > > > @@ -533,6 +554,16 @@
> > > > status = "disabled";
> > > > };
> > > >
> > > > + pcie_ep@360 {
> > > > + compatible =
> > > > "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > > > + reg = <0x00 0x0360 0x0 0x0010
> > > > + 0x30 0x 0x8 0x>;
> > > > + reg-names = "regs",
RE: [PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a in pci_device_id table
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月12日 21:00
> To: Xiaowei Bao ; helg...@kernel.org
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
>
> Subject: Re: [PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a in
> pci_device_id table
>
> On Tue, Sep 03, 2019 at 01:52:30AM +, Xiaowei Bao wrote:
> >
> >
> > > -Original Message-
> > > From: Andrew Murray
> > > Sent: 2019年9月2日 20:55
> > > To: Xiaowei Bao
> > > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > > Leo Li ; kis...@ti.com; lorenzo.pieral...@arm.com;
> M.h.
> > > Lian ; Mingkai Hu ; Roy
> > > Zang ; jingooh...@gmail.com;
> > > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> > > a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> > >
> > > Subject: Re: [PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a
> > > in pci_device_id table
> > >
> > > On Mon, Sep 02, 2019 at 11:17:16AM +0800, Xiaowei Bao wrote:
> > > > Add LS1088a in pci_device_id table so that pci-epf-test can be
> > > > used for testing PCIe EP in LS1088a.
> > > >
> > > > Signed-off-by: Xiaowei Bao
> > > > ---
> > > > v2:
> > > > - No change.
> > > > v3:
> > > > - No change.
> > > >
> > > > drivers/misc/pci_endpoint_test.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/misc/pci_endpoint_test.c
> > > > b/drivers/misc/pci_endpoint_test.c
> > > > index 6e208a0..d531951 100644
> > > > --- a/drivers/misc/pci_endpoint_test.c
> > > > +++ b/drivers/misc/pci_endpoint_test.c
> > > > @@ -793,6 +793,7 @@ static const struct pci_device_id
> > > pci_endpoint_test_tbl[] = {
> > > > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
> > > > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
> > > > { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0) },
> > > > + { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x80c0) },
> > >
> > > The Freescale PCI devices are the only devices in this table that
> > > don't have a define for their device ID. I think a define should be
> > > created for both of the device IDs above.
> >
> > OK, but I only define in this file, I am not sure this can define in
> > include/linux/pci_ids.h file
>
> This file seems a little inconsistent...
>
> - Two of the TI device IDs are defined in pci_ids.h and only used in
> pci_endpoint_test.c
> - One of the TI device IDs are defined in pci_endpoint_test.c and only used
> there
> - The Freescale device ID is hardcoded and only used in pci_endpoint_test.c
>
> The header in pci_ids.h has a comment suggestion definitions are only added
> where used in multiple files - yet I don't think this holds true.
Thanks Andrew.
>
> Bjorn - do you have a suggestion?
>
> Thanks,
>
> Andrew Murray
>
> >
> > Thanks
> > Xiaowei
> >
> > >
> > > Thanks,
> > >
> > > Andrew Murray
> > >
> > > > { PCI_DEVICE_DATA(SYNOPSYS, EDDA, NULL) },
> > > > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
> > > > .driver_data = (kernel_ulong_t)_data
> > > > --
> > > > 2.9.5
> > > >
RE: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月12日 20:50
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
>
> Subject: Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for
> ls1088a and ls2088a
>
> On Tue, Sep 03, 2019 at 01:47:36AM +, Xiaowei Bao wrote:
> >
> >
> > > -Original Message-
> > > From: Andrew Murray
> > > Sent: 2019年9月2日 20:46
> > > To: Xiaowei Bao
> > > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > > Leo Li ; kis...@ti.com; lorenzo.pieral...@arm.com;
> M.h.
> > > Lian ; Mingkai Hu ; Roy
> > > Zang ; jingooh...@gmail.com;
> > > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> > > a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> > >
> > > Subject: Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support
> > > for ls1088a and ls2088a
> > >
> > > On Mon, Sep 02, 2019 at 11:17:14AM +0800, Xiaowei Bao wrote:
> > > > Add PCIe EP mode support for ls1088a and ls2088a, there are some
> > > > difference between LS1 and LS2 platform, so refactor the code of
> > > > the EP driver.
> > > >
> > > > Signed-off-by: Xiaowei Bao
> > > > ---
> > > > v2:
> > > > - This is a new patch for supporting the ls1088a and ls2088a platform.
> > > > v3:
> > > > - Adjust the some struct assignment order in probe function.
> > > >
> > > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 72
> > > > +++---
> > > > 1 file changed, 53 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > index 5f0cb99..723bbe5 100644
> > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > @@ -20,27 +20,29 @@
> > > >
> > > > #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> > > >
> > > > -struct ls_pcie_ep {
> > > > - struct dw_pcie *pci;
> > > > - struct pci_epc_features *ls_epc;
> > > > +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > +
> > > > +struct ls_pcie_ep_drvdata {
> > > > + u32 func_offset;
> > > > + const struct dw_pcie_ep_ops *ops;
> > > > + const struct dw_pcie_ops*dw_pcie_ops;
> > > > };
> > > >
> > > > -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > +struct ls_pcie_ep {
> > > > + struct dw_pcie *pci;
> > > > + struct pci_epc_features *ls_epc;
> > > > + const struct ls_pcie_ep_drvdata *drvdata; };
> > > >
> > > > static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > > > return 0;
> > > > }
> > > >
> > > > -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > > > +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > > > .start_link = ls_pcie_establish_link, };
> > > >
> > > > -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > > - { .compatible = "fsl,ls-pcie-ep",},
> > > > - { },
> > > > -};
> > > > -
> > > > static const struct pci_epc_features*
> > > > ls_pcie_ep_get_features(struct dw_pcie_ep *ep) { @@ -87,10 +89,39
> > > > @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > > > }
> > > > }
> > > >
> > > > -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > > > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep
> *ep,
> > > > + u8 func_no)
> > > > +{
> > > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > > +
> > > > + WARN_ON(func_no && !pcie->drvdata->func_offset);
> > > > + return pcie->drvdata->func_offset * func_no; }
> > > > +
> > > > +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > > > .ep_init = ls_pcie_ep_init,
> > > > .raise_irq = ls_pcie_ep_raise_irq,
> > > > .get_features = ls_pcie_ep_get_features,
> > > > + .func_conf_select = ls_pcie_ep_func_conf_select, };
> > > > +
> > > > +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > > > + .ops = _pcie_ep_ops,
> > > > + .dw_pcie_ops = _ls_pcie_ep_ops, };
> > > > +
> > > > +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> > > > + .func_offset = 0x2,
> > > > + .ops = _pcie_ep_ops,
> > > > + .dw_pcie_ops = _ls_pcie_ep_ops, };
> > > >
Re: [v5 PATCH] RISC-V: Fix unsupported isa string info.
On Fri, 2019-09-13 at 13:47 -0700, Palmer Dabbelt wrote: > On Mon, 09 Sep 2019 23:00:10 PDT (-0700), Christoph Hellwig wrote: > > On Fri, Sep 06, 2019 at 11:27:57PM +, Atish Patra wrote: > > > > Agreed. May be something like this ? > > > > > > > > Let's say f/d is enabled in kernel but cpu doesn't support it. > > > > "unsupported isa" will only appear if there are any unsupported > > > > isa. > > > > > > > > processor : 3 > > > > hart: 4 > > > > isa : rv64imac > > > > unsupported isa : fd > > > > mmu : sv39 > > > > uarch : sifive,u54-mc > > > > > > > > May be I am just trying over optimize one corner case :) :). > > > > /proc/cpuinfo should just print all the isa string. That's it. > > > > > > > > > > Ping ? > > > > Yes, I agree with the "dumb" reporting of all capabilities. > > I agree: it looks like other architectures are passing info (ie, x86 > flags) > that isn't supported by userspace. We have the ELF hwcap stuff for > those who > want to tell which instructions they can run, so it's sane to just > keep this > simple. Great. That will simplify the code path as well. I will send a v6 with the fixes. -- Regards, Atish
Re: [PATCH 4.14 00/21] 4.14.144-stable review
On Fri, 13 Sep 2019 at 09:11, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.144 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun 15 Sep 2019 01:03:32 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.144-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.14.144-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 6073f0ee406c52baaf3625e28c631a33b20efef5 git describe: v4.14.143-22-g6073f0ee406c Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.143-22-g6073f0ee406c No regressions (compared to build v4.14.142-41-g9ea9c62091b3) No fixes (compared to build v4.14.142-41-g9ea9c62091b3) Ran 23599 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-containers-tests * ltp-fs-tests * network-basic-tests * ltp-open-posix-tests * kvm-unit-tests * ssuite * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] riscv: modify the Image header to improve compatibility with the ARM64 header
On Fri, 2019-09-13 at 20:08 -0700, Paul Walmsley wrote: > Part of the intention during the definition of the RISC-V kernel > image > header was to lay the groundwork for a future merge with the ARM64 > image header. One error during my original review was not noticing > that the RISC-V header's "magic" field was at a different size and > position than the ARM64's "magic" field. If the existing ARM64 Image > header parsing code were to attempt to parse an existing RISC-V > kernel > image header format, it would see a magic number 0. This is > undesirable, since it's our intention to align as closely as possible > with the ARM64 header format. Another problem was that the original > "res3" field was not being initialized correctly to zero. > > Address these issues by creating a 32-bit "magic2" field in the RISC- > V > header which matches the ARM64 "magic" field. RISC-V binaries will > store "RSC\x05" in this field. The intention is that the use of the > existing 64-bit "magic" field in the RISC-V header will be deprecated > over time. Increment the minor version number of the file format to > indicate this change, and update the documentation accordingly. Fix > the assembler directives in head.S to ensure that reserved fields are > properly zero-initialized. > Thanks for the quick fix. Is there a planned timeline when we can remove the deprecated magic ? I was planning to send a U-boot header documentation patch to match Linux one anyways. Do you want me that to rebase based on this patch or are you planning to send a U-boot patch as well ? > Signed-off-by: Paul Walmsley > Reported-by: Palmer Dabbelt > Cc: Atish Patra > Cc: Karsten Merker > --- > Will try to get this merged before v5.3, to minimize the delta with > the > ARM64 header in the final release. > > Documentation/riscv/boot-image-header.txt | 13 +++-- > arch/riscv/include/asm/image.h| 12 ++-- > arch/riscv/kernel/head.S | 4 ++-- > 3 files changed, 15 insertions(+), 14 deletions(-) > > diff --git a/Documentation/riscv/boot-image-header.txt > b/Documentation/riscv/boot-image-header.txt > index 1b73fea23b39..14b1492f689b 100644 > --- a/Documentation/riscv/boot-image-header.txt > +++ b/Documentation/riscv/boot-image-header.txt There is a patch already queued that changed the format to ReST. You need to rebase the patch accordingly https://lkml.org/lkml/2019/7/26/1321 > @@ -18,7 +18,7 @@ The following 64-byte header is present in > decompressed Linux kernel image. > u32 res1 = 0;/* Reserved */ > u64 res2 = 0;/* Reserved */ > u64 magic = 0x5643534952; /* Magic number, little endian, > "RISCV" */ > - u32 res3; /* Reserved for additional RISC-V specific > header */ > + u32 magic2 = 0x56534905; /* Magic number 2, little endian, > "RSC\x05" */ > u32 res4; /* Reserved for PE COFF offset */ > > This header format is compliant with PE/COFF header and largely > inspired from > @@ -37,13 +37,14 @@ Notes: > Bits 16:31 - Major version > >This preserves compatibility across newer and older version of the > header. > - The current version is defined as 0.1. > + The current version is defined as 0.2. > > -- res3 is reserved for offset to any other additional fields. This > makes the > - header extendible in future. One example would be to accommodate > ISA > - extension for RISC-V in future. For current version, it is set to > be zero. > +- The "magic" field is deprecated as of version 0.2. In a future > + release, it may be removed. This originally should have matched > up > + with the ARM64 header "magic" field, but unfortunately does not. > + The "magic2" field replaces it, matching up with the ARM64 header. > > -- In current header, the flag field has only one field. > +- In current header, the flags field has only one field. > Bit 0: Kernel endianness. 1 if BE, 0 if LE. > > - Image size is mandatory for boot loader to load kernel image. > Booting will > diff --git a/arch/riscv/include/asm/image.h > b/arch/riscv/include/asm/image.h > index ef28e106f247..344db5244547 100644 > --- a/arch/riscv/include/asm/image.h > +++ b/arch/riscv/include/asm/image.h > @@ -3,7 +3,8 @@ > #ifndef __ASM_IMAGE_H > #define __ASM_IMAGE_H > > -#define RISCV_IMAGE_MAGIC"RISCV" > +#define RISCV_IMAGE_MAGIC"RISCV\0\0\0" > +#define RISCV_IMAGE_MAGIC2 "RSC\x05" > > #define RISCV_IMAGE_FLAG_BE_SHIFT0 > #define RISCV_IMAGE_FLAG_BE_MASK 0x1 > @@ -23,7 +24,7 @@ > #define __HEAD_FLAGS (__HEAD_FLAG(BE)) > > #define RISCV_HEADER_VERSION_MAJOR 0 > -#define RISCV_HEADER_VERSION_MINOR 1 > +#define RISCV_HEADER_VERSION_MINOR 2 > > #define RISCV_HEADER_VERSION (RISCV_HEADER_VERSION_MAJOR << 16 | \ > RISCV_HEADER_VERSION_MINOR) > @@ -39,9 +40,8 @@ > * @version: version > * @res1:reserved > * @res2:
Re: [PATCH 4.9 00/14] 4.9.193-stable review
On Fri, 13 Sep 2019 at 09:09, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.193 release. > There are 14 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun 15 Sep 2019 01:03:32 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.193-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.9.193-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 8e25fc1750f0dd9f378c153ecda509a578059b81 git describe: v4.9.192-15-g8e25fc1750f0 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.192-15-g8e25fc1750f0 No regressions (compared to build v4.9.192) No fixes (compared to build v4.9.192) Ran 23550 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * network-basic-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * prep-tmp-disk * ssuite -- Linaro LKFT https://lkft.linaro.org
[PATCH] ASoC: sdm845: remove unneeded semicolon
Remove excess semicolon after closing parenthesis. Signed-off-by: Saiyam Doshi --- sound/soc/qcom/sdm845.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c index 882f52ed8231..28f3cef696e6 100644 --- a/sound/soc/qcom/sdm845.c +++ b/sound/soc/qcom/sdm845.c @@ -319,7 +319,7 @@ static void sdm845_snd_shutdown(struct snd_pcm_substream *substream) snd_soc_dai_set_sysclk(cpu_dai, Q6AFE_LPASS_CLK_ID_PRI_MI2S_IBIT, 0, SNDRV_PCM_STREAM_PLAYBACK); - }; + } break; case SECONDARY_MI2S_TX: -- 2.20.1
[PATCH] riscv: modify the Image header to improve compatibility with the ARM64 header
Part of the intention during the definition of the RISC-V kernel image
header was to lay the groundwork for a future merge with the ARM64
image header. One error during my original review was not noticing
that the RISC-V header's "magic" field was at a different size and
position than the ARM64's "magic" field. If the existing ARM64 Image
header parsing code were to attempt to parse an existing RISC-V kernel
image header format, it would see a magic number 0. This is
undesirable, since it's our intention to align as closely as possible
with the ARM64 header format. Another problem was that the original
"res3" field was not being initialized correctly to zero.
Address these issues by creating a 32-bit "magic2" field in the RISC-V
header which matches the ARM64 "magic" field. RISC-V binaries will
store "RSC\x05" in this field. The intention is that the use of the
existing 64-bit "magic" field in the RISC-V header will be deprecated
over time. Increment the minor version number of the file format to
indicate this change, and update the documentation accordingly. Fix
the assembler directives in head.S to ensure that reserved fields are
properly zero-initialized.
Signed-off-by: Paul Walmsley
Reported-by: Palmer Dabbelt
Cc: Atish Patra
Cc: Karsten Merker
---
Will try to get this merged before v5.3, to minimize the delta with the
ARM64 header in the final release.
Documentation/riscv/boot-image-header.txt | 13 +++--
arch/riscv/include/asm/image.h| 12 ++--
arch/riscv/kernel/head.S | 4 ++--
3 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/Documentation/riscv/boot-image-header.txt
b/Documentation/riscv/boot-image-header.txt
index 1b73fea23b39..14b1492f689b 100644
--- a/Documentation/riscv/boot-image-header.txt
+++ b/Documentation/riscv/boot-image-header.txt
@@ -18,7 +18,7 @@ The following 64-byte header is present in decompressed Linux
kernel image.
u32 res1 = 0;/* Reserved */
u64 res2 = 0;/* Reserved */
u64 magic = 0x5643534952; /* Magic number, little endian, "RISCV" */
- u32 res3; /* Reserved for additional RISC-V specific
header */
+ u32 magic2 = 0x56534905; /* Magic number 2, little endian, "RSC\x05" */
u32 res4; /* Reserved for PE COFF offset */
This header format is compliant with PE/COFF header and largely inspired from
@@ -37,13 +37,14 @@ Notes:
Bits 16:31 - Major version
This preserves compatibility across newer and older version of the header.
- The current version is defined as 0.1.
+ The current version is defined as 0.2.
-- res3 is reserved for offset to any other additional fields. This makes the
- header extendible in future. One example would be to accommodate ISA
- extension for RISC-V in future. For current version, it is set to be zero.
+- The "magic" field is deprecated as of version 0.2. In a future
+ release, it may be removed. This originally should have matched up
+ with the ARM64 header "magic" field, but unfortunately does not.
+ The "magic2" field replaces it, matching up with the ARM64 header.
-- In current header, the flag field has only one field.
+- In current header, the flags field has only one field.
Bit 0: Kernel endianness. 1 if BE, 0 if LE.
- Image size is mandatory for boot loader to load kernel image. Booting will
diff --git a/arch/riscv/include/asm/image.h b/arch/riscv/include/asm/image.h
index ef28e106f247..344db5244547 100644
--- a/arch/riscv/include/asm/image.h
+++ b/arch/riscv/include/asm/image.h
@@ -3,7 +3,8 @@
#ifndef __ASM_IMAGE_H
#define __ASM_IMAGE_H
-#define RISCV_IMAGE_MAGIC "RISCV"
+#define RISCV_IMAGE_MAGIC "RISCV\0\0\0"
+#define RISCV_IMAGE_MAGIC2 "RSC\x05"
#define RISCV_IMAGE_FLAG_BE_SHIFT 0
#define RISCV_IMAGE_FLAG_BE_MASK 0x1
@@ -23,7 +24,7 @@
#define __HEAD_FLAGS (__HEAD_FLAG(BE))
#define RISCV_HEADER_VERSION_MAJOR 0
-#define RISCV_HEADER_VERSION_MINOR 1
+#define RISCV_HEADER_VERSION_MINOR 2
#define RISCV_HEADER_VERSION (RISCV_HEADER_VERSION_MAJOR << 16 | \
RISCV_HEADER_VERSION_MINOR)
@@ -39,9 +40,8 @@
* @version: version
* @res1: reserved
* @res2: reserved
- * @magic: Magic number
- * @res3: reserved (will be used for additional RISC-V specific
- * header)
+ * @magic: Magic number (RISC-V specific; deprecated)
+ * @magic2:Magic number 2 (to match the ARM64 'magic' field pos)
* @res4: reserved (will be used for PE COFF offset)
*
* The intention is for this header format to be shared between multiple
@@ -58,7 +58,7 @@ struct riscv_image_header {
u32 res1;
u64 res2;
u64 magic;
- u32 res3;
+ u32 magic2;
u32 res4;
};
#endif /* __ASSEMBLY__ */
diff --git a/arch/riscv/kernel/head.S
[PATCH for vm-scalability] usemem: Add new option -Z|--read-again
usemem will read memory again after access the memory with this option.
It can help test the speed that load page from swap to memory.
Signed-off-by: Hui Zhu
---
usemem.c | 46 --
1 file changed, 40 insertions(+), 6 deletions(-)
diff --git a/usemem.c b/usemem.c
index 264d52a..2d31946 100644
--- a/usemem.c
+++ b/usemem.c
@@ -94,6 +94,7 @@ int opt_sync_rw = 0;
int opt_sync_free = 0;
int opt_bind_interval = 0;
unsigned long opt_delay = 0;
+int opt_read_again = 0;
int nr_task;
int nr_thread;
int nr_cpu;
@@ -151,6 +152,7 @@ void usage(int ok)
"-e|--delay delay for each page in ns\n"
"-O|--anonymous mmap with MAP_ANONYMOUS\n"
"-U|--hugetlballocate hugetlbfs page\n"
+ "-Z|--read-again read memory again after access the memory\n"
"-h|--help show this message\n"
, ourname);
@@ -188,6 +190,7 @@ static const struct option opts[] = {
{ "sync-rw" , 0, NULL, 'y' },
{ "delay" , 1, NULL, 'e' },
{ "hugetlb" , 0, NULL, 'U' },
+ { "read-again" , 0, NULL, 'Z' },
{ "help", 0, NULL, 'h' },
{ NULL , 0, NULL, 0 }
};
@@ -616,7 +619,7 @@ unsigned long do_unit(unsigned long bytes, struct
drand48_data *rand_data,
return rw_bytes;
}
-static void output_statistics(unsigned long unit_bytes)
+static void output_statistics(unsigned long unit_bytes, const char *intro)
{
struct timeval stop;
char buf[1024];
@@ -629,8 +632,8 @@ static void output_statistics(unsigned long unit_bytes)
(stop.tv_usec - start_time.tv_usec);
throughput = ((unit_bytes * 100ULL) >> 10) / delta_us;
len = snprintf(buf, sizeof(buf),
- "%lu bytes / %lu usecs = %lu KB/s\n",
- unit_bytes, delta_us, throughput);
+ "%s%lu bytes / %lu usecs = %lu KB/s\n",
+ intro, unit_bytes, delta_us, throughput);
fflush(stdout);
write(1, buf, len);
}
@@ -690,7 +693,34 @@ long do_units(void)
} while (bytes);
if (!opt_write_signal_read && unit_bytes)
- output_statistics(unit_bytes);
+ output_statistics(unit_bytes, "");
+
+ if (opt_read_again && unit_bytes) {
+ unsigned long rw_bytes = 0;
+
+ gettimeofday(_time, NULL);
+ for (i = 0; i < nptr; i++) {
+ int rep;
+
+ for (rep = 0; rep < reps; rep++) {
+ if (rep > 0 && !quiet) {
+ printf(".");
+ fflush(stdout);
+ }
+
+ rw_bytes += do_rw_once(ptrs[i], lens[i],
_data, 1, , reps);
+
+ if (msync_mode) {
+ if ((msync(ptrs[i], lens[i],
msync_mode)) == -1) {
+ fprintf(stderr, "msync failed
with error %s \n", strerror(errno));
+ exit(1);
+ }
+ }
+ }
+ }
+
+ output_statistics(rw_bytes, "read again ");
+ }
if (opt_write_signal_read) {
struct sigaction act;
@@ -731,7 +761,7 @@ long do_units(void)
sigsuspend();
gettimeofday(_time, NULL);
unit_bytes = do_rw_once(buffer, opt_bytes, _data, 1, NULL,
0);
- output_statistics(unit_bytes);
+ output_statistics(unit_bytes, "");
}
if (opt_sync_free)
@@ -879,7 +909,7 @@ int main(int argc, char *argv[])
pagesize = getpagesize();
while ((c = getopt_long(argc, argv,
-
"aAB:f:FPp:gqowRMm:n:t:b:ds:T:Sr:u:j:e:EHDNLWyxOUh", opts, NULL)) != -1)
+
"aAB:f:FPp:gqowRMm:n:t:b:ds:T:Sr:u:j:e:EHDNLWyxOUZh", opts, NULL)) != -1)
{
switch (c) {
case 'a':
@@ -1005,6 +1035,10 @@ int main(int argc, char *argv[])
map_hugetlb = MAP_HUGETLB | MAP_HUGE_2MB;
break;
+ case 'Z':
+ opt_read_again = 1;
+ break;
+
default:
usage(1);
}
--
2.7.4
[PATCH] arm64: dts: meson: Add capacity-dmips-mhz attributes to G12B
From: Frank Hartung From: Frank Hartung Meson G12B SoCs (S922X and A311D) are a big-little design where not all CPUs are equal; the A53s cores are weaker than the A72s. Include capacity-dmips-mhz properties to tell the OS there is a difference in processing capacity. The dmips values are based on similar submissions for other A53/A72 SoCs: HiSilicon 3660 [1] and Rockchip RK3399 [2]. This change is particularly beneficial for use-cases like retro gaming where emulators often run on a single core. The OS now chooses an A72 core instead of an A53 core. [1] https://lore.kernel.org/patchwork/patch/862742/ [2] https://patchwork.kernel.org/patch/10836577/ Signed-off-by: Frank Hartung Signed-off-by: Christian Hewitt --- arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi index 5628ccd..7f78d88 100644 --- a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi +++ b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi @@ -49,6 +49,7 @@ compatible = "arm,cortex-a53"; reg = <0x0 0x0>; enable-method = "psci"; + capacity-dmips-mhz = <592>; next-level-cache = <>; }; @@ -57,6 +58,7 @@ compatible = "arm,cortex-a53"; reg = <0x0 0x1>; enable-method = "psci"; + capacity-dmips-mhz = <592>; next-level-cache = <>; }; @@ -65,6 +67,7 @@ compatible = "arm,cortex-a73"; reg = <0x0 0x100>; enable-method = "psci"; + capacity-dmips-mhz = <1024>; next-level-cache = <>; }; @@ -73,6 +76,7 @@ compatible = "arm,cortex-a73"; reg = <0x0 0x101>; enable-method = "psci"; + capacity-dmips-mhz = <1024>; next-level-cache = <>; }; @@ -81,6 +85,7 @@ compatible = "arm,cortex-a73"; reg = <0x0 0x102>; enable-method = "psci"; + capacity-dmips-mhz = <1024>; next-level-cache = <>; }; @@ -89,6 +94,7 @@ compatible = "arm,cortex-a73"; reg = <0x0 0x103>; enable-method = "psci"; + capacity-dmips-mhz = <1024>; next-level-cache = <>; }; -- 2.7.4
Re: [PATCH v5 00/13] Common patches from downstream development
On Tue, Aug 27, 2019 at 01:18:16PM +, Philippe Schenker wrote: > > This patchset holds some common changes that were never upstreamed. > With latest downstream kernel upgrade, I took the aproach to select > mainline devicetrees and atomically add missing stuff for downstream. > > These patches I send here are separated out with changes that also > have a benefit for mainline. > > - Update version 4 and later --- > Patches that got pulled in an earlier patchset version got dropped in > this patchset. > > > Philippe > > Changes in v5: > - changed legacy gpio-key,wakeup to wakeup-source > - Add note in commit message about disabled status > - Added Olek's reviewed-by > - change group name > - Add pinmux to iomuxc > - Adjusted commit message > - Switched to consistent naming: pinctrl_xxx: xxxgrp > - Added Olek's Reviewed-by > - Added Olek's Reviewed-by > - Added Olek's Reviewed-by > - Added Olek's Reviewd-by > - Added Olek's Reviewed-by > - Add Olek's Reviewed-by > - Added note to commit message about disabled status > - Add Olek's Reviewed-by > > Changes in v4: > - Add Marcel Ziswiler's Ack > - Add Marcel Ziswiler's Ack > - Add Marcel Ziswiler's Ack > - Add Marcel Ziswiler's Ack > - Add Marcel Ziswiler's Ack > - Add Marcel Ziswiler's Ack > - Add Marcel Ziswiler's Ack > - Add Marcel Ziswiler's Ack > - Add Marcel Ziswiler's Ack > - Add Marcel Ziswiler's Ack > - Move can nodes to module deviceteree include imx6ull-colibri.dtsi > - Add Marcel Ziswiler's Ack > > Changes in v3: > - Add new commit message from Stefan's proposal on ML > - Fix commit message > - Fix commit title to "...imx6-apalis:..." > > Changes in v2: > - Deleted touchrevolution downstream stuff > - Use generic node name > - Better comment > - Changed commit title to '...imx6qdl-apalis:...' > - Deleted touchrevolution downstream stuff > - Use generic node name > - Put a better comment in there > - Commit title > - Removed f0710a > that is downstream only > - Changed to generic node name > - Better comment > > Max Krummenacher (2): > ARM: dts: imx6ull-colibri: reduce v_batt current in power off > ARM: dts: imx6ull: improve can templates > > Philippe Schenker (9): > ARM: dts: imx7-colibri: Add touch controllers > ARM: dts: imx6qdl-colibri: Add missing pin declaration in iomuxc > ARM: dts: imx6qdl-apalis: Add sleep state to can interfaces > ARM: dts: imx6-apalis: Add touchscreens used on Toradex eval boards > ARM: dts: imx6-colibri: Add missing pinmuxing to Toradex eval board > ARM: dts: imx6ull-colibri: Add sleep mode to fec > ARM: dts: imx6ull-colibri: Add watchdog > ARM: dts: imx6ull-colibri: Add general wakeup key used on Colibri > ARM: dts: imx6ull-colibri: Add touchscreen used with Eval Board Applied all, but except this one which uses base64 Content-Transfer-Encoding. Shawn > > Stefan Agner (2): > ARM: dts: imx7-colibri: add GPIO wakeup key > ARM: dts: imx7-colibri: fix 1.8V/UHS support > > arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 39 +++ > arch/arm/boot/dts/imx6q-apalis-eval.dts | 13 > arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts | 13 > arch/arm/boot/dts/imx6q-apalis-ixora.dts | 13 > arch/arm/boot/dts/imx6qdl-apalis.dtsi | 27 ++-- > arch/arm/boot/dts/imx6qdl-colibri.dtsi| 17 + > .../arm/boot/dts/imx6ull-colibri-eval-v3.dtsi | 38 +++ > .../arm/boot/dts/imx6ull-colibri-nonwifi.dtsi | 2 +- > arch/arm/boot/dts/imx6ull-colibri-wifi.dtsi | 2 +- > arch/arm/boot/dts/imx6ull-colibri.dtsi| 64 +-- > arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 38 +++ > arch/arm/boot/dts/imx7-colibri.dtsi | 30 - > 12 files changed, 280 insertions(+), 16 deletions(-) > > -- > 2.23.0 >
Re: [PATCH glibc 2.31 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v12)
* Mathieu Desnoyers: > I'm unsure whether there are changes I need to do in my rseq patchset, or > if this is a separate issue that will be fixed separately before glibc 2.31 > is out, which would then update the rseq bits accordingly ? Someone else (perhaps me) has to fix __libc_multiple_libcs. Then you can use it instead/in addition to the rtld_active check (depending on the semantics we agree upon for __libc_multiple_libcs). Fixing __libc_multiple_libcs may also address the early initialization issue because for that to be always correct, we need to run the initialization code before ELF constructors. >>> I'm less convinced that we actually need this. I don't think we have >>> ever done anything like that before, and I don't think it's necessary. >>> Any secondary rseq library just needs to note if it could perform >>> registration, and if it failed to do so, do not perform unregistration >>> in a pthread destructor callback. > > If that secondary rseq library happens to try to perform registration within > its library constructor (before glibc has performed the __rseq_abi TLS > registration), we end up in a situation where the secondary library takes > ownership of rseq, even though libc would require ownership. This is a > scenario we want to avoid. We can avoid that if we run the glibc initialization before user code (except IFUNC resolvers). glibc itself doesn't have to do the initialization from an ELF constructor. > Making sure libc reserves ownership through __rseq_handled (which is > a non-TLS variable that can be accessed early in the program lifetime) > protects against this. If that's it's only purpose, I don't think it's necessary. If the kernel can fail the second registration attempt, that would be all the information the alternative rseq implementation needs (plus the matter of destruction). Thanks, Florian
Greetings From Mrs. Hilda Kickett Hancock.
Greetings From Mrs. Hilda Kickett Hancock. May this day bring you peace, happiness, prosperity, good health and every blessings from above, may all of your wishes and dreams come true! I was touched to send this message to you after I have carefully gone through your profile that speaks good of you in your country. I am Dr. Mrs. Hilda Kickett Hancock a 69 years old woman from Australia, I am writing this message to let you know my heart desire to establish a charity foundation in your country through your noble assistance. For more information, please respond to me via my personal E-mail: hildhanc...@yahoo.com for more details. The future belongs to those who believe in the beauty of their dreams. Yours respectfully, Mrs. Hilda Hancock
Re: [PATCH] e1000: fix memory leaks
On Mon, 2019-08-12 at 00:59 -0500, Wenwen Wang wrote: > In e1000_set_ringparam(), 'tx_old' and 'rx_old' are not deallocated if > e1000_up() fails, leading to memory leaks. Refactor the code to fix this > issue. > > Signed-off-by: Wenwen Wang > --- > drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) Tested-by: Aaron Brown
Re: [PATCH] igb/igc: Don't warn on fatal read failures when the device is removed
On Thu, 2019-08-22 at 14:33 -0400, Lyude Paul wrote:
> Fatal read errors are worth warning about, unless of course the device
> was just unplugged from the machine - something that's a rather normal
> occurence when the igb/igc adapter is located on a Thunderbolt dock. So,
> let's only WARN() if there's a fatal read error while the device is
> still present.
>
> This fixes the following WARN splat that's been appearing whenever I
> unplug my Caldigit TS3 Thunderbolt dock from my laptop:
>
> igb :09:00.0 enp9s0: PCIe link lost
> [ cut here ]
> igb: Failed to read reg 0x18!
> WARNING: CPU: 7 PID: 516 at
> drivers/net/ethernet/intel/igb/igb_main.c:756 igb_rd32+0x57/0x6a [igb]
> Modules linked in: igb dca thunderbolt fuse vfat fat elan_i2c mei_wdt
> mei_hdcp i915 wmi_bmof intel_wmi_thunderbolt iTCO_wdt
> iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp joydev
> coretemp crct10dif_pclmul crc32_pclmul i2c_algo_bit ghash_clmulni_intel
> intel_cstate drm_kms_helper intel_uncore syscopyarea sysfillrect
> sysimgblt fb_sys_fops intel_rapl_perf intel_xhci_usb_role_switch mei_me
> drm roles idma64 i2c_i801 ucsi_acpi typec_ucsi mei intel_lpss_pci
> processor_thermal_device typec intel_pch_thermal intel_soc_dts_iosf
> intel_lpss int3403_thermal thinkpad_acpi wmi int340x_thermal_zone
> ledtrig_audio int3400_thermal acpi_thermal_rel acpi_pad video
> pcc_cpufreq ip_tables serio_raw nvme nvme_core crc32c_intel uas
> usb_storage e1000e i2c_dev
> CPU: 7 PID: 516 Comm: kworker/u16:3 Not tainted 5.2.0-rc1Lyude-Test+ #14
> Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 )
> 04/09/2018
> Workqueue: kacpi_hotplug acpi_hotplug_work_fn
> RIP: 0010:igb_rd32+0x57/0x6a [igb]
> Code: 87 b8 fc ff ff 48 c7 47 08 00 00 00 00 48 c7 c6 33 42 9b c0 4c 89
> c7 e8 47 45 cd dc 89 ee 48 c7 c7 43 42 9b c0 e8 c1 94 71 dc <0f> 0b eb
> 08 8b 00 ff c0 75 b0 eb c8 44 89 e0 5d 41 5c c3 0f 1f 44
> RSP: 0018:ba5801cf7c48 EFLAGS: 00010286
> RAX: RBX: 9e7956608840 RCX: 0007
> RDX: RSI: ba5801cf7b24 RDI: 9e795e3d6a00
> RBP: 0018 R08: 9dec4a01 R09: 9e61018f
> R10: R11: ba5801cf7ae5 R12:
> R13: 9e7956608840 R14: 9e795a6f10b0 R15:
> FS: () GS:9e795e3c() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 564317bc4088 CR3: 00010e00a006 CR4: 003606e0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> Call Trace:
>igb_release_hw_control+0x1a/0x30 [igb]
>igb_remove+0xc5/0x14b [igb]
>pci_device_remove+0x3b/0x93
>device_release_driver_internal+0xd7/0x17e
>pci_stop_bus_device+0x36/0x75
>pci_stop_bus_device+0x66/0x75
>pci_stop_bus_device+0x66/0x75
>pci_stop_and_remove_bus_device+0xf/0x19
>trim_stale_devices+0xc5/0x13a
>? __pm_runtime_resume+0x6e/0x7b
>trim_stale_devices+0x103/0x13a
>? __pm_runtime_resume+0x6e/0x7b
>trim_stale_devices+0x103/0x13a
>acpiphp_check_bridge+0xd8/0xf5
>acpiphp_hotplug_notify+0xf7/0x14b
>? acpiphp_check_bridge+0xf5/0xf5
>acpi_device_hotplug+0x357/0x3b5
>acpi_hotplug_work_fn+0x1a/0x23
>process_one_work+0x1a7/0x296
>worker_thread+0x1a8/0x24c
>? process_scheduled_works+0x2c/0x2c
>kthread+0xe9/0xee
>? kthread_destroy_worker+0x41/0x41
>ret_from_fork+0x35/0x40
> ---[ end trace 252bf10352c63d22 ]---
>
> Signed-off-by: Lyude Paul
> Fixes: 47e16692b26b ("igb/igc: warn when fatal read failure happens")
> Cc: Feng Tang
> Cc: Sasha Neftin
> Cc: Jeff Kirsher
> Cc: intel-wired-...@lists.osuosl.org
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 3 ++-
> drivers/net/ethernet/intel/igc/igc_main.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
Tested-by: Aaron Brown
Re: [PATCH v22 00/24] Intel SGX foundations
On 9/3/19 7:26 AM, Jarkko Sakkinen wrote: > Not having LSM hooks does not cause any risk to other parts of the > kernel as the device can still be controlled by using DAC permissions. > The hooks just provide more granularity than DAC in access decisions. Could we translate the security-speak to english, please? :) Is this it: LSMs can (try to) enforce things like "all executable code must be verified". The implementation in these patches has the potential to subvert policies like that since it has its own unique mechanisms for loading and mapping executable code. This will be fixed by future LSM enhancements on top of this set. For now, permissions on the SGX device file should be used to prevent untrusted users from using SGX to subvert LSM policies. ?
Re: [PATCH 5.2 36/37] vhost: block speculation of translated descriptors
Hi On 2019-09-13, Greg Kroah-Hartman wrote: > From: Michael S. Tsirkin > > commit a89db445fbd7f1f8457b03759aa7343fa530ef6b upstream. > > iovec addresses coming from vhost are assumed to be > pre-validated, but in fact can be speculated to a value > out of range. > > Userspace address are later validated with array_index_nospec so we can > be sure kernel info does not leak through these addresses, but vhost > must also not leak userspace info outside the allowed memory table to > guests. > > Following the defence in depth principle, make sure > the address is not validated out of node range. [...] This fails to compile as part of 5.2.15-rc1 on i386 (amd64 is fine), using gcc 9.2.1. Reverting just this patch results in a successful build again. > --- a/drivers/vhost/vhost.c > +++ b/drivers/vhost/vhost.c > @@ -1965,8 +1965,10 @@ static int translate_desc(struct vhost_v > _iov = iov + ret; > size = node->size - addr + node->start; > _iov->iov_len = min((u64)len - s, size); > - _iov->iov_base = (void __user *)(unsigned long) > - (node->userspace_addr + addr - node->start); > + _iov->iov_base = (void __user *) > + ((unsigned long)node->userspace_addr + > + array_index_nospec((unsigned long)(addr - node->start), > + node->size)); > s += size; > addr += size; > ++ret; > > CC [M] drivers/vhost/vhost.o In file included from /build/linux-5.2/include/linux/export.h:45, from /build/linux-5.2/include/linux/linkage.h:7, from /build/linux-5.2/include/linux/kernel.h:8, from /build/linux-5.2/include/linux/list.h:9, from /build/linux-5.2/include/linux/wait.h:7, from /build/linux-5.2/include/linux/eventfd.h:13, from /build/linux-5.2/drivers/vhost/vhost.c:13: /build/linux-5.2/drivers/vhost/vhost.c: In function 'translate_desc': /build/linux-5.2/include/linux/compiler.h:345:38: error: call to '__compiletime_assert_1970' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long) 345 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^ /build/linux-5.2/include/linux/compiler.h:326:4: note: in definition of macro '__compiletime_assert' 326 |prefix ## suffix();\ |^~ /build/linux-5.2/include/linux/compiler.h:345:2: note: in expansion of macro '_compiletime_assert' 345 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^~~ /build/linux-5.2/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) | ^~ /build/linux-5.2/include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ /build/linux-5.2/include/linux/nospec.h:56:2: note: in expansion of macro 'BUILD_BUG_ON' 56 | BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \ | ^~~~ /build/linux-5.2/drivers/vhost/vhost.c:1970:5: note: in expansion of macro 'array_index_nospec' 1970 | array_index_nospec((unsigned long)(addr - node->start), | ^~ make[3]: *** [/build/linux-5.2/scripts/Makefile.build:285: drivers/vhost/vhost.o] Error 1 make[2]: *** [/build/linux-5.2/scripts/Makefile.build:489: drivers/vhost] Error 2 make[1]: *** [/build/linux-5.2/Makefile:1072: drivers] Error 2 make: *** [/build/linux-5.2/Makefile:179: sub-make] Error 2 Regards Stefan Lippers-Hollmann
Re: [PATCH 4/4] x86: fix function types in COND_SYSCALL
> On Sep 13, 2019, at 4:28 PM, Sami Tolvanen wrote: > >> On Fri, Sep 13, 2019 at 3:46 PM Andy Lutomirski wrote: >> Didn't you just fix the type of sys_ni_syscall? What am I missing here? > > The other patch fixes indirect call type mismatches when the function > is called through the syscall table. However, cond_syscall creates an > alias to the actual sys_ni_syscall function defined in > kernel/sys_ni.c, which still has the wrong type. > Ah, I get it. Doesn’t this cause a little bit of code bloat, though? What if you made __x86_ni_syscall, etc (possibly using the *DEFINE_SYSCALL0 macros) and then generate weak aliases to those?
Re: [PATCH 3/4] x86: use the correct function type for sys_ni_syscall
> On Sep 13, 2019, at 4:26 PM, Sami Tolvanen wrote: > >> On Fri, Sep 13, 2019 at 3:45 PM Andy Lutomirski wrote: >> Should this be SYSCALL_DEFINE0? > > It can be, and that would also fix the issue. However, it does result > in unnecessary error injection to be hooked up here, which is why > arm64 preferred to avoid the macro when I fixed it there. S390 uses > SYSCALL_DEFINE0 for this though and since sys_ni_syscall always > returns -ENOSYS, it shouldn't be a huge problem. Thoughts? > I don’t see why all syscalls except these few should have error injection hooked up. It’s also IMO nicer from a maintenance perspective to have all syscalls use the same macros. Will, is there something I’m missing?
RE: [PATCH] hv_balloon: Add the support of hibernation
> From: David Hildenbrand > Sent: Friday, September 13, 2019 2:44 PM > > > On recent Windows Server 2019+ hosts, the toolstacks on the hosts > > guarantees that Dynamic Memory and Memory Resizing can not be enabled > > if the virtual ACPI S4 state is enabled, and vice versa. Please refer to the > > long write-up I made here. > > Hah, so the patch here is not actually relevant for modern Hyper-V Correct. > installations. (I would have loved to read that in the patch description > - but maybe I missed that) I'll add the related description into the changelog of v2 of this patch. > > And, to make the hibernation functionality automated, the host is able to > > send a "please hibernate" message to the VM via the Hyper-V shutdown > > device upon the user's request (e.g. via GUI or scripting): see [...] > > When the host sends the message, > > it checks if the virtual ACPI S4 state is enabled for the VM: if not, the > > host > > refuses to send the message. This means that the user does want to make > > sure the virtual ACPI S4 state is enabled for the VM, if the user of the VM > > wants to use the hibernation feature, and this means Dynamic Memory > > and Memory Resizing can not be active due to the restrictions from the > > host toolstack. > > Okay, *but* this is a current limitation. Just saying. If you could at > least support balloon inflate/deflate, that would be a clear win for > users. And less configuration knobs. For Hyper-V (on recently hosts), Dynamic Memory (and Memory Resizing) and hibernation are mutually exclusive and as I mentioned the host toolstack guarantees they can not be both enabled. This is a host limitation and the VM (i.e. we the Linux team) can do nothing about this. Note: here "enable hibernation for a VM" means "enable the virtual ACPI S4 state for the VM". By default a VM running on Hyper-V doesn't have the S4 state enabled, and balloon inflate/deflate are indeed supported. The knob (I think you mean the virtual ACPI S4 state) is introduced in the host side design of the VM hibernation feature, and is enforced in the host toolstack (as I described about the host-to-VM "please hibernate" message). No knob or module parameter is introduced by the VM here. > > And the hibernation functionality won't be officially supported on old > > Windows Server hosts. > > > > So, IMHO we can't be bother to implement the idea you described in > > detail. Sorry. :-) > > No worries, I neither develop for, use or work with Hyper-V. I was just > reading along and wondering why you basically make the hv_balloon > unusable in these environments. (initially I thought, "why don't you > just disallow probing the device completely") The Hyper-V team told me that: when hibernation is enabled & used for a VM the only purpose of loading hv_balloon is that the driver can still report the VM's memory pressure to the host, and it looks due to some (non-technical?) reason the Hyper-V team thinks this info can be useful. > I am aware of the (hypervisor) issues of hibernation/suspend when it > comes to balloon drivers / memory hot(un)plug. (currently working on > virtio-mem myself and initially decided to block any > hibernation/suspension attempts in case the driver is loaded and memory > was plugged/unplugged) > > > > > And, while I agree your idea is good, technically speaking I suspect it may > > not be really useful, because once hv_balloon allows balloon-up/down, > > hv_balloon effectively loses control of memory pages: after the host > > takes some memory away, the VM never knows when exactly the > > host will give it back -- actually the host never guarantees how soon > > it will give the memory back. Consequently, the VM almost immediately > > ends up in an un-hibernatable state... > If you go via the host, you might be able to make sure to request to > deflate the balloon before you try to hibernate, and inflate again when > back up. You might even ask the user for permissions. Of course, once > you deflated the balloon, it might not be guaranteed to inflate the > balloon to the original size. But after all, it's "dynamic memory", so > it might even be what the name suggests. It could be very well > controlled from the host. > > If you go via the guest, you would first have to tell your hypervisor > "please allow me to deflate so I can hibernate", or something like that. > After hibernation (or some time X), the host might then decide to > inflate again. > > E.g., take a look at virtio-balloon. When suspending, it simply deflates > (without asking ...), to inflate again when resuming. Not saying that's > the best approach (it's not :) ), but one approach to at least make it work. Yes, I noticed this a few months ago. I think a major difference in Hyper-V ballooning mechanism is that: all the deflate/inflate requests are from the host and the VM can never proactively ask the host to deflate/inflate the VM's memory. All that the VM can do is report its memory pressure to the host and hope the
[PATCH v3 2/2] mm: avoid slub allocation while holding list_lock
If we are already under list_lock, don't call kmalloc(). Otherwise we
will run into deadlock because kmalloc() also tries to grab the same
lock.
Fixing the problem by using a static bitmap instead.
WARNING: possible recursive locking detected
mount-encrypted/4921 is trying to acquire lock:
(&(>list_lock)->rlock){-.-.}, at: ___slab_alloc+0x104/0x437
but task is already holding lock:
(&(>list_lock)->rlock){-.-.}, at: __kmem_cache_shutdown+0x81/0x3cb
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&(>list_lock)->rlock);
lock(&(>list_lock)->rlock);
*** DEADLOCK ***
Acked-by: Kirill A. Shutemov
Signed-off-by: Yu Zhao
---
mm/slub.c | 88 +--
1 file changed, 47 insertions(+), 41 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 445ef8b2aec0..c1de01730648 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -441,19 +441,38 @@ static inline bool cmpxchg_double_slab(struct kmem_cache
*s, struct page *page,
}
#ifdef CONFIG_SLUB_DEBUG
+static unsigned long object_map[BITS_TO_LONGS(MAX_OBJS_PER_PAGE)];
+static DEFINE_SPINLOCK(object_map_lock);
+
/*
* Determine a map of object in use on a page.
*
* Node listlock must be held to guarantee that the page does
* not vanish from under us.
*/
-static void get_map(struct kmem_cache *s, struct page *page, unsigned long
*map)
+static unsigned long *get_map(struct kmem_cache *s, struct page *page)
{
void *p;
void *addr = page_address(page);
+ VM_BUG_ON(!irqs_disabled());
+
+ spin_lock(_map_lock);
+
+ bitmap_zero(object_map, page->objects);
+
for (p = page->freelist; p; p = get_freepointer(s, p))
- set_bit(slab_index(p, s, addr), map);
+ set_bit(slab_index(p, s, addr), object_map);
+
+ return object_map;
+}
+
+static void put_map(unsigned long *map)
+{
+ VM_BUG_ON(map != object_map);
+ lockdep_assert_held(_map_lock);
+
+ spin_unlock(_map_lock);
}
static inline unsigned int size_from_object(struct kmem_cache *s)
@@ -3683,13 +3702,12 @@ static void list_slab_objects(struct kmem_cache *s,
struct page *page,
#ifdef CONFIG_SLUB_DEBUG
void *addr = page_address(page);
void *p;
- unsigned long *map = bitmap_zalloc(page->objects, GFP_ATOMIC);
- if (!map)
- return;
+ unsigned long *map;
+
slab_err(s, page, text, s->name);
slab_lock(page);
- get_map(s, page, map);
+ map = get_map(s, page);
for_each_object(p, s, addr, page->objects) {
if (!test_bit(slab_index(p, s, addr), map)) {
@@ -3697,8 +3715,9 @@ static void list_slab_objects(struct kmem_cache *s,
struct page *page,
print_tracking(s, p);
}
}
+ put_map(map);
+
slab_unlock(page);
- bitmap_free(map);
#endif
}
@@ -4384,19 +4403,19 @@ static int count_total(struct page *page)
#endif
#ifdef CONFIG_SLUB_DEBUG
-static void validate_slab(struct kmem_cache *s, struct page *page,
- unsigned long *map)
+static void validate_slab(struct kmem_cache *s, struct page *page)
{
void *p;
void *addr = page_address(page);
+ unsigned long *map;
+
+ slab_lock(page);
if (!check_slab(s, page) || !on_freelist(s, page, NULL))
- return;
+ goto unlock;
/* Now we know that a valid freelist exists */
- bitmap_zero(map, page->objects);
-
- get_map(s, page, map);
+ map = get_map(s, page);
for_each_object(p, s, addr, page->objects) {
u8 val = test_bit(slab_index(p, s, addr), map) ?
SLUB_RED_INACTIVE : SLUB_RED_ACTIVE;
@@ -4404,18 +4423,13 @@ static void validate_slab(struct kmem_cache *s, struct
page *page,
if (!check_object(s, page, p, val))
break;
}
-}
-
-static void validate_slab_slab(struct kmem_cache *s, struct page *page,
- unsigned long *map)
-{
- slab_lock(page);
- validate_slab(s, page, map);
+ put_map(map);
+unlock:
slab_unlock(page);
}
static int validate_slab_node(struct kmem_cache *s,
- struct kmem_cache_node *n, unsigned long *map)
+ struct kmem_cache_node *n)
{
unsigned long count = 0;
struct page *page;
@@ -4424,7 +4438,7 @@ static int validate_slab_node(struct kmem_cache *s,
spin_lock_irqsave(>list_lock, flags);
list_for_each_entry(page, >partial, slab_list) {
- validate_slab_slab(s, page, map);
+ validate_slab(s, page);
count++;
}
if (count != n->nr_partial)
@@ -4435,7 +4449,7 @@ static int validate_slab_node(struct kmem_cache *s,
[PATCH v3 1/2] mm: clean up validate_slab()
The function doesn't need to return any value, and the check can be
done in one pass.
There is a behavior change: before the patch, we stop at the first
invalid free object; after the patch, we stop at the first invalid
object, free or in use. This shouldn't matter because the original
behavior isn't intended anyway.
Signed-off-by: Yu Zhao
---
mm/slub.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 8834563cdb4b..445ef8b2aec0 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -4384,31 +4384,26 @@ static int count_total(struct page *page)
#endif
#ifdef CONFIG_SLUB_DEBUG
-static int validate_slab(struct kmem_cache *s, struct page *page,
+static void validate_slab(struct kmem_cache *s, struct page *page,
unsigned long *map)
{
void *p;
void *addr = page_address(page);
- if (!check_slab(s, page) ||
- !on_freelist(s, page, NULL))
- return 0;
+ if (!check_slab(s, page) || !on_freelist(s, page, NULL))
+ return;
/* Now we know that a valid freelist exists */
bitmap_zero(map, page->objects);
get_map(s, page, map);
for_each_object(p, s, addr, page->objects) {
- if (test_bit(slab_index(p, s, addr), map))
- if (!check_object(s, page, p, SLUB_RED_INACTIVE))
- return 0;
- }
+ u8 val = test_bit(slab_index(p, s, addr), map) ?
+SLUB_RED_INACTIVE : SLUB_RED_ACTIVE;
- for_each_object(p, s, addr, page->objects)
- if (!test_bit(slab_index(p, s, addr), map))
- if (!check_object(s, page, p, SLUB_RED_ACTIVE))
- return 0;
- return 1;
+ if (!check_object(s, page, p, val))
+ break;
+ }
}
static void validate_slab_slab(struct kmem_cache *s, struct page *page,
--
2.23.0.237.gc6a4ce50a0-goog
[PATCH] rsi: release skb if rsi_prepare_beacon fails
In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should
be released.
Signed-off-by: Navid Emamdoost
---
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
index 6c7f26ef6476..9cc8a335d519 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -1756,6 +1756,7 @@ static int rsi_send_beacon(struct rsi_common *common)
skb_pull(skb, (64 - dword_align_bytes));
if (rsi_prepare_beacon(common, skb)) {
rsi_dbg(ERR_ZONE, "Failed to prepare beacon\n");
+ dev_kfree_skb(skb);
return -EINVAL;
}
skb_queue_tail(>tx_queue[MGMT_BEACON_Q], skb);
--
2.17.1
Re: [PATCH] mm: remove redundant assignment of entry
On Mon, Jul 08, 2019 at 04:27:40PM +0800, Wei Yang wrote:
>Since ptent will not be changed after previous assignment of entry, it
>is not necessary to do the assignment again.
>
Sounds this one is lost in the time line :-)
>Signed-off-by: Wei Yang
>---
> mm/memory.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/mm/memory.c b/mm/memory.c
>index ddf20bd0c317..d108bb979a08 100644
>--- a/mm/memory.c
>+++ b/mm/memory.c
>@@ -1127,7 +1127,6 @@ static unsigned long zap_pte_range(struct mmu_gather
>*tlb,
> if (unlikely(details))
> continue;
>
>- entry = pte_to_swp_entry(ptent);
> if (!non_swap_entry(entry))
> rss[MM_SWAPENTS]--;
> else if (is_migration_entry(entry)) {
>--
>2.17.1
--
Wei Yang
Help you, Help me
[PATCH] media: usb: fix memory leak in af9005_identify_state
In af9005_identify_state when returning -EIO the allocated buffer should
be released.
Signed-off-by: Navid Emamdoost
---
drivers/media/usb/dvb-usb/af9005.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/af9005.c
b/drivers/media/usb/dvb-usb/af9005.c
index 02697d86e8c1..aee500beaab6 100644
--- a/drivers/media/usb/dvb-usb/af9005.c
+++ b/drivers/media/usb/dvb-usb/af9005.c
@@ -975,8 +975,10 @@ static int af9005_identify_state(struct usb_device *udev,
*cold = 1;
else if (reply == 0x02)
*cold = 0;
- else
+ else {
+ kfree(buf);
return -EIO;
+ }
deb_info("Identify state cold = %d\n", *cold);
err:
--
2.17.1
Re: [PATCH 2/4] x86: use the correct function type for sys32_(rt_)sigreturn
On Fri, Sep 13, 2019 at 3:44 PM Andy Lutomirski wrote: > Shouldn't these be COMPAT_SYSCALL_DEFINE0? Sure, that would work too. > I think you should pick this patch up and add it to your series: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/syscalls=07daeef08d26728c120ecbe57a55cb5714810b84 > > with the obvious type fixup, of course. And then write a little patch > to use COMPAT_SYSCALL_DEFINE0 for rt_sigreturn and sigreturn. Thanks. I'll do that and send v2 next week once I get some more feedback on the other patches. Sami
Re: [PATCH 4/4] x86: fix function types in COND_SYSCALL
On Fri, Sep 13, 2019 at 3:46 PM Andy Lutomirski wrote: > Didn't you just fix the type of sys_ni_syscall? What am I missing here? The other patch fixes indirect call type mismatches when the function is called through the syscall table. However, cond_syscall creates an alias to the actual sys_ni_syscall function defined in kernel/sys_ni.c, which still has the wrong type. Sami
Re: [PATCH 3/4] x86: use the correct function type for sys_ni_syscall
On Fri, Sep 13, 2019 at 3:45 PM Andy Lutomirski wrote: > Should this be SYSCALL_DEFINE0? It can be, and that would also fix the issue. However, it does result in unnecessary error injection to be hooked up here, which is why arm64 preferred to avoid the macro when I fixed it there. S390 uses SYSCALL_DEFINE0 for this though and since sys_ni_syscall always returns -ENOSYS, it shouldn't be a huge problem. Thoughts? Sami
[PATCH 3/7] irqchip/irq-bcm2835: Add support for 7211 interrupt controller
BCM7211 has a number of similarities with BCM2836, except the register
offsets are different and the bank bits are also different, account for
all of these differences.
Signed-off-by: Florian Fainelli
---
drivers/irqchip/irq-bcm2835.c | 86 +--
1 file changed, 72 insertions(+), 14 deletions(-)
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index 418245d31921..55afc3487723 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -57,19 +57,34 @@
#define SHORTCUT_SHIFT 10
#define BANK1_HWIRQBIT(8)
#define BANK2_HWIRQBIT(9)
+#define BANK1_HWIRQ_BCM7211BIT(24)
+#define BANK2_HWIRQ_BCM7211BIT(25)
#define BANK0_VALID_MASK (BANK0_HWIRQ_MASK | BANK1_HWIRQ | BANK2_HWIRQ \
| SHORTCUT1_MASK | SHORTCUT2_MASK)
+#define BANK0_VALID_MASK_BCM7211 (BANK0_HWIRQ_MASK | BANK1_HWIRQ_BCM7211 | \
+ BANK2_HWIRQ_BCM7211 | SHORTCUT1_MASK | \
+ SHORTCUT2_MASK)
#define REG_FIQ_CONTROL0x0c
#define NR_BANKS 3
#define IRQS_PER_BANK 32
+enum armctrl_type {
+ ARMCTRL_BCM2835 = 0,
+ ARMCTRL_BCM2836,
+ ARMCTRL_BCM7211
+};
+
static const int reg_pending[] __initconst = { 0x00, 0x04, 0x08 };
static const int reg_enable[] __initconst = { 0x18, 0x10, 0x14 };
static const int reg_disable[] __initconst = { 0x24, 0x1c, 0x20 };
static const int bank_irqs[] __initconst = { 8, 32, 32 };
+static const int reg_pending_bcm7211[] __initconst = { 0x08, 0x00, 0x04 };
+static const int reg_enable_bcm7211[] __initconst = { 0x18, 0x10, 0x14 };
+static const int reg_disable_bcm7211[] __initconst = { 0x28, 0x20, 0x24 };
+
static const int shortcuts[] = {
7, 9, 10, 18, 19, /* Bank 1 */
21, 22, 23, 24, 25, 30 /* Bank 2 */
@@ -87,6 +102,7 @@ static struct armctrl_ic intc __read_mostly;
static void __exception_irq_entry bcm2835_handle_irq(
struct pt_regs *regs);
static void bcm2836_chained_handle_irq(struct irq_desc *desc);
+static void bcm7211_chained_handle_irq(struct irq_desc *desc);
static void armctrl_mask_irq(struct irq_data *d)
{
@@ -131,11 +147,14 @@ static const struct irq_domain_ops armctrl_ops = {
static int __init armctrl_of_init(struct device_node *node,
struct device_node *parent,
- bool is_2836)
+ enum armctrl_type type)
{
void __iomem *base;
int irq, b, i;
+ if (type > ARMCTRL_BCM7211)
+ return -EINVAL;
+
base = of_iomap(node, 0);
if (!base)
panic("%pOF: unable to map IC registers\n", node);
@@ -146,9 +165,19 @@ static int __init armctrl_of_init(struct device_node *node,
panic("%pOF: unable to create IRQ domain\n", node);
for (b = 0; b < NR_BANKS; b++) {
- intc.pending[b] = base + reg_pending[b];
- intc.enable[b] = base + reg_enable[b];
- intc.disable[b] = base + reg_disable[b];
+ if (type <= ARMCTRL_BCM2836) {
+ intc.pending[b] = base + reg_pending[b];
+ intc.enable[b] = base + reg_enable[b];
+ intc.disable[b] = base + reg_disable[b];
+ } else {
+ intc.pending[b] = base + reg_pending_bcm7211[b];
+ intc.enable[b] = base + reg_enable_bcm7211[b];
+ intc.disable[b] = base + reg_disable_bcm7211[b];
+ }
+
+ if (type == ARMCTRL_BCM7211)
+ armctrl_chip.flags |= IRQCHIP_MASK_ON_SUSPEND |
+ IRQCHIP_SKIP_SET_WAKE;
for (i = 0; i < bank_irqs[b]; i++) {
irq = irq_create_mapping(intc.domain, MAKE_HWIRQ(b, i));
@@ -159,14 +188,19 @@ static int __init armctrl_of_init(struct device_node
*node,
}
}
- if (is_2836) {
+ if (type >= ARMCTRL_BCM2836) {
int parent_irq = irq_of_parse_and_map(node, 0);
if (!parent_irq) {
panic("%pOF: unable to get parent interrupt.\n",
node);
}
- irq_set_chained_handler(parent_irq, bcm2836_chained_handle_irq);
+ if (type == ARMCTRL_BCM2836)
+ irq_set_chained_handler(parent_irq,
+ bcm2836_chained_handle_irq);
+ else
+ irq_set_chained_handler(parent_irq,
+ bcm7211_chained_handle_irq);
} else {
set_handle_irq(bcm2835_handle_irq);
}
@@ -177,13 +211,19 @@ static int __init armctrl_of_init(struct device_node
[PATCH 1/7] irqchip: Introduce Kconfig symbol to build irq-bcm283x.c
Both irq-bcm2835.c and irq-bcm2836.c are currently used with ARCH_BCM2835 but are soon going to be used with ARCH_BRCMSTB, introduce a Kconfig symbol to make that those drivers selected/built by other platforms. Signed-off-by: Florian Fainelli --- drivers/irqchip/Kconfig | 5 + drivers/irqchip/Makefile | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index 80e10f4e213a..d1bb20d23d27 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -113,6 +113,11 @@ config I8259 bool select IRQ_DOMAIN +config BCM283X_IRQ + bool + select IRQ_DOMAIN + default ARCH_BCM2835 + config BCM6345_L1_IRQ bool select GENERIC_IRQ_CHIP diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile index 8d0fcec6ab23..9cf14c7945f6 100644 --- a/drivers/irqchip/Makefile +++ b/drivers/irqchip/Makefile @@ -5,8 +5,8 @@ obj-$(CONFIG_AL_FIC)+= irq-al-fic.o obj-$(CONFIG_ALPINE_MSI) += irq-alpine-msi.o obj-$(CONFIG_ATH79)+= irq-ath79-cpu.o obj-$(CONFIG_ATH79)+= irq-ath79-misc.o -obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o -obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2836.o +obj-$(CONFIG_BCM283X_IRQ) += irq-bcm2835.o +obj-$(CONFIG_BCM283X_IRQ) += irq-bcm2836.o obj-$(CONFIG_DAVINCI_AINTC)+= irq-davinci-aintc.o obj-$(CONFIG_DAVINCI_CP_INTC) += irq-davinci-cp-intc.o obj-$(CONFIG_ARCH_EXYNOS) += exynos-combiner.o -- 2.17.1
[PATCH 7/7] irqchip/irq-bcm283x: Add registration prints
With many different kind of interrupt controllers available and used on
7211, add prints to help determine which ones are registered.
Signed-off-by: Florian Fainelli
---
drivers/irqchip/irq-bcm2835.c | 9 +
drivers/irqchip/irq-bcm2836.c | 2 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index 55afc3487723..ae23e9ec86d0 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -76,6 +76,12 @@ enum armctrl_type {
ARMCTRL_BCM7211
};
+static const char *armctrl_type_str[] = {
+ [ARMCTRL_BCM2835] = "BCM2835",
+ [ARMCTRL_BCM2836] = "BCM2836",
+ [ARMCTRL_BCM7211] = "BCM7211",
+};
+
static const int reg_pending[] __initconst = { 0x00, 0x04, 0x08 };
static const int reg_enable[] __initconst = { 0x18, 0x10, 0x14 };
static const int reg_disable[] __initconst = { 0x24, 0x1c, 0x20 };
@@ -205,6 +211,9 @@ static int __init armctrl_of_init(struct device_node *node,
set_handle_irq(bcm2835_handle_irq);
}
+ pr_info("registered %s intc (%pOF)\n", armctrl_type_str[type],
+ node);
+
return 0;
}
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 77fa395c8f6b..b159dc91919d 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -240,6 +240,8 @@ static int __init arm_irqchip_l1_intc_of_init_smp(struct
device_node *node,
set_handle_irq(bcm2836_arm_irqchip_handle_irq);
+ pr_info("Registered BCM2836 intc (%s)\n", node->full_name);
+
return 0;
}
--
2.17.1
[PATCH 5/7] irqchip/irq-bcm2836: Add support for the 7211 interrupt controller
The root interrupt controller on 7211 is about identical to the one
existing on BCM2836, except that the SMP cross call are done through the
standard ARM GIC-400 interrupt controller. This interrupt controller is
used for side band wake-up signals though.
Signed-off-by: Florian Fainelli
---
drivers/irqchip/irq-bcm2836.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 2038693f074c..77fa395c8f6b 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -112,6 +112,8 @@ static int bcm2836_map(struct irq_domain *d, unsigned int
irq,
return -EINVAL;
}
+ chip->flags |= IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE;
+
irq_set_percpu_devid(irq);
irq_domain_set_info(d, irq, hw, chip, d->host_data,
handle_percpu_devid_irq, NULL, NULL);
@@ -216,8 +218,9 @@ static void bcm2835_init_local_timer_frequency(void)
writel(0x8000, intc.base + LOCAL_PRESCALER);
}
-static int __init bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
- struct device_node
*parent)
+static int __init arm_irqchip_l1_intc_of_init_smp(struct device_node *node,
+ struct device_node *parent,
+ bool smp_init)
{
intc.base = of_iomap(node, 0);
if (!intc.base) {
@@ -232,11 +235,27 @@ static int __init
bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
if (!intc.domain)
panic("%pOF: unable to create IRQ domain\n", node);
- bcm2836_arm_irqchip_smp_init();
+ if (smp_init)
+ bcm2836_arm_irqchip_smp_init();
set_handle_irq(bcm2836_arm_irqchip_handle_irq);
+
return 0;
}
+static int __init bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
+ struct device_node
*parent)
+{
+ return arm_irqchip_l1_intc_of_init_smp(node, parent, true);
+}
+
+static int __init bcm7211_arm_irqchip_l1_intc_of_init(struct device_node *node,
+ struct device_node
*parent)
+{
+ return arm_irqchip_l1_intc_of_init_smp(node, parent, false);
+}
+
IRQCHIP_DECLARE(bcm2836_arm_irqchip_l1_intc, "brcm,bcm2836-l1-intc",
bcm2836_arm_irqchip_l1_intc_of_init);
+IRQCHIP_DECLARE(bcm7211_arm_irqchip_l1_intc, "brcm,bcm7211-l1-intc",
+ bcm7211_arm_irqchip_l1_intc_of_init);
--
2.17.1
[PATCH 6/7] irqchip: Build BCM283X_IRQ for ARCH_BRCMSTB
Now that irq-bcm2835.c and irq-bcm2836.c have been updated to support BCM7211 which is under ARCH_BRCMSTB, build both drivers for ARCH_BRCMSTB. Signed-off-by: Florian Fainelli --- drivers/irqchip/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index d1bb20d23d27..ffd5f986172a 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -116,7 +116,7 @@ config I8259 config BCM283X_IRQ bool select IRQ_DOMAIN - default ARCH_BCM2835 + default ARCH_BCM2835 || ARCH_BRCMSTB config BCM6345_L1_IRQ bool -- 2.17.1
[PATCH 2/7] dt-bindings: interrupt-controller: Add brcm,bcm7211-armctrl-ic binding
BCM7211 features a second level interrupt controller similar in nature to BCM2836, with a few modifications to the register offsets, document that specific compatible string. Signed-off-by: Florian Fainelli --- .../interrupt-controller/brcm,bcm2835-armctrl-ic.txt| 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt index 0f1af5a1c12e..0b07845b46e4 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt @@ -12,7 +12,8 @@ interrupt there indicates that the ARMCTRL has an interrupt to handle. Required properties: - compatible : should be "brcm,bcm2835-armctrl-ic" or - "brcm,bcm2836-armctrl-ic" + "brcm,bcm2836-armctrl-ic" or +"brcm,bcm7211-armctrl-ic" - reg : Specifies base physical address and size of the registers. - interrupt-controller : Identifies the node as an interrupt controller - #interrupt-cells : Specifies the number of cells needed to encode an @@ -25,7 +26,8 @@ Required properties: The 2nd cell contains the interrupt number within the bank. Valid values are 0..7 for bank 0, and 0..31 for bank 1. -Additional required properties for brcm,bcm2836-armctrl-ic: +Additional required properties for brcm,bcm2836-armctrl-ic and +brcm,bcm7211-armctrl-ic: - interrupts : Specifies the interrupt on the parent for this interrupt controller to handle. -- 2.17.1
[PATCH 4/7] dt-bindings: interrupt-controller: Add brcm,bcm7211-l1-intc binding
BCM7211 uses a very similar root interrupt controller than what exists on BCM2836, define a specific compatible string to key off specific behavior. Signed-off-by: Florian Fainelli --- .../bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt| 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt index 8ced1696c325..13bef028d6ad 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt @@ -7,7 +7,9 @@ controller. Required properties: -- compatible: Should be "brcm,bcm2836-l1-intc" +- compatible: Should be one of + "brcm,bcm2836-l1-intc" + "brcm,bcm7211-l1-intc" - reg: Specifies base physical address and size of the registers - interrupt-controller:Identifies the node as an interrupt controller -- 2.17.1
[PATCH 0/7] irqchip/irq-bcm283x update for BCM7211
Hi Marc, Jason, Thomas, This patch series updates the BCM2835 and BCM2836 interrupt controller drivers to support BCM7211 which can make use of those drivers in some configurations where the ARM GIC is muxed out and the legacy ARM interrupt controller is used instead. Thank you! Florian Fainelli (7): irqchip: Introduce Kconfig symbol to build irq-bcm283x.c dt-bindings: interrupt-controller: Add brcm,bcm7211-armctrl-ic binding irqchip/irq-bcm2835: Add support for 7211 interrupt controller dt-bindings: interrupt-controller: Add brcm,bcm7211-l1-intc binding irqchip/irq-bcm2836: Add support for the 7211 interrupt controller irqchip: Build BCM283X_IRQ for ARCH_BRCMSTB irqchip/irq-bcm283x: Add registration prints .../brcm,bcm2835-armctrl-ic.txt | 6 +- .../brcm,bcm2836-l1-intc.txt | 4 +- drivers/irqchip/Kconfig | 5 + drivers/irqchip/Makefile | 4 +- drivers/irqchip/irq-bcm2835.c | 95 --- drivers/irqchip/irq-bcm2836.c | 27 +- 6 files changed, 119 insertions(+), 22 deletions(-) -- 2.17.1
RE: [PATCH v3 0/5] Introduce variable length mdev alias
Hi Alex, > -Original Message- > From: Alex Williamson > Sent: Friday, September 13, 2019 4:33 PM > To: Parav Pandit > Cc: Jiri Pirko ; kwankh...@nvidia.com; > coh...@redhat.com; da...@davemloft.net; k...@vger.kernel.org; linux- > ker...@vger.kernel.org; net...@vger.kernel.org > Subject: Re: [PATCH v3 0/5] Introduce variable length mdev alias > > On Wed, 11 Sep 2019 16:38:49 + > Parav Pandit wrote: > > > > -Original Message- > > > From: linux-kernel-ow...@vger.kernel.org > > ow...@vger.kernel.org> On Behalf Of Parav Pandit > > > Sent: Wednesday, September 11, 2019 10:31 AM > > > To: Alex Williamson > > > Cc: Jiri Pirko ; kwankh...@nvidia.com; > > > coh...@redhat.com; da...@davemloft.net; k...@vger.kernel.org; linux- > > > ker...@vger.kernel.org; net...@vger.kernel.org > > > Subject: RE: [PATCH v3 0/5] Introduce variable length mdev alias > > > > > > Hi Alex, > > > > > > > -Original Message- > > > > From: Alex Williamson > > > > Sent: Wednesday, September 11, 2019 8:56 AM > > > > To: Parav Pandit > > > > Cc: Jiri Pirko ; kwankh...@nvidia.com; > > > > coh...@redhat.com; da...@davemloft.net; k...@vger.kernel.org; > > > > linux- ker...@vger.kernel.org; net...@vger.kernel.org > > > > Subject: Re: [PATCH v3 0/5] Introduce variable length mdev alias > > > > > > > > On Mon, 9 Sep 2019 20:42:32 + > > > > Parav Pandit wrote: > > > > > > > > > Hi Alex, > > > > > > > > > > > -Original Message- > > > > > > From: Parav Pandit > > > > > > Sent: Sunday, September 1, 2019 11:25 PM > > > > > > To: alex.william...@redhat.com; Jiri Pirko > > > > > > ; kwankh...@nvidia.com; coh...@redhat.com; > > > > > > da...@davemloft.net > > > > > > Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > > > > net...@vger.kernel.org; Parav Pandit > > > > > > Subject: [PATCH v3 0/5] Introduce variable length mdev alias > > > > > > > > > > > > To have consistent naming for the netdevice of a mdev and to > > > > > > have consistent naming of the devlink port [1] of a mdev, > > > > > > which is formed using phys_port_name of the devlink port, > > > > > > current UUID is not usable because UUID is too long. > > > > > > > > > > > > UUID in string format is 36-characters long and in binary 128-bit. > > > > > > Both formats are not able to fit within 15 characters limit of > > > > > > netdev > > > > name. > > > > > > > > > > > > It is desired to have mdev device naming consistent using UUID. > > > > > > So that widely used user space framework such as ovs [2] can > > > > > > make use of mdev representor in similar way as PCIe SR-IOV VF > > > > > > and PF > > > > representors. > > > > > > > > > > > > Hence, > > > > > > (a) mdev alias is created which is derived using sha1 from the > > > > > > mdev > > > > name. > > > > > > (b) Vendor driver describes how long an alias should be for > > > > > > the child mdev created for a given parent. > > > > > > (c) Mdev aliases are unique at system level. > > > > > > (d) alias is created optionally whenever parent requested. > > > > > > This ensures that non networking mdev parents can function > > > > > > without alias creation overhead. > > > > > > > > > > > > This design is discussed at [3]. > > > > > > > > > > > > An example systemd/udev extension will have, > > > > > > > > > > > > 1. netdev name created using mdev alias available in sysfs. > > > > > > > > > > > > mdev UUID=83b8f4f2-509f-382f-3c1e-e6bfe0fa1001 > > > > > > mdev 12 character alias=cd5b146a80a5 > > > > > > > > > > > > netdev name of this mdev = enmcd5b146a80a5 Here en = Ethernet > > > > > > link m = mediated device > > > > > > > > > > > > 2. devlink port phys_port_name created using mdev alias. > > > > > > devlink phys_port_name=pcd5b146a80a5 > > > > > > > > > > > > This patchset enables mdev core to maintain unique alias for a mdev. > > > > > > > > > > > > Patch-1 Introduces mdev alias using sha1. > > > > > > Patch-2 Ensures that mdev alias is unique in a system. > > > > > > Patch-3 Exposes mdev alias in a sysfs hirerchy, update > > > > > > Documentation > > > > > > Patch-4 Introduces mdev_alias() API. > > > > > > Patch-5 Extends mtty driver to optionally provide alias generation. > > > > > > This also enables to test UUID based sha1 collision and > > > > > > trigger error handling for duplicate sha1 results. > > > > > > > > > > > > [1] http://man7.org/linux/man-pages/man8/devlink-port.8.html > > > > > > [2] > > > > > > https://docs.openstack.org/os-vif/latest/user/plugins/ovs.html > > > > > > [3] https://patchwork.kernel.org/cover/11084231/ > > > > > > > > > > > > --- > > > > > > Changelog: > > > > > > v2->v3: > > > > > > - Addressed comment from Yunsheng Lin > > > > > > - Changed strcmp() ==0 to !strcmp() > > > > > > - Addressed comment from Cornelia Hunk > > > > > > - Merged sysfs Documentation patch with syfs patch > > > > > > - Added more description for alias return value > > > > > > > > > > Did you get a chance review this updated series? > > > > > I addressed Cornelia's and
Re: Documentation for plain accesses and data races
On Fri, Sep 13, 2019 at 11:21:17AM -0400, Alan Stern wrote:
> On Thu, 12 Sep 2019, Paul E. McKenney wrote:
> > On Fri, Sep 06, 2019 at 02:11:29PM -0400, Alan Stern wrote:
> > > Folks:
> > >
> > > I have spent some time writing up a section for
> > > tools/memory-model/Documentation/explanation.txt on plain accesses and
> > > data races. The initial version is below.
> > >
> > > I'm afraid it's rather long and perhaps gets too bogged down in
> > > complexities. On the other hand, this is a complicated topic so to
> > > some extent this is unavoidable.
> > >
> > > In any case, I'd like to hear your comments and reviews.
> >
> > Good stuff, thank you for putting this together!
> >
> > Please see below for some questions, comments, and confusion interspersed.
>
> Thanks for looking over this. Replies given inline below...
>
> > > Alan
> > >
> > >
> > >
> > >
> > > PLAIN ACCESSES AND DATA RACES
> > > -
> > >
> > > In the LKMM, memory accesses such as READ_ONCE(x), atomic_inc(),
> > > smp_load_acquire(), and so on are collectively referred to as
> > > "marked" accesses, because they are all annotated with special
> > > operations of one kind or another. Ordinary C-language memory
> > > accesses such as x or y = 0 are simply called "plain" accesses.
> > >
> > > Early versions of the LKMM had nothing to say about plain accesses.
> > > The C standard allows compilers to assume that the variables affected
> > > by plain accesses are not concurrently read or written by any other
> > > threads or CPUs. This leaves compilers free to implement all manner
> > > of transformations or optimizations of code containing plain accesses,
> > > making such code very difficult for a memory model to handle.
> > >
> > > Here is just one example of a possible pitfall:
> > >
> > > int a = 6;
> > > int *x =
> > >
> > > P0()
> > > {
> > > int *r1;
> > > int r2 = 0;
> > >
> > > r1 = x;
> > > if (r1 != NULL)
> > > r2 = READ_ONCE(*r1);
> > > }
> > >
> > > P1()
> > > {
> > > WRITE_ONCE(x, NULL);
> > > }
> >
> > I tried making a litmus test out of this:
> >
> >
> > C plain-1
> >
> > {
> > int a = 6;
> > int *x =
> > }
> >
> > P0(int **x)
> > {
> > int *r1;
> > int r2 = 0;
> >
> > r1 = *x;
> > if (r1 != 0)
> > r2 = READ_ONCE(*r1);
> > }
> >
> > P1(int **x)
> > {
> > WRITE_ONCE(*x, 0);
> > }
> >
> > locations [a; x; r1]
> > exists ~r2=6 /\ ~r2=0
> >
> >
> > However, r1 steadfastly refuses to have any value other than zero.
> >
> >
> > $ herd7 -conf linux-kernel.cfg /tmp/argh
> > Test plain-1 Allowed
> > States 1
> > a=6; r1=0; r2=0; x=0;
> > No
> > Witnesses
> > Positive: 0 Negative: 2
> > Flag data-race
> > Condition exists (not (r2=6) /\ not (r2=0))
> > Observation plain-1 Never 0 2
> > Time plain-1 0.00
> > Hash=b0fdbd0f627fd65e0cd413bf87f6f4a4
> >
> >
> > What am I doing wrong here? Outdated herd7 version?
>
> In this and all the other litmus tests below, your "exists" clauses
> are wrong. For example, here it should say:
>
> exists ~0:r2=6 /\ ~0:r2=0
>
> You forgot about the "0:" in front of the CPU-local variables.
> Similarly for the "locations" clause.
Thank you! Color me blind...
C plain-1
{
int a = 6;
int *x =
}
P0(int **x)
{
int *r1;
int r2 = 0;
r1 = *x;
if (r1 != 0)
r2 = READ_ONCE(*r1);
}
P1(int **x)
{
WRITE_ONCE(*x, 0);
}
locations [a; x; 0:r1]
exists ~0:r2=6 /\ ~0:r2=0
$ herd7 -conf linux-kernel.cfg /tmp/plain1.litmus
Test plain-1 Allowed
States 2
0:r1=0; 0:r2=0; a=6; x=0;
0:r1=a; 0:r2=6; a=6; x=0;
No
Witnesses
Positive: 0 Negative: 2
Flag data-race
Condition exists (not (0:r2=6) /\ not (0:r2=0))
Observation plain-1 Never 0 2
Time plain-1 0.00
Hash=85c5c52abcd2e90733526b3fc42a01f2
[ . . . ]
> > > compiler's assumptions, which would render the ultimate outcome
> > > undefined.
> > >
> > > In technical terms, the compiler is allowed to assume that when the
> > > program executes, there will not be any data races. A "data race"
> > > occurs when two conflicting memory accesses execute concurrently;
> > > two memory accesses "conflict" if:
> > >
> > > they access the same location,
> > >
> > > they occur on different CPUs (or in different threads on the
> > > same CPU),
> >
[PATCH 2/2] pwm: core: Add option to config PWM duty/period with u64 data length
From: Fenglin Wu
Currently, PWM core driver provides interfaces for configuring PWM
period and duty length in nanoseconds with an integer data type, so
the max period can be only set to ~2.147 seconds. Add interfaces which
can set PWM period and duty with u64 data type to remove this
limitation.
Change-Id: Ic8722088510d447fc939ab6a5014711aef1b832f
Signed-off-by: Fenglin Wu
Signed-off-by: Guru Das Srinagesh
---
drivers/pwm/core.c | 20 ++---
drivers/pwm/sysfs.c | 6 +--
include/linux/pwm.h | 115
3 files changed, 126 insertions(+), 15 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 960a451..02ad16b 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -526,9 +526,19 @@ int pwm_apply_state(struct pwm_device *pwm, struct
pwm_state *state)
if (state->period != pwm->state.period ||
state->duty_cycle != pwm->state.duty_cycle) {
- err = pwm->chip->ops->config(pwm->chip, pwm,
-state->duty_cycle,
-state->period);
+ if (pwm->chip->ops->config_extend) {
+ err = pwm->chip->ops->config_extend(pwm->chip,
+ pwm, state->duty_cycle,
+ state->period);
+ } else {
+ if (state->period > UINT_MAX)
+ pr_warn("period %llu duty_cycle %llu
will be truncated\n",
+ state->period,
+ state->duty_cycle);
+ err = pwm->chip->ops->config(pwm->chip, pwm,
+ state->duty_cycle,
+ state->period);
+ }
if (err)
return err;
@@ -1181,8 +1191,8 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct
seq_file *s)
if (state.enabled)
seq_puts(s, " enabled");
- seq_printf(s, " period: %u ns", state.period);
- seq_printf(s, " duty: %u ns", state.duty_cycle);
+ seq_printf(s, " period: %llu ns", state.period);
+ seq_printf(s, " duty: %llu ns", state.duty_cycle);
seq_printf(s, " polarity: %s",
state.polarity ? "inverse" : "normal");
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index ab703f2..ef78c40 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -42,7 +42,7 @@ static ssize_t period_show(struct device *child,
pwm_get_state(pwm, );
- return sprintf(buf, "%u\n", state.period);
+ return sprintf(buf, "%llu\n", state.period);
}
static ssize_t period_store(struct device *child,
@@ -77,7 +77,7 @@ static ssize_t duty_cycle_show(struct device *child,
pwm_get_state(pwm, );
- return sprintf(buf, "%u\n", state.duty_cycle);
+ return sprintf(buf, "%llu\n", state.duty_cycle);
}
static ssize_t duty_cycle_store(struct device *child,
@@ -212,7 +212,7 @@ static ssize_t capture_show(struct device *child,
if (ret)
return ret;
- return sprintf(buf, "%u %u\n", result.period, result.duty_cycle);
+ return sprintf(buf, "%llu %llu\n", result.period, result.duty_cycle);
}
static ssize_t output_type_show(struct device *child,
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 416f08e..d714385 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -39,7 +39,7 @@ enum pwm_polarity {
* current PWM hardware state.
*/
struct pwm_args {
- unsigned int period;
+ u64 period;
enum pwm_polarity polarity;
};
@@ -66,9 +66,9 @@ enum pwm_output_type {
* @cycles_per_duty: number of PWM period cycles an entry stays at
*/
struct pwm_output_pattern {
- unsigned int *duty_pattern;
+ u64 *duty_pattern;
unsigned int num_entries;
- unsigned int cycles_per_duty;
+ u64 cycles_per_duty;
};
/*
@@ -79,8 +79,8 @@ struct pwm_output_pattern {
* @enabled: PWM enabled status
*/
struct pwm_state {
- unsigned int period;
- unsigned int duty_cycle;
+ u64 period;
+ u64 duty_cycle;
enum pwm_polarity polarity;
enum pwm_output_type output_type;
struct pwm_output_pattern *output_pattern;
@@ -136,12 +136,30 @@ static inline void pwm_set_period(struct pwm_device *pwm,
unsigned int period)
pwm->state.period = period;
}
+static inline void pwm_set_period_extend(struct pwm_device *pwm, u64 period)
+{
+ if (pwm)
+ pwm->state.period = period;
+}
+
static inline unsigned int pwm_get_period(const
[PATCH 1/2] pwm: Add different PWM output types support
From: Fenglin Wu
Normally, PWM channel has fixed output until software request to change
its settings. There are some PWM devices which their outputs could be
changed autonomously according to a predefined pattern programmed in
hardware. Add pwm_output_type enum type to identify these two different
PWM types and add relevant helper functions to set and get PWM output
types and pattern.
Change-Id: Ia1f914a45ab4f4dd7be037a395eeb89d0e65a80e
Signed-off-by: Fenglin Wu
Signed-off-by: Guru Das Srinagesh
---
drivers/pwm/core.c | 26
drivers/pwm/sysfs.c | 50 ++
include/linux/pwm.h | 70 +
3 files changed, 146 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 8edfac1..960a451 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -282,6 +282,7 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
pwm->pwm = chip->base + i;
pwm->hwpwm = i;
pwm->state.polarity = polarity;
+ pwm->state.output_type = PWM_OUTPUT_FIXED;
if (chip->ops->get_state)
chip->ops->get_state(chip, pwm, >state);
@@ -498,6 +499,31 @@ int pwm_apply_state(struct pwm_device *pwm, struct
pwm_state *state)
pwm->state.polarity = state->polarity;
}
+ if (state->output_type != pwm->state.output_type) {
+ if (!pwm->chip->ops->set_output_type)
+ return -ENOTSUPP;
+
+ err = pwm->chip->ops->set_output_type(pwm->chip, pwm,
+ state->output_type);
+ if (err)
+ return err;
+
+ pwm->state.output_type = state->output_type;
+ }
+
+ if (state->output_pattern != pwm->state.output_pattern &&
+ state->output_pattern != NULL) {
+ if (!pwm->chip->ops->set_output_pattern)
+ return -ENOTSUPP;
+
+ err = pwm->chip->ops->set_output_pattern(pwm->chip,
+ pwm, state->output_pattern);
+ if (err)
+ return err;
+
+ pwm->state.output_pattern = state->output_pattern;
+ }
+
if (state->period != pwm->state.period ||
state->duty_cycle != pwm->state.duty_cycle) {
err = pwm->chip->ops->config(pwm->chip, pwm,
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 2389b86..ab703f2 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -215,11 +215,60 @@ static ssize_t capture_show(struct device *child,
return sprintf(buf, "%u %u\n", result.period, result.duty_cycle);
}
+static ssize_t output_type_show(struct device *child,
+struct device_attribute *attr,
+char *buf)
+{
+ const struct pwm_device *pwm = child_to_pwm_device(child);
+ const char *output_type = "unknown";
+ struct pwm_state state;
+
+ pwm_get_state(pwm, );
+ switch (state.output_type) {
+ case PWM_OUTPUT_FIXED:
+ output_type = "fixed";
+ break;
+ case PWM_OUTPUT_MODULATED:
+ output_type = "modulated";
+ break;
+ default:
+ break;
+ }
+
+ return snprintf(buf, PAGE_SIZE, "%s\n", output_type);
+}
+
+static ssize_t output_type_store(struct device *child,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct pwm_export *export = child_to_pwm_export(child);
+ struct pwm_device *pwm = export->pwm;
+ struct pwm_state state;
+ int ret = -EINVAL;
+
+ mutex_lock(>lock);
+ pwm_get_state(pwm, );
+ if (sysfs_streq(buf, "fixed"))
+ state.output_type = PWM_OUTPUT_FIXED;
+ else if (sysfs_streq(buf, "modulated"))
+ state.output_type = PWM_OUTPUT_MODULATED;
+ else
+ goto unlock;
+
+ ret = pwm_apply_state(pwm, );
+unlock:
+ mutex_unlock(>lock);
+
+ return ret ? : size;
+}
+
static DEVICE_ATTR_RW(period);
static DEVICE_ATTR_RW(duty_cycle);
static DEVICE_ATTR_RW(enable);
static DEVICE_ATTR_RW(polarity);
static DEVICE_ATTR_RO(capture);
+static DEVICE_ATTR_RW(output_type);
static struct attribute *pwm_attrs[] = {
_attr_period.attr,
@@ -227,6 +276,7 @@ static ssize_t capture_show(struct device *child,
_attr_enable.attr,
_attr_polarity.attr,
_attr_capture.attr,
+ _attr_output_type.attr,
NULL
};
ATTRIBUTE_GROUPS(pwm);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 24632a7..416f08e 100644
Re: problem starting /sbin/init (32-bit 5.3-rc8)
On 9/12/19 6:46 PM, Kees Cook wrote:
> On Thu, Sep 12, 2019 at 05:16:02PM -0700, Kees Cook wrote:
>> On Thu, Sep 12, 2019 at 02:40:19PM -0700, Randy Dunlap wrote:
>>> This is 32-bit kernel, just happens to be running on a 64-bit laptop.
>>> I added the debug printk in __phys_addr() just before "[cut here]".
>>>
>>> CONFIG_HARDENED_USERCOPY=y
>>
>> I can reproduce this under CONFIG_DEBUG_VIRTUAL=y, and it goes back
>> to at least to v5.2. Booting with "hardened_usercopy=off" or without
>> CONFIG_DEBUG_VIRTUAL makes this go away (since __phys_addr() doesn't
>> get called):
>>
>> __check_object_size+0xff/0x1b0:
>> pfn_to_section_nr at include/linux/mmzone.h:1153
>> (inlined by) __pfn_to_section at include/linux/mmzone.h:1291
>> (inlined by) virt_to_head_page at include/linux/mm.h:729
>> (inlined by) check_heap_object at mm/usercopy.c:230
>> (inlined by) __check_object_size at mm/usercopy.c:280
>>
>> Is virt_to_head_page() illegal to use under some recently new conditions?
>
> This combination appears to be bugged since the original introduction
> of hardened usercopy in v4.8. Is this an untested combination until
> now? (I don't usually do tests with CONFIG_DEBUG_VIRTUAL, but I guess
> I will from now on!)
>
> Note from the future (i.e. the end of this email where I figure it out):
> it turns out it's actually these three together:
>
> CONFIG_HIGHMEM=y
> CONFIG_DEBUG_VIRTUAL=y
> CONFIG_HARDENED_USERCOPY=y
>
>>
>>> The BUG is this line in arch/x86/mm/physaddr.c:
>>> VIRTUAL_BUG_ON((phys_addr >> PAGE_SHIFT) > max_low_pfn);
>>> It's line 83 in my source file only due to adding and
>>> a conditional pr_crit() call.
>
> What exactly is this trying to test?
>
>>> [ 19.730409][T1] debug: unmapping init [mem 0xdc7bc000-0xdca30fff]
>>> [ 19.734289][T1] Write protecting kernel text and read-only data:
>>> 13888k
>>> [ 19.737675][T1] rodata_test: all tests were successful
>>> [ 19.740757][T1] Run /sbin/init as init process
>>> [ 19.792877][T1] __phys_addr: max_low_pfn=0x36ffe, x=0xff001ff1,
>>> phys_addr=0x3f001ff1
>
> It seems like this address is way out of range of the physical memory.
> That seems like it's vmalloc or something, but that was actually
> explicitly tested for back in the v4.8 version (it became unneeded
> later).
>
>>> [ 19.796561][T1] [ cut here ]
>>> [ 19.797501][T1] kernel BUG at ../arch/x86/mm/physaddr.c:83!
>>> [ 19.802799][T1] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
>>> [ 19.803782][T1] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc8
>>> #6
>>> [ 19.803782][T1] Hardware name: Dell Inc. Inspiron 1318
>>> /0C236D, BIOS A04 01/15/2009
>>> [ 19.803782][T1] EIP: __phys_addr+0xaf/0x100
>>> [ 19.803782][T1] Code: 85 c0 74 67 89 f7 c1 ef 0c 39 f8 73 2e 56 53
>>> 50 68 90 9f 1f dc 68 00 eb 45 dc e8 ec b3 09 00 83 c4 14 3b 3d 30 55 cf dc
>>> 76 11 <0f> 0b b8 7c 3b 5c dc e8 45 53 4c 00 90 8d 74 26 00 89 d8 e8 39 cd
>>> [ 19.803782][T1] EAX: 0044 EBX: ff001ff1 ECX: EDX:
>>> db90a471
>>> [ 19.803782][T1] ESI: 3f001ff1 EDI: 0003f001 EBP: f41ddea0 ESP:
>>> f41dde90
>>> [ 19.803782][T1] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS:
>>> 00010216
>>> [ 19.803782][T1] CR0: 80050033 CR2: dc218544 CR3: 1ca39000 CR4:
>>> 000406d0
>>> [ 19.803782][T1] Call Trace:
>>> [ 19.803782][T1] __check_object_size+0xaf/0x3c0
>>> [ 19.803782][T1] ? __might_sleep+0x80/0xa0
>>> [ 19.803782][T1] copy_strings+0x1c2/0x370
>
> Oh, this is actually copying into a kmap() pointer due to the weird
> stuff exec() does:
>
> kaddr = kmap(kmapped_page);
> ...
> if (copy_from_user(kaddr+offset, str, bytes_to_copy)) {
>
>>> [ 19.803782][T1] copy_strings_kernel+0x2b/0x40
>>>
>>> Full boot log or kernel .config file are available if wanted.
>
> Is kmap somewhere "unexpected" in this case? Ah-ha, yes, it seems it is.
> There is even a helper to do the "right" thing as virt_to_page(). This
> seems to be used very rarely in the kernel... is there a page type for
> kmap pages? This seems like a hack, but it fixes it:
>
Tested-by: Randy Dunlap
Thanks.
>
> diff --git a/mm/usercopy.c b/mm/usercopy.c
> index 98e924864554..5a14b80ad63e 100644
> --- a/mm/usercopy.c
> +++ b/mm/usercopy.c
> @@ -11,6 +11,7 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include
> +#include
> #include
> #include
> #include
> @@ -227,7 +228,7 @@ static inline void check_heap_object(const void *ptr,
> unsigned long n,
> if (!virt_addr_valid(ptr))
> return;
>
> - page = virt_to_head_page(ptr);
> + page = compound_head(kmap_to_page((void *)ptr));
>
> if (PageSlab(page)) {
> /* Check slab allocator for flags and size. */
>
>
> What's the right way to "ignore" the kmap range? (i.e. it's not Slab, so
> ignore
[PATCH v2] net: mdio: switch to using gpiod_get_optional()
The MDIO device reset line is optional and now that gpiod_get_optional()
returns proper value when GPIO support is compiled out, there is no
reason to use fwnode_get_named_gpiod() that I plan to hide away.
Let's switch to using more standard gpiod_get_optional() and
gpiod_set_consumer_name() to keep the nice "PHY reset" label.
Also there is no reason to only try to fetch the reset GPIO when we have
OF node, gpiolib can fetch GPIO data from firmwares as well.
Signed-off-by: Dmitry Torokhov
---
Note this is an update to a patch titled "[PATCH 05/11] net: mdio:
switch to using fwnode_gpiod_get_index()" that no longer uses the new
proposed API and instead works with already existing ones.
drivers/net/phy/mdio_bus.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index ce940871331e..2e29ab841b4d 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -42,21 +42,17 @@
static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
{
- struct gpio_desc *gpiod = NULL;
+ int error;
/* Deassert the optional reset signal */
- if (mdiodev->dev.of_node)
- gpiod = fwnode_get_named_gpiod(>dev.of_node->fwnode,
- "reset-gpios", 0, GPIOD_OUT_LOW,
- "PHY reset");
- if (IS_ERR(gpiod)) {
- if (PTR_ERR(gpiod) == -ENOENT || PTR_ERR(gpiod) == -ENOSYS)
- gpiod = NULL;
- else
- return PTR_ERR(gpiod);
- }
-
- mdiodev->reset_gpio = gpiod;
+ mdiodev->reset_gpio = gpiod_get_optional(>dev,
+"reset", GPIOD_OUT_LOW);
+ error = PTR_ERR_OR_ZERO(mdiodev->reset_gpio);
+ if (error)
+ return error;
+
+ if (mdiodev->reset_gpio)
+ gpiod_set_consumer_name(mdiodev->reset_gpio, "PHY reset");
return 0;
}
--
2.23.0.237.gc6a4ce50a0-goog
--
Dmitry
Re: [PATCH 1/2] x86,sched: Add support for frequency invariance
On Mon, 2019-09-09 at 04:42 +0200, Giovanni Gherdovich wrote: ... > + > +/* > + * APERF/MPERF frequency ratio computation. > + * > + * The scheduler wants to do frequency invariant accounting and > needs a <1 > + * ratio to account for the 'current' frequency, corresponding to > + * freq_curr / freq_max. I thought this is no longer the restriction and Vincent did some work to remove this restriction. Thanks, Srinivas
Re: [PATCH] scsi: storvsc: Add the support of hibernation
Dexuan, > When we're in storvsc_suspend(), we're sure the SCSI layer has > quiesced the scsi device by scsi_bus_suspend() -> ... -> > scsi_device_quiesce(), so the low level SCSI adapter driver only needs > to suspend/resume its own state. Acked-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 4/4] x86: fix function types in COND_SYSCALL
On Fri, Sep 13, 2019 at 2:00 PM Sami Tolvanen wrote: > > Define a weak function in COND_SYSCALL instead of a weak alias to > sys_ni_syscall, which has an incompatible type. This fixes indirect > call mismatches with Control-Flow Integrity (CFI) checking. > Didn't you just fix the type of sys_ni_syscall? What am I missing here?
Re: [PATCH 3/4] x86: use the correct function type for sys_ni_syscall
On Fri, Sep 13, 2019 at 2:00 PM Sami Tolvanen wrote: > > Use the correct function type for sys_ni_syscall in system > call tables to fix indirect call mismatches with Control-Flow > Integrity (CFI) checking. Should this be SYSCALL_DEFINE0?
Re: [PATCH 2/4] x86: use the correct function type for sys32_(rt_)sigreturn
On Fri, Sep 13, 2019 at 2:00 PM Sami Tolvanen wrote:
>
> Use the correct function type to avoid tripping Control-Flow
> Integrity (CFI) checking.
>
> Signed-off-by: Sami Tolvanen
> ---
> arch/x86/ia32/ia32_signal.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
> index 1cee10091b9f..878d8998ce6d 100644
> --- a/arch/x86/ia32/ia32_signal.c
> +++ b/arch/x86/ia32/ia32_signal.c
> @@ -118,7 +118,7 @@ static int ia32_restore_sigcontext(struct pt_regs *regs,
> return err;
> }
>
> -asmlinkage long sys32_sigreturn(void)
> +asmlinkage long sys32_sigreturn(const struct pt_regs *__unused)
> {
> struct pt_regs *regs = current_pt_regs();
> struct sigframe_ia32 __user *frame = (struct sigframe_ia32 __user
> *)(regs->sp-8);
> @@ -144,7 +144,7 @@ asmlinkage long sys32_sigreturn(void)
> return 0;
> }
>
> -asmlinkage long sys32_rt_sigreturn(void)
> +asmlinkage long sys32_rt_sigreturn(const struct pt_regs *__unused)
> {
> struct pt_regs *regs = current_pt_regs();
> struct rt_sigframe_ia32 __user *frame;
Shouldn't these be COMPAT_SYSCALL_DEFINE0?
I think you should pick this patch up and add it to your series:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/syscalls=07daeef08d26728c120ecbe57a55cb5714810b84
with the obvious type fixup, of course. And then write a little patch
to use COMPAT_SYSCALL_DEFINE0 for rt_sigreturn and sigreturn.
> --
> 2.23.0.237.gc6a4ce50a0-goog
>
[tip: sched/core] sched/fair: Speed-up energy-aware wake-ups
The following commit has been merged into the sched/core branch of tip: Commit-ID: eb92692b2544d3f415887dbbc98499843dfe568b Gitweb: https://git.kernel.org/tip/eb92692b2544d3f415887dbbc98499843dfe568b Author:Quentin Perret AuthorDate:Thu, 12 Sep 2019 11:44:04 +02:00 Committer: Ingo Molnar CommitterDate: Fri, 13 Sep 2019 07:45:17 +02:00 sched/fair: Speed-up energy-aware wake-ups EAS computes the energy impact of migrating a waking task when deciding on which CPU it should run. However, the current approach is known to have a high algorithmic complexity, which can result in prohibitively high wake-up latencies on systems with complex energy models, such as systems with per-CPU DVFS. On such systems, the algorithm complexity is in O(n^2) (ignoring the cost of searching for performance states in the EM) with 'n' the number of CPUs. To address this, re-factor the EAS wake-up path to compute the energy 'delta' (with and without the task) on a per-performance domain basis, rather than system-wide, which brings the complexity down to O(n). No functional changes intended. Test results * Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs, A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android userspace, no graphics. * Test case: Run a periodic rt-app task, with 16ms period, ramping down from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]). Frequencies of all CPUs are pinned to max (using scaling_min_freq CPUFreq sysfs entries) to reduce variability. The time to run select_task_rq_fair() is measured using the function profiler (/sys/kernel/debug/tracing/trace_stat/function*). See the test script for more details [2]. Test 1: I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one CPUFreq policy per CPU (8 policies in total). Since all frequencies are pinned to max for the test, this should have no impact on the actual frequency selection, but it does in the EAS calculation. +---+--+ | Without patch | With patch | +-+-+--+--+-+-+--+ | CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us)| s^2 (us) | |-+-+--+--+-+-+--+ | 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 | | 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 | | 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 | | 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 | | 4 | 316 | 7.834| 178.217 | 425 | 5.413 (-30.9%) | 20.803 | | 5 | 447 | 8.424| 144.638 | 556 | 5.929 (-29.6%) | 27.301 | | 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 | | 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 | +-+-+--+--+-+-+--+ * Hit, Avg and s^2 are as reported by the function profiler Test 2: I also ran the same test with a normal DT, with 2 CPUFreq policies, to see if this causes regressions in the most common case. +---+--+ | Without patch | With patch | +-+-+--+--+-+-+--+ | CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us)| s^2 (us) | |-+-+--+--+-+-+--+ | 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 | | 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 | | 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 | | 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 | | 4 | 457 | 3.822| 9.895| 757 | 4.616 (+20.8%) | 13.369 | | 5 | 344 | 4.301| 7.121| 594 | 5.320 (+23.7%) | 18.798 | | 6 | 472 | 4.326| 7.849| 464 | 5.648 (+30.6%) | 22.022 | | 7 | 331 | 4.630| 13.937 | 408 | 5.299 (+14.4%) | 18.273 | +-+-+--+--+-+-+--+ * Hit, Avg and s^2 are as reported by the function profiler In addition to these two tests, I also ran 50 iterations of the Lisa EAS functional test suite [3] with this patch applied on Arm Juno r0, Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions (all EAS functional tests are passing). [1] https://paste.debian.net/1100055/ [2] https://paste.debian.net/1100057/ [3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py Signed-off-by: Quentin Perret Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: dietmar.eggem...@arm.com Cc: juri.le...@redhat.com Cc: morten.rasmus...@arm.com Cc: qais.you...@arm.com Cc: qper...@qperret.net Cc: r...@rjwysocki.net Cc: tk...@google.com Cc:
[tip: sched/core] sched/psi: Correct overly pessimistic size calculation
The following commit has been merged into the sched/core branch of tip: Commit-ID: 4adcdcea717cb2d8436bef00dd689aa5bc76f11b Gitweb: https://git.kernel.org/tip/4adcdcea717cb2d8436bef00dd689aa5bc76f11b Author:Miles Chen AuthorDate:Thu, 12 Sep 2019 18:34:52 +08:00 Committer: Ingo Molnar CommitterDate: Fri, 13 Sep 2019 07:49:28 +02:00 sched/psi: Correct overly pessimistic size calculation When passing a equal or more then 32 bytes long string to psi_write(), psi_write() copies 31 bytes to its buf and overwrites buf[30] with '\0'. Which makes the input string 1 byte shorter than it should be. Fix it by copying sizeof(buf) bytes when nbytes >= sizeof(buf). This does not cause problems in normal use case like: "some 50 1000" or "full 50 1000" because they are less than 32 bytes in length. /* assuming nbytes == 35 */ char buf[32]; buf_size = min(nbytes, (sizeof(buf) - 1)); /* buf_size = 31 */ if (copy_from_user(buf, user_buf, buf_size)) return -EFAULT; buf[buf_size - 1] = '\0'; /* buf[30] = '\0' */ Before: %cd /proc/pressure/ %echo "123456789|123456789|123456789|1234" > memory [ 22.473497] nbytes=35,buf_size=31 [ 22.473775] 123456789|123456789|123456789| (print 30 chars) %sh: write error: Invalid argument %echo "123456789|123456789|123456789|1" > memory [ 64.916162] nbytes=32,buf_size=31 [ 64.916331] 123456789|123456789|123456789| (print 30 chars) %sh: write error: Invalid argument After: %cd /proc/pressure/ %echo "123456789|123456789|123456789|1234" > memory [ 254.837863] nbytes=35,buf_size=32 [ 254.838541] 123456789|123456789|123456789|1 (print 31 chars) %sh: write error: Invalid argument %echo "123456789|123456789|123456789|1" > memory [ 9965.714935] nbytes=32,buf_size=32 [ 9965.715096] 123456789|123456789|123456789|1 (print 31 chars) %sh: write error: Invalid argument Also remove the superfluous parentheses. Signed-off-by: Miles Chen Cc: Cc: Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: https://lkml.kernel.org/r/20190912103452.13281-1-miles.c...@mediatek.com Signed-off-by: Ingo Molnar --- kernel/sched/psi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c index 7acc632..4b14a32 100644 --- a/kernel/sched/psi.c +++ b/kernel/sched/psi.c @@ -1190,7 +1190,7 @@ static ssize_t psi_write(struct file *file, const char __user *user_buf, if (static_branch_likely(_disabled)) return -EOPNOTSUPP; - buf_size = min(nbytes, (sizeof(buf) - 1)); + buf_size = min(nbytes, sizeof(buf)); if (copy_from_user(buf, user_buf, buf_size)) return -EFAULT;
Re: [PATCH bpf-next 11/11] samples: bpf: makefile: add sysroot support
On Fri, Sep 13, 2019 at 09:45:31PM +, Yonghong Song wrote:
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote:
Basically it only enables that was added by previous couple fixes.
For sure, just make tools/include to be included after sysroot
headers.
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
make samples/bpf/ SYSROOT="path/to/sysroot"
Sysroot contains correct libs installed and its headers ofc.
Useful when working with NFC or virtual machine.
Signed-off-by: Ivan Khoronzhuk
---
samples/bpf/Makefile | 5 +
samples/bpf/README.rst | 10 ++
2 files changed, 15 insertions(+)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 4edc5232cfc1..68ba78d1dbbe 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -177,6 +177,11 @@ ifeq ($(ARCH), arm)
CLANG_EXTRA_CFLAGS := $(D_OPTIONS)
endif
+ifdef SYSROOT
+ccflags-y += --sysroot=${SYSROOT}
+PROGS_LDFLAGS := -L${SYSROOT}/usr/lib
+endif
+
ccflags-y += -I$(objtree)/usr/include
ccflags-y += -I$(srctree)/tools/lib/bpf/
ccflags-y += -I$(srctree)/tools/testing/selftests/bpf/
diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
index 5f27e4faca50..786d0ab98e8a 100644
--- a/samples/bpf/README.rst
+++ b/samples/bpf/README.rst
@@ -74,3 +74,13 @@ samples for the cross target.
export ARCH=arm64
export CROSS_COMPILE="aarch64-linux-gnu-"
make samples/bpf/ LLC=~/git/llvm/build/bin/llc
CLANG=~/git/llvm/build/bin/clang
+
+If need to use environment of target board (headers and libs), the SYSROOT
+also can be set, pointing on FS of target board:
+
+export ARCH=arm64
+export CROSS_COMPILE="aarch64-linux-gnu-"
+make samples/bpf/ SYSROOT=~/some_sdk/linux-devkit/sysroots/aarch64-linux-gnu
+
+Setting LLC and CLANG is not necessarily if it's installed on HOST and have
+in its targets appropriate arch triple (usually it has several arches).
You have very good description about how to build and test in cover
letter. Could you include those instructions here as well? This will
help keep a record so later people can try/test if needed.
I will try.
Thanks!!!
--
Regards,
Ivan Khoronzhuk
Re: [PATCH 1/4] x86: use the correct function type in SYSCALL_DEFINE0
On Fri, Sep 13, 2019 at 2:00 PM Sami Tolvanen wrote: > > Although a syscall defined using SYSCALL_DEFINE0 doesn't accept > parameters, use the correct function type to avoid type mismatches > with Control-Flow Integrity (CFI) checking. Acked-by: Andy Lutomirski
Re: [PATCH bpf-next 10/11] libbpf: makefile: add C/CXX/LDFLAGS to libbpf.so and test_libpf targets
On Fri, Sep 13, 2019 at 09:43:22PM +, Yonghong Song wrote: On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote: In case of LDFLAGS and EXTRA_CC/CXX flags there is no way to pass them correctly to build command, for instance when --sysroot is used or external libraries are used, like -lelf, wich can be absent in toolchain. This is used for samples/bpf cross-compiling allowing to get elf lib from sysroot. Signed-off-by: Ivan Khoronzhuk --- samples/bpf/Makefile | 8 +++- tools/lib/bpf/Makefile | 11 --- 2 files changed, 15 insertions(+), 4 deletions(-) Could you separate this patch into two? One of libbpf and another for samples. The subject 'libbpf: ...' is not entirely accurate. Yes, ofc. But there is too many patches already, but better a lot of small changes then couple huge. diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile index 79c9aa41832e..4edc5232cfc1 100644 --- a/samples/bpf/Makefile +++ b/samples/bpf/Makefile @@ -186,6 +186,10 @@ ccflags-y += -I$(srctree)/tools/perf ccflags-y += $(D_OPTIONS) ccflags-y += -Wall ccflags-y += -fomit-frame-pointer + +EXTRA_CXXFLAGS := $(ccflags-y) + +# options not valid for C++ ccflags-y += -Wmissing-prototypes ccflags-y += -Wstrict-prototypes @@ -252,7 +256,9 @@ clean: $(LIBBPF): FORCE # Fix up variables inherited from Kbuild that tools/ build system won't like - $(MAKE) -C $(dir $@) RM='rm -rf' LDFLAGS= srctree=$(BPF_SAMPLES_PATH)/../../ O= + $(MAKE) -C $(dir $@) RM='rm -rf' EXTRA_CFLAGS="$(PROGS_CFLAGS)" \ + EXTRA_CXXFLAGS="$(EXTRA_CXXFLAGS)" LDFLAGS=$(PROGS_LDFLAGS) \ + srctree=$(BPF_SAMPLES_PATH)/../../ O= $(obj)/syscall_nrs.h: $(obj)/syscall_nrs.s FORCE $(call filechk,offsets,__SYSCALL_NRS_H__) diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile index c6f94cffe06e..bccfa556ef4e 100644 --- a/tools/lib/bpf/Makefile +++ b/tools/lib/bpf/Makefile @@ -94,6 +94,10 @@ else CFLAGS := -g -Wall endif +ifdef EXTRA_CXXFLAGS + CXXFLAGS := $(EXTRA_CXXFLAGS) +endif + ifeq ($(feature-libelf-mmap), 1) override CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT endif @@ -176,8 +180,9 @@ $(BPF_IN): force elfdep bpfdep $(OUTPUT)libbpf.so: $(OUTPUT)libbpf.so.$(LIBBPF_VERSION) $(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN) - $(QUIET_LINK)$(CC) --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \ - -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@ + $(QUIET_LINK)$(CC) $(LDFLAGS) \ + --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \ + -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@ @ln -sf $(@F) $(OUTPUT)libbpf.so @ln -sf $(@F) $(OUTPUT)libbpf.so.$(LIBBPF_MAJOR_VERSION) @@ -185,7 +190,7 @@ $(OUTPUT)libbpf.a: $(BPF_IN) $(QUIET_LINK)$(RM) $@; $(AR) rcs $@ $^ $(OUTPUT)test_libbpf: test_libbpf.cpp $(OUTPUT)libbpf.a - $(QUIET_LINK)$(CXX) $(INCLUDES) $^ -lelf -o $@ + $(QUIET_LINK)$(CXX) $(CXXFLAGS) $(LDFLAGS) $(INCLUDES) $^ -lelf -o $@ $(OUTPUT)libbpf.pc: $(QUIET_GEN)sed -e "s|@PREFIX@|$(prefix)|" \ -- Regards, Ivan Khoronzhuk
Re: [PATCH bpf-next 08/11] samples: bpf: makefile: base progs build on makefile.progs
On Fri, Sep 13, 2019 at 09:41:25PM +, Yonghong Song wrote: On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote: The main reason for that - HOSTCC and CC have different aims. It was tested for arm cross compilation, based on linaro toolchain, but should work for others. In order to split cross compilation (CC) with host build (HOSTCC), lets base bpf samples on Makefile.progs. It allows to cross-compile samples/bpf progs with CC while auxialry tools running on host built with HOSTCC. I got a compilation failure with the following error $ make samples/bpf/ ... LD samples/bpf/hbm CC samples/bpf/syscall_nrs.s gcc: error: -pg and -fomit-frame-pointer are incompatible make[2]: *** [samples/bpf/syscall_nrs.s] Error 1 make[1]: *** [samples/bpf/] Error 2 make: *** [sub-make] Error 2 Could you take a look? Yes, sure. Ilias also observer this, interesting that on my setup for cross and native build on arm and arm64 doesn't have this error. Now I see log and know how to proceed, I will fix it, maybe by using another var for cflags. Despite of it, just to be sure in order to avoid smth like this at least for native build, I will add one more patch like: " samples: bpf: makefile: don't use host cflags when cross compile While compile natively, the hosts cflags and ldflags are equal to ones used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should have own, used for target arch. While verification, for arm, arm64 and x86_64 the following flags were used alsways: -Wall -O2 -fomit-frame-pointer -Wmissing-prototypes -Wstrict-prototypes So, add them as they were verified and used before adding Makefile.progs, but anyway limit it only for cross compile options as for host can be some configurations when another options can be used, So, for host arch samples left all as is, it allows to avoid potential option mistmatches for existent environments. " +ifdef CROSS_COMPILE +ccflags-y += -Wall +ccflags-y += -O2 +ccflags-y += -fomit-frame-pointer +ccflags-y += -Wmissing-prototypes +ccflags-y += -Wstrict-prototypes +else +ccflags-y += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS) +PROGS_LDLIBS := $(KBUILD_HOSTLDLIBS) +endif Signed-off-by: Ivan Khoronzhuk --- samples/bpf/Makefile | 138 +++ 1 file changed, 73 insertions(+), 65 deletions(-) diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile index f5dbf3d0c5f3..625a71f2e9d2 100644 --- a/samples/bpf/Makefile +++ b/samples/bpf/Makefile @@ -4,55 +4,53 @@ BPF_SAMPLES_PATH ?= $(abspath $(srctree)/$(src)) TOOLS_PATH := $(BPF_SAMPLES_PATH)/../../tools # List of programs to build -hostprogs-y := test_lru_dist -hostprogs-y += sock_example -hostprogs-y += fds_example -hostprogs-y += sockex1 -hostprogs-y += sockex2 -hostprogs-y += sockex3 -hostprogs-y += tracex1 -hostprogs-y += tracex2 -hostprogs-y += tracex3 -hostprogs-y += tracex4 -hostprogs-y += tracex5 -hostprogs-y += tracex6 -hostprogs-y += tracex7 -hostprogs-y += test_probe_write_user -hostprogs-y += trace_output -hostprogs-y += lathist -hostprogs-y += offwaketime -hostprogs-y += spintest -hostprogs-y += map_perf_test -hostprogs-y += test_overhead -hostprogs-y += test_cgrp2_array_pin -hostprogs-y += test_cgrp2_attach -hostprogs-y += test_cgrp2_sock -hostprogs-y += test_cgrp2_sock2 -hostprogs-y += xdp1 -hostprogs-y += xdp2 -hostprogs-y += xdp_router_ipv4 -hostprogs-y += test_current_task_under_cgroup -hostprogs-y += trace_event -hostprogs-y += sampleip -hostprogs-y += tc_l2_redirect -hostprogs-y += lwt_len_hist -hostprogs-y += xdp_tx_iptunnel -hostprogs-y += test_map_in_map -hostprogs-y += per_socket_stats_example -hostprogs-y += xdp_redirect -hostprogs-y += xdp_redirect_map -hostprogs-y += xdp_redirect_cpu -hostprogs-y += xdp_monitor -hostprogs-y += xdp_rxq_info -hostprogs-y += syscall_tp -hostprogs-y += cpustat -hostprogs-y += xdp_adjust_tail -hostprogs-y += xdpsock -hostprogs-y += xdp_fwd -hostprogs-y += task_fd_query -hostprogs-y += xdp_sample_pkts -hostprogs-y += ibumad -hostprogs-y += hbm +progs-y := test_lru_dist +progs-y += sock_example +progs-y += fds_example +progs-y += sockex1 +progs-y += sockex2 +progs-y += sockex3 +progs-y += tracex1 +progs-y += tracex2 +progs-y += tracex3 +progs-y += tracex4 +progs-y += tracex5 +progs-y += tracex6 +progs-y += tracex7 +progs-y += test_probe_write_user +progs-y += trace_output +progs-y += lathist +progs-y += offwaketime +progs-y += spintest +progs-y += map_perf_test +progs-y += test_overhead +progs-y += test_cgrp2_array_pin +progs-y += test_cgrp2_attach +progs-y += test_cgrp2_sock +progs-y += test_cgrp2_sock2 +progs-y += xdp1 +progs-y += xdp2 +progs-y += xdp_router_ipv4 +progs-y += test_current_task_under_cgroup +progs-y += trace_event +progs-y += sampleip +progs-y += tc_l2_redirect +progs-y += lwt_len_hist +progs-y += xdp_tx_iptunnel +progs-y += test_map_in_map +progs-y += xdp_redirect_map +progs-y += xdp_redirect_cpu +progs-y += xdp_monitor +progs-y +=
[PATCH 2/3] drm/encoder: Fix possible_crtcs documentation
Similar to possible_clones, we don't actually use possible_crtcs until
the driver is registered with userspace. So, fix the documentation to
indicate this.
Signed-off-by: Lyude Paul
---
include/drm/drm_encoder.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index 81273b50b3f6..d65173d413b7 100644
--- a/include/drm/drm_encoder.h
+++ b/include/drm/drm_encoder.h
@@ -140,7 +140,7 @@ struct drm_encoder {
* @possible_crtcs: Bitmask of potential CRTC bindings, using
* drm_crtc_index() as the index into the bitfield. The driver must set
* the bits for all _crtc objects this encoder can be connected to
-* before calling drm_encoder_init().
+* before calling drm_dev_register().
*
* In reality almost every driver gets this wrong.
*
--
2.21.0
Re: [PATCH bpf-next 07/11] samples: bpf: add makefile.prog for separate CC build
On Fri, Sep 13, 2019 at 09:33:58PM +, Yonghong Song wrote: On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote: The makefile.prog is added only, will be used in sample/bpf/Makefile later in order to switch cross-compiling on CC from HOSTCC. The HOSTCC is supposed to build binaries and tools running on the host afterwards, in order to simplify build or so, like "fixdep" or else. In case of cross compiling "fixdep" is executed on host when the rest samples should run on target arch. In order to build binaries for target arch with CC and tools running on host with HOSTCC, lets add Makefile.prog for simplicity, having definition and routines similar to ones, used in script/Makefile.host. This allows later add cross-compilation to samples/bpf with minimum changes. So this is really Makefile.host or Makefile.user, right? It's cut and modified version of Makefile.host In BPF, 'prog' can refers to user prog or bpf prog. To avoid ambiguity, maybe Makefile.host? Makefile.target? as target = host not always. Makefile.user also looks ok, but doesn't contain target, maybe "targetuser", but bpf is also target... Initially I was thinking about Makefile.targetprog, but it looks too long. Makefile.prog contains only stuff needed for samples/bpf, potentially can be reused and extended for other prog sets later and now needed What do you mean 'extended for other prog sets'? I am wondering whether Another kind of samples...with c++ for instance. we could just include 'scripts/Makefile.host'? How hard it is? It's bound to HOSTCC and it's environment. It is included by default and was used before this patchset, blocking cross complication. only for unblocking tricky samples/bpf cross compilation. Signed-off-by: Ivan Khoronzhuk --- samples/bpf/Makefile.prog | 77 +++ 1 file changed, 77 insertions(+) create mode 100644 samples/bpf/Makefile.prog diff --git a/samples/bpf/Makefile.prog b/samples/bpf/Makefile.prog new file mode 100644 index ..3781999b9193 --- /dev/null +++ b/samples/bpf/Makefile.prog @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: GPL-2.0 +# == +# Building binaries on the host system +# Binaries are not used during the compilation of the kernel, and intendent +# to be build for target board, target board can be host ofc. Added to build +# binaries to run not on host system. +# +# Only C is supported, but can be extended for C++. The above comment is not needed. will drop it. samples/bpf/ only have C now. I am wondering whether your below scripts can be simplified, e.g., removing cxxobjs. I think yes, will try +# +# Sample syntax (see Documentation/kbuild/makefiles.rst for reference) +# progs-y := xsk_example +# Will compile xdpsock_example.c and create an executable named xsk_example +# +# progs-y:= xdpsock +# xdpsock-objs := xdpsock_1.o xdpsock_2.o +# Will compile xdpsock_1.c and xdpsock_2.c, and then link the executable +# xdpsock, based on xdpsock_1.o and xdpsock_2.o +# +# Inherited from scripts/Makefile.host +# +__progs := $(sort $(progs-y)) + +# C code +# Executables compiled from a single .c file +prog-csingle := $(foreach m,$(__progs), \ + $(if $($(m)-objs)$($(m)-cxxobjs),,$(m))) + +# C executables linked based on several .o files +prog-cmulti:= $(foreach m,$(__progs),\ + $(if $($(m)-cxxobjs),,$(if $($(m)-objs),$(m + +# Object (.o) files compiled from .c files +prog-cobjs := $(sort $(foreach m,$(__progs),$($(m)-objs))) + +prog-csingle := $(addprefix $(obj)/,$(prog-csingle)) +prog-cmulti:= $(addprefix $(obj)/,$(prog-cmulti)) +prog-cobjs := $(addprefix $(obj)/,$(prog-cobjs)) + +# +# Handle options to gcc. Support building with separate output directory + +_progc_flags = $(PROGS_CFLAGS) \ + $(PROGCFLAGS_$(basetarget).o) + +# $(objtree)/$(obj) for including generated headers from checkin source files +ifeq ($(KBUILD_EXTMOD),) +ifdef building_out_of_srctree +_progc_flags += -I $(objtree)/$(obj) +endif +endif + +progc_flags= -Wp,-MD,$(depfile) $(_progc_flags) + +# Create executable from a single .c file +# prog-csingle -> Executable +quiet_cmd_prog-csingle = CC $@ + cmd_prog-csingle = $(CC) $(progc_flags) $(PROGS_LDFLAGS) -o $@ $< \ + $(PROGS_LDLIBS) $(PROGLDLIBS_$(@F)) +$(prog-csingle): $(obj)/%: $(src)/%.c FORCE + $(call if_changed_dep,prog-csingle) + +# Link an executable based on list of .o files, all plain c +# prog-cmulti -> executable +quiet_cmd_prog-cmulti = LD $@ + cmd_prog-cmulti = $(CC) $(progc_flags) $(PROGS_LDFLAGS) -o $@ \ + $(addprefix $(obj)/,$($(@F)-objs)) \ + $(PROGS_LDLIBS) $(PROGLDLIBS_$(@F)) +$(prog-cmulti): $(prog-cobjs) FORCE + $(call if_changed,prog-cmulti) +$(call multi_depend, $(prog-cmulti), , -objs) + +# Create .o file from a single .c file +#
Re: [PATCH 00/11] KVM: x86/mmu: Restore fast invalidate/zap flow
On 13/09/19 04:46, Sean Christopherson wrote: > Restore the fast invalidate flow for zapping shadow pages and use it > whenever vCPUs can be active in the VM. This fixes (in theory, not yet > confirmed) a regression reported by James Harvey where KVM can livelock > in kvm_mmu_zap_all() when it's invoked in response to a memslot update. > > The fast invalidate flow was removed as it was deemed to be unnecessary > after its primary user, memslot flushing, was reworked to zap only the > memslot in question instead of all shadow pages. Unfortunately, zapping > only the memslot being (re)moved during a memslot update introduced a > regression for VMs with assigned devices. Because we could not discern > why zapping only the relevant memslot broke device assignment, or if the > regression extended beyond device assignment, we reverted to zapping all > shadow pages when a memslot is (re)moved. > > The revert to "zap all" failed to account for subsequent changes that > have been made to kvm_mmu_zap_all() between then and now. Specifically, > kvm_mmu_zap_all() now conditionally drops reschedules and drops mmu_lock > if a reschedule is needed or if the lock is contended. Dropping the lock > allows other vCPUs to add shadow pages, and, with enough vCPUs, can cause > kvm_mmu_zap_all() to get stuck in an infinite loop as it can never zap all > pages before observing lock contention or the need to reschedule. > > The reasoning behind having kvm_mmu_zap_all() conditionally reschedule was > that it would only be used when the VM is inaccesible, e.g. when its > mm_struct is dying or when the VM itself is being destroyed. In that case, > playing nice with the rest of the kernel instead of hogging cycles to free > unused shadow pages made sense. > > Since it's unlikely we'll root cause the device assignment regression any > time soon, and that simply removing the conditional rescheduling isn't > guaranteed to return us to a known good state, restore the fast invalidate > flow for zapping on memslot updates, including mmio generation wraparound. > Opportunisticaly tack on a bug fix and a couple enhancements. > > Alex and James, it probably goes without saying... please test, especially > patch 01/11 as a standalone patch as that'll likely need to be applied to > stable branches, assuming it works. Thanks! > > Sean Christopherson (11): > KVM: x86/mmu: Reintroduce fast invalidate/zap for flushing memslot > KVM: x86/mmu: Treat invalid shadow pages as obsolete > KVM: x86/mmu: Use fast invalidate mechanism to zap MMIO sptes > KVM: x86/mmu: Revert "Revert "KVM: MMU: show mmu_valid_gen in shadow > page related tracepoints"" > KVM: x86/mmu: Revert "Revert "KVM: MMU: add tracepoint for > kvm_mmu_invalidate_all_pages"" > KVM: x86/mmu: Revert "Revert "KVM: MMU: zap pages in batch"" > KVM: x86/mmu: Revert "Revert "KVM: MMU: collapse TLB flushes when zap > all pages"" > KVM: x86/mmu: Revert "Revert "KVM: MMU: reclaim the zapped-obsolete > page first"" > KVM: x86/mmu: Revert "KVM: x86/mmu: Remove is_obsolete() call" > KVM: x86/mmu: Explicitly track only a single invalid mmu generation > KVM: x86/mmu: Skip invalid pages during zapping iff root_count is zero > > arch/x86/include/asm/kvm_host.h | 4 +- > arch/x86/kvm/mmu.c | 154 > arch/x86/kvm/mmutrace.h | 42 +++-- > arch/x86/kvm/x86.c | 1 + > 4 files changed, 173 insertions(+), 28 deletions(-) > Thanks, I'm testing patch 1 and should send a pull request to Linus tomorrow morning as soon as I get the results. Paolo
Re: [RFC V1 3/7] x86/ims: Add support for a new IMS irq domain
On Thu, 12 Sep 2019 18:32:04 -0700
Megha Dey wrote:
> This patch adds support for the creation of a new IMS irq domain. It
> creates a new irq_chip associated with the IMS domain and adds the
> necessary domain operations to it.
>
> Cc: Jacob Pan
> Signed-off-by: Sanjay Kumar
> Signed-off-by: Megha Dey
> ---
> arch/x86/include/asm/msi.h | 4 ++
> arch/x86/kernel/apic/Makefile| 1 +
> arch/x86/kernel/apic/ims.c | 93
>
> arch/x86/kernel/apic/msi.c | 4 +-
> drivers/vfio/mdev/mdev_core.c| 6 +++
> drivers/vfio/mdev/mdev_private.h | 1 -
> include/linux/mdev.h | 2 +
> 7 files changed, 108 insertions(+), 3 deletions(-)
> create mode 100644 arch/x86/kernel/apic/ims.c
>
> diff --git a/arch/x86/include/asm/msi.h b/arch/x86/include/asm/msi.h
> index 25ddd09..51f9d25 100644
> --- a/arch/x86/include/asm/msi.h
> +++ b/arch/x86/include/asm/msi.h
> @@ -11,4 +11,8 @@ int pci_msi_prepare(struct irq_domain *domain, struct
> device *dev, int nvec,
>
> void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc);
>
> +struct msi_domain_info;
> +
> +irq_hw_number_t msi_get_hwirq(struct msi_domain_info *info,
> + msi_alloc_info_t *arg);
> #endif /* _ASM_X86_MSI_H */
> diff --git a/arch/x86/kernel/apic/Makefile b/arch/x86/kernel/apic/Makefile
> index a6fcaf16..75a2270 100644
> --- a/arch/x86/kernel/apic/Makefile
> +++ b/arch/x86/kernel/apic/Makefile
> @@ -12,6 +12,7 @@ obj-y += hw_nmi.o
>
> obj-$(CONFIG_X86_IO_APIC)+= io_apic.o
> obj-$(CONFIG_PCI_MSI)+= msi.o
> +obj-$(CONFIG_MSI_IMS)+= ims.o
> obj-$(CONFIG_SMP)+= ipi.o
>
> ifeq ($(CONFIG_X86_64),y)
> diff --git a/arch/x86/kernel/apic/ims.c b/arch/x86/kernel/apic/ims.c
> new file mode 100644
> index 000..d9808a5
> --- /dev/null
> +++ b/arch/x86/kernel/apic/ims.c
> @@ -0,0 +1,93 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright © 2019 Intel Corporation.
> + *
> + * Author: Megha Dey
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * Determine if a dev is mdev or not. Return NULL if not mdev device.
> + * Return mdev's parent dev if success.
> + */
> +static inline struct device *mdev_to_parent(struct device *dev)
> +{
> + struct device *ret = NULL;
> + struct device *(*fn)(struct device *dev);
> + struct bus_type *bus = symbol_get(mdev_bus_type);
> +
> + if (bus && dev->bus == bus) {
> + fn = symbol_get(mdev_dev_to_parent_dev);
> + ret = fn(dev);
> + symbol_put(mdev_dev_to_parent_dev);
> + symbol_put(mdev_bus_type);
Leaks a reference to the mdev module if dev->bus != bus. The new
version of dev_is_mdev() unconditionally leaks a reference. Thanks,
Alex
> + }
> +
> + return ret;
> +}
> +
> +static struct pci_dev *ims_get_pci_dev(struct device *dev)
> +{
> + struct pci_dev *pdev;
> +
> + if (dev_is_mdev(dev)) {
> + struct device *parent = mdev_to_parent(dev);
> +
> + pdev = to_pci_dev(parent);
> + } else {
> + pdev = to_pci_dev(dev);
> + }
> +
> + return pdev;
> +}
> +
> +int dev_ims_prepare(struct irq_domain *domain, struct device *dev, int nvec,
> + msi_alloc_info_t *arg)
> +{
> + struct pci_dev *pdev = ims_get_pci_dev(dev);
> +
> + init_irq_alloc_info(arg, NULL);
> + arg->msi_dev = pdev;
> + arg->type = X86_IRQ_ALLOC_TYPE_MSIX;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(dev_ims_prepare);
> +
> +#ifdef CONFIG_IRQ_REMAP
> +
> +static struct msi_domain_ops dev_ims_domain_ops = {
> + .get_hwirq = msi_get_hwirq,
> + .msi_prepare= dev_ims_prepare,
> +};
> +
> +static struct irq_chip dev_ims_ir_controller = {
> + .name = "IR-DEV-IMS",
> + .irq_unmask = dev_ims_unmask_irq,
> + .irq_mask = dev_ims_mask_irq,
> + .irq_ack= irq_chip_ack_parent,
> + .irq_retrigger = irq_chip_retrigger_hierarchy,
> + .irq_set_vcpu_affinity = irq_chip_set_vcpu_affinity_parent,
> + .flags = IRQCHIP_SKIP_SET_WAKE,
> + .irq_write_msi_msg = dev_ims_write_msg,
> +};
> +
> +static struct msi_domain_info ims_ir_domain_info = {
> + .flags = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> + MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX,
> + .ops= _ims_domain_ops,
> + .chip = _ims_ir_controller,
> + .handler= handle_edge_irq,
> + .handler_name = "edge",
> +};
> +
> +struct irq_domain *arch_create_ims_irq_domain(struct irq_domain *parent)
> +{
> + return pci_msi_create_irq_domain(NULL, _ir_domain_info, parent);
> +}
> +
> +#endif
> diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
> index 435bcda..65da813 100644
> ---
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
Hi Bart, > On 9/11/19 5:40 PM, Martin K. Petersen wrote: >> * Do not use custom To: and Cc: for individual patches. We want to see the >> whole series, even patches that potentially need to go through a different >> subsystem tree. > > Thanks for having written this summary. This is very helpful. For the > above paragraph, should it be clarified whether that requirement > applies to mailing list e-mail addresses only or also to individual > e-mail addresses? When using git send-email it is easy to end up with > different cc-lists per patch. I prefer to have the entire series sent to linux-scsi or target-devel. It wouldn't be so bad if discussions about the merits of a tree-wide change consistently happened in responses to the cover letter. But more often than not discussion happens in response to a patch touching a different subsystem and therefore in a mail exchange that doesn't end up on linux-scsi. >> * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__") >> and does not incur any zeroday test robot complaints. > > How about adding W=1 to that make command? > > How about existing drivers that trigger tons of endianness warnings, > e.g. qla2xxx? How about requiring that no new warnings are introduced? This was in response to a driver submission (for a different driver) around the time this doc was written. The problem is that it's sometimes hard to distinguish new warnings from old ones. I'm all for requiring that no new warnings are introduced. >> * The patch must have a commit message that describes, >> comprehensively and in plain English, what the patch does. > > How about making this requirement more detailed and requiring that not > only what has been changed is document but also why that change has > been made? I'd really like all this patch submission guideline material to live in Documentation/process. But yes. -- Martin K. Petersen Oracle Linux Engineering
[PATCH 1/3] HID: google: whiskers: more robust tablet mode detection
The USB interface may get detected before the platform/EC one, so let's
note the state of the base (if we receive event) and use it to correctly
initialize the tablet mode switch state.
Also let's start the HID interface immediately when probing, this will
ensure that we correctly process "base folded" events that may be sent
as we initialize the base. Note that this requires us to add a release()
function where we stop and close the hardware and switch the LED
registration away from devm interface as we need to make sure that we
destroy the LED instance before we stop the hardware.
Signed-off-by: Dmitry Torokhov
---
drivers/hid/hid-google-hammer.c | 71 ++---
1 file changed, 56 insertions(+), 15 deletions(-)
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 84f8c127ebdc..4f64f93ddfcb 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -35,6 +35,7 @@ struct cbas_ec {
struct device *dev; /* The platform device (EC) */
struct input_dev *input;
bool base_present;
+ bool base_folded;
struct notifier_block notifier;
};
@@ -208,7 +209,14 @@ static int __cbas_ec_probe(struct platform_device *pdev)
return error;
}
- input_report_switch(input, SW_TABLET_MODE, !cbas_ec.base_present);
+ if (!cbas_ec.base_present)
+ cbas_ec.base_folded = false;
+
+ dev_dbg(>dev, "%s: base: %d, folded: %d\n", __func__,
+ cbas_ec.base_present, cbas_ec.base_folded);
+
+ input_report_switch(input, SW_TABLET_MODE,
+ !cbas_ec.base_present || cbas_ec.base_folded);
cbas_ec_set_input(input);
@@ -322,10 +330,9 @@ static int hammer_kbd_brightness_set_blocking(struct
led_classdev *cdev,
static int hammer_register_leds(struct hid_device *hdev)
{
struct hammer_kbd_leds *kbd_backlight;
+ int error;
- kbd_backlight = devm_kzalloc(>dev,
-sizeof(*kbd_backlight),
-GFP_KERNEL);
+ kbd_backlight = kzalloc(sizeof(*kbd_backlight), GFP_KERNEL);
if (!kbd_backlight)
return -ENOMEM;
@@ -339,7 +346,26 @@ static int hammer_register_leds(struct hid_device *hdev)
/* Set backlight to 0% initially. */
hammer_kbd_brightness_set_blocking(_backlight->cdev, 0);
- return devm_led_classdev_register(>dev, _backlight->cdev);
+ error = led_classdev_register(>dev, _backlight->cdev);
+ if (error)
+ goto err_free_mem;
+
+ hid_set_drvdata(hdev, kbd_backlight);
+ return 0;
+
+err_free_mem:
+ kfree(kbd_backlight);
+ return error;
+}
+
+static void hammer_unregister_leds(struct hid_device *hdev)
+{
+ struct hammer_kbd_leds *kbd_backlight = hid_get_drvdata(hdev);
+
+ if (kbd_backlight) {
+ led_classdev_unregister(_backlight->cdev);
+ kfree(kbd_backlight);
+ }
}
#define HID_UP_GOOGLEVENDOR0xffd1
@@ -376,8 +402,9 @@ static int hammer_event(struct hid_device *hid, struct
hid_field *field,
usage->hid == WHISKERS_KBD_FOLDED) {
spin_lock_irqsave(_ec_lock, flags);
+ cbas_ec.base_folded = value;
hid_dbg(hid, "%s: base: %d, folded: %d\n", __func__,
- cbas_ec.base_present, value);
+ cbas_ec.base_present, cbas_ec.base_folded);
/*
* We should not get event if base is detached, but in case
@@ -436,6 +463,14 @@ static int hammer_probe(struct hid_device *hdev,
{
int error;
+ error = hid_parse(hdev);
+ if (error)
+ return error;
+
+ error = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (error)
+ return error;
+
/*
* We always want to poll for, and handle tablet mode events from
* Whiskers, even when nobody has opened the input device. This also
@@ -443,16 +478,12 @@ static int hammer_probe(struct hid_device *hdev,
* the device.
*/
if (hdev->product == USB_DEVICE_ID_GOOGLE_WHISKERS &&
- hammer_is_keyboard_interface(hdev))
+ hammer_is_keyboard_interface(hdev)) {
hdev->quirks |= HID_QUIRK_ALWAYS_POLL;
-
- error = hid_parse(hdev);
- if (error)
- return error;
-
- error = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
- if (error)
- return error;
+ error = hid_hw_open(hdev);
+ if (error)
+ return error;
+ }
if (hammer_has_backlight_control(hdev)) {
error = hammer_register_leds(hdev);
@@ -465,6 +496,15 @@ static int hammer_probe(struct hid_device *hdev,
return 0;
}
+static void hammer_remove(struct hid_device *hdev)
+{
+ if (hdev->product ==
[PATCH 3/3] HID: google: whiskers: signal tablet mode on connect
When we receive "keyboard position" event from Whiskers we can
conclude that the base is attached, even if we did not get EC event
for that. We may miss EC event because there are some units which
have a lot of leakage on the ADC pins that the EC uses to determine
whether or not a base is attached.
Signed-off-by: Dmitry Torokhov
---
drivers/hid/hid-google-hammer.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 3dc6116c8f76..31e4a39946f5 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -402,16 +402,16 @@ static int hammer_event(struct hid_device *hid, struct
hid_field *field,
usage->hid == WHISKERS_KBD_FOLDED) {
spin_lock_irqsave(_ec_lock, flags);
+ /*
+* If we are getting events from Whiskers that means that it
+* is attached to the lid.
+*/
+ cbas_ec.base_present = true;
cbas_ec.base_folded = value;
hid_dbg(hid, "%s: base: %d, folded: %d\n", __func__,
cbas_ec.base_present, cbas_ec.base_folded);
- /*
-* We should not get event if base is detached, but in case
-* we happen to service HID and EC notifications out of order
-* let's still check the "base present" flag.
-*/
- if (cbas_ec.input && cbas_ec.base_present) {
+ if (cbas_ec.input) {
input_report_switch(cbas_ec.input,
SW_TABLET_MODE, value);
input_sync(cbas_ec.input);
--
2.23.0.237.gc6a4ce50a0-goog
[PATCH 2/3] HID: google: whiskers: signal tablet mode switch on disconnect
Currently, the tablet mode switch that takes two signals as its input:
base attached switch from the EC and some GMR signal from whiskers when
it's folded over. This tablet mode switch is then sent to Chrome, which
changes the UI.
However, there are some units which have a lot of leakage on the ADC
pins that the EC uses to determine whether or not a base is attached.
This can result in the base being physically detached, but the EC
thinking that it's still attached. The user would then be stuck in
laptop mode and wouldn't be able to rotate their display.
To work around this let's send "tablet mode" signal when we remove HID
interface, which normally happens when we physically disconnect
whiskers.
Signed-off-by: Dmitry Torokhov
---
drivers/hid/hid-google-hammer.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 4f64f93ddfcb..3dc6116c8f76 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -498,11 +498,33 @@ static int hammer_probe(struct hid_device *hdev,
static void hammer_remove(struct hid_device *hdev)
{
+ unsigned long flags;
+
if (hdev->product == USB_DEVICE_ID_GOOGLE_WHISKERS &&
- hammer_is_keyboard_interface(hdev))
+ hammer_is_keyboard_interface(hdev)) {
hid_hw_close(hdev);
+ /*
+* If we are disconnecting then most likely Whiskers is
+* being removed. Even if it is not removed, without proper
+* keyboard we should not stay in clamshell mode.
+*
+* The reason for doing it here and not waiting for signal
+* from EC, is that on some devices there are high leakage
+* on Whiskers pins and we do not detect disconnect reliably,
+* resulting in devices being stuck in clamshell mode.
+*/
+ spin_lock_irqsave(_ec_lock, flags);
+ if (cbas_ec.input && cbas_ec.base_present) {
+ input_report_switch(cbas_ec.input, SW_TABLET_MODE, 1);
+ input_sync(cbas_ec.input);
+ }
+ cbas_ec.base_present = false;
+ spin_unlock_irqrestore(_ec_lock, flags);
+ }
+
hammer_unregister_leds(hdev);
+
hid_hw_stop(hdev);
}
--
2.23.0.237.gc6a4ce50a0-goog
Re: [PATCH] bus: qcom: fix spelling mistake "ambigous" -> "ambiguous"
On Wed, 11 Sep 2019 16:39:47 +0100, Colin King wrote: > From: Colin Ian King > > There is a spelling mistake on the documentation. Fix it. > > Signed-off-by: Colin Ian King > --- > Documentation/devicetree/bindings/bus/qcom,ebi2.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied, thanks. Rob
[PATCH RFC v2 12/14] arm64: dts: qcom: add PDC interrupt controller for SDM845
Add PDC interrupt controller device bindings for SDM845.
Signed-off-by: Lina Iyer
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index be0022e..41455b8 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2375,6 +2375,16 @@
#power-domain-cells = <1>;
};
+ pdc_intc: interrupt-controller@b22 {
+ compatible = "qcom,sdm845-pdc";
+ reg = <0 0x0b22 0 0x3>, <0 0x179900f0 0 0x60>;
+ qcom,pdc-ranges = <0 480 94>, <94 609 15>, <115 630 7>;
+ #interrupt-cells = <2>;
+ interrupt-parent = <>;
+ interrupt-controller;
+ qcom,scm-spi-cfg;
+ };
+
pdc_reset: reset-controller@b2e {
compatible = "qcom,sdm845-pdc-global";
reg = <0 0x0b2e 0 0x2>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH RFC v2 05/14] of: irq: document properties for wakeup interrupt parent
Some interrupt controllers in a SoC, are always powered on and have a select interrupts routed to them, so that they can wakeup the SoC from suspend. Add wakeup-parent DT property to refer to these interrupt controllers. Cc: devicet...@vger.kernel.org Signed-off-by: Lina Iyer Reviewed-by: Rob Herring --- .../devicetree/bindings/interrupt-controller/interrupts.txt | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt index 8a3c408..c10e310 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt @@ -108,3 +108,16 @@ commonly used: sensitivity = <7>; }; }; + +3) Interrupt wakeup parent +-- + +Some interrupt controllers in a SoC, are always powered on and have a select +interrupts routed to them, so that they can wakeup the SoC from suspend. These +interrupt controllers do not fall into the category of a parent interrupt +controller and can be specified by the "wakeup-parent" property and contain a +single phandle referring to the wakeup capable interrupt controller. + + Example: + wakeup-parent = <_intc>; + -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH RFC v2 04/14] drivers: irqchip: add PDC irqdomain for wakeup capable GPIOs
Introduce a new domain for wakeup capable GPIOs. The domain can be
requested using the bus token DOMAIN_BUS_WAKEUP. In the following
patches, we will specify PDC as the wakeup-parent for the TLMM GPIO
irqchip. Requesting a wakeup GPIO will setup the GPIO and the
corresponding PDC interrupt as its parent.
Co-developed-by: Stephen Boyd
Signed-off-by: Stephen Boyd
Signed-off-by: Lina Iyer
---
Changes in RFC v2:
- Move irq_domain_qcom_handle_wakeup to the patch where it is
used
- Replace #define definitons
- Add Signed-off-by and other minor changes
---
drivers/irqchip/qcom-pdc.c | 104 +++
include/linux/soc/qcom/irq.h | 19
2 files changed, 114 insertions(+), 9 deletions(-)
create mode 100644 include/linux/soc/qcom/irq.h
diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index 5eef5ea..4abd775 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -13,12 +13,13 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
#define PDC_MAX_IRQS 168
+#define PDC_MAX_GPIO_IRQS 256
#define CLEAR_INTR(reg, intr) (reg & ~(1 << intr))
#define ENABLE_INTR(reg, intr) (reg | (1 << intr))
@@ -26,6 +27,8 @@
#define IRQ_ENABLE_BANK0x10
#define IRQ_i_CFG 0x110
+#define PDC_NO_PARENT_IRQ ~0UL
+
struct pdc_pin_region {
u32 pin_base;
u32 parent_base;
@@ -65,23 +68,35 @@ static void pdc_enable_intr(struct irq_data *d, bool on)
static void qcom_pdc_gic_disable(struct irq_data *d)
{
+ if (d->hwirq == GPIO_NO_WAKE_IRQ)
+ return;
+
pdc_enable_intr(d, false);
irq_chip_disable_parent(d);
}
static void qcom_pdc_gic_enable(struct irq_data *d)
{
+ if (d->hwirq == GPIO_NO_WAKE_IRQ)
+ return;
+
pdc_enable_intr(d, true);
irq_chip_enable_parent(d);
}
static void qcom_pdc_gic_mask(struct irq_data *d)
{
+ if (d->hwirq == GPIO_NO_WAKE_IRQ)
+ return;
+
irq_chip_mask_parent(d);
}
static void qcom_pdc_gic_unmask(struct irq_data *d)
{
+ if (d->hwirq == GPIO_NO_WAKE_IRQ)
+ return;
+
irq_chip_unmask_parent(d);
}
@@ -124,6 +139,9 @@ static int qcom_pdc_gic_set_type(struct irq_data *d,
unsigned int type)
int pin_out = d->hwirq;
enum pdc_irq_config_bits pdc_type;
+ if (pin_out == GPIO_NO_WAKE_IRQ)
+ return 0;
+
switch (type) {
case IRQ_TYPE_EDGE_RISING:
pdc_type = PDC_EDGE_RISING;
@@ -181,8 +199,7 @@ static irq_hw_number_t get_parent_hwirq(int pin)
return (region->parent_base + pin - region->pin_base);
}
- WARN_ON(1);
- return ~0UL;
+ return PDC_NO_PARENT_IRQ;
}
static int qcom_pdc_translate(struct irq_domain *d, struct irq_fwspec *fwspec,
@@ -211,17 +228,17 @@ static int qcom_pdc_alloc(struct irq_domain *domain,
unsigned int virq,
ret = qcom_pdc_translate(domain, fwspec, , );
if (ret)
- return -EINVAL;
-
- parent_hwirq = get_parent_hwirq(hwirq);
- if (parent_hwirq == ~0UL)
- return -EINVAL;
+ return ret;
ret = irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
_pdc_gic_chip, NULL);
if (ret)
return ret;
+ parent_hwirq = get_parent_hwirq(hwirq);
+ if (parent_hwirq == PDC_NO_PARENT_IRQ)
+ return 0;
+
if (type & IRQ_TYPE_EDGE_BOTH)
type = IRQ_TYPE_EDGE_RISING;
@@ -244,6 +261,60 @@ static const struct irq_domain_ops qcom_pdc_ops = {
.free = irq_domain_free_irqs_common,
};
+static int qcom_pdc_gpio_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *data)
+{
+ struct irq_fwspec *fwspec = data;
+ struct irq_fwspec parent_fwspec;
+ irq_hw_number_t hwirq, parent_hwirq;
+ unsigned int type;
+ int ret;
+
+ ret = qcom_pdc_translate(domain, fwspec, , );
+ if (ret)
+ return ret;
+
+ ret = irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
+ _pdc_gic_chip, NULL);
+ if (ret)
+ return ret;
+
+ if (hwirq == GPIO_NO_WAKE_IRQ)
+ return 0;
+
+ parent_hwirq = get_parent_hwirq(hwirq);
+ if (parent_hwirq == PDC_NO_PARENT_IRQ)
+ return 0;
+
+ if (type & IRQ_TYPE_EDGE_BOTH)
+ type = IRQ_TYPE_EDGE_RISING;
+
+ if (type & IRQ_TYPE_LEVEL_MASK)
+ type = IRQ_TYPE_LEVEL_HIGH;
+
+ parent_fwspec.fwnode = domain->parent->fwnode;
+ parent_fwspec.param_count = 3;
+ parent_fwspec.param[0]= 0;
+ parent_fwspec.param[1]= parent_hwirq;
+
[PATCH RFC v2 09/14] drivers: irqchip: pdc: Add irqchip set/get state calls
From: Maulik Shah
Add irqchip calls to set/get interrupt state from the parent interrupt
controller. When GPIOs are renabled as interrupt lines, it is desirable
to clear the interrupt state at the GIC. This avoids any unwanted
interrupt as a result of stale pending state recorded when the line was
used as a GPIO.
Signed-off-by: Maulik Shah
[updated commit text]
Signed-off-by: Lina Iyer
---
drivers/irqchip/qcom-pdc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index affb0bfa..2b49e70 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -87,6 +88,24 @@ static void qcom_pdc_gic_disable(struct irq_data *d)
irq_chip_disable_parent(d);
}
+static int qcom_pdc_gic_get_irqchip_state(struct irq_data *d,
+ enum irqchip_irq_state which, bool *state)
+{
+ if (d->hwirq == GPIO_NO_WAKE_IRQ)
+ return 0;
+
+ return irq_chip_get_parent_state(d, which, state);
+}
+
+static int qcom_pdc_gic_set_irqchip_state(struct irq_data *d,
+ enum irqchip_irq_state which, bool value)
+{
+ if (d->hwirq == GPIO_NO_WAKE_IRQ)
+ return 0;
+
+ return irq_chip_set_parent_state(d, which, value);
+}
+
static void qcom_pdc_gic_enable(struct irq_data *d)
{
if (d->hwirq == GPIO_NO_WAKE_IRQ)
@@ -248,6 +267,8 @@ static struct irq_chip qcom_pdc_gic_chip = {
.irq_unmask = qcom_pdc_gic_unmask,
.irq_disable= qcom_pdc_gic_disable,
.irq_enable = qcom_pdc_gic_enable,
+ .irq_get_irqchip_state = qcom_pdc_gic_get_irqchip_state,
+ .irq_set_irqchip_state = qcom_pdc_gic_set_irqchip_state,
.irq_retrigger = irq_chip_retrigger_hierarchy,
.irq_set_type = qcom_pdc_gic_set_type,
.flags = IRQCHIP_MASK_ON_SUSPEND |
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH RFC v2 14/14] arm64: defconfig: enable PDC interrupt controller for Qualcomm SDM845
Enable PDC interrupt controller for SDM845 devices. The interrupt controller can detect wakeup capable interrupts when the SoC is in a low power state. Signed-off-by: Lina Iyer --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 0e58ef0..310b604 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -729,6 +729,7 @@ CONFIG_ARCH_R8A77970=y CONFIG_ARCH_R8A77980=y CONFIG_ARCH_R8A77990=y CONFIG_ARCH_R8A77995=y +CONFIG_QCOM_PDC=y CONFIG_ROCKCHIP_PM_DOMAINS=y CONFIG_ARCH_TEGRA_132_SOC=y CONFIG_ARCH_TEGRA_210_SOC=y -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH RFC v2 13/14] arm64: dts: qcom: setup PDC as the wakeup parent for TLMM on SDM845
PDC always-on interrupt controller can detect certain GPIOs even when
the TLMM interrupt controller is powered off. Link the PDC as TLMM's
wakeup parent.
Signed-off-by: Lina Iyer
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 41455b8..1b70254 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1358,6 +1358,7 @@
interrupt-controller;
#interrupt-cells = <2>;
gpio-ranges = < 0 0 150>;
+ wakeup-parent = <_intc>;
qspi_clk: qspi-clk {
pinmux {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH RFC v2 10/14] drivers: pinctrl: msm: setup GPIO chip in hierarchy
Some GPIOs are marked as wakeup capable and are routed to another
interrupt controller that is an always-domain and can detect interrupts
even most of the SoC is powered off. The wakeup interrupt controller
wakes up the GIC and replays the interrupt at the GIC.
Setup the TLMM irqchip in hierarchy with the wakeup interrupt controller
and ensure the wakeup GPIOs are handled correctly.
Signed-off-by: Maulik Shah
Signed-off-by: Lina Iyer
Changes in RFC v2:
- Define irq_domain_qcom_handle_wakeup()
- Rebase on top of GPIO hierarchy support in linux-next
- Set the chained irq handler for summary line
---
drivers/pinctrl/qcom/pinctrl-msm.c | 119 +
drivers/pinctrl/qcom/pinctrl-msm.h | 16 +
include/linux/soc/qcom/irq.h | 13
3 files changed, 148 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index f355ddd..c5ba389 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -23,6 +23,8 @@
#include
#include
+#include
+
#include "../core.h"
#include "../pinconf.h"
#include "pinctrl-msm.h"
@@ -44,6 +46,7 @@
* @enabled_irqs: Bitmap of currently enabled irqs.
* @dual_edge_irqs: Bitmap of irqs that need sw emulated dual edge
* detection.
+ * @skip_wake_irqs: Skip IRQs that are handled by wakeup interrupt contrroller
* @soc;Reference to soc_data of platform specific data.
* @regs: Base addresses for the TLMM tiles.
*/
@@ -61,6 +64,7 @@ struct msm_pinctrl {
DECLARE_BITMAP(dual_edge_irqs, MAX_NR_GPIO);
DECLARE_BITMAP(enabled_irqs, MAX_NR_GPIO);
+ DECLARE_BITMAP(skip_wake_irqs, MAX_NR_GPIO);
const struct msm_pinctrl_soc_data *soc;
void __iomem *regs[MAX_NR_TILES];
@@ -709,6 +713,12 @@ static void msm_gpio_irq_mask(struct irq_data *d)
unsigned long flags;
u32 val;
+ if (d->parent_data)
+ irq_chip_mask_parent(d);
+
+ if (test_bit(d->hwirq, pctrl->skip_wake_irqs))
+ return;
+
g = >soc->groups[d->hwirq];
raw_spin_lock_irqsave(>lock, flags);
@@ -753,6 +763,12 @@ static void msm_gpio_irq_clear_unmask(struct irq_data *d,
bool status_clear)
unsigned long flags;
u32 val;
+ if (d->parent_data)
+ irq_chip_unmask_parent(d);
+
+ if (test_bit(d->hwirq, pctrl->skip_wake_irqs))
+ return;
+
g = >soc->groups[d->hwirq];
raw_spin_lock_irqsave(>lock, flags);
@@ -780,10 +796,37 @@ static void msm_gpio_irq_clear_unmask(struct irq_data *d,
bool status_clear)
static void msm_gpio_irq_enable(struct irq_data *d)
{
+ /*
+* Clear the interrupt that may be pending before we enable
+* the line.
+* This is especially a problem with the GPIOs routed to the
+* PDC. These GPIOs are direct-connect interrupts to the GIC.
+* Disabling the interrupt line at the PDC does not prevent
+* the interrupt from being latched at the GIC. The state at
+* GIC needs to be cleared before enabling.
+*/
+ if (d->parent_data) {
+ irq_chip_set_parent_state(d, IRQCHIP_STATE_PENDING, 0);
+ irq_chip_enable_parent(d);
+ }
msm_gpio_irq_clear_unmask(d, true);
}
+static void msm_gpio_irq_disable(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
+
+ if (d->parent_data)
+ irq_chip_disable_parent(d);
+
+ if (test_bit(d->hwirq, pctrl->skip_wake_irqs))
+ return;
+
+ msm_gpio_irq_mask(d);
+}
+
static void msm_gpio_irq_unmask(struct irq_data *d)
{
msm_gpio_irq_clear_unmask(d, false);
@@ -797,6 +840,9 @@ static void msm_gpio_irq_ack(struct irq_data *d)
unsigned long flags;
u32 val;
+ if (test_bit(d->hwirq, pctrl->skip_wake_irqs))
+ return;
+
g = >soc->groups[d->hwirq];
raw_spin_lock_irqsave(>lock, flags);
@@ -822,6 +868,12 @@ static int msm_gpio_irq_set_type(struct irq_data *d,
unsigned int type)
unsigned long flags;
u32 val;
+ if (d->parent_data)
+ irq_chip_set_type_parent(d, type);
+
+ if (test_bit(d->hwirq, pctrl->skip_wake_irqs))
+ return 0;
+
g = >soc->groups[d->hwirq];
raw_spin_lock_irqsave(>lock, flags);
@@ -914,6 +966,15 @@ static int msm_gpio_irq_set_wake(struct irq_data *d,
unsigned int on)
struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
unsigned long flags;
+ if (d->parent_data)
+ irq_chip_set_wake_parent(d, on);
+
+ /*
+* While they may not wake up when the TLMM is powered off,
+* some GPIOs would like to wakeup the system from suspend
+* when TLMM is powered on. To allow that, enable
[PATCH RFC v2 08/14] genirq: Introduce irq_chip_get/set_parent_state calls
From: Maulik Shah
On certain QTI chipsets some GPIOs are direct-connect interrupts to the
GIC to be used as regular interrupt lines. When the GPIOs are not used
for interrupt generation the interrupt line is disabled. But disabling
the interrupt at GIC does not prevent the interrupt to be reported as
pending at GIC_ISPEND. Later, when drivers call enable_irq() on the
interrupt, an unwanted interrupt occurs.
Introduce get and set methods for irqchip's parent to clear it's pending
irq state. This then can be invoked by the GPIO interrupt controller on
the parents in it hierarchy to clear the interrupt before enabling the
interrupt.
Signed-off-by: Maulik Shah
[updated commit text and minor code fixes]
Signed-off-by: Lina Iyer
---
Changes in RFC v2 -
- Rephrase commit text
- Address code review comments
---
include/linux/irq.h | 6 ++
kernel/irq/chip.c | 44
2 files changed, 50 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index fb301cf..7853eb9 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -610,6 +610,12 @@ extern int irq_chip_pm_put(struct irq_data *data);
#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
extern void handle_fasteoi_ack_irq(struct irq_desc *desc);
extern void handle_fasteoi_mask_irq(struct irq_desc *desc);
+extern int irq_chip_set_parent_state(struct irq_data *data,
+enum irqchip_irq_state which,
+bool val);
+extern int irq_chip_get_parent_state(struct irq_data *data,
+enum irqchip_irq_state which,
+bool *state);
extern void irq_chip_enable_parent(struct irq_data *data);
extern void irq_chip_disable_parent(struct irq_data *data);
extern void irq_chip_ack_parent(struct irq_data *data);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index b76703b..b3fa2d8 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1298,6 +1298,50 @@ EXPORT_SYMBOL_GPL(handle_fasteoi_mask_irq);
#endif /* CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS */
/**
+ * irq_chip_set_parent_state - set the state of a parent interrupt.
+ *
+ * @data: Pointer to interrupt specific data
+ * @which: State to be restored (one of IRQCHIP_STATE_*)
+ * @val: Value corresponding to @which
+ *
+ * Conditional success, if the underlying irqchip does not implement it.
+ */
+int irq_chip_set_parent_state(struct irq_data *data,
+ enum irqchip_irq_state which,
+ bool val)
+{
+ data = data->parent_data;
+
+ if (!data || !data->chip->irq_set_irqchip_state)
+ return 0;
+
+ return data->chip->irq_set_irqchip_state(data, which, val);
+}
+EXPORT_SYMBOL_GPL(irq_chip_set_parent_state);
+
+/**
+ * irq_chip_get_parent_state - get the state of a parent interrupt.
+ *
+ * @data: Pointer to interrupt specific data
+ * @which: one of IRQCHIP_STATE_* the caller wants to know
+ * @state: a pointer to a boolean where the state is to be stored
+ *
+ * Conditional success, if the underlying irqchip does not implement it.
+ */
+int irq_chip_get_parent_state(struct irq_data *data,
+ enum irqchip_irq_state which,
+ bool *state)
+{
+ data = data->parent_data;
+
+ if (!data || !data->chip->irq_get_irqchip_state)
+ return 0;
+
+ return data->chip->irq_get_irqchip_state(data, which, state);
+}
+EXPORT_SYMBOL_GPL(irq_chip_get_parent_state);
+
+/**
* irq_chip_enable_parent - Enable the parent interrupt (defaults to unmask if
* NULL)
* @data: Pointer to interrupt specific data
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH RFC v2 11/14] drivers: pinctrl: sdm845: add PDC wakeup interrupt map for GPIOs
Add interrupt parents for wakeup capable GPIOs for Qualcomm SDM845 SoC.
Signed-off-by: Lina Iyer
---
Changes in RFC v2:
- Rearranged GPIO wakeup parent map
---
drivers/pinctrl/qcom/pinctrl-sdm845.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index 39f498c..9cff3a4 100644
--- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
+++ b/drivers/pinctrl/qcom/pinctrl-sdm845.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2016-2019, The Linux Foundation. All rights reserved.
*/
#include
@@ -1282,6 +1282,24 @@ static const int sdm845_acpi_reserved_gpios[] = {
0, 1, 2, 3, 81, 82, 83, 84, -1
};
+static const struct msm_gpio_wakeirq_map sdm845_pdc_map[] = {
+ { 1, 30 }, { 3, 31 }, { 5, 32 }, { 10, 33 }, { 11, 34 },
+ { 20, 35 }, { 22, 36 }, { 24, 37 }, { 26, 38 }, { 30, 39 },
+ { 31, 117 }, { 32, 41 }, { 34, 42 }, { 36, 43 }, { 37, 44 },
+ { 38, 45 }, { 39, 46 }, { 40, 47 }, { 41, 115 }, { 43, 49 },
+ { 44, 50 }, { 46, 51 }, { 48, 52 }, { 49, 118 }, { 52, 54 },
+ { 53, 55 }, { 54, 56 }, { 56, 57 }, { 57, 58 }, { 58, 59 },
+ { 59, 60 }, { 60, 61 }, { 61, 62 }, { 62, 63 }, { 63, 64 },
+ { 64, 65 }, { 66, 66 }, { 68, 67 }, { 71, 68 }, { 73, 69 },
+ { 77, 70 }, { 78, 71 }, { 79, 72 }, { 80, 73 }, { 84, 74 },
+ { 85, 75 }, { 86, 76 }, { 88, 77 }, { 89, 116 }, { 91, 79 },
+ { 92, 80 }, { 95, 81 }, { 96, 82 }, { 97, 83 }, { 101, 84 },
+ { 103, 85 }, { 104, 86 }, { 115, 90 }, { 116, 91 }, { 117, 92 },
+ { 118, 93 }, { 119, 94 }, { 120, 95 }, { 121, 96 }, { 122, 97 },
+ { 123, 98 }, { 124, 99 }, { 125, 100 }, { 127, 102 }, { 128, 103 },
+ { 129, 104 }, { 130, 105 }, { 132, 106 }, { 133, 107 }, { 145, 108 },
+};
+
static const struct msm_pinctrl_soc_data sdm845_pinctrl = {
.pins = sdm845_pins,
.npins = ARRAY_SIZE(sdm845_pins),
@@ -1290,6 +1308,9 @@ static const struct msm_pinctrl_soc_data sdm845_pinctrl =
{
.groups = sdm845_groups,
.ngroups = ARRAY_SIZE(sdm845_groups),
.ngpios = 151,
+ .wakeirq_map = sdm845_pdc_map,
+ .nwakeirq_map = ARRAY_SIZE(sdm845_pdc_map),
+
};
static const struct msm_pinctrl_soc_data sdm845_acpi_pinctrl = {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH RFC v2 07/14] drivers: irqchip: pdc: additionally set type in SPI config registers
GPIOs that can be configured as wakeup are routed to the PDC wakeup
interrupt controller and from there to the GIC interrupt controller. On
some QCOM SoCs, the interface to the GIC for wakeup capable GPIOs have
additional hardware registers that need to be configured as well to
match the trigger type of the GPIO. This register interfaces the PDC to
the GIC and therefore updated from the PDC driver.
Typically, the firmware intializes the interface registers for the
wakeup capable GPIOs with commonly used GPIO trigger type, but it is
possible that a platform may want to use the GPIO differently. So, in
addition to configuring the PDC, configure the interface registers as
well.
Signed-off-by: Lina Iyer
---
drivers/irqchip/qcom-pdc.c | 93 ++
1 file changed, 93 insertions(+)
diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index 4abd775..affb0bfa 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+
#define PDC_MAX_IRQS 168
#define PDC_MAX_GPIO_IRQS 256
@@ -35,10 +37,20 @@ struct pdc_pin_region {
u32 cnt;
};
+struct spi_cfg_regs {
+ union {
+ u64 start;
+ void __iomem *base;
+ };
+ resource_size_t size;
+ bool scm_io;
+};
+
static DEFINE_RAW_SPINLOCK(pdc_lock);
static void __iomem *pdc_base;
static struct pdc_pin_region *pdc_region;
static int pdc_region_cnt;
+static struct spi_cfg_regs *spi_cfg;
static void pdc_reg_write(int reg, u32 i, u32 val)
{
@@ -100,6 +112,57 @@ static void qcom_pdc_gic_unmask(struct irq_data *d)
irq_chip_unmask_parent(d);
}
+static u32 __spi_pin_read(unsigned int pin)
+{
+ void __iomem *cfg_reg = spi_cfg->base + pin * 4;
+ u64 scm_cfg_reg = spi_cfg->start + pin * 4;
+
+ if (spi_cfg->scm_io) {
+ unsigned int val;
+
+ qcom_scm_io_readl(scm_cfg_reg, );
+ return val;
+ } else {
+ return readl(cfg_reg);
+ }
+}
+
+static void __spi_pin_write(unsigned int pin, unsigned int val)
+{
+ void __iomem *cfg_reg = spi_cfg->base + pin * 4;
+ u64 scm_cfg_reg = spi_cfg->start + pin * 4;
+
+ if (spi_cfg->scm_io)
+ qcom_scm_io_writel(scm_cfg_reg, val);
+ else
+ writel(val, cfg_reg);
+}
+
+static int spi_configure_type(irq_hw_number_t hwirq, unsigned int type)
+{
+ int spi = hwirq - 32;
+ u32 pin = spi / 32;
+ u32 mask = BIT(spi % 32);
+ u32 val;
+ unsigned long flags;
+
+ if (!spi_cfg)
+ return 0;
+
+ if (pin * 4 > spi_cfg->size)
+ return -EFAULT;
+
+ raw_spin_lock_irqsave(_lock, flags);
+ val = __spi_pin_read(pin);
+ val &= ~mask;
+ if (type & IRQ_TYPE_LEVEL_MASK)
+ val |= mask;
+ __spi_pin_write(pin, val);
+ raw_spin_unlock_irqrestore(_lock, flags);
+
+ return 0;
+}
+
/*
* GIC does not handle falling edge or active low. To allow falling edge and
* active low interrupts to be handled at GIC, PDC has an inverter that inverts
@@ -137,7 +200,9 @@ enum pdc_irq_config_bits {
static int qcom_pdc_gic_set_type(struct irq_data *d, unsigned int type)
{
int pin_out = d->hwirq;
+ int parent_hwirq = d->parent_data->hwirq;
enum pdc_irq_config_bits pdc_type;
+ int ret;
if (pin_out == GPIO_NO_WAKE_IRQ)
return 0;
@@ -168,6 +233,11 @@ static int qcom_pdc_gic_set_type(struct irq_data *d,
unsigned int type)
pdc_reg_write(IRQ_i_CFG, pin_out, pdc_type);
+ /* Additionally, configure (only) the GPIO in the f/w */
+ ret = spi_configure_type(parent_hwirq, type);
+ if (ret)
+ return ret;
+
return irq_chip_set_type_parent(d, type);
}
@@ -354,6 +424,7 @@ static int pdc_setup_pin_mapping(struct device_node *np)
static int qcom_pdc_init(struct device_node *node, struct device_node *parent)
{
struct irq_domain *parent_domain, *pdc_domain, *pdc_gpio_domain;
+ struct resource res;
int ret;
pdc_base = of_iomap(node, 0);
@@ -384,6 +455,27 @@ static int qcom_pdc_init(struct device_node *node, struct
device_node *parent)
goto fail;
}
+ ret = of_address_to_resource(node, 1, );
+ if (!ret) {
+ spi_cfg = kcalloc(1, sizeof(*spi_cfg), GFP_KERNEL);
+ if (!spi_cfg) {
+ ret = -ENOMEM;
+ goto remove;
+ }
+ spi_cfg->scm_io = of_find_property(node,
+ "qcom,scm-spi-cfg", NULL);
+ spi_cfg->size = resource_size();
+ if (spi_cfg->scm_io) {
+ spi_cfg->start = res.start;
+ } else {
+ spi_cfg->base = ioremap(res.start, spi_cfg->size);
+
[PATCH RFC v2 02/14] drivers: irqchip: qcom-pdc: update max PDC interrupts
Newer SoCs have increased the number of interrupts routed to the PDC interrupt controller. Update the definition of max PDC interrupts. Signed-off-by: Lina Iyer --- drivers/irqchip/qcom-pdc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c index faa7d61..b230794 100644 --- a/drivers/irqchip/qcom-pdc.c +++ b/drivers/irqchip/qcom-pdc.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. + * Copyright (c) 2017-2019, The Linux Foundation. All rights reserved. */ #include @@ -18,7 +18,7 @@ #include #include -#define PDC_MAX_IRQS 126 +#define PDC_MAX_IRQS 168 #define CLEAR_INTR(reg, intr) (reg & ~(1 << intr)) #define ENABLE_INTR(reg, intr) (reg | (1 << intr)) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH RFC v2 00/14] Support wakeup capable GPIOs
Thanks for all the helpful reviews. Here is the next revision addressing the comments. Changes in RFC v2: - Address review comments #3, #4, #6, #7, #8, #9, #10 - Rebased on top of linux-next GPIO latest patches [1],[3],[4] - Increase PDC max irqs in #2 (avoid merge conflicts with downstream) - Add Reviewed-by #5 Note: This revision does not update writing the config registers that are written from the PDC. There needs more discussion in that area. #6, #7 --- This series is another attempt on adding wakeup capable GPIOs for QCOM SoC. This patchset is based on Linus's support for hierarchical GPIOs merged into linux-next [1]. The essense of the idea remains the same as the previous submission [2]. GPIO irqchip TLMM is setup in hierarchy wit the PDC as the wakeup-parent. PDC's interrupt parent is the GIC. GPIOs in QCOM SoC that are wakeup capable (when TLMM is powered off) are routed to the PDC as well and can be detected at the always-on interrupt controller (PDC). The idea is setup the irqchips in hierarchy and if the interrupt is handled at the PDC, then TLMM relinquishes control and configuration of the interrupt to the PDC. There are few new additions in this submission. The first is the additional SPI configuration that needs to be done to setup the GPIO type in a register interface between the PDC and the GIC. This is needed only for GPIOs. This registers in some QCOM SoCs is access restricted and has to be written from the TZ. The DT bindings are also updated for this new requirement. The second change is that with the new hierarchical support in gpiolib, we could remove the .alloc and .translate functions from the pinctrl driver. But to distinguish the case where a wakeup interrupt controller needs the TLMM to configure the GPIO interrupts (in the case of MPM interrupt controller), irqdomain flags have been added. The third change is ensure the interrupt controllers' interrupt pending bits are cleared when the GPIO is enabled as an interrupt. Please consider reviewing these patches. Thanks, Lina [1]. https://lore.kernel.org/linux-gpio/20190808123242.5359-1-linus.wall...@linaro.org/ [2]. https://lkml.org/lkml/2019/5/7/1173 [3]. https://lore.kernel.org/r/20190819084904.30027-1-linus.wall...@linaro.org [4]. https://lore.kernel.org/r/20190724083828.7496-1-linus.wall...@linaro.org Lina Iyer (12): irqdomain: add bus token DOMAIN_BUS_WAKEUP drivers: irqchip: qcom-pdc: update max PDC interrupts drivers: irqchip: pdc: Do not toggle IRQ_ENABLE during mask/unmask drivers: irqchip: add PDC irqdomain for wakeup capable GPIOs of: irq: document properties for wakeup interrupt parent dt-bindings/interrupt-controller: pdc: add SPI config register drivers: irqchip: pdc: additionally set type in SPI config registers drivers: pinctrl: msm: setup GPIO chip in hierarchy drivers: pinctrl: sdm845: add PDC wakeup interrupt map for GPIOs arm64: dts: qcom: add PDC interrupt controller for SDM845 arm64: dts: qcom: setup PDC as the wakeup parent for TLMM on SDM845 arm64: defconfig: enable PDC interrupt controller for Qualcomm SDM845 Maulik Shah (2): genirq: Introduce irq_chip_get/set_parent_state calls drivers: irqchip: pdc: Add irqchip set/get state calls .../bindings/interrupt-controller/interrupts.txt | 13 ++ .../bindings/interrupt-controller/qcom,pdc.txt | 13 +- arch/arm64/boot/dts/qcom/sdm845.dtsi | 11 + arch/arm64/configs/defconfig | 1 + drivers/irqchip/qcom-pdc.c | 238 +++-- drivers/pinctrl/qcom/pinctrl-msm.c | 119 +++ drivers/pinctrl/qcom/pinctrl-msm.h | 16 ++ drivers/pinctrl/qcom/pinctrl-sdm845.c | 23 +- include/linux/irq.h| 6 + include/linux/irqdomain.h | 1 + include/linux/soc/qcom/irq.h | 32 +++ kernel/irq/chip.c | 44 12 files changed, 502 insertions(+), 15 deletions(-) create mode 100644 include/linux/soc/qcom/irq.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH RFC v2 01/14] irqdomain: add bus token DOMAIN_BUS_WAKEUP
A single controller can handle normal interrupts and wake-up interrupts
independently, with a different numbering space. It is thus crucial to
allow the driver for such a controller discriminate between the two.
A simple way to do so is to tag the wake-up irqdomain with a "bus token"
that indicates the wake-up domain. This slightly abuses the notion of
bus, but also radically simplifies the design of such a driver. Between
two evils, we choose the least damaging.
Suggested-by: Stephen Boyd
Signed-off-by: Lina Iyer
---
include/linux/irqdomain.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 07ec8b3..cc846ab 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -83,6 +83,7 @@ enum irq_domain_bus_token {
DOMAIN_BUS_IPI,
DOMAIN_BUS_FSL_MC_MSI,
DOMAIN_BUS_TI_SCI_INTA_MSI,
+ DOMAIN_BUS_WAKEUP,
};
/**
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH RFC v2 03/14] drivers: irqchip: pdc: Do not toggle IRQ_ENABLE during mask/unmask
When an interrupt is to be serviced, the convention is to mask the
interrupt at the chip and unmask after servicing the interrupt. Enabling
and disabling the interrupt at the PDC irqchip causes an interrupt storm
due to the way dual edge interrupts are handled in hardware.
Skip configuring the PDC when the IRQ is masked and unmasked, instead
use the irq_enable/irq_disable callbacks to toggle the IRQ_ENABLE
register at the PDC. The PDC's IRQ_ENABLE register is only used during
the monitoring mode when the system is asleep and is not needed for
active mode detection.
Signed-off-by: Lina Iyer
---
drivers/irqchip/qcom-pdc.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index b230794..5eef5ea 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -63,15 +63,25 @@ static void pdc_enable_intr(struct irq_data *d, bool on)
raw_spin_unlock(_lock);
}
-static void qcom_pdc_gic_mask(struct irq_data *d)
+static void qcom_pdc_gic_disable(struct irq_data *d)
{
pdc_enable_intr(d, false);
+ irq_chip_disable_parent(d);
+}
+
+static void qcom_pdc_gic_enable(struct irq_data *d)
+{
+ pdc_enable_intr(d, true);
+ irq_chip_enable_parent(d);
+}
+
+static void qcom_pdc_gic_mask(struct irq_data *d)
+{
irq_chip_mask_parent(d);
}
static void qcom_pdc_gic_unmask(struct irq_data *d)
{
- pdc_enable_intr(d, true);
irq_chip_unmask_parent(d);
}
@@ -148,6 +158,8 @@ static struct irq_chip qcom_pdc_gic_chip = {
.irq_eoi= irq_chip_eoi_parent,
.irq_mask = qcom_pdc_gic_mask,
.irq_unmask = qcom_pdc_gic_unmask,
+ .irq_disable= qcom_pdc_gic_disable,
+ .irq_enable = qcom_pdc_gic_enable,
.irq_retrigger = irq_chip_retrigger_hierarchy,
.irq_set_type = qcom_pdc_gic_set_type,
.flags = IRQCHIP_MASK_ON_SUSPEND |
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH RFC v2 06/14] dt-bindings/interrupt-controller: pdc: add SPI config register
In addition to configuring the PDC, additional registers that interface
the GIC have to be configured to match the GPIO type. The registers on
some QCOM SoCs are access restricted, while on other SoCs are not. They
SoCs with access restriction to these SPI registers need to be written
from the firmware using the SCM interface. Add a flag to indicate if the
register is to be written using SCM interface.
Cc: devicet...@vger.kernel.org
Signed-off-by: Lina Iyer
---
.../devicetree/bindings/interrupt-controller/qcom,pdc.txt | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
index 8e0797c..e329f8d 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
@@ -24,6 +24,9 @@ Properties:
Usage: required
Value type:
Definition: Specifies the base physical address for PDC hardware.
+ Optionally, specify the PDC's GIC interface registers that
+ need to be configured for wakeup capable GPIOs routed to
+ the PDC.
- interrupt-cells:
Usage: required
@@ -50,15 +53,23 @@ Properties:
The second element is the GIC hwirq number for the PDC port.
The third element is the number of interrupts in sequence.
+- qcom,scm-spi-cfg:
+ Usage: optional
+ Value type:
+ Definition: Specifies if the SPI configuration registers have to be
+ written from the firmware. Sometimes the PDC interface
+ register to the GIC can only be written from the firmware.
+
Example:
pdc: interrupt-controller@b22 {
compatible = "qcom,sdm845-pdc";
- reg = <0xb22 0x3>;
+ reg = <0 0x0b22 0 0x3>, <0 0x179900f0 0 0x60>;
qcom,pdc-ranges = <0 512 94>, <94 641 15>, <115 662 7>;
#interrupt-cells = <2>;
interrupt-parent = <>;
interrupt-controller;
+ qcom,scm-spi-cfg;
};
DT binding of a device that wants to use the GIC SPI 514 as a wakeup
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: linux-next: manual merge of the configfs tree with the vfs-fixes tree
On Thu, Sep 12, 2019 at 03:47:16PM +0200, Christoph Hellwig wrote:
> On Thu, Sep 12, 2019 at 11:44:12PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the configfs tree got a conflict in:
> >
> > fs/configfs/symlink.c
> >
> > between commit:
> >
> > e272d4fb74d6 ("configfs: fix a deadlock in configfs_symlink()")
> >
> > from the vfs-fixes tree and commit:
>
> The configfs one has been rebased. I also have another refactoring
> after this one before the rest of Als patches, so you'll run into
> more issues.
>
> Al, can you drop the branch from your tree?
Done.
Re: [PATCH v1 2/2] of: Let of_for_each_phandle fallback to non-negative cell_count
On Sat, 24 Aug 2019 15:28:46 +0200, =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=
wrote:
> Referencing device tree nodes from a property allows to pass arguments.
> This is for example used for referencing gpios. This looks as follows:
>
> gpio_ctrl: gpio-controller {
> #gpio-cells = <2>
> ...
> }
>
> someothernode {
> gpios = <_ctrl 5 0 _ctrl 3 0>;
> ...
> }
>
> To know the number of arguments this must be either fixed, or the
> referenced node is checked for a $cells_name (here: "#gpio-cells")
> property and with this information the start of the second reference can
> be determined.
>
> Currently regulators are referenced with no additional arguments. To
> allow some optional arguments without having to change all referenced
> nodes this change introduces a way to specify a default cell_count. So
> when a phandle is parsed we check for the $cells_name property and use
> it as before if present. If it is not present we fall back to
> cells_count if non-negative and only fail if cells_count is smaller than
> zero.
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/of/base.c | 25 +
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
Applied both patches, thanks.
Rob
Re: [PATCH] PCI: dwc: fix find_next_bit() usage
On Wed, Sep 4, 2019 at 9:03 AM Niklas Cassel wrote:
>
> find_next_bit() takes a parameter of size long, and performs arithmetic
> that assumes that the argument is of size long.
>
> Therefore we cannot pass a u32, since this will cause find_next_bit()
> to read outside the stack buffer and will produce the following print:
> BUG: KASAN: stack-out-of-bounds in find_next_bit+0x38/0xb0
>
> Fixes: 1b497e6493c4 ("PCI: dwc: Fix uninitialized variable in
> dw_handle_msi_irq()")
> Signed-off-by: Niklas Cassel
Tested-by: Bjorn Andersson
> ---
> drivers/pci/controller/dwc/pcie-designware-host.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index d3156446ff27..45f21640c977 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -78,7 +78,8 @@ static struct msi_domain_info dw_pcie_msi_domain_info = {
> irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
> {
> int i, pos, irq;
> - u32 val, num_ctrls;
> + unsigned long val;
> + u32 status, num_ctrls;
> irqreturn_t ret = IRQ_NONE;
>
> num_ctrls = pp->num_vectors / MAX_MSI_IRQS_PER_CTRL;
> @@ -86,14 +87,14 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
> for (i = 0; i < num_ctrls; i++) {
> dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS +
> (i * MSI_REG_CTRL_BLOCK_SIZE),
> - 4, );
> - if (!val)
> + 4, );
> + if (!status)
> continue;
>
> ret = IRQ_HANDLED;
> + val = status;
> pos = 0;
> - while ((pos = find_next_bit((unsigned long *) ,
> - MAX_MSI_IRQS_PER_CTRL,
> + while ((pos = find_next_bit(, MAX_MSI_IRQS_PER_CTRL,
> pos)) != MAX_MSI_IRQS_PER_CTRL) {
> irq = irq_find_mapping(pp->irq_domain,
>(i * MAX_MSI_IRQS_PER_CTRL) +
> --
> 2.21.0
>
Re: [PATCH] checkpatch: Warn if DT bindings are not in schema format
On Fri, 2019-09-13 at 16:13 -0500, Rob Herring wrote:
> DT bindings are moving to using a json-schema based schema format
> instead of freeform text. Add a checkpatch.pl check to encourage using
> the schema for new bindings. It's not yet a requirement, but is
> progressively being required by some maintainers.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -2822,6 +2822,14 @@ sub process {
>"added, moved or deleted file(s), does MAINTAINERS
> need updating?\n" . $herecurr);
> }
>
> +# Check for adding new DT bindings not in schema format
> + if (!$in_commit_log &&
> + ($line =~ /^new file mode\s*\d+\s*$/) &&
> + ($realfile =~
> m@^Documentation/devicetree/bindings/.*\.txt$@)) {
> + WARN("DT_SCHEMA_BINDING_PATCH",
> + "DT bindings should be in DT schema format. See:
> Documentation/devicetree/writing-schema.rst\n");
> + }
> +
As this already seems to be git dependent, perhaps
it's easier to read with a single line test like:
if ($line =~ m{^\s*create
mode\s*\d+\s*Documentation/devicetree/bindings/.*\.txt$}) {
etc...
}
There are ~3500 existing .txt files:
$ git ls-files -- 'Documentation/devicetree/bindings/*.txt' | wc -l
3476
Are these going to be converted somehow?
What about files like these? (not .txt)
Documentation/devicetree/bindings/timer/st,stih407-lpc
Documentation/devicetree/bindings/nds32/andestech-boards
Documentation/devicetree/bindings/media/nokia,n900-ir
Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
Documentation/devicetree/bindings/arm/cpu-enable-method/nuvoton,npcm750-smp
Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,berlin-smp
Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp
Documentation/devicetree/bindings/arm/arm-boards
Re: [PATCH V2 08/12] dt-bindings: mailbox: qom: Add ipq8074 APPS compatible
On Fri, 13 Sep 2019 17:26:07 +0530, Gokul Sriram Palanisamy wrote: > Add mailbox support required in IPQ8074 SoCs. > > Signed-off-by: Gokul Sriram Palanisamy > Signed-off-by: Sricharan R > --- > Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt | 1 + > 1 file changed, 1 insertion(+) > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed.
Re: [PATCH V2 10/12] dt-bindings: firmware: qcom: Add compatible for IPQ8074 SoC
On Fri, 13 Sep 2019 17:26:09 +0530, Gokul Sriram Palanisamy wrote: > Add compatible for IPQ8074 support. > This does not need clocks for scm calls. > > Signed-off-by: Gokul Sriram Palanisamy > Signed-off-by: Sricharan R > --- > Documentation/devicetree/bindings/firmware/qcom,scm.txt | 1 + > 1 file changed, 1 insertion(+) > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed.
Re: [PATCH V2 06/12] dt-bindings: clock: qcom: Add reset for WCSSAON
On Fri, 13 Sep 2019 17:26:05 +0530, Gokul Sriram Palanisamy wrote: > Add binding for WCSSAON reset required for Q6v5 reset on IPQ8074 SoC. > > Signed-off-by: Gokul Sriram Palanisamy > Signed-off-by: Sricharan R > Signed-off-by: Nikhil Prakash V > --- > include/dt-bindings/clock/qcom,gcc-ipq8074.h | 1 + > 1 file changed, 1 insertion(+) > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed.
Re: [PATCH v5] hid-logitech-hidpp: read battery voltage from newer devices
On 9/9/19 8:00 AM, Filipe Laíns wrote:
On Sat, 2019-08-31 at 13:56 -0400, Pedro Vanzella wrote:
+static int hidpp20_battery_map_status_voltage(u8 data[3], int
*voltage)
+{
+ int status;
+
+ switch (data[2]) {
+ case 0x00: /* discharging */
+ status = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ case 0x10: /* wireless charging */
+ case 0x80: /* charging */
+ status = POWER_SUPPLY_STATUS_CHARGING;
+ break;
+ case 0x81: /* fully charged */
+ status = POWER_SUPPLY_STATUS_FULL;
+ break;
+ default:
+ status = POWER_SUPPLY_STATUS_NOT_CHARGING;
+ }
+
+ *voltage = get_unaligned_be16(data);
+
+ return status;
+}
Here's the missing specification:
++-+
| byte |2
|
++--+++--+--+--+
| bit | 0..2 | 3 | 4 | 5| 6| 7
|
++--+++--+--+--+
| buffer | chargeStatus | fastCharge | slowCharge | critical | (unused) |
extPower |
++--+++--+--+--+
Table 1 - battery voltage (0x1001), getBatteryInfo() (ASE 0), 3rd byte
+---+--+
| value |meaning |
+---+--+
| 0 | Charging |
+---+--+
| 1 | End of charge (100% charged) |
+---+--+
| 2 | Charge stopped (any "normal" reason) |
+---+--+
| 7 | Hardware error |
+---+--+
Table 2 - chargeStatus value
I know this is already on the 5th revision but could you please change
hidpp20_battery_map_status_voltage() to properly handle the 3rd byte?
Also, if you could make sure those values are properly exported via
sysfs it would be great! We will need them for proper upower support.
Sure thing. I'll have a new patch in a few days.
Thanks for figuring that stuff out, by the way.
Sorry for not saying this in my first review. Since then I have done
some testing and I discovered that if we want to get accurate upower
support we will need the values exposed by the 3rd byte to be
exported properly.
I am not sure about the endianness of chargeStatus but you can find
that easily.
Thank you!
Filipe Laíns
Re: [PATCH bpf-next 11/11] samples: bpf: makefile: add sysroot support
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote:
> Basically it only enables that was added by previous couple fixes.
> For sure, just make tools/include to be included after sysroot
> headers.
>
> export ARCH=arm
> export CROSS_COMPILE=arm-linux-gnueabihf-
> make samples/bpf/ SYSROOT="path/to/sysroot"
>
> Sysroot contains correct libs installed and its headers ofc.
> Useful when working with NFC or virtual machine.
>
> Signed-off-by: Ivan Khoronzhuk
> ---
> samples/bpf/Makefile | 5 +
> samples/bpf/README.rst | 10 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 4edc5232cfc1..68ba78d1dbbe 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -177,6 +177,11 @@ ifeq ($(ARCH), arm)
> CLANG_EXTRA_CFLAGS := $(D_OPTIONS)
> endif
>
> +ifdef SYSROOT
> +ccflags-y += --sysroot=${SYSROOT}
> +PROGS_LDFLAGS := -L${SYSROOT}/usr/lib
> +endif
> +
> ccflags-y += -I$(objtree)/usr/include
> ccflags-y += -I$(srctree)/tools/lib/bpf/
> ccflags-y += -I$(srctree)/tools/testing/selftests/bpf/
> diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
> index 5f27e4faca50..786d0ab98e8a 100644
> --- a/samples/bpf/README.rst
> +++ b/samples/bpf/README.rst
> @@ -74,3 +74,13 @@ samples for the cross target.
> export ARCH=arm64
> export CROSS_COMPILE="aarch64-linux-gnu-"
> make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> CLANG=~/git/llvm/build/bin/clang
> +
> +If need to use environment of target board (headers and libs), the SYSROOT
> +also can be set, pointing on FS of target board:
> +
> +export ARCH=arm64
> +export CROSS_COMPILE="aarch64-linux-gnu-"
> +make samples/bpf/ SYSROOT=~/some_sdk/linux-devkit/sysroots/aarch64-linux-gnu
> +
> +Setting LLC and CLANG is not necessarily if it's installed on HOST and have
> +in its targets appropriate arch triple (usually it has several arches).
You have very good description about how to build and test in cover
letter. Could you include those instructions here as well? This will
help keep a record so later people can try/test if needed.
Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
Jens, > Additionally, it would seem saner to standardize rules around when > code is expected to hit the maintainers hands for kernel > releases. Both yours and Martins deals with that, there really > shouldn't be the need to have this specified in detail per sub-system. Yeah. There is basically nothing specific about SCSI in my write-up outside of the branch naming. I deliberately didn't mention coding style preferences. We have so much 20+ year old cruft in SCSI that's impossible to even entertain. But I do request new code to follow coding-style.rst. BYOXT. Also note that the original target audience for my document. It was aimed at onboarding new driver contributors from hardware companies. So people that don't live and breathe Linux development and who are not intimately familiar with the kernel development process. It's possible that we have this information in Documentation/ these days; I'll go look. But it didn't exist when this doc was written. And in my experience nobody coming to Linux development from the outside understands what the "merge window" is. And when the appropriate time is to submit patches and features. I think this would be a great area to have a common set of guidelines and documentation. I'd prefer for this to be global and then let maintainers apply their own wiggle room instead of documenting particular rules for a given subsystem. One pet peeve I have is that people are pretty bad at indicating the intended target tree. I often ask for it in private mail but the practice doesn't seem to stick. I spend a ton of time guessing whether a patch is a fix for a new feature in the x+1 queue or a fix for the current release. It is not always obvious. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH bpf-next 10/11] libbpf: makefile: add C/CXX/LDFLAGS to libbpf.so and test_libpf targets
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote: > In case of LDFLAGS and EXTRA_CC/CXX flags there is no way to pass them > correctly to build command, for instance when --sysroot is used or > external libraries are used, like -lelf, wich can be absent in > toolchain. This is used for samples/bpf cross-compiling allowing to > get elf lib from sysroot. > > Signed-off-by: Ivan Khoronzhuk > --- > samples/bpf/Makefile | 8 +++- > tools/lib/bpf/Makefile | 11 --- > 2 files changed, 15 insertions(+), 4 deletions(-) Could you separate this patch into two? One of libbpf and another for samples. The subject 'libbpf: ...' is not entirely accurate. > > diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile > index 79c9aa41832e..4edc5232cfc1 100644 > --- a/samples/bpf/Makefile > +++ b/samples/bpf/Makefile > @@ -186,6 +186,10 @@ ccflags-y += -I$(srctree)/tools/perf > ccflags-y += $(D_OPTIONS) > ccflags-y += -Wall > ccflags-y += -fomit-frame-pointer > + > +EXTRA_CXXFLAGS := $(ccflags-y) > + > +# options not valid for C++ > ccflags-y += -Wmissing-prototypes > ccflags-y += -Wstrict-prototypes > > @@ -252,7 +256,9 @@ clean: > > $(LIBBPF): FORCE > # Fix up variables inherited from Kbuild that tools/ build system won't like > - $(MAKE) -C $(dir $@) RM='rm -rf' LDFLAGS= > srctree=$(BPF_SAMPLES_PATH)/../../ O= > + $(MAKE) -C $(dir $@) RM='rm -rf' EXTRA_CFLAGS="$(PROGS_CFLAGS)" \ > + EXTRA_CXXFLAGS="$(EXTRA_CXXFLAGS)" LDFLAGS=$(PROGS_LDFLAGS) \ > + srctree=$(BPF_SAMPLES_PATH)/../../ O= > > $(obj)/syscall_nrs.h: $(obj)/syscall_nrs.s FORCE > $(call filechk,offsets,__SYSCALL_NRS_H__) > diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile > index c6f94cffe06e..bccfa556ef4e 100644 > --- a/tools/lib/bpf/Makefile > +++ b/tools/lib/bpf/Makefile > @@ -94,6 +94,10 @@ else > CFLAGS := -g -Wall > endif > > +ifdef EXTRA_CXXFLAGS > + CXXFLAGS := $(EXTRA_CXXFLAGS) > +endif > + > ifeq ($(feature-libelf-mmap), 1) > override CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT > endif > @@ -176,8 +180,9 @@ $(BPF_IN): force elfdep bpfdep > $(OUTPUT)libbpf.so: $(OUTPUT)libbpf.so.$(LIBBPF_VERSION) > > $(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN) > - $(QUIET_LINK)$(CC) --shared > -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \ > - -Wl,--version-script=$(VERSION_SCRIPT) $^ > -lelf -o $@ > + $(QUIET_LINK)$(CC) $(LDFLAGS) \ > + --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \ > + -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@ > @ln -sf $(@F) $(OUTPUT)libbpf.so > @ln -sf $(@F) $(OUTPUT)libbpf.so.$(LIBBPF_MAJOR_VERSION) > > @@ -185,7 +190,7 @@ $(OUTPUT)libbpf.a: $(BPF_IN) > $(QUIET_LINK)$(RM) $@; $(AR) rcs $@ $^ > > $(OUTPUT)test_libbpf: test_libbpf.cpp $(OUTPUT)libbpf.a > - $(QUIET_LINK)$(CXX) $(INCLUDES) $^ -lelf -o $@ > + $(QUIET_LINK)$(CXX) $(CXXFLAGS) $(LDFLAGS) $(INCLUDES) $^ -lelf -o $@ > > $(OUTPUT)libbpf.pc: > $(QUIET_GEN)sed -e "s|@PREFIX@|$(prefix)|" \ >
Re: [PATCH] hv_balloon: Add the support of hibernation
On 13.09.19 22:54, Dexuan Cui wrote: >> From: David Hildenbrand >> Sent: Friday, September 13, 2019 12:46 AM >> >> On 12.09.19 21:18, Dexuan Cui wrote: >>> 3. Hibernation can be especially useful when we pass through a PCIe device, >>> e.g. a NIC, a NVMe controller or a GPU, to the VM, as usually save/restore >>> and live migration can not work with this kind of configuration, because >>> usually the host doesn't know how to save/restore the state of the PCIe >>> device. >> >> Interesting. Under QEMU/KVM (especially for migration), the discussed >> solutions I am aware of rather wanted to temporarily unplug the PCI >> devices or replace them with some kind of "standby" device temporarily. > > For the complex devices like a modern GPU, there may not be an > equivalent "standby" software-emulated device for it, and unplugging the > PCI device temporarily is not good, as it may not be transparent to the > userspace applications. Hibernation here is especially useful, e.g. to Virtual > Desktop Infrastructure users whose VMs can own physical GPUs, because > all the userspace applications are frozen when the VM is hibernated, and > when the VM resumes back, the applications are automatically resumed > and continue to run seamlessly, at least in theory. A hibernated VM saves > compute resources and cost for the users. Yes, I can see how GPUs might be problematic, especially for desktop infrastructures (and maybe especially when running specific guest operating systems :) ). Thanks for the explanation. [...] > On recent Windows Server 2019+ hosts, the toolstacks on the hosts > guarantees that Dynamic Memory and Memory Resizing can not be enabled > if the virtual ACPI S4 state is enabled, and vice versa. Please refer to the > long write-up I made here: https://lkml.org/lkml/2019/9/5/1160 . Hah, so the patch here is not actually relevant for modern Hyper-V installations. (I would have loved to read that in the patch description - but maybe I missed that) > > And, to make the hibernation functionality automated, the host is able to > send a "please hibernate" message to the VM via the Hyper-V shutdown > device upon the user's request (e.g. via GUI or scripting): see > https://lkml.org/lkml/2019/9/13/811 . When the host sends the message, > it checks if the virtual ACPI S4 state is enabled for the VM: if not, the host > refuses to send the message. This means that the user does want to make > sure the virtual ACPI S4 state is enabled for the VM, if the user of the VM > wants to use the hibernation feature, and this means Dynamic Memory > and Memory Resizing can not be active due to the restrictions from the > host toolstack. Okay, *but* this is a current limitation. Just saying. If you could at least support balloon inflate/deflate, that would be a clear win for users. And less configuration knobs. > > And the hibernation functionality won't be officially supported on old > Windows Server hosts. > > So, IMHO we can't be bother to implement the idea you described in > detail. Sorry. :-) No worries, I neither develop for, use or work with Hyper-V. I was just reading along and wondering why you basically make the hv_balloon unusable in these environments. (initially I thought, "why don't you just disallow probing the device completely") I am aware of the (hypervisor) issues of hibernation/suspend when it comes to balloon drivers / memory hot(un)plug. (currently working on virtio-mem myself and initially decided to block any hibernation/suspension attempts in case the driver is loaded and memory was plugged/unplugged) > > And, while I agree your idea is good, technically speaking I suspect it may > not be really useful, because once hv_balloon allows balloon-up/down, > hv_balloon effectively loses control of memory pages: after the host > takes some memory away, the VM never knows when exactly the > host will give it back -- actually the host never guarantees how soon > it will give the memory back. Consequently, the VM almost immediately > ends up in an un-hibernatable state... If you go via the host, you might be able to make sure to request to deflate the balloon before you try to hibernate, and inflate again when back up. You might even ask the user for permissions. Of course, once you deflated the balloon, it might not be guaranteed to inflate the balloon to the original size. But after all, it's "dynamic memory", so it might even be what the name suggests. It could be very well controlled from the host. If you go via the guest, you would first have to tell your hypervisor "please allow me to deflate so I can hibernate", or something like that. After hibernation (or some time X), the host might then decide to inflate again. E.g., take a look at virtio-balloon. When suspending, it simply deflates (without asking ...), to inflate again when resuming. Not saying that's the best approach (it's not :) ), but one approach to at least make it work. Anyhow, just some comments from my side :) I can see
Re: [PATCH bpf-next 08/11] samples: bpf: makefile: base progs build on makefile.progs
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote: > The main reason for that - HOSTCC and CC have different aims. > It was tested for arm cross compilation, based on linaro toolchain, > but should work for others. > > In order to split cross compilation (CC) with host build (HOSTCC), > lets base bpf samples on Makefile.progs. It allows to cross-compile > samples/bpf progs with CC while auxialry tools running on host built > with HOSTCC. I got a compilation failure with the following error $ make samples/bpf/ ... LD samples/bpf/hbm CC samples/bpf/syscall_nrs.s gcc: error: -pg and -fomit-frame-pointer are incompatible make[2]: *** [samples/bpf/syscall_nrs.s] Error 1 make[1]: *** [samples/bpf/] Error 2 make: *** [sub-make] Error 2 Could you take a look? > > Signed-off-by: Ivan Khoronzhuk > --- > samples/bpf/Makefile | 138 +++ > 1 file changed, 73 insertions(+), 65 deletions(-) > > diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile > index f5dbf3d0c5f3..625a71f2e9d2 100644 > --- a/samples/bpf/Makefile > +++ b/samples/bpf/Makefile > @@ -4,55 +4,53 @@ BPF_SAMPLES_PATH ?= $(abspath $(srctree)/$(src)) > TOOLS_PATH := $(BPF_SAMPLES_PATH)/../../tools > > # List of programs to build > -hostprogs-y := test_lru_dist > -hostprogs-y += sock_example > -hostprogs-y += fds_example > -hostprogs-y += sockex1 > -hostprogs-y += sockex2 > -hostprogs-y += sockex3 > -hostprogs-y += tracex1 > -hostprogs-y += tracex2 > -hostprogs-y += tracex3 > -hostprogs-y += tracex4 > -hostprogs-y += tracex5 > -hostprogs-y += tracex6 > -hostprogs-y += tracex7 > -hostprogs-y += test_probe_write_user > -hostprogs-y += trace_output > -hostprogs-y += lathist > -hostprogs-y += offwaketime > -hostprogs-y += spintest > -hostprogs-y += map_perf_test > -hostprogs-y += test_overhead > -hostprogs-y += test_cgrp2_array_pin > -hostprogs-y += test_cgrp2_attach > -hostprogs-y += test_cgrp2_sock > -hostprogs-y += test_cgrp2_sock2 > -hostprogs-y += xdp1 > -hostprogs-y += xdp2 > -hostprogs-y += xdp_router_ipv4 > -hostprogs-y += test_current_task_under_cgroup > -hostprogs-y += trace_event > -hostprogs-y += sampleip > -hostprogs-y += tc_l2_redirect > -hostprogs-y += lwt_len_hist > -hostprogs-y += xdp_tx_iptunnel > -hostprogs-y += test_map_in_map > -hostprogs-y += per_socket_stats_example > -hostprogs-y += xdp_redirect > -hostprogs-y += xdp_redirect_map > -hostprogs-y += xdp_redirect_cpu > -hostprogs-y += xdp_monitor > -hostprogs-y += xdp_rxq_info > -hostprogs-y += syscall_tp > -hostprogs-y += cpustat > -hostprogs-y += xdp_adjust_tail > -hostprogs-y += xdpsock > -hostprogs-y += xdp_fwd > -hostprogs-y += task_fd_query > -hostprogs-y += xdp_sample_pkts > -hostprogs-y += ibumad > -hostprogs-y += hbm > +progs-y := test_lru_dist > +progs-y += sock_example > +progs-y += fds_example > +progs-y += sockex1 > +progs-y += sockex2 > +progs-y += sockex3 > +progs-y += tracex1 > +progs-y += tracex2 > +progs-y += tracex3 > +progs-y += tracex4 > +progs-y += tracex5 > +progs-y += tracex6 > +progs-y += tracex7 > +progs-y += test_probe_write_user > +progs-y += trace_output > +progs-y += lathist > +progs-y += offwaketime > +progs-y += spintest > +progs-y += map_perf_test > +progs-y += test_overhead > +progs-y += test_cgrp2_array_pin > +progs-y += test_cgrp2_attach > +progs-y += test_cgrp2_sock > +progs-y += test_cgrp2_sock2 > +progs-y += xdp1 > +progs-y += xdp2 > +progs-y += xdp_router_ipv4 > +progs-y += test_current_task_under_cgroup > +progs-y += trace_event > +progs-y += sampleip > +progs-y += tc_l2_redirect > +progs-y += lwt_len_hist > +progs-y += xdp_tx_iptunnel > +progs-y += test_map_in_map > +progs-y += xdp_redirect_map > +progs-y += xdp_redirect_cpu > +progs-y += xdp_monitor > +progs-y += xdp_rxq_info > +progs-y += syscall_tp > +progs-y += cpustat > +progs-y += xdp_adjust_tail > +progs-y += xdpsock > +progs-y += xdp_fwd > +progs-y += task_fd_query > +progs-y += xdp_sample_pkts > +progs-y += ibumad > +progs-y += hbm > > # Libbpf dependencies > LIBBPF = $(TOOLS_PATH)/lib/bpf/libbpf.a > @@ -111,7 +109,7 @@ ibumad-objs := bpf_load.o ibumad_user.o $(TRACE_HELPERS) > hbm-objs := bpf_load.o hbm.o $(CGROUP_HELPERS) > > # Tell kbuild to always build the programs > -always := $(hostprogs-y) > +always := $(progs-y) > always += sockex1_kern.o > always += sockex2_kern.o > always += sockex3_kern.o > @@ -170,21 +168,6 @@ always += ibumad_kern.o > always += hbm_out_kern.o > always += hbm_edt_kern.o > > -KBUILD_HOSTCFLAGS += -I$(objtree)/usr/include > -KBUILD_HOSTCFLAGS += -I$(srctree)/tools/lib/bpf/ > -KBUILD_HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/ > -KBUILD_HOSTCFLAGS += -I$(srctree)/tools/lib/ -I$(srctree)/tools/include > -KBUILD_HOSTCFLAGS += -I$(srctree)/tools/perf > - > -HOSTCFLAGS_bpf_load.o += -Wno-unused-variable > - > -KBUILD_HOSTLDLIBS+= $(LIBBPF) -lelf > -HOSTLDLIBS_tracex4 += -lrt > -HOSTLDLIBS_trace_output += -lrt >
Re: KASAN: slab-out-of-bounds Read in handle_vmptrld
On 13/09/19 17:32, Robin Murphy wrote: > Oh, that bit of usbdev_mmap() is already known to be pretty much totally > bogus for various reasons - there have been a few threads about it, of > which I think [1] is both the most recent and the most informative. > There was another patch[2], but that might have stalled (and might need > reworking with additional hcd_uses_dma() checks anyway). Neither is enough, see my reply to Alan. Memory from kmalloc just *cannot* be passed down to remap_pfn_range, dma_mmap_coherent or anything like that. It's a simple alignment issue. Paolo
Re: [PATCH bpf-next 07/11] samples: bpf: add makefile.prog for separate CC build
On 9/10/19 11:38 AM, Ivan Khoronzhuk wrote: > The makefile.prog is added only, will be used in sample/bpf/Makefile > later in order to switch cross-compiling on CC from HOSTCC. > > The HOSTCC is supposed to build binaries and tools running on the host > afterwards, in order to simplify build or so, like "fixdep" or else. > In case of cross compiling "fixdep" is executed on host when the rest > samples should run on target arch. In order to build binaries for > target arch with CC and tools running on host with HOSTCC, lets add > Makefile.prog for simplicity, having definition and routines similar > to ones, used in script/Makefile.host. This allows later add > cross-compilation to samples/bpf with minimum changes. So this is really Makefile.host or Makefile.user, right? In BPF, 'prog' can refers to user prog or bpf prog. To avoid ambiguity, maybe Makefile.host? > > Makefile.prog contains only stuff needed for samples/bpf, potentially > can be reused and extended for other prog sets later and now needed What do you mean 'extended for other prog sets'? I am wondering whether we could just include 'scripts/Makefile.host'? How hard it is? > only for unblocking tricky samples/bpf cross compilation. > > Signed-off-by: Ivan Khoronzhuk > --- > samples/bpf/Makefile.prog | 77 +++ > 1 file changed, 77 insertions(+) > create mode 100644 samples/bpf/Makefile.prog > > diff --git a/samples/bpf/Makefile.prog b/samples/bpf/Makefile.prog > new file mode 100644 > index ..3781999b9193 > --- /dev/null > +++ b/samples/bpf/Makefile.prog > @@ -0,0 +1,77 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# == > +# Building binaries on the host system > +# Binaries are not used during the compilation of the kernel, and intendent > +# to be build for target board, target board can be host ofc. Added to build > +# binaries to run not on host system. > +# > +# Only C is supported, but can be extended for C++. The above comment is not needed. samples/bpf/ only have C now. I am wondering whether your below scripts can be simplified, e.g., removing cxxobjs. > +# > +# Sample syntax (see Documentation/kbuild/makefiles.rst for reference) > +# progs-y := xsk_example > +# Will compile xdpsock_example.c and create an executable named xsk_example > +# > +# progs-y:= xdpsock > +# xdpsock-objs := xdpsock_1.o xdpsock_2.o > +# Will compile xdpsock_1.c and xdpsock_2.c, and then link the executable > +# xdpsock, based on xdpsock_1.o and xdpsock_2.o > +# > +# Inherited from scripts/Makefile.host > +# > +__progs := $(sort $(progs-y)) > + > +# C code > +# Executables compiled from a single .c file > +prog-csingle := $(foreach m,$(__progs), \ > + $(if $($(m)-objs)$($(m)-cxxobjs),,$(m))) > + > +# C executables linked based on several .o files > +prog-cmulti := $(foreach m,$(__progs),\ > +$(if $($(m)-cxxobjs),,$(if $($(m)-objs),$(m > + > +# Object (.o) files compiled from .c files > +prog-cobjs := $(sort $(foreach m,$(__progs),$($(m)-objs))) > + > +prog-csingle := $(addprefix $(obj)/,$(prog-csingle)) > +prog-cmulti := $(addprefix $(obj)/,$(prog-cmulti)) > +prog-cobjs := $(addprefix $(obj)/,$(prog-cobjs)) > + > +# > +# Handle options to gcc. Support building with separate output directory > + > +_progc_flags = $(PROGS_CFLAGS) \ > + $(PROGCFLAGS_$(basetarget).o) > + > +# $(objtree)/$(obj) for including generated headers from checkin source files > +ifeq ($(KBUILD_EXTMOD),) > +ifdef building_out_of_srctree > +_progc_flags += -I $(objtree)/$(obj) > +endif > +endif > + > +progc_flags= -Wp,-MD,$(depfile) $(_progc_flags) > + > +# Create executable from a single .c file > +# prog-csingle -> Executable > +quiet_cmd_prog-csingle = CC $@ > + cmd_prog-csingle = $(CC) $(progc_flags) $(PROGS_LDFLAGS) -o $@ > $< \ > + $(PROGS_LDLIBS) $(PROGLDLIBS_$(@F)) > +$(prog-csingle): $(obj)/%: $(src)/%.c FORCE > + $(call if_changed_dep,prog-csingle) > + > +# Link an executable based on list of .o files, all plain c > +# prog-cmulti -> executable > +quiet_cmd_prog-cmulti= LD $@ > + cmd_prog-cmulti= $(CC) $(progc_flags) $(PROGS_LDFLAGS) -o $@ \ > + $(addprefix $(obj)/,$($(@F)-objs)) \ > + $(PROGS_LDLIBS) $(PROGLDLIBS_$(@F)) > +$(prog-cmulti): $(prog-cobjs) FORCE > + $(call if_changed,prog-cmulti) > +$(call multi_depend, $(prog-cmulti), , -objs) > + > +# Create .o file from a single .c file > +# prog-cobjs -> .o > +quiet_cmd_prog-cobjs = CC $@ > + cmd_prog-cobjs = $(CC) $(progc_flags) -c -o $@ $< > +$(prog-cobjs): $(obj)/%.o: $(src)/%.c FORCE > + $(call if_changed_dep,prog-cobjs) >
Re: [PATCH v3 0/5] Introduce variable length mdev alias
On Wed, 11 Sep 2019 16:38:49 + Parav Pandit wrote: > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Parav Pandit > > Sent: Wednesday, September 11, 2019 10:31 AM > > To: Alex Williamson > > Cc: Jiri Pirko ; kwankh...@nvidia.com; > > coh...@redhat.com; da...@davemloft.net; k...@vger.kernel.org; linux- > > ker...@vger.kernel.org; net...@vger.kernel.org > > Subject: RE: [PATCH v3 0/5] Introduce variable length mdev alias > > > > Hi Alex, > > > > > -Original Message- > > > From: Alex Williamson > > > Sent: Wednesday, September 11, 2019 8:56 AM > > > To: Parav Pandit > > > Cc: Jiri Pirko ; kwankh...@nvidia.com; > > > coh...@redhat.com; da...@davemloft.net; k...@vger.kernel.org; linux- > > > ker...@vger.kernel.org; net...@vger.kernel.org > > > Subject: Re: [PATCH v3 0/5] Introduce variable length mdev alias > > > > > > On Mon, 9 Sep 2019 20:42:32 + > > > Parav Pandit wrote: > > > > > > > Hi Alex, > > > > > > > > > -Original Message- > > > > > From: Parav Pandit > > > > > Sent: Sunday, September 1, 2019 11:25 PM > > > > > To: alex.william...@redhat.com; Jiri Pirko ; > > > > > kwankh...@nvidia.com; coh...@redhat.com; da...@davemloft.net > > > > > Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > > > net...@vger.kernel.org; Parav Pandit > > > > > Subject: [PATCH v3 0/5] Introduce variable length mdev alias > > > > > > > > > > To have consistent naming for the netdevice of a mdev and to have > > > > > consistent naming of the devlink port [1] of a mdev, which is > > > > > formed using phys_port_name of the devlink port, current UUID is > > > > > not usable because UUID is too long. > > > > > > > > > > UUID in string format is 36-characters long and in binary 128-bit. > > > > > Both formats are not able to fit within 15 characters limit of > > > > > netdev > > > name. > > > > > > > > > > It is desired to have mdev device naming consistent using UUID. > > > > > So that widely used user space framework such as ovs [2] can make > > > > > use of mdev representor in similar way as PCIe SR-IOV VF and PF > > > representors. > > > > > > > > > > Hence, > > > > > (a) mdev alias is created which is derived using sha1 from the > > > > > mdev > > > name. > > > > > (b) Vendor driver describes how long an alias should be for the > > > > > child mdev created for a given parent. > > > > > (c) Mdev aliases are unique at system level. > > > > > (d) alias is created optionally whenever parent requested. > > > > > This ensures that non networking mdev parents can function without > > > > > alias creation overhead. > > > > > > > > > > This design is discussed at [3]. > > > > > > > > > > An example systemd/udev extension will have, > > > > > > > > > > 1. netdev name created using mdev alias available in sysfs. > > > > > > > > > > mdev UUID=83b8f4f2-509f-382f-3c1e-e6bfe0fa1001 > > > > > mdev 12 character alias=cd5b146a80a5 > > > > > > > > > > netdev name of this mdev = enmcd5b146a80a5 Here en = Ethernet link > > > > > m = mediated device > > > > > > > > > > 2. devlink port phys_port_name created using mdev alias. > > > > > devlink phys_port_name=pcd5b146a80a5 > > > > > > > > > > This patchset enables mdev core to maintain unique alias for a mdev. > > > > > > > > > > Patch-1 Introduces mdev alias using sha1. > > > > > Patch-2 Ensures that mdev alias is unique in a system. > > > > > Patch-3 Exposes mdev alias in a sysfs hirerchy, update > > > > > Documentation > > > > > Patch-4 Introduces mdev_alias() API. > > > > > Patch-5 Extends mtty driver to optionally provide alias generation. > > > > > This also enables to test UUID based sha1 collision and trigger > > > > > error handling for duplicate sha1 results. > > > > > > > > > > [1] http://man7.org/linux/man-pages/man8/devlink-port.8.html > > > > > [2] https://docs.openstack.org/os-vif/latest/user/plugins/ovs.html > > > > > [3] https://patchwork.kernel.org/cover/11084231/ > > > > > > > > > > --- > > > > > Changelog: > > > > > v2->v3: > > > > > - Addressed comment from Yunsheng Lin > > > > > - Changed strcmp() ==0 to !strcmp() > > > > > - Addressed comment from Cornelia Hunk > > > > > - Merged sysfs Documentation patch with syfs patch > > > > > - Added more description for alias return value > > > > > > > > Did you get a chance review this updated series? > > > > I addressed Cornelia's and yours comment. > > > > I do not think allocating alias memory twice, once for comparison > > > > and once for storing is good idea or moving alias generation logic > > > > inside the mdev_list_lock(). So I didn't address that suggestion of > > Cornelia. > > > > > > Sorry, I'm at LPC this week. I agree, I don't think the double > > > allocation is necessary, I thought the comment was sufficient to > > > clarify null'ing the variable. It's awkward, but seems correct. > > > > > > I'm not sure what we do with this patch series though, has the real > > > consumer of this
[PATCH v6 02/10] s390: vfio-ap: allow assignment of unavailable AP resources to mdev device
The AP architecture does not preclude assignment of AP resources that are
not available. Let's go ahead and implement this facet of the AP
architecture for linux guests.
The current implementation does not allow assignment of an AP adapter or
domain to an mdev device if the APQNs resulting from the assignment
do not reference AP queue devices that are bound to the vfio_ap device
driver. This patch allows assignment of AP resources to the mdev device as
long as the APQNs resulting from the assignment:
1. Are not reserved by the AP BUS for use by the zcrypt device drivers.
2. Are not assigned to another mdev device.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c | 233 --
1 file changed, 48 insertions(+), 185 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 75a413fada4f..18da9ab2b2fb 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -406,122 +406,6 @@ static struct attribute_group *vfio_ap_mdev_type_groups[]
= {
NULL,
};
-struct vfio_ap_queue_reserved {
- unsigned long *apid;
- unsigned long *apqi;
- bool reserved;
-};
-
-/**
- * vfio_ap_has_queue
- *
- * @dev: an AP queue device
- * @data: a struct vfio_ap_queue_reserved reference
- *
- * Flags whether the AP queue device (@dev) has a queue ID containing the APQN,
- * apid or apqi specified in @data:
- *
- * - If @data contains both an apid and apqi value, then @data will be flagged
- * as reserved if the APID and APQI fields for the AP queue device matches
- *
- * - If @data contains only an apid value, @data will be flagged as
- * reserved if the APID field in the AP queue device matches
- *
- * - If @data contains only an apqi value, @data will be flagged as
- * reserved if the APQI field in the AP queue device matches
- *
- * Returns 0 to indicate the input to function succeeded. Returns -EINVAL if
- * @data does not contain either an apid or apqi.
- */
-static int vfio_ap_has_queue(struct device *dev, void *data)
-{
- struct vfio_ap_queue_reserved *qres = data;
- struct ap_queue *ap_queue = to_ap_queue(dev);
- ap_qid_t qid;
- unsigned long id;
-
- if (qres->apid && qres->apqi) {
- qid = AP_MKQID(*qres->apid, *qres->apqi);
- if (qid == ap_queue->qid)
- qres->reserved = true;
- } else if (qres->apid && !qres->apqi) {
- id = AP_QID_CARD(ap_queue->qid);
- if (id == *qres->apid)
- qres->reserved = true;
- } else if (!qres->apid && qres->apqi) {
- id = AP_QID_QUEUE(ap_queue->qid);
- if (id == *qres->apqi)
- qres->reserved = true;
- } else {
- return -EINVAL;
- }
-
- return 0;
-}
-
-/**
- * vfio_ap_verify_queue_reserved
- *
- * @matrix_dev: a mediated matrix device
- * @apid: an AP adapter ID
- * @apqi: an AP queue index
- *
- * Verifies that the AP queue with @apid/@apqi is reserved by the VFIO AP
device
- * driver according to the following rules:
- *
- * - If both @apid and @apqi are not NULL, then there must be an AP queue
- * device bound to the vfio_ap driver with the APQN identified by @apid and
- * @apqi
- *
- * - If only @apid is not NULL, then there must be an AP queue device bound
- * to the vfio_ap driver with an APQN containing @apid
- *
- * - If only @apqi is not NULL, then there must be an AP queue device bound
- * to the vfio_ap driver with an APQN containing @apqi
- *
- * Returns 0 if the AP queue is reserved; otherwise, returns -EADDRNOTAVAIL.
- */
-static int vfio_ap_verify_queue_reserved(unsigned long *apid,
-unsigned long *apqi)
-{
- int ret;
- struct vfio_ap_queue_reserved qres;
-
- qres.apid = apid;
- qres.apqi = apqi;
- qres.reserved = false;
-
- ret = driver_for_each_device(_dev->vfio_ap_drv->driver, NULL,
-, vfio_ap_has_queue);
- if (ret)
- return ret;
-
- if (qres.reserved)
- return 0;
-
- return -EADDRNOTAVAIL;
-}
-
-static int
-vfio_ap_mdev_verify_queues_reserved_for_apid(struct ap_matrix_mdev
*matrix_mdev,
-unsigned long apid)
-{
- int ret;
- unsigned long apqi;
- unsigned long nbits = matrix_mdev->matrix.aqm_max + 1;
-
- if (find_first_bit_inv(matrix_mdev->matrix.aqm, nbits) >= nbits)
- return vfio_ap_verify_queue_reserved(, NULL);
-
- for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm, nbits) {
- ret = vfio_ap_verify_queue_reserved(, );
- if (ret)
- return ret;
- }
-
- return 0;
-}
-
/**
* vfio_ap_mdev_verify_no_sharing
*
@@ -530,16 +414,25 @@ vfio_ap_mdev_verify_queues_reserved_for_apid(struct
