[PATCH] MAINTAINERS: adjust entry to renaming and conversion
Commit a74e81a56405 ("drm/panel: rocktech-jh057n00900: Rename the driver to
st7703") and commit 7317f4574492 ("dt-bindings: panel: Convert
rocktech,jh057n00900 to yaml") renamed and converted the files mentioned in
DRM DRIVER FOR ROCKTECH JH057N00900 PANELS, but did not adjust the entries
in MAINTAINERS.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: \
Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
warning: no file matches F: \
drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
Adjust entries after this file renaming and devicetree conversion.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20200703
Ondrej, please ack this patch.
Sam, please pick this minor non-urgent patch into your -next tree.
This is the minimal change to address the warning. You might consider
changing the name of the section from ROCKTECH to ST7703, change
maintainers etc.
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9375edaef11f..8a7b92faff99 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5493,8 +5493,8 @@ DRM DRIVER FOR ROCKTECH JH057N00900 PANELS
M: Guido Günther
R: Purism Kernel Team
S: Maintained
-F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
-F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
+F:
Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
+F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
DRM DRIVER FOR SAVAGE VIDEO CARDS
S: Orphan / Obsolete
--
2.17.1
Re: [PATCH 4/5] nvme-pci: Use the consistent return type of nvme_pci_iod_alloc_size()
Reviewed-by: Sagi Grimberg
Re: [PATCH 5/5] nvme-pci: Use standard block status macro
Reviewed-by: Sagi Grimberg
Re: [PATCH 3/3] selftests/seccomp: Check ENOSYS under tracing
On Sat, Jul 04, 2020 at 11:12:32PM -0700, Kees Cook wrote:
> There should be no difference between -1 and other negative syscalls
> while tracing.
>
> Cc: Andy Lutomirski
> Cc: Will Drewry
> Cc: Will Deacon
> Cc: Keno Fischer
> Signed-off-by: Kees Cook
> ---
> tools/testing/selftests/seccomp/seccomp_bpf.c | 26 +++
> 1 file changed, 26 insertions(+)
>
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
> b/tools/testing/selftests/seccomp/seccomp_bpf.c
> index 966dec340ea8..bf6aa06c435c 100644
> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> @@ -1973,6 +1973,32 @@ FIXTURE_TEARDOWN(TRACE_syscall)
> teardown_trace_fixture(_metadata, self->tracer);
> }
>
> +TEST(negative_ENOSYS)
> +{
> + /* Untraced negative syscalls should return ENOSYS. */
> + errno = 0;
> + EXPECT_EQ(-1, syscall(-1));
> + EXPECT_EQ(errno, ENOSYS);
> + errno = 0;
> + EXPECT_EQ(-1, syscall(-101));
> + EXPECT_EQ(errno, ENOSYS);
> +}
> +
> +TEST_F(TRACE_syscall, negative_ENOSYS)
> +{
> + /*
> + * There should be no difference between an "internal" skip
> + * and userspace asking for syscall "-1".
> + */
> + errno = 0;
> + EXPECT_EQ(-1, syscall(-1));
> + EXPECT_EQ(errno, ENOSYS);
> + /* And no difference for "still not valid but not -1". */
> + errno = 0;
> + EXPECT_EQ(-1, syscall(-101));
> + EXPECT_EQ(errno, ENOSYS);
> +}
> +
I realized after sending this that the second function could just be:
+TEST_F(TRACE_syscall, negative_ENOSYS)
+{
+ negative_ENOSYS(_metadata);
+}
:)
> TEST_F(TRACE_syscall, syscall_allowed)
> {
> /* getppid works as expected (no changes). */
> --
> 2.25.1
>
--
Kees Cook
Re: [GIT pull resend] x86/entry for v5.8
On 13/06/20 00:05, Thomas Gleixner wrote: >- KVM > > KVM is inconsistent as well. Patches have been posted, but they have > not yet been commented on or picked up by the KVM folks. Hi Thomas, which patches are these? I must have missed them, and I would like to pick them up for either 5.8 or 5.9. Thanks, Paolo
Re: [PATCH v2] .gitignore: Do not track `defconfig` from `make savedefconfig`
On Thu, Jul 2, 2020 at 8:12 PM Paul Menzel wrote: > > Running `make savedefconfig` creates by default `defconfig`, which is, > currently, on git’s radar, for example, `git status` lists this file as > untracked. > > So, add the file to `.gitignore`, so it’s ignored by git. > > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Paul Menzel > --- > .gitignore | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/.gitignore b/.gitignore > index 87b9dd8a163b..f07500889fba 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -143,6 +143,9 @@ x509.genkey > /allrandom.config > /allyes.config > > +# Kconfig presets, default savedefconfg output I just noticed this comment is wrong since 'defconfig' is not a preset. I will change it to 'Kconfig savedefconfig output'. Thanks. > +/defconfig > + > # Kdevelop4 > *.kdev4 > > -- > 2.27.0 > -- Best Regards Masahiro Yamada
[PATCH 1/2] arm64: dts: exynos: Fix silent hang after boot
Once regulators are disabled after kernel boot, on espresso
board silent hang observed because of LDO7 being disabled.
LDO7 actually provide power to CPU cores and non-cpu blocks
circuitries.
Keep this regulator always-on to fix this hang.
Fixes: 9589f7721e16 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso")
Signed-off-by: Alim Akhtar
---
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 790f12ca8981..bb86950032d3 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -157,6 +157,7 @@
regulator-min-microvolt = <70>;
regulator-max-microvolt = <115>;
regulator-enable-ramp-delay = <125>;
+ regulator-always-on;
};
ldo8_reg: LDO8 {
base-commit: 9e50b94b3eb0d859a2586b5a40d7fd6e5afd9210
--
2.17.1
[PATCH 2/2] arm64: dts: exynos: keep LDO12 always-on
LDO12 on exynos7 supply power to VDDQ_UFS20_RESET,
in case this regulator is OFF, UFS host controller
can not send command to UFS device. To keep this supply
ON, set regulator-always-on property for this ldo.
Signed-off-by: Alim Akhtar
---
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index bb86950032d3..92fecc539c6c 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -194,6 +194,7 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <130>;
regulator-enable-ramp-delay = <125>;
+ regulator-always-on;
};
ldo13_reg: LDO13 {
--
2.17.1
Re: [PATCH v2] .gitignore: Do not track `defconfig` from `make savedefconfig`
Dear Masahiro, Am 05.07.20 um 09:14 schrieb Masahiro Yamada: On Thu, Jul 2, 2020 at 8:12 PM Paul Menzel wrote: Running `make savedefconfig` creates by default `defconfig`, which is, currently, on git’s radar, for example, `git status` lists this file as untracked. So, add the file to `.gitignore`, so it’s ignored by git. Cc: linux-kernel@vger.kernel.org Signed-off-by: Paul Menzel --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 87b9dd8a163b..f07500889fba 100644 --- a/.gitignore +++ b/.gitignore @@ -143,6 +143,9 @@ x509.genkey /allrandom.config /allyes.config +# Kconfig presets, default savedefconfg output I just noticed this comment is wrong since 'defconfig' is not a preset. I will change it to 'Kconfig savedefconfig output'. Thank you for finding my error and correcting it. I couldn’t find out more about *presets*. $ git grep -i preset scripts/kconfig/ $ Where can I look, so I won’t repeat the same mistake next time? +/defconfig + # Kdevelop4 *.kdev4 -- 2.27.0 Kind regards, Paul
KASAN: slab-out-of-bounds Read in __xfrm_state_lookup
Hello, syzbot found the following crash on: HEAD commit:c28e58ee Add linux-next specific files for 20200629 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=14fe1b1710 kernel config: https://syzkaller.appspot.com/x/.config?x=dcd26bbca17dd1db dashboard link: https://syzkaller.appspot.com/bug?extid=deb366561a1f28f6c13d compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+deb366561a1f28f6c...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in __xfrm_state_lookup.isra.0+0x809/0x870 net/xfrm/xfrm_state.c:938 Read of size 8 at addr 88809585dab8 by task syz-executor.1/12920 CPU: 1 PID: 12920 Comm: syz-executor.1 Not tainted 5.8.0-rc3-next-20200629-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 __xfrm_state_lookup.isra.0+0x809/0x870 net/xfrm/xfrm_state.c:938 xfrm_state_find+0x1d57/0x4d70 net/xfrm/xfrm_state.c:1100 xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2384 [inline] xfrm_tmpl_resolve+0x2f3/0xd20 net/xfrm/xfrm_policy.c:2429 xfrm_resolve_and_create_bundle+0x123/0x24f0 net/xfrm/xfrm_policy.c:2719 xfrm_lookup_with_ifid+0x235/0x2100 net/xfrm/xfrm_policy.c:3042 xfrm_lookup net/xfrm/xfrm_policy.c:3166 [inline] xfrm_lookup_route+0x36/0x1e0 net/xfrm/xfrm_policy.c:3177 ip6_dst_lookup_flow+0x159/0x1d0 net/ipv6/ip6_output.c:1160 rawv6_sendmsg+0xc82/0x38f0 net/ipv6/raw.c:928 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:814 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x331/0x810 net/socket.c:2352 ___sys_sendmsg+0xf3/0x170 net/socket.c:2406 __sys_sendmmsg+0x195/0x480 net/socket.c:2496 __do_sys_sendmmsg net/socket.c:2525 [inline] __se_sys_sendmmsg net/socket.c:2522 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2522 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45cb29 Code: Bad RIP value. RSP: 002b:7f46d295bc78 EFLAGS: 0246 ORIG_RAX: 0133 RAX: ffda RBX: 004fd720 RCX: 0045cb29 RDX: 02e9 RSI: 2480 RDI: 0008 RBP: 0078bf00 R08: R09: R10: R11: 0246 R12: R13: 0903 R14: 004cbe13 R15: 7f46d295c6d4 Allocated by task 23: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:494 __do_kmalloc mm/slab.c:3659 [inline] __kmalloc+0x18f/0x4d0 mm/slab.c:3668 kmalloc include/linux/slab.h:559 [inline] kzalloc include/linux/slab.h:666 [inline] xfrm_hash_alloc+0xbd/0xe0 net/xfrm/xfrm_hash.c:21 xfrm_hash_resize+0x96/0x14a0 net/xfrm/xfrm_state.c:135 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Freed by task 1: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] kasan_set_free_info mm/kasan/common.c:316 [inline] __kasan_slab_free+0xf2/0x130 mm/kasan/common.c:455 __cache_free mm/slab.c:3422 [inline] kfree+0x103/0x2c0 mm/slab.c:3760 tomoyo_path_perm+0x234/0x3f0 security/tomoyo/file.c:842 security_inode_getattr+0xcf/0x140 security/security.c:1278 vfs_getattr fs/stat.c:121 [inline] vfs_statx_fd+0x70/0xf0 fs/stat.c:151 vfs_fstat include/linux/fs.h:3172 [inline] __do_sys_newfstat+0x88/0x100 fs/stat.c:398 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at 88809585da00 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 56 bytes to the right of 128-byte region [88809585da00, 88809585da80) The buggy address belongs to the page: page:ea0002561740 refcount:1 mapcount:0 mapping: index:0x0 flags: 0xfffe000200(slab) raw: 00fffe000200 ea0002526348 ea00022f4588 8880aa000400 raw: 88809585d000 00010010 page dumped because: kasan: bad access detected Memory state around the buggy address: 88809585d980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 88809585da00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >88809585da80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ff
Re: [PATCH 3/3] selftests: add readfile(2) selftests
On Sun, Jul 05, 2020 at 03:41:48AM +0200, Heinrich Schuchardt wrote: > On 7/4/20 4:02 PM, Greg Kroah-Hartman wrote: > > Test the functionality of readfile(2) in various ways. > > Hello Greg, > > I expect readfile() to generate fanotify events FAN_OPEN_PERM, FAN_OPEN, > FAN_ACCESS_PERM, FAN_ACCESS, FAN_CLOSE_NOWRITE in this sequence. Yes, it should, I don't think I do anything unique here when it comes to vfs accesses that would go around those events. > Looking at patch 1/3 you took care of notifications. Would this deserve > testing here? Possibly, do we have other in-tree tests of syscalls that validate those events properly being created? thanks, greg k-h
[PATCH v1 2/2] arm64: dts: exynos: keep LDO12 always-on
LDO12 on exynos7 supply power to VDDQ_UFS20_RESET,
in case this regulator is OFF, UFS host controller
can not send command to UFS device. To keep this supply
ON, set regulator-always-on property for this ldo.
Signed-off-by: Alim Akhtar
---
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index bb86950032d3..92fecc539c6c 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -194,6 +194,7 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <130>;
regulator-enable-ramp-delay = <125>;
+ regulator-always-on;
};
ldo13_reg: LDO13 {
--
2.17.1
WARNING in bpf_xdp_adjust_tail
Hello, syzbot found the following crash on: HEAD commit:2ce578ca net: ipv4: Fix wrong type conversion from hint to.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=1190cf2310 kernel config: https://syzkaller.appspot.com/x/.config?x=bf3aec367b9ab569 dashboard link: https://syzkaller.appspot.com/bug?extid=c3157bda041952444952 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c3157bda041952444...@syzkaller.appspotmail.com WARNING: CPU: 0 PID: 22595 at net/core/filter.c:3463 bpf_xdp_adjust_tail net/core/filter.c:3463 [inline] WARNING: CPU: 0 PID: 22595 at net/core/filter.c:3463 bpf_xdp_adjust_tail+0x18e/0x1e0 net/core/filter.c:3452 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 22595 Comm: syz-executor.4 Not tainted 5.8.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 panic+0x2e3/0x75c kernel/panic.c:231 __warn.cold+0x20/0x45 kernel/panic.c:600 report_bug+0x1bd/0x210 lib/bug.c:198 exc_invalid_op+0x24d/0x400 arch/x86/kernel/traps.c:235 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:563 RIP: 0010:bpf_xdp_adjust_tail net/core/filter.c:3463 [inline] RIP: 0010:bpf_xdp_adjust_tail+0x18e/0x1e0 net/core/filter.c:3452 Code: 37 fb 84 db 74 09 49 c7 c4 ea ff ff ff eb c7 e8 f8 f5 37 fb 44 89 e6 48 c7 c7 e0 fc fd 88 c6 05 dc f5 6d 04 01 e8 94 3b 09 fb <0f> 0b eb d8 e8 d9 48 77 fb e9 c5 fe ff ff e8 df 48 77 fb e9 92 fe RSP: 0018:c900018878e0 EFLAGS: 00010286 RAX: RBX: RCX: RDX: 0004 RSI: 815ce8d7 RDI: f52000310f0e RBP: R08: 0001 R09: 8880ae620fcb R10: R11: R12: 0002 R13: 88804c20feef R14: 88804c20feef R15: bpf_prog_4add87e5301a4105+0x20/0x818 bpf_prog_run_xdp include/linux/filter.h:734 [inline] netif_receive_generic_xdp+0x70f/0x1760 net/core/dev.c:4647 do_xdp_generic net/core/dev.c:4735 [inline] do_xdp_generic+0x96/0x1a0 net/core/dev.c:4728 tun_get_user+0x22d2/0x35b0 drivers/net/tun.c:1905 tun_chr_write_iter+0xba/0x151 drivers/net/tun.c:1999 call_write_iter include/linux/fs.h:1907 [inline] new_sync_write+0x422/0x650 fs/read_write.c:484 __vfs_write+0xc9/0x100 fs/read_write.c:497 vfs_write+0x268/0x5d0 fs/read_write.c:559 ksys_write+0x12d/0x250 fs/read_write.c:612 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x416661 Code: Bad RIP value. RSP: 002b:7f8bc3971c60 EFLAGS: 0293 ORIG_RAX: 0001 RAX: ffda RBX: 005095a0 RCX: 00416661 RDX: fdef RSI: 2080 RDI: 00f0 RBP: 0078bf00 R08: R09: R10: 7f8bc39729d0 R11: 0293 R12: R13: 0bfd R14: 004ce559 R15: 7f8bc39726d4 Kernel Offset: disabled --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[PATCH v1 1/2] arm64: dts: exynos: Fix silent hang after boot
Once regulators are disabled after kernel boot, on espresso
board silent hang observed because of LDO7 being disabled.
LDO7 actually provide power to CPU cores and non-cpu blocks
circuitries.
Keep this regulator always-on to fix this hang.
Fixes: 9589f7721e16 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso")
Signed-off-by: Alim Akhtar
---
-
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 790f12ca8981..bb86950032d3 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -157,6 +157,7 @@
regulator-min-microvolt = <70>;
regulator-max-microvolt = <115>;
regulator-enable-ramp-delay = <125>;
+ regulator-always-on;
};
ldo8_reg: LDO8 {
base-commit: 9e50b94b3eb0d859a2586b5a40d7fd6e5afd9210
--
2.17.1
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 5, 2020 at 8:32 AM Andreas Dilger wrote:
>
> On Jul 4, 2020, at 8:46 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
> >
> > On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox wrote:
> >>
> >> On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
> >>> Hello
> >>>
> >>> At first, I thought that the proposed system call is capable of
> >>> reading *multiple* small files using a single system call - which
> >>> would help increase HDD/SSD queue utilization and increase IOPS (I/O
> >>> operations per second) - but that isn't the case and the proposed
> >>> system call can read just a single file.
> >>>
> >>> Without the ability to read multiple small files using a single system
> >>> call, it is impossible to increase IOPS (unless an application is
> >>> using multiple reader threads or somehow instructs the kernel to
> >>> prefetch multiple files into memory).
> >>
> >> What API would you use for this?
> >>
> >> ssize_t readfiles(int dfd, char **files, void **bufs, size_t *lens);
> >>
> >> I pretty much hate this interface, so I hope you have something better
> >> in mind.
> >
> > I am proposing the following:
> >
> > struct readfile_t {
> > int dirfd;
> > const char *pathname;
> > void *buf;
> > size_t count;
> > int flags;
> > ssize_t retval; // set by kernel
> > int reserved; // not used by kernel
> > };
>
> If you are going to pass a struct from userspace to the kernel, it
> should not mix int and pointer types (which may be 64-bit values,
> so that there are not structure packing issues, like:
>
> struct readfile {
> int dirfd;
> int flags;
> const char *pathname;
> void*buf;
> size_t count;
> ssize_t retval;
> };
>
> It would be better if "retval" was returned in "count", so that
> the structure fits nicely into 32 bytes on a 64-bit system, instead
> of being 40 bytes per entry, which adds up over many entries, like.
I know what you mean and it is a valid point, but in my opinion it
shouldn't (in most cases) be left to the programmer to decide what the
binary layout of a data structure is - instead it should be left to an
optimizing compiler to decide it. Just like code optimization,
determining the physical layout of data structures can be subject to
automatic optimizations as well. It is kind of unfortunate that in
C/C++, and in many other statically compiled languages (even recent
ones), the physical layout of all data structures is determined by the
programmer rather than the compiler. Also, tagging fields as "input",
"output", or both (the default) would be helpful in obtaining smaller
sizes:
struct readfile_t {
input int dirfd;
input const char *pathname;
input void *buf;
input size_t count;
input int flags;
output ssize_t retval; // set by kernel
output int reserved; // not used by kernel
};
int readfiles(struct readfile_t *requests, size_t count);
struct readfile_t r[10];
// Write r[i] inputs
int status = readfiles(r, nelem(r));
// Read r[i] outputs
A data-layout optimizing compiler should be able to determine that the
optimal layout of readfile_t is UNION(INPUT: 2*int+2*pointer+1*size_t,
OUTPUT: 1*ssize_t+1*int).
In the unfortunate case of the non-optimizing C language and if it is
just a micro-optimization (optimizing readfile_t is a
micro-optimization), it is better to leave the data structure in a
form that is appropriate for being efficiently readable by programmers
rather than to micro-optimize it and make it confusing to programmers.
> struct readfile {
> int dirfd;
> int flags;
> const char *pathname;
> void*buf;
> ssize_t count; /* input: bytes requested, output: bytes read or
> -errno */
> };
>
>
> However, there is still an issue with passing pointers from userspace,
> since they may be 32-bit userspace pointers on a 64-bit kernel.
>
> > int readfiles(struct readfile_t *requests, size_t count);
>
> It's not clear why count is a "size_t" since it is not a size.
> An unsigned int is fine here, since it should never be negative.
Generally speaking, size_t reflects the size of the address space
while unsigned int doesn't and therefore it is easier for unsigned int
to overflow on very large data sets.
> > Returns zero if all requests succeeded, otherwise the returned value
> > is non-zero (glibc wrapper: -1) and user-space is expected to check
> > which requests have succeeded and which have failed. retval in
> > readfile_t is set to what the single-file readfile syscall would
> > return if it was called with the contents of the corresponding
> > readfile_t struct.
> >
> > The glibc library wrapper of this system call is expected to store the
> > errno in the "reserved" field. Thus, a programmer using glibc sees:
> >
> > struct readfile_t {
> > int dirfd;
> > const char *pathname;
> > void *buf;
> > size_t count;
> > int flags;
> > ssize_t retval; // set by glibc (-1 on error)
> > int errno; // set by glibc if retval is -1
> >
[PATCH] Replace HTTP links with HTTPS ones: input drivers
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov --- Continuing my work started at 93431e0607e5. If there are any URLs to be removed completely or at least not HTTPSified: Just clearly say so and I'll *undo my change*. See also https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See https://lkml.org/lkml/2020/6/26/837 .../devicetree/bindings/input/ps2keyb-mouse-apbps2.txt| 2 +- .../devicetree/bindings/input/rmi4/rmi_2d_sensor.txt | 2 +- Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt | 2 +- Documentation/devicetree/bindings/input/ti,drv260x.txt| 2 +- Documentation/devicetree/bindings/input/ti,drv2665.txt| 2 +- Documentation/devicetree/bindings/input/ti,drv2667.txt| 2 +- Documentation/input/devices/appletouch.rst| 2 +- Documentation/input/devices/bcm5974.rst | 4 ++-- Documentation/input/devices/iforce-protocol.rst | 2 +- Documentation/input/devices/joystick-parport.rst | 2 +- Documentation/input/devices/ntrig.rst | 2 +- Documentation/input/devices/pxrc.rst | 2 +- Documentation/input/multi-touch-protocol.rst | 2 +- drivers/input/keyboard/Kconfig| 2 +- drivers/input/keyboard/lkkbd.c| 2 +- drivers/input/keyboard/opencores-kbd.c| 2 +- drivers/input/keyboard/tca8418_keypad.c | 2 +- drivers/input/misc/Kconfig| 2 +- drivers/input/misc/cm109.c| 2 +- drivers/input/misc/gpio_decoder.c | 2 +- drivers/input/misc/palmas-pwrbutton.c | 2 +- drivers/input/misc/powermate.c| 2 +- drivers/input/misc/tps65218-pwrbutton.c | 2 +- drivers/input/misc/yealink.c | 2 +- drivers/input/mouse/vsxxxaa.c | 2 +- drivers/input/serio/apbps2.c | 2 +- drivers/input/touchscreen/edt-ft5x06.c| 2 +- drivers/input/touchscreen/iqs5xx.c| 2 +- drivers/input/touchscreen/mc13783_ts.c| 2 +- drivers/input/touchscreen/ti_am335x_tsc.c | 2 +- drivers/input/touchscreen/usbtouchscreen.c| 2 +- include/uapi/linux/input-event-codes.h| 2 +- 32 files changed, 33 insertions(+), 33 deletions(-) diff --git a/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt b/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt index 3029c5694cf6..4606b07317ff 100644 --- a/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt +++ b/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt @@ -13,4 +13,4 @@ Required properties: - interrupts : Interrupt numbers for this device For further information look in the documentation for the GLIB IP core library: -http://www.gaisler.com/products/grlib/grip.pdf +https://www.gaisler.com/products/grlib/grip.pdf diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt index 9afffbdf6e28..f0906e90cb35 100644 --- a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt @@ -9,7 +9,7 @@ Documentation/devicetree/bindings/input/rmi4. RMI4 Function 11 and Function 12 are for 2D touch position sensing. Additional documentation for F11 can be found at: -http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf +https://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf Optional Touch Properties: Description in Documentation/devicetree/bindings/input/touchscreen diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt index 079cad2b6843..23186fce40a1 100644 --- a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt @@ -7,7 +7,7 @@ for transports and other functions can be found in: Documentation/devicetree/bindings/input/rmi4. Additional documentation for F01 can be found at: -http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Inter
[PATCH] Replace HTTP links with HTTPS ones: Xilinx video IP cores
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov --- Continuing my work started at 93431e0607e5. If there are any URLs to be removed completely or at least not HTTPSified: Just clearly say so and I'll *undo my change*. See also https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See https://lkml.org/lkml/2020/6/26/837 Documentation/devicetree/bindings/media/xilinx/video.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/xilinx/video.txt b/Documentation/devicetree/bindings/media/xilinx/video.txt index 68ac210e688e..d0335ca0cd57 100644 --- a/Documentation/devicetree/bindings/media/xilinx/video.txt +++ b/Documentation/devicetree/bindings/media/xilinx/video.txt @@ -32,4 +32,4 @@ The following properties are common to all Xilinx video IP cores. defaults to "mono". -[UG934] http://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf +[UG934] https://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf -- 2.27.0
[PATCH] Replace HTTP links with HTTPS ones: Dialog Semiconductor drivers
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov --- Continuing my work started at 93431e0607e5. If there are any URLs to be removed completely or at least not HTTPSified: Just clearly say so and I'll *undo my change*. See also https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See https://lkml.org/lkml/2020/6/26/837 Documentation/devicetree/bindings/mfd/da9062.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt index 857af982c88f..bab0d0e66cb3 100644 --- a/Documentation/devicetree/bindings/mfd/da9062.txt +++ b/Documentation/devicetree/bindings/mfd/da9062.txt @@ -1,8 +1,8 @@ * Dialog DA9062 Power Management Integrated Circuit (PMIC) Product information for the DA9062 and DA9061 devices can be found here: -- http://www.dialog-semiconductor.com/products/da9062 -- http://www.dialog-semiconductor.com/products/da9061 +- https://www.dialog-semiconductor.com/products/da9062 +- https://www.dialog-semiconductor.com/products/da9061 The DA9062 PMIC consists of: -- 2.27.0
[PATCH] Replace HTTP links with HTTPS ones: CAN network drivers
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov --- Continuing my work started at 93431e0607e5. If there are any URLs to be removed completely or at least not HTTPSified: Just clearly say so and I'll *undo my change*. See also https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See https://lkml.org/lkml/2020/6/26/837 Documentation/devicetree/bindings/net/can/grcan.txt | 2 +- drivers/net/can/grcan.c | 2 +- drivers/net/can/m_can/m_can.c | 2 +- drivers/net/can/m_can/m_can.h | 2 +- drivers/net/can/m_can/m_can_platform.c | 2 +- drivers/net/can/m_can/tcan4x5x.c| 2 +- drivers/net/can/sja1000/Kconfig | 12 ++-- drivers/net/can/sja1000/tscan1.c| 2 +- drivers/net/can/slcan.c | 2 +- drivers/net/can/ti_hecc.c | 4 ++-- drivers/net/can/usb/Kconfig | 6 +++--- 11 files changed, 19 insertions(+), 19 deletions(-) diff --git a/Documentation/devicetree/bindings/net/can/grcan.txt b/Documentation/devicetree/bindings/net/can/grcan.txt index 34ef3498f887..d05b5c80d2b4 100644 --- a/Documentation/devicetree/bindings/net/can/grcan.txt +++ b/Documentation/devicetree/bindings/net/can/grcan.txt @@ -25,4 +25,4 @@ Optional properties: a bug workaround is activated. For further information look in the documentation for the GLIB IP core library: -http://www.gaisler.com/products/grlib/grip.pdf +https://www.gaisler.com/products/grlib/grip.pdf diff --git a/drivers/net/can/grcan.c b/drivers/net/can/grcan.c index 378200b682fa..c6be0ed9ae90 100644 --- a/drivers/net/can/grcan.c +++ b/drivers/net/can/grcan.c @@ -8,7 +8,7 @@ * VHDL IP core library. * * Full documentation of the GRCAN core can be found here: - * http://www.gaisler.com/products/grlib/grip.pdf + * https://www.gaisler.com/products/grlib/grip.pdf * * See "Documentation/devicetree/bindings/net/can/grcan.txt" for information on * open firmware properties. diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c index 02c5795b7393..d7d6e5111e0d 100644 --- a/drivers/net/can/m_can/m_can.c +++ b/drivers/net/can/m_can/m_can.c @@ -2,7 +2,7 @@ // CAN bus driver for Bosch M_CAN controller // Copyright (C) 2014 Freescale Semiconductor, Inc. // Dong Aisheng -// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/ +// Copyright (C) 2018-19 Texas Instruments Incorporated - https://www.ti.com/ /* Bosch M_CAN user manual can be obtained from: * http://www.bosch-semiconductors.de/media/pdf_1/ipmodules_1/m_can/ diff --git a/drivers/net/can/m_can/m_can.h b/drivers/net/can/m_can/m_can.h index 49f42b50627a..30a1a030ce17 100644 --- a/drivers/net/can/m_can/m_can.h +++ b/drivers/net/can/m_can/m_can.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 */ /* CAN bus driver for Bosch M_CAN controller - * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ + * Copyright (C) 2018 Texas Instruments Incorporated - https://www.ti.com/ */ #ifndef _CAN_M_CAN_H_ diff --git a/drivers/net/can/m_can/m_can_platform.c b/drivers/net/can/m_can/m_can_platform.c index 38ea5e600fb8..1905b7108429 100644 --- a/drivers/net/can/m_can/m_can_platform.c +++ b/drivers/net/can/m_can/m_can_platform.c @@ -3,7 +3,7 @@ // Copyright (C) 2014 Freescale Semiconductor, Inc. // Dong Aisheng // -// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/ +// Copyright (C) 2018-19 Texas Instruments Incorporated - https://www.ti.com/ #include diff --git a/drivers/net/can/m_can/tcan4x5x.c b/drivers/net/can/m_can/tcan4x5x.c index eacd428e07e9..d36ac51cde8c 100644 --- a/drivers/net/can/m_can/tcan4x5x.c +++ b/drivers/net/can/m_can/tcan4x5x.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 // SPI to CAN driver for the Texas Instruments TCAN4x5x -// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/ +// Copyright (C) 2018-19 Texas Instruments Incorporated - https://www.ti.com/ #include #include diff --git a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig index 110071b26921..0a9558db3088 100644 --- a/drivers/net/can/sja1000/Kconfig +++ b/drivers/net/can/sja1000/Kconfig @@ -12,14 +12,14 @@ config CAN_EMS_PCI help This driver is for the one, two or four channel CPC-PCI, CPC-PCIe and CPC-104P cards from EMS Dr. Thomas Wuensche - (http://www.em
[PATCH 1/1] mm/mmap: optimize a branch judgment in ksys_mmap_pgoff()
Look at the pseudo code below. It's very clear that, the judgement
"!is_file_hugepages(file)" at 3) is duplicated to the one at 1), we can
use "else if" to avoid it. And the assignment "retval = -EINVAL" at 2)
is only needed by the branch 3), because "retval" will be overwritten
at 4).
No functional change, but it can reduce the code size. Maybe more clearer?
Before:
textdata bss dec hex filename
287331590 1 303247674 mm/mmap.o
After:
textdata bss dec hex filename
287011590 1 302927654 mm/mmap.o
pseudo code:
if (!(flags & MAP_ANONYMOUS)) {
...
1) if (is_file_hugepages(file))
len = ALIGN(len, huge_page_size(hstate_file(file)));
2) retval = -EINVAL;
3) if (unlikely(flags & MAP_HUGETLB && !is_file_hugepages(file)))
goto out_fput;
} else if (flags & MAP_HUGETLB) {
...
}
...
4) retval = vm_mmap_pgoff(file, addr, len, prot, flags, pgoff);
out_fput:
...
return retval;
Signed-off-by: Zhen Lei
---
mm/mmap.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 59a4682ebf3faed..a7bb2039738528f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1562,11 +1562,12 @@ unsigned long ksys_mmap_pgoff(unsigned long addr,
unsigned long len,
file = fget(fd);
if (!file)
return -EBADF;
- if (is_file_hugepages(file))
+ if (is_file_hugepages(file)) {
len = ALIGN(len, huge_page_size(hstate_file(file)));
- retval = -EINVAL;
- if (unlikely(flags & MAP_HUGETLB && !is_file_hugepages(file)))
+ } else if (unlikely(flags & MAP_HUGETLB)) {
+ retval = -EINVAL;
goto out_fput;
+ }
} else if (flags & MAP_HUGETLB) {
struct user_struct *user = NULL;
struct hstate *hs;
--
1.8.3
Re: [PATCH] drm/panel: auo,b116xw03: fix flash backlight when power on
Hi Jitao.
On Fri, Jul 03, 2020 at 05:51:13PM +0800, Jitao Shi wrote:
> Delay the backlight on to make sure the video stable.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/panel/panel-simple.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 3ad828eaefe1..18f34f286d3d 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -734,6 +734,9 @@ static const struct panel_desc auo_b116xw03 = {
> .width = 256,
> .height = 144,
> },
> + .delay = {
> + .enable = 400,
> + },
> };
>
> static const struct drm_display_mode auo_b133xtn01_mode = {
Patch did not apply to drm-misc-next.
Please update - and when you do so also add:
.bus_flags
.bus_format
.connector_type
So we have this panel properly defined.
Sam
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 05, 2020 at 04:27:32AM +0100, Matthew Wilcox wrote: > On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote: > > On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox wrote: > > > > > > You should probably take a look at io_uring. That has the level of > > > complexity of this proposal and supports open/read/close along with many > > > other opcodes. > > > > Then glibc can implement readfile using io_uring and there is no need > > for a new single-file readfile syscall. > > It could, sure. But there's also a value in having a simple interface > to accomplish a simple task. Your proposed API added a very complex > interface to satisfy needs that clearly aren't part of the problem space > that Greg is looking to address. I disagree re: "aren't part of the problem space". Reading small files from procfs was specifically called out in the rationale for the syscall. In my experience you're rarely monitoring a single proc file in any situation where you care about the syscall overhead. You're monitoring many of them, and any serious effort to do this efficiently in a repeatedly sampled situation has cached the open fds and already uses pread() to simply restart from 0 on every sample and not repeatedly pay for the name lookup. Basically anything optimally using the existing interfaces for sampling proc files needs a way to read multiple open file descriptors in a single syscall to move the needle. This syscall doesn't provide that. It doesn't really give any advantage over what we can achieve already. It seems basically pointless to me, from a monitoring proc files perspective. Regards, Vito Caputo
Re: [PATCH v2] pinctrl-single: fix pcs_parse_pinconf() return value
On Mon, 8 Jun 2020 at 20:51, Drew Fustini wrote:
>
> This patch causes pcs_parse_pinconf() to return -ENOTSUPP when no
> pinctrl_map is added. The current behavior is to return 0 when
> !PCS_HAS_PINCONF or !nconfs. Thus pcs_parse_one_pinctrl_entry()
> incorrectly assumes that a map was added and sets num_maps = 2.
>
> Analysis:
> =
> The function pcs_parse_one_pinctrl_entry() calls pcs_parse_pinconf()
> if PCS_HAS_PINCONF is enabled. The function pcs_parse_pinconf()
> returns 0 to indicate there was no error and num_maps is then set to 2:
>
> 980 static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
> 981 struct device_node *np,
> 982 struct pinctrl_map **map,
> 983 unsigned *num_maps,
> 984 const char **pgnames)
> 985 {
>
> 1053 (*map)->type = PIN_MAP_TYPE_MUX_GROUP;
> 1054 (*map)->data.mux.group = np->name;
> 1055 (*map)->data.mux.function = np->name;
> 1056
> 1057 if (PCS_HAS_PINCONF && function) {
> 1058 res = pcs_parse_pinconf(pcs, np, function, map);
> 1059 if (res)
> 1060 goto free_pingroups;
> 1061 *num_maps = 2;
> 1062 } else {
> 1063 *num_maps = 1;
> 1064 }
>
> However, pcs_parse_pinconf() will also return 0 if !PCS_HAS_PINCONF or
> !nconfs. I believe these conditions should indicate that no map was
> added by returning -ENOTSUPP. Otherwise pcs_parse_one_pinctrl_entry()
> will set num_maps = 2 even though no maps were successfully added, as
> it does not reach "m++" on line 940:
>
> 895 static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node
> *np,
> 896 struct pcs_function *func,
> 897 struct pinctrl_map **map)
> 898
> 899 {
> 900 struct pinctrl_map *m = *map;
>
> 917 /* If pinconf isn't supported, don't parse properties in below.
> */
> 918 if (!PCS_HAS_PINCONF)
> 919 return 0;
> 920
> 921 /* cacluate how much properties are supported in current node */
> 922 for (i = 0; i < ARRAY_SIZE(prop2); i++) {
> 923 if (of_find_property(np, prop2[i].name, NULL))
> 924 nconfs++;
> 925 }
> 926 for (i = 0; i < ARRAY_SIZE(prop4); i++) {
> 927 if (of_find_property(np, prop4[i].name, NULL))
> 928 nconfs++;
> 929 }
> 930 if (!nconfs)
> 919 return 0;
> 932
> 933 func->conf = devm_kcalloc(pcs->dev,
> 934 nconfs, sizeof(struct pcs_conf_vals),
> 935 GFP_KERNEL);
> 936 if (!func->conf)
> 937 return -ENOMEM;
> 938 func->nconfs = nconfs;
> 939 conf = &(func->conf[0]);
> 940 m++;
>
> This situtation will cause a boot failure [0] on the BeagleBone Black
> (AM3358) when am33xx_pinmux node in arch/arm/boot/dts/am33xx-l4.dtsi
> has compatible = "pinconf-single" instead of "pinctrl-single".
>
> The patch fixes this issue by returning -ENOSUPP when !PCS_HAS_PINCONF
> or !nconfs, so that pcs_parse_one_pinctrl_entry() will know that no
> map was added.
>
> Logic is also added to pcs_parse_one_pinctrl_entry() to distinguish
> between -ENOSUPP and other errors. In the case of -ENOSUPP, num_maps
> is set to 1 as it is valid for pinconf to be enabled and a given pin
> group to not any pinconf properties.
>
> [0] https://lore.kernel.org/linux-omap/20200529175544.GA3766151@x1/
>
> Fixes: 9dddb4df90d1 ("pinctrl: single: support generic pinconf")
> Signed-off-by: Drew Fustini
> ---
> changes from V1 [0]:
> - if pcs_parse_pinconf() returns -ENOSUPP, then set num_maps to 1 and
> proceed normally as it is valid for group to have no pinconf props
> - added Fixes: tag thanks to Gustavo A. R. Silva
>
> [0] https://lore.kernel.org/linux-omap/20200531204147.GA664833@x1/
>
> drivers/pinctrl/pinctrl-single.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c
> b/drivers/pinctrl/pinctrl-single.c
> index 1e0614daee9b..a9d511982780 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -916,7 +916,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs,
> struct device_node *np,
>
> /* If pinconf isn't supported, don't parse properties in below. */
> if (!PCS_HAS_PINCONF)
> - return 0;
> + return -ENOTSUPP;
>
> /* cacluate how much properties are supported in current node */
> for (i = 0; i < ARRAY_SIZE(prop2); i++) {
> @@ -928,7 +928,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs,
> struct device_node *np,
>
Re: [PATCH v4 0/2] pinctrl: single: support #pinctrl-cells = 2
On Wed, 1 Jul 2020 at 09:33, Drew Fustini wrote: > > Currently, pinctrl-single only allows #pinctrl-cells = 1. > > This series will allow pinctrl-single to also support #pinctrl-cells = 2 > > If "pinctrl-single,pins" has 3 arguments (offset, conf, mux) then > pcs_parse_one_pinctrl_entry() does an OR operation on conf and mux to > get the value to store in the register. > > To take advantage of #pinctrl-cells = 2, the AM33XX_PADCONF macro in > omap.h is modified to keep pin conf and pin mux values separate. > > change log: > - v4: squash patches 2 and 3 together so that git biesct will not result > in a boot failure > > - v3: change order of patches to make sure the pinctrl-single.c patch > does not break anything without the dts patches > > - v2: remove outer parentheses from AM33XX_PADCONF macro as it causes a > compile error in dtc. I had added it per suggestion from checkpatch > about having parentheses around complex values. > > Drew Fustini (2): > pinctrl: single: parse #pinctrl-cells = 2 > ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2 > > arch/arm/boot/dts/am33xx-l4.dtsi | 2 +- > drivers/pinctrl/pinctrl-single.c | 11 +-- > include/dt-bindings/pinctrl/omap.h | 2 +- > 3 files changed, 11 insertions(+), 4 deletions(-) > > -- > 2.25.1 > Acked-by: Haojian Zhuang
[PATCH 6/9] phy: qcom-qmp: Add compatible for ipq8074 pcie gen3 qmp phy
ipq8074 has two pcie ports, one gen2 and one gen3 ports. with phy support already available for gen2 pcie ports add support for pcie gen3 port phy. Co-developed-by: Selvam Sathappan Periakaruppan Signed-off-by: Selvam Sathappan Periakaruppan Signed-off-by: Sivaprakash Murugesan --- drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h | 137 drivers/phy/qualcomm/phy-qcom-qmp.c | 172 +- 2 files changed, 307 insertions(+), 2 deletions(-) create mode 100644 drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h diff --git a/drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h b/drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h new file mode 100644 index ..bb567673d9b5 --- /dev/null +++ b/drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h @@ -0,0 +1,137 @@ +/* SPDX-License-Identifier: GPL-2.0* + * + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ + +#ifndef PHY_QCOM_PCIE_H + +/* QMP V2 PCIE PHY - Found in IPQ8074 gen3 port - QSERDES PLL registers */ +#define QSERDES_PLL_BG_TIMER 0x00c +#define QSERDES_PLL_SSC_PER1 0x01c +#define QSERDES_PLL_SSC_PER2 0x020 +#define QSERDES_PLL_SSC_STEP_SIZE1_MODE0 0x024 +#define QSERDES_PLL_SSC_STEP_SIZE2_MODE0 0x028 +#define QSERDES_PLL_SSC_STEP_SIZE1_MODE1 0x02c +#define QSERDES_PLL_SSC_STEP_SIZE2_MODE1 0x030 +#define QSERDES_PLL_BIAS_EN_CLKBUFLR_EN0x03c +#define QSERDES_PLL_CLK_ENABLE10x040 +#define QSERDES_PLL_SYS_CLK_CTRL 0x044 +#define QSERDES_PLL_SYSCLK_BUF_ENABLE 0x048 +#define QSERDES_PLL_PLL_IVCO 0x050 +#define QSERDES_PLL_LOCK_CMP1_MODE00x054 +#define QSERDES_PLL_LOCK_CMP2_MODE00x058 +#define QSERDES_PLL_LOCK_CMP1_MODE10x060 +#define QSERDES_PLL_LOCK_CMP2_MODE10x064 +#define QSERDES_PLL_BG_TRIM0x074 +#define QSERDES_PLL_CLK_EP_DIV_MODE0 0x078 +#define QSERDES_PLL_CLK_EP_DIV_MODE1 0x07c +#define QSERDES_PLL_CP_CTRL_MODE0 0x080 +#define QSERDES_PLL_CP_CTRL_MODE1 0x084 +#define QSERDES_PLL_PLL_RCTRL_MODE00x088 +#defineQSERDES_PLL_PLL_RCTRL_MODE1 0x08C +#define QSERDES_PLL_PLL_CCTRL_MODE00x090 +#defineQSERDES_PLL_PLL_CCTRL_MODE1 0x094 +#define QSERDES_PLL_BIAS_EN_CTRL_BY_PSM0x0a4 +#defineQSERDES_PLL_SYSCLK_EN_SEL 0x0a8 +#define QSERDES_PLL_RESETSM_CNTRL 0x0b0 +#define QSERDES_PLL_LOCK_CMP_EN0x0c4 +#define QSERDES_PLL_DEC_START_MODE00x0cc +#define QSERDES_PLL_DEC_START_MODE10x0d0 +#define QSERDES_PLL_DIV_FRAC_START1_MODE0 0x0d8 +#define QSERDES_PLL_DIV_FRAC_START2_MODE0 0x0dc +#define QSERDES_PLL_DIV_FRAC_START3_MODE0 0x0e0 +#define QSERDES_PLL_DIV_FRAC_START1_MODE1 0x0e4 +#define QSERDES_PLL_DIV_FRAC_START2_MODE1 0x0e8 +#define QSERDES_PLL_DIV_FRAC_START3_MODE1 0x0eC +#define QSERDES_PLL_INTEGLOOP_GAIN0_MODE0 0x100 +#define QSERDES_PLL_INTEGLOOP_GAIN1_MODE0 0x104 +#define QSERDES_PLL_INTEGLOOP_GAIN0_MODE1 0x108 +#define QSERDES_PLL_INTEGLOOP_GAIN1_MODE1 0x10c +#define QSERDES_PLL_VCO_TUNE_MAP 0x120 +#define QSERDES_PLL_VCO_TUNE1_MODE00x124 +#define QSERDES_PLL_VCO_TUNE2_MODE00x128 +#define QSERDES_PLL_VCO_TUNE1_MODE10x12c +#define QSERDES_PLL_VCO_TUNE2_MODE10x130 +#define QSERDES_PLL_VCO_TUNE_TIMER10x13c +#define QSERDES_PLL_VCO_TUNE_TIMER20x140 +#define QSERDES_PLL_CLK_SELECT 0x16c +#define QSERDES_PLL_HSCLK_SEL 0x170 +#define QSERDES_PLL_CORECLK_DIV0x17c +#define QSERDES_PLL_CORE_CLK_EN0x184 +#defineQSERDES_PLL_CMN_CONFIG 0x18c +#define QSERDES_PLL_SVS_MODE_CLK_SEL 0x194 +#define QSERDES_PLL_CORECLK_DIV_MODE1 0x1b4 + +/* QMP V2 PCIE PHY - Found in IPQ8074 gen3 port - - QSERDES TX registers */ +#define QSERDES_TX0_RES_CODE_LANE_OFFSET_TX0x03c +#define QSERDES_TX0_HIGHZ_DRVR_EN 0x058 +#define QSERDES_TX0_LANE_MODE_10x084 +#define QSERDES_TX0_RCV_DETECT_LVL_2 0x09c + +/* QMP V2 PCIE PHY - Found in IPQ8074 gen3 port - QSERDES RX registers */ +#define QSERDES_RX0_UCDR_FO_GAIN 0x008 +#define QSERDES_RX0_UCDR_
[PATCH 2/9] dt-bindings: phy: qcom,qmp: Add dt-binding for ipq8074 gen3 pcie phy
ipq8074 has two different phy blocks for two pcie ports, with pcie gen2 compatible already available, specify the pcie phy compatible for gen3 pcie port. Co-developed-by: Selvam Sathappan Periakaruppan Signed-off-by: Selvam Sathappan Periakaruppan Signed-off-by: Sivaprakash Murugesan --- Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index f80f8896d527..3e8681679f53 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,ipq8074-qmp-pcie-phy + - qcom,ipq8074-qmp-pcie-gen3-phy - qcom,msm8996-qmp-pcie-phy - qcom,msm8996-qmp-ufs-phy - qcom,msm8996-qmp-usb3-phy -- 2.7.4
[PATCH 1/9] dt-bindings: pci: Add ipq8074 gen3 pci compatible
ipq8074 has two PCIe ports while the support for gen2 pcie port is already available add the support for gen3 binding. Co-developed-by: Selvam Sathappan Periakaruppan Signed-off-by: Selvam Sathappan Periakaruppan Signed-off-by: Sivaprakash Murugesan --- .../devicetree/bindings/pci/qcom,pcie.yaml | 47 ++ 1 file changed, 47 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml index b119ce4711b4..b5ec45df735e 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml @@ -22,6 +22,7 @@ properties: - qcom,pcie-ipq4019 - qcom,pcie-ipq8064 - qcom,pcie-ipq8074 + - qcom,pcie-ipq8074-gen3 - qcom,pcie-msm8996 - qcom,pcie-qcs404 - qcom,pcie-sdm845 @@ -330,6 +331,52 @@ allOf: compatible: contains: enum: + - qcom,pcie-ipq8074-gen3 + then: + properties: + clocks: + items: + - description: sys noc interface clock + - description: AXI master clock + - description: AXI slave clock + - description: AHB clock + - description: Auxilary clock + - description: AXI slave bridge clock + - description: PCIe rchng clock + clock-names: + items: + - const: iface + - const: axi_m + - const: axi_s + - const: ahb + - const: aux + - const: axi_bridge + - const: rchng + resets: + items: + - description: PIPE reset + - description: PCIe sleep reset + - description: PCIe sticky reset + - description: AXI master reset + - description: AXI slave reset + - description: AHB reset + - description: AXI master sticky reset + - description: AXI Slave sticky reset + reset-names: + items: + - const: pipe + - const: sleep + - const: sticky + - const: axi_m + - const: axi_s + - const: ahb + - const: axi_m_sticky + - const: axi_s_sticky + - if: + properties: + compatible: + contains: + enum: - qcom,pcie-msm8996 then: properties: -- 2.7.4
[PATCH 4/9] clk: qcom: ipq8074: Add missing clocks for pcie
Add missing clocks and resets for pcie port0 of ipq8074 devices.
Co-developed-by: Selvam Sathappan Periakaruppan
Signed-off-by: Selvam Sathappan Periakaruppan
Signed-off-by: Sivaprakash Murugesan
---
drivers/clk/qcom/gcc-ipq8074.c | 60 ++
1 file changed, 60 insertions(+)
diff --git a/drivers/clk/qcom/gcc-ipq8074.c b/drivers/clk/qcom/gcc-ipq8074.c
index e01f5f591d1e..443e28cda8ed 100644
--- a/drivers/clk/qcom/gcc-ipq8074.c
+++ b/drivers/clk/qcom/gcc-ipq8074.c
@@ -4316,6 +4316,62 @@ static struct clk_branch gcc_gp3_clk = {
},
};
+struct freq_tbl ftbl_pcie_rchng_clk_src[] = {
+ F(1920, P_XO, 1, 0, 0),
+ F(1, P_GPLL0, 8, 0, 0),
+ { }
+};
+
+struct clk_rcg2 pcie0_rchng_clk_src = {
+ .cmd_rcgr = 0x75070,
+ .freq_tbl = ftbl_pcie_rchng_clk_src,
+ .hid_width = 5,
+ .parent_map = gcc_xo_gpll0_map,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "pcie0_rchng_clk_src",
+ .parent_hws = (const struct clk_hw *[]) {
+ &gpll0.clkr.hw },
+ .num_parents = 2,
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_branch gcc_pcie0_rchng_clk = {
+ .halt_reg = 0x75070,
+ .halt_bit = 31,
+ .clkr = {
+ .enable_reg = 0x75070,
+ .enable_mask = BIT(1),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_pcie0_rchng_clk",
+ .parent_hws = (const struct clk_hw *[]){
+ &pcie0_rchng_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch gcc_pcie0_axi_s_bridge_clk = {
+ .halt_reg = 0x75048,
+ .halt_bit = 31,
+ .clkr = {
+ .enable_reg = 0x75048,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_pcie0_axi_s_bridge_clk",
+ .parent_hws = (const struct clk_hw *[]){
+ &pcie0_axi_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
static struct clk_hw *gcc_ipq8074_hws[] = {
&gpll0_out_main_div2.hw,
&gpll6_out_main_div2.hw,
@@ -4551,6 +4607,9 @@ static struct clk_regmap *gcc_ipq8074_clks[] = {
[GCC_GP1_CLK] = &gcc_gp1_clk.clkr,
[GCC_GP2_CLK] = &gcc_gp2_clk.clkr,
[GCC_GP3_CLK] = &gcc_gp3_clk.clkr,
+ [GCC_PCIE0_RCHNG_CLK_SRC] = &pcie0_rchng_clk_src.clkr,
+ [GCC_PCIE0_RCHNG_CLK] = &gcc_pcie0_rchng_clk.clkr,
+ [GCC_PCIE0_AXI_S_BRIDGE_CLK] = &gcc_pcie0_axi_s_bridge_clk.clkr,
};
static const struct qcom_reset_map gcc_ipq8074_resets[] = {
@@ -4678,6 +4737,7 @@ static const struct qcom_reset_map gcc_ipq8074_resets[] =
{
[GCC_PCIE0_AXI_SLAVE_ARES] = { 0x75040, 4 },
[GCC_PCIE0_AHB_ARES] = { 0x75040, 5 },
[GCC_PCIE0_AXI_MASTER_STICKY_ARES] = { 0x75040, 6 },
+ [GCC_PCIE0_AXI_SLAVE_STICKY_ARES] = { 0x75040, 7 },
[GCC_PCIE1_PIPE_ARES] = { 0x76040, 0 },
[GCC_PCIE1_SLEEP_ARES] = { 0x76040, 1 },
[GCC_PCIE1_CORE_STICKY_ARES] = { 0x76040, 2 },
--
2.7.4
[PATCH 0/9] Add PCIe support for IPQ8074
IPQ8074 has two PCIe ports both are based on synopsis designware PCIe controller. while it was assumed that PCIe support for IPQ8074 was already available. PCIe was not functional until now. This patch series adds support for PCIe ports on IPQ8074. First PCIe port is of gen2 synposis version is 2_3_2 which has already been enabled. But it had some problems on phy init and needed dt updates. Second PCIe port is gen3 synopsis version is 2_9_0. This series adds support for this PCIe port while fixing dt nodes. Patch 1 on this series depends on qcom pcie bindings patch https://lkml.org/lkml/2020/6/24/162 Sivaprakash Murugesan (9): dt-bindings: pci: Add ipq8074 gen3 pci compatible dt-bindings: phy: qcom,qmp: Add dt-binding for ipq8074 gen3 pcie phy clk: qcom: ipq8074: Add missing bindings for pcie clk: qcom: ipq8074: Add missing clocks for pcie phy: qcom-qmp: use correct values for ipq8074 gen2 pcie phy init phy: qcom-qmp: Add compatible for ipq8074 pcie gen3 qmp phy pci: dwc: qcom: do phy power on before pcie init pci: qcom: Add support for ipq8074 pci controller arm64: dts: ipq8074: Fixup pcie dts nodes .../devicetree/bindings/pci/qcom,pcie.yaml | 47 ++ .../devicetree/bindings/phy/qcom,qmp-phy.yaml | 1 + arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 8 +- arch/arm64/boot/dts/qcom/ipq8074.dtsi | 109 drivers/clk/qcom/gcc-ipq8074.c | 60 +++ drivers/pci/controller/dwc/pcie-qcom.c | 187 +++- drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h | 132 +++ drivers/phy/qualcomm/phy-qcom-qmp.c| 188 - drivers/phy/qualcomm/phy-qcom-qmp.h| 2 + include/dt-bindings/clock/qcom,gcc-ipq8074.h | 4 + 10 files changed, 683 insertions(+), 55 deletions(-) create mode 100644 drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h -- 2.7.4
[PATCH 3/9] clk: qcom: ipq8074: Add missing bindings for pcie
Add missing clock bindings for pcie port0 of ipq8074. Co-developed-by: Selvam Sathappan Periakaruppan Signed-off-by: Selvam Sathappan Periakaruppan Signed-off-by: Sivaprakash Murugesan --- include/dt-bindings/clock/qcom,gcc-ipq8074.h | 4 1 file changed, 4 insertions(+) diff --git a/include/dt-bindings/clock/qcom,gcc-ipq8074.h b/include/dt-bindings/clock/qcom,gcc-ipq8074.h index 4de4811a3540..e3e018565add 100644 --- a/include/dt-bindings/clock/qcom,gcc-ipq8074.h +++ b/include/dt-bindings/clock/qcom,gcc-ipq8074.h @@ -362,5 +362,9 @@ #define GCC_PCIE1_AXI_SLAVE_ARES 128 #define GCC_PCIE1_AHB_ARES 129 #define GCC_PCIE1_AXI_MASTER_STICKY_ARES 130 +#define GCC_PCIE0_AXI_SLAVE_STICKY_ARES131 +#define GCC_PCIE0_AXI_S_BRIDGE_CLK 132 +#define GCC_PCIE0_RCHNG_CLK_SRC133 +#define GCC_PCIE0_RCHNG_CLK134 #endif -- 2.7.4
[PATCH 9/9] arm64: dts: ipq8074: Fixup pcie dts nodes
ipq8074 pcie nodes missing several properties which is needed to make
them work add these properties.
Co-developed-by: Selvam Sathappan Periakaruppan
Signed-off-by: Selvam Sathappan Periakaruppan
Signed-off-by: Sivaprakash Murugesan
---
arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 8 +--
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 109 --
2 files changed, 78 insertions(+), 39 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
index 6754cb0638f4..dfb8ad73f134 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
+++ b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
@@ -52,19 +52,19 @@
&pcie0 {
status = "ok";
- perst-gpio = <&tlmm 61 0x1>;
+ perst-gpio = <&tlmm 58 0x1>;
};
&pcie1 {
status = "ok";
- perst-gpio = <&tlmm 58 0x1>;
+ perst-gpio = <&tlmm 61 0x1>;
};
-&pcie_phy0 {
+&qmp_pcie_phy0 {
status = "ok";
};
-&pcie_phy1 {
+&qmp_pcie_phy1 {
status = "ok";
};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index 5303821300b4..5bb58b70199e 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -82,34 +82,66 @@
ranges = <0 0 0 0x>;
compatible = "simple-bus";
- pcie_phy0: phy@86000 {
- compatible = "qcom,ipq8074-qmp-pcie-phy";
- reg = <0x00086000 0x1000>;
- #phy-cells = <0>;
- clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
- clock-names = "pipe_clk";
- clock-output-names = "pcie20_phy0_pipe_clk";
+ qmp_pcie_phy0: phy@84000 {
+ compatible = "qcom,ipq8074-qmp-pcie-gen3-phy";
+ reg = <0x00084000 0x1bc>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ clocks = <&gcc GCC_PCIE0_AUX_CLK>,
+<&gcc GCC_PCIE0_AHB_CLK>;
+ clock-names = "aux", "cfg_ahb";
resets = <&gcc GCC_PCIE0_PHY_BCR>,
- <&gcc GCC_PCIE0PHY_PHY_BCR>;
+<&gcc GCC_PCIE0PHY_PHY_BCR>;
reset-names = "phy",
"common";
+
status = "disabled";
+ pcie_phy0: lane@84200 {
+ reg = <0x84200 0x16c>, /* Serdes Tx */
+ <0x84400 0x200>, /* Serdes Rx */
+ <0x84800 0x4f4>; /* PCS: Lane0, COM, PCIE
*/
+ #phy-cells = <0>;
+
+ clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
+ clock-names = "pipe0";
+ clock-output-names = "gcc_pcie0_pipe_clk_src";
+ clock-output-rate = <25000>;
+ #clock-cells = <0>;
+ };
};
- pcie_phy1: phy@8e000 {
+ qmp_pcie_phy1: phy@8e000 {
compatible = "qcom,ipq8074-qmp-pcie-phy";
- reg = <0x0008e000 0x1000>;
- #phy-cells = <0>;
- clocks = <&gcc GCC_PCIE1_PIPE_CLK>;
- clock-names = "pipe_clk";
- clock-output-names = "pcie20_phy1_pipe_clk";
+ reg = <0x8e000 0x1c4>; /* Serdes PLL */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ clocks = <&gcc GCC_PCIE1_AUX_CLK>,
+<&gcc GCC_PCIE1_AHB_CLK>;
+ clock-names = "aux", "cfg_ahb";
resets = <&gcc GCC_PCIE1_PHY_BCR>,
- <&gcc GCC_PCIE1PHY_PHY_BCR>;
+<&gcc GCC_PCIE1PHY_PHY_BCR>;
reset-names = "phy",
"common";
+
status = "disabled";
+ pcie_phy1: lane@8e200 {
+ reg = <0x8e200 0x130>, /* Serdes Tx */
+ <0x8e400 0x200>, /* Serdes Rx */
+ <0x8e800 0x1f8>; /* PCS */
+ #phy-cells = <0>;
+
+ clocks = <&gcc GCC_PCIE1_PIPE_CLK>;
+ clock-names = "pipe0";
+ clock-output-names = "gcc_pcie1_pipe_clk_src";
+ clock-output-rate = <12500>;
+ #clock-cells = <0>;
+ };
};
[PATCH 5/9] phy: qcom-qmp: use correct values for ipq8074 gen2 pcie phy init
There were some problem in ipq8074 gen2 pcie phy init sequence, fix
these to make gen2 pcie port on ipq8074 to work.
Fixes: eef243d04b2b6 ("phy: qcom-qmp: Add support for IPQ8074")
Cc: sta...@vger.kernel.org
Co-developed-by: Selvam Sathappan Periakaruppan
Signed-off-by: Selvam Sathappan Periakaruppan
Signed-off-by: Sivaprakash Murugesan
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 16 +---
drivers/phy/qualcomm/phy-qcom-qmp.h | 2 ++
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index e91040af3394..ba277136f52b 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -504,8 +504,8 @@ static const struct qmp_phy_init_tbl
ipq8074_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_COM_BG_TRIM, 0xf),
QMP_PHY_INIT_CFG(QSERDES_COM_LOCK_CMP_EN, 0x1),
QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_MAP, 0x0),
- QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER1, 0x1f),
- QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER2, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER1, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER2, 0x1f),
QMP_PHY_INIT_CFG(QSERDES_COM_CMN_CONFIG, 0x6),
QMP_PHY_INIT_CFG(QSERDES_COM_PLL_IVCO, 0xf),
QMP_PHY_INIT_CFG(QSERDES_COM_HSCLK_SEL, 0x0),
@@ -531,7 +531,6 @@ static const struct qmp_phy_init_tbl
ipq8074_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_COM_INTEGLOOP_GAIN1_MODE0, 0x0),
QMP_PHY_INIT_CFG(QSERDES_COM_INTEGLOOP_GAIN0_MODE0, 0x80),
QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CTRL_BY_PSM, 0x1),
- QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_CTRL, 0xa),
QMP_PHY_INIT_CFG(QSERDES_COM_SSC_EN_CENTER, 0x1),
QMP_PHY_INIT_CFG(QSERDES_COM_SSC_PER1, 0x31),
QMP_PHY_INIT_CFG(QSERDES_COM_SSC_PER2, 0x1),
@@ -540,7 +539,6 @@ static const struct qmp_phy_init_tbl
ipq8074_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_COM_SSC_STEP_SIZE1, 0x2f),
QMP_PHY_INIT_CFG(QSERDES_COM_SSC_STEP_SIZE2, 0x19),
QMP_PHY_INIT_CFG(QSERDES_COM_CLK_EP_DIV, 0x19),
- QMP_PHY_INIT_CFG(QSERDES_RX_SIGDET_CNTRL, 0x7),
};
static const struct qmp_phy_init_tbl ipq8074_pcie_tx_tbl[] = {
@@ -548,6 +546,8 @@ static const struct qmp_phy_init_tbl ipq8074_pcie_tx_tbl[]
= {
QMP_PHY_INIT_CFG(QSERDES_TX_LANE_MODE, 0x6),
QMP_PHY_INIT_CFG(QSERDES_TX_RES_CODE_LANE_OFFSET, 0x2),
QMP_PHY_INIT_CFG(QSERDES_TX_RCV_DETECT_LVL_2, 0x12),
+ QMP_PHY_INIT_CFG(QSERDES_TX_EMP_POST1_LVL, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_TX_SLEW_CNTL, 0x0a),
};
static const struct qmp_phy_init_tbl ipq8074_pcie_rx_tbl[] = {
@@ -558,7 +558,6 @@ static const struct qmp_phy_init_tbl ipq8074_pcie_rx_tbl[]
= {
QMP_PHY_INIT_CFG(QSERDES_RX_RX_EQU_ADAPTOR_CNTRL4, 0xdb),
QMP_PHY_INIT_CFG(QSERDES_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x4b),
QMP_PHY_INIT_CFG(QSERDES_RX_UCDR_SO_GAIN, 0x4),
- QMP_PHY_INIT_CFG(QSERDES_RX_UCDR_SO_GAIN_HALF, 0x4),
};
static const struct qmp_phy_init_tbl ipq8074_pcie_pcs_tbl[] = {
@@ -1673,6 +1672,9 @@ static const struct qmp_phy_cfg msm8996_usb3phy_cfg = {
.pwrdn_ctrl = SW_PWRDN,
};
+static const char * const ipq8074_pciephy_clk_l[] = {
+ "aux", "cfg_ahb",
+};
/* list of resets */
static const char * const ipq8074_pciephy_reset_l[] = {
"phy", "common",
@@ -1690,8 +1692,8 @@ static const struct qmp_phy_cfg ipq8074_pciephy_cfg = {
.rx_tbl_num = ARRAY_SIZE(ipq8074_pcie_rx_tbl),
.pcs_tbl= ipq8074_pcie_pcs_tbl,
.pcs_tbl_num= ARRAY_SIZE(ipq8074_pcie_pcs_tbl),
- .clk_list = NULL,
- .num_clks = 0,
+ .clk_list = ipq8074_pciephy_clk_l,
+ .num_clks = ARRAY_SIZE(ipq8074_pciephy_clk_l),
.reset_list = ipq8074_pciephy_reset_l,
.num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l),
.vreg_list = NULL,
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h
b/drivers/phy/qualcomm/phy-qcom-qmp.h
index 6d017a0c0c8d..832b3d098403 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.h
@@ -77,6 +77,8 @@
#define QSERDES_COM_CORECLK_DIV_MODE1 0x1bc
/* Only for QMP V2 PHY - TX registers */
+#define QSERDES_TX_EMP_POST1_LVL 0x018
+#define QSERDES_TX_SLEW_CNTL 0x040
#define QSERDES_TX_RES_CODE_LANE_OFFSET0x054
#define QSERDES_TX_DEBUG_BUS_SEL 0x064
#define QSERDES_TX_HIGHZ_TRANSCEIVEREN_BIAS_DRVR_EN0x068
--
2.7.4
[PATCH 7/9] pci: dwc: qcom: do phy power on before pcie init
Commit cc1e06f033af ("phy: qcom: qmp: Use power_on/off ops for PCIe")
changed phy ops from init/deinit to power on/off, due to this phy enable
is getting called after pcie init.
On some platforms like ipq8074 phy should be inited before accessing the
pcie register space, otherwise the system would hang.
So move phy_power_on API before pcie init API.
Fixes: commit cc1e06f033af ("phy: qcom: qmp: Use power_on/off ops for PCIe")
Co-developed-by: Selvam Sathappan Periakaruppan
Signed-off-by: Selvam Sathappan Periakaruppan
Signed-off-by: Sivaprakash Murugesan
---
drivers/pci/controller/dwc/pcie-qcom.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
b/drivers/pci/controller/dwc/pcie-qcom.c
index 138e1a2d21cc..aa52a2124760 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -1222,18 +1222,18 @@ static int qcom_pcie_host_init(struct pcie_port *pp)
qcom_ep_reset_assert(pcie);
- ret = pcie->ops->init(pcie);
+ ret = phy_power_on(pcie->phy);
if (ret)
return ret;
- ret = phy_power_on(pcie->phy);
+ ret = pcie->ops->init(pcie);
if (ret)
- goto err_deinit;
+ goto err_disable_phy;
if (pcie->ops->post_init) {
ret = pcie->ops->post_init(pcie);
if (ret)
- goto err_disable_phy;
+ goto err_deinit;
}
dw_pcie_setup_rc(pp);
@@ -1252,10 +1252,10 @@ static int qcom_pcie_host_init(struct pcie_port *pp)
qcom_ep_reset_assert(pcie);
if (pcie->ops->post_deinit)
pcie->ops->post_deinit(pcie);
-err_disable_phy:
- phy_power_off(pcie->phy);
err_deinit:
pcie->ops->deinit(pcie);
+err_disable_phy:
+ phy_power_off(pcie->phy);
return ret;
}
--
2.7.4
[PATCH 8/9] pci: qcom: Add support for ipq8074 pci controller
ipq8074 has one gen2 and one gen3 pcie port, with support for gen2 port
is already available add support for pcie gen3 port.
Co-developed-by: Selvam Sathappan Periakaruppan
Signed-off-by: Selvam Sathappan Periakaruppan
Signed-off-by: Sivaprakash Murugesan
---
drivers/pci/controller/dwc/pcie-qcom.c | 175 -
1 file changed, 174 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
b/drivers/pci/controller/dwc/pcie-qcom.c
index aa52a2124760..1a6fafdb2642 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -39,8 +39,17 @@
#define L23_CLK_RMV_DISBIT(2)
#define L1_CLK_RMV_DIS BIT(1)
+#define PCIE_ATU_CR1_OUTBOUND_6_GEN3 0xC00
+#define PCIE_ATU_CR2_OUTBOUND_6_GEN3 0xC04
+#define PCIE_ATU_LIMIT_OUTBOUND_6_GEN3 0xC10
+#define PCIE_ATU_CR1_OUTBOUND_7_GEN3 0xE00
+#define PCIE_ATU_CR2_OUTBOUND_7_GEN3 0xE04
+#define PCIE_ATU_LOWER_BASE_OUTBOUND_7_GEN30xE08
+#define PCIE_ATU_LIMIT_OUTBOUND_7_GEN3 0xE10
+
#define PCIE20_COMMAND_STATUS 0x04
#define CMD_BME_VAL0x4
+#define BUS_MASTER_EN 0x7
#define PCIE20_DEVICE_CONTROL2_STATUS2 0x98
#define PCIE_CAP_CPL_TIMEOUT_DISABLE 0x10
@@ -49,6 +58,15 @@
#define PCIE20_PARF_DBI_BASE_ADDR 0x168
#define PCIE20_PARF_SLV_ADDR_SPACE_SIZE0x16C
#define PCIE20_PARF_MHI_CLOCK_RESET_CTRL 0x174
+
+#define AHB_CLK_EN BIT(0)
+#define MSTR_AXI_CLK_ENBIT(1)
+#define BYPASS BIT(4)
+
+#define PCIE20_LNK_CONTROL2_LINK_STATUS2 0xA0
+#define PCIE_CAP_CURR_DEEMPHASIS BIT(16)
+#define SPEED_GEN3 0x3
+
#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT 0x178
#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2 0x1A8
#define PCIE20_PARF_LTSSM 0x1B0
@@ -56,6 +74,9 @@
#define PCIE20_PARF_BDF_TRANSLATE_CFG 0x24C
#define PCIE20_PARF_DEVICE_TYPE0x1000
+#define PCIE20_PARF_BDF_TO_SID_TABLE 0x2000
+#define BDF_TO_SID_TABLE_SIZE 0x100
+
#define PCIE20_ELBI_SYS_CTRL 0x04
#define PCIE20_ELBI_SYS_CTRL_LT_ENABLE BIT(0)
@@ -83,6 +104,10 @@
#define DEVICE_TYPE_RC 0x4
+#define PCIE30_GEN3_RELATED_OFF0x890
+#define RXEQ_RGRDLESS_RXTS BIT(13)
+#define GEN3_ZRXDC_NONCOMPLBIT(0)
+
#define QCOM_PCIE_2_1_0_MAX_SUPPLY 3
struct qcom_pcie_resources_2_1_0 {
struct clk *iface_clk;
@@ -149,6 +174,11 @@ struct qcom_pcie_resources_2_7_0 {
struct clk *pipe_clk;
};
+struct qcom_pcie_resources_2_9_0 {
+ struct clk_bulk_data clks[7];
+ struct reset_control *rst[8];
+};
+
union qcom_pcie_resources {
struct qcom_pcie_resources_1_0_0 v1_0_0;
struct qcom_pcie_resources_2_1_0 v2_1_0;
@@ -156,6 +186,7 @@ union qcom_pcie_resources {
struct qcom_pcie_resources_2_3_3 v2_3_3;
struct qcom_pcie_resources_2_4_0 v2_4_0;
struct qcom_pcie_resources_2_7_0 v2_7_0;
+ struct qcom_pcie_resources_2_9_0 v2_9_0;
};
struct qcom_pcie;
@@ -1207,6 +1238,133 @@ static void qcom_pcie_post_deinit_2_7_0(struct
qcom_pcie *pcie)
clk_disable_unprepare(res->pipe_clk);
}
+static int qcom_pcie_get_resources_2_9_0(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_2_9_0 *res = &pcie->res.v2_9_0;
+ struct dw_pcie *pci = pcie->pci;
+ struct device *dev = pci->dev;
+ int ret, i;
+ const char *rst_names[] = { "pipe", "sleep", "sticky", "axi_m",
+ "axi_s", "ahb", "axi_m_sticky",
+ "axi_s_sticky" };
+
+ res->clks[0].id = "iface";
+ res->clks[1].id = "axi_m";
+ res->clks[2].id = "axi_s";
+ res->clks[3].id = "ahb";
+ res->clks[4].id = "aux";
+ res->clks[5].id = "axi_bridge";
+ res->clks[6].id = "rchng";
+
+ ret = devm_clk_bulk_get(dev, ARRAY_SIZE(res->clks), res->clks);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < ARRAY_SIZE(rst_names); i++) {
+ res->rst[i] = devm_reset_control_get(dev, rst_names[i]);
+ if (IS_ERR(res->rst[i]))
+ return PTR_ERR(res->rst[i]);
+ }
+
+ return 0;
+}
+
+static int qcom_pcie_init_2_9_0(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_2_9_0 *res = &pcie->res.v2_9_0;
+ struct dw_pcie *pci = pcie->pci;
+ struct device *dev = pci->dev;
+ int i, ret;
+ u32 val;
+
+ for (i = 0; i < ARRAY_SIZE(res->rst); i++) {
+ ret = reset_control_assert(res->rst[i]);
+ if (ret) {
[PATCH v3 1/3] crypto: permit users to specify numa node of acomp hardware
For a Linux server with NUMA, there are possibly multiple (de)compressors
which are either local or remote to some NUMA node. Some drivers will
automatically use the (de)compressor near the CPU calling acomp_alloc().
However, it is not necessarily correct because users who send acomp_req
could be from different NUMA node with the CPU which allocates acomp.
Just like kernel has kmalloc() and kmalloc_node(), here crypto can have
same support.
Cc: Seth Jennings
Cc: Dan Streetman
Cc: Vitaly Wool
Cc: Andrew Morton
Cc: Jonathan Cameron
Signed-off-by: Barry Song
---
-v3: use kzalloc_node() according to Herbert Xu's comment
crypto/acompress.c | 8
crypto/api.c | 24 +++-
crypto/internal.h | 23 +++
include/crypto/acompress.h | 18 ++
include/linux/crypto.h | 2 ++
5 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/crypto/acompress.c b/crypto/acompress.c
index 84a76723e851..c32c72048a1c 100644
--- a/crypto/acompress.c
+++ b/crypto/acompress.c
@@ -109,6 +109,14 @@ struct crypto_acomp *crypto_alloc_acomp(const char
*alg_name, u32 type,
}
EXPORT_SYMBOL_GPL(crypto_alloc_acomp);
+struct crypto_acomp *crypto_alloc_acomp_node(const char *alg_name, u32 type,
+ u32 mask, int node)
+{
+ return crypto_alloc_tfm_node(alg_name, &crypto_acomp_type, type, mask,
+ node);
+}
+EXPORT_SYMBOL_GPL(crypto_alloc_acomp_node);
+
struct acomp_req *acomp_request_alloc(struct crypto_acomp *acomp)
{
struct crypto_tfm *tfm = crypto_acomp_tfm(acomp);
diff --git a/crypto/api.c b/crypto/api.c
index edcf690800d4..5d8fe60b36c1 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -433,8 +433,9 @@ struct crypto_tfm *crypto_alloc_base(const char *alg_name,
u32 type, u32 mask)
}
EXPORT_SYMBOL_GPL(crypto_alloc_base);
-void *crypto_create_tfm(struct crypto_alg *alg,
- const struct crypto_type *frontend)
+void *crypto_create_tfm_node(struct crypto_alg *alg,
+ const struct crypto_type *frontend,
+ int node)
{
char *mem;
struct crypto_tfm *tfm = NULL;
@@ -445,12 +446,13 @@ void *crypto_create_tfm(struct crypto_alg *alg,
tfmsize = frontend->tfmsize;
total = tfmsize + sizeof(*tfm) + frontend->extsize(alg);
- mem = kzalloc(total, GFP_KERNEL);
+ mem = kzalloc_node(total, GFP_KERNEL, node);
if (mem == NULL)
goto out_err;
tfm = (struct crypto_tfm *)(mem + tfmsize);
tfm->__crt_alg = alg;
+ tfm->node = node;
err = frontend->init_tfm(tfm);
if (err)
@@ -472,7 +474,7 @@ void *crypto_create_tfm(struct crypto_alg *alg,
out:
return mem;
}
-EXPORT_SYMBOL_GPL(crypto_create_tfm);
+EXPORT_SYMBOL_GPL(crypto_create_tfm_node);
struct crypto_alg *crypto_find_alg(const char *alg_name,
const struct crypto_type *frontend,
@@ -490,11 +492,13 @@ struct crypto_alg *crypto_find_alg(const char *alg_name,
EXPORT_SYMBOL_GPL(crypto_find_alg);
/*
- * crypto_alloc_tfm - Locate algorithm and allocate transform
+ * crypto_alloc_tfm_node - Locate algorithm and allocate transform
* @alg_name: Name of algorithm
* @frontend: Frontend algorithm type
* @type: Type of algorithm
* @mask: Mask for type comparison
+ * @node: NUMA node in which users desire to put requests, if node is
+ * NUMA_NO_NODE, it means users have no special requirement.
*
* crypto_alloc_tfm() will first attempt to locate an already loaded
* algorithm. If that fails and the kernel supports dynamically loadable
@@ -509,8 +513,10 @@ EXPORT_SYMBOL_GPL(crypto_find_alg);
*
* In case of error the return value is an error pointer.
*/
-void *crypto_alloc_tfm(const char *alg_name,
- const struct crypto_type *frontend, u32 type, u32 mask)
+
+void *crypto_alloc_tfm_node(const char *alg_name,
+ const struct crypto_type *frontend, u32 type, u32 mask,
+ int node)
{
void *tfm;
int err;
@@ -524,7 +530,7 @@ void *crypto_alloc_tfm(const char *alg_name,
goto err;
}
- tfm = crypto_create_tfm(alg, frontend);
+ tfm = crypto_create_tfm_node(alg, frontend, node);
if (!IS_ERR(tfm))
return tfm;
@@ -542,7 +548,7 @@ void *crypto_alloc_tfm(const char *alg_name,
return ERR_PTR(err);
}
-EXPORT_SYMBOL_GPL(crypto_alloc_tfm);
+EXPORT_SYMBOL_GPL(crypto_alloc_tfm_node);
/*
* crypto_destroy_tfm - Free crypto transform
diff --git a/crypto/internal.h b/crypto/internal.h
index ff06a3bd1ca1..1b92a5a61852 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -68,13 +68,28 @@ void crypto_remove_final(struct list_head *list);
void crypto_shoot_alg(str
[PATCH v3 0/3] crypto: allow users to specify acomp hardware from a desired NUMA node
For a typical Linux server, probably there are multiple ZIP modules. For example, numa node0 has a compressor, numa node2 has a same module. Some drivers are automatically using the module near the CPU calling acomp_alloc. But it isn't necessarily correct. Just like memory allocation API like kmalloc and kmalloc_node. Similar optimization may be done for crypto. -v3: move to use kzalloc_node according to Herbert's comment -v2: cleanup according to Jonathan Cameron's comment Barry Song (3): crypto: permit users to specify numa node of acomp hardware crypto: hisilicon/zip - permit users to specify NUMA node mm/zswap: allocate acomp on the numa node committing acomp_req[1] [1] This patch is againest a zswap patch which has not been merged yet: "[PATCH v3] mm/zswap: move to use crypto_acomp API for hardware acceleration" https://lkml.org/lkml/2020/6/26/95 crypto/acompress.c| 8 crypto/api.c | 24 ++- crypto/internal.h | 23 ++ drivers/crypto/hisilicon/zip/zip.h| 2 +- drivers/crypto/hisilicon/zip/zip_crypto.c | 6 +++--- drivers/crypto/hisilicon/zip/zip_main.c | 5 +++-- include/crypto/acompress.h| 18 + include/linux/crypto.h| 2 ++ mm/zswap.c| 2 +- 9 files changed, 70 insertions(+), 20 deletions(-) -- 2.27.0
[PATCH v3 2/3] crypto: hisilicon/zip - permit users to specify NUMA node
If users don't specify NUMA node, the driver will use the ZIP module near
the CPU allocating acomp. Otherwise, it uses the ZIP module according to
the requirement of users.
Cc: Zhou Wang
Signed-off-by: Barry Song
---
drivers/crypto/hisilicon/zip/zip.h| 2 +-
drivers/crypto/hisilicon/zip/zip_crypto.c | 6 +++---
drivers/crypto/hisilicon/zip/zip_main.c | 5 +++--
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip.h
b/drivers/crypto/hisilicon/zip/zip.h
index f3ed4c0e5493..4484be13812b 100644
--- a/drivers/crypto/hisilicon/zip/zip.h
+++ b/drivers/crypto/hisilicon/zip/zip.h
@@ -76,7 +76,7 @@ struct hisi_zip_sqe {
u32 rsvd1[4];
};
-int zip_create_qps(struct hisi_qp **qps, int ctx_num);
+int zip_create_qps(struct hisi_qp **qps, int ctx_num, int node);
int hisi_zip_register_to_crypto(void);
void hisi_zip_unregister_from_crypto(void);
#endif
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c
b/drivers/crypto/hisilicon/zip/zip_crypto.c
index c73707c2e539..01fd6a78111d 100644
--- a/drivers/crypto/hisilicon/zip/zip_crypto.c
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -158,13 +158,13 @@ static void hisi_zip_release_qp(struct hisi_zip_qp_ctx
*ctx)
hisi_qm_release_qp(ctx->qp);
}
-static int hisi_zip_ctx_init(struct hisi_zip_ctx *hisi_zip_ctx, u8 req_type)
+static int hisi_zip_ctx_init(struct hisi_zip_ctx *hisi_zip_ctx, u8 req_type,
int node)
{
struct hisi_qp *qps[HZIP_CTX_Q_NUM] = { NULL };
struct hisi_zip *hisi_zip;
int ret, i, j;
- ret = zip_create_qps(qps, HZIP_CTX_Q_NUM);
+ ret = zip_create_qps(qps, HZIP_CTX_Q_NUM, node);
if (ret) {
pr_err("Can not create zip qps!\n");
return -ENODEV;
@@ -379,7 +379,7 @@ static int hisi_zip_acomp_init(struct crypto_acomp *tfm)
struct hisi_zip_ctx *ctx = crypto_tfm_ctx(&tfm->base);
int ret;
- ret = hisi_zip_ctx_init(ctx, COMP_NAME_TO_TYPE(alg_name));
+ ret = hisi_zip_ctx_init(ctx, COMP_NAME_TO_TYPE(alg_name),
tfm->base.node);
if (ret)
return ret;
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c
b/drivers/crypto/hisilicon/zip/zip_main.c
index 2229a21ae7c8..e2845b2c963d 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -234,9 +234,10 @@ static const struct pci_device_id hisi_zip_dev_ids[] = {
};
MODULE_DEVICE_TABLE(pci, hisi_zip_dev_ids);
-int zip_create_qps(struct hisi_qp **qps, int qp_num)
+int zip_create_qps(struct hisi_qp **qps, int qp_num, int node)
{
- int node = cpu_to_node(smp_processor_id());
+ if (node == NUMA_NO_NODE)
+ node = cpu_to_node(smp_processor_id());
return hisi_qm_alloc_qps_node(&zip_devices, qp_num, 0, node, qps);
}
--
2.27.0
[PATCH v3 3/3] mm/zswap: allocate acomp on the numa node committing acomp_req
zswap is allocating acomp on one different cpu with those cpus which will
eventually committing acomp_req. this patch specifies the numa node to
help compression/decompression done by local (de)compressors hardware.
Cc: Seth Jennings
Cc: Dan Streetman
Cc: Vitaly Wool
Cc: Herbert Xu
Cc: David S. Miller
Signed-off-by: Barry Song
---
this patch depends on a zswap patch which has not been merged yet:
"[PATCH v3] mm/zswap: move to use crypto_acomp API for hardware
acceleration"
https://lkml.org/lkml/2020/6/26/95
mm/zswap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index d170ef06c693..3c2acf51f09e 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -437,7 +437,7 @@ static int zswap_cpu_comp_prepare(unsigned int cpu, struct
hlist_node *node)
if (!acomp_ctx)
return -ENOMEM;
- acomp = crypto_alloc_acomp(pool->tfm_name, 0, 0);
+ acomp = crypto_alloc_acomp_node(pool->tfm_name, 0, 0, cpu_to_node(cpu));
if (IS_ERR(acomp)) {
pr_err("could not alloc crypto acomp %s : %ld\n",
pool->tfm_name, PTR_ERR(acomp));
--
2.27.0
[PATCH] tty: serial: meson_uart: Init port lock early
The meson UART driver triggers a lockdep splat at boot time, due
to the new expectation that the driver has to initialize the
per-port spinlock itself.
It remains unclear why a double initialization of the port
spinlock is a desirable outcome, but in the meantime let's
fix the splat.
Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for
console")
Cc: Andy Shevchenko
Cc: Greg Kroah-Hartman
Signed-off-by: Marc Zyngier
---
drivers/tty/serial/meson_uart.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
index d2c08b760f83..386e39c90628 100644
--- a/drivers/tty/serial/meson_uart.c
+++ b/drivers/tty/serial/meson_uart.c
@@ -759,6 +759,9 @@ static int meson_uart_probe(struct platform_device *pdev)
if (ret)
return ret;
+ /* Init the spinlock early in case this is the console */
+ spin_lock_init(&port->lock);
+
port->iotype = UPIO_MEM;
port->mapbase = res_mem->start;
port->mapsize = resource_size(res_mem);
--
2.26.2
drivers/atm/iphase.c:149:16: sparse: sparse: cast removes address space '__iomem' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 35e884f89df4c48566d745dc5a97a0d058d04263 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 2 weeks ago config: i386-randconfig-s001-20200705 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-3-gfa153962-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/atm/iphase.c:149:16: sparse: sparse: cast removes address space >> '__iomem' of expression drivers/atm/iphase.c:153:11: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:165:56: sparse: sparse: invalid assignment: |= drivers/atm/iphase.c:165:56: sparse:left side has type restricted __be16 drivers/atm/iphase.c:165:56: sparse:right side has type int drivers/atm/iphase.c:203:14: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:220:16: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:228:19: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:241:29: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:242:29: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:279:20: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:384:14: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:444:17: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:446:20: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:529:19: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:583:16: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:2976:11: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:3050:23: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __be16 [usertype] protocol @@ got int vci @@ drivers/atm/iphase.c:3050:23: sparse: expected restricted __be16 [usertype] protocol drivers/atm/iphase.c:3050:23: sparse: got int vci drivers/atm/iphase.c:668:17: sparse: sparse: restricted __be16 degrades to integer drivers/atm/iphase.c:1185:23: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __be16 [usertype] protocol @@ got int [assigned] desc @@ drivers/atm/iphase.c:1185:23: sparse: expected restricted __be16 [usertype] protocol drivers/atm/iphase.c:1185:23: sparse: got int [assigned] desc drivers/atm/iphase.c:1297:12: sparse: sparse: incorrect type in assignment (different base types) @@ expected int desc @@ got restricted __be16 [usertype] protocol @@ drivers/atm/iphase.c:1297:12: sparse: expected int desc drivers/atm/iphase.c:1297:12: sparse: got restricted __be16 [usertype] protocol drivers/atm/iphase.c:1506:24: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:1553:24: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:1565:20: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:1582:25: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:1735:34: sparse: sparse: invalid assignment: |= drivers/atm/iphase.c:1735:34: sparse:left side has type restricted __be16 drivers/atm/iphase.c:1735:34: sparse:right side has type int drivers/atm/iphase.c:1812:15: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:1813:16: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:1966:24: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:2022:22: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:2049:22: sparse: sparse: cast removes address space '__iomem' of expression drivers/atm/iphase.c:2112:9: sparse: sparse: cast removes address space '__iomem' of expre
Re: [PATCH] kvm: x86: rewrite kvm_spec_ctrl_valid_bits
On Thu, 2020-07-02 at 11:16 -0700, Sean Christopherson wrote:
> On Thu, Jul 02, 2020 at 08:44:55PM +0300, Maxim Levitsky wrote:
> > There are few cases when this function was creating a bogus #GP condition,
> > for example case when and AMD host supports STIBP but doesn't support SSBD.
> >
> > Follow the rules for AMD and Intel strictly instead.
>
> Can you elaborate on the conditions that are problematic, e.g. what does
> the guest expect to exist that KVM isn't providing?
Hi Sean Christopherson!
Sorry that I haven't explained the issue here.
I explained it in bugzilla I opened in details and forgot to explain it
in the commit message.
https://bugzilla.redhat.com/show_bug.cgi?id=1853447
The issue is that on my cpu (3970X), it does not support IBRS,
but it does support STIBP, and thus guest gets the STIBP cpuid bits enabled
(both the amd one and KVM also enables the intel's cpuid bit for this feature).
Then, when guest actually starts to use STIBP, it gets #GP because both of
these conditions
potentially don't allow STIBP bit to be set when IBRS is not supported:
if (!guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL) &&
!guest_cpuid_has(vcpu, X86_FEATURE_AMD_IBRS))
bits &= ~(SPEC_CTRL_IBRS | SPEC_CTRL_STIBP);
if (!boot_cpu_has(X86_FEATURE_SPEC_CTRL) &&
!boot_cpu_has(X86_FEATURE_AMD_IBRS))
bits &= ~(SPEC_CTRL_IBRS | SPEC_CTRL_STIBP);
Most likely it fails on the second condition, since X86_FEATURE_SPEC_CTRL
is enabled in the guest because host does support IBPB which
X86_FEATURE_SPEC_CTRL also cover.
But the host doesn't support X86_FEATURE_SPEC_CTRL and it doesn't support
X86_FEATURE_AMD_IBRS
thus second condition clears the SPEC_CTRL_STIBP wrongly.
Now in addition to that, I long ago had known that win10 guests on my machine
started to
crash when qemu added ability to pass through X86_FEATURE_AMD_IBRS.
I haven't paid much attention to that other than bisecting this and adding
'-amd-stibp' to my cpu flags.
I did notice that I am not the only one to have that issue, for example
https://www.reddit.com/r/VFIO/comments/gf53o8/upgrading_to_qemu_5_broke_my_setup_windows_bsods/
https://forum.level1techs.com/t/amd-fix-for-host-passthrough-on-qemu-5-0-0-kernel-5-6/157710
Now after I debugged this issue in Linux, it occured to me that this might be
the same issue as in Windows,
and indeed it is. The only difference is that Windows doesn't start to play
with STIBP when Intel
specific cpuid bit is set on AMD machine (which KVM sets for long time) but
starts to enable it when AMD specific
bit is set, that is X86_FEATURE_AMD_IBRS, the bit that qemu recently started to
set and it gets the same #GP and crashes.
>From findings on my machine, if we cross-reference this with the above posts,
>I can assume that many Ryzens have this configuration
of no support for IBRS but support STIBP.
In fact I don't see the kernel use IBRS much (it seem only used around firmware
calls or so), so it makes sense
that AMD chose to not enable it.
For the fix itself,
I can fix this by only changing the above condition, but then I read the AMD
whitepaper on
this and they mention that bits in IA32_SPEC_CTRL don't #GP even if not
supported,
and to implement this correctly would be too complicated with current logic,
thus I rewrote the logic to be as simple as possible and as close to the
official docs as possible
as well.
>
> > AMD #GP rules for IA32_SPEC_CTRL can be found here:
> > https://bugzilla.kernel.org/show_bug.cgi?id=199889
> >
> > Fixes: 6441fa6178f5 ("KVM: x86: avoid incorrect writes to host
> > MSR_IA32_SPEC_CTRL")
> >
> > Signed-off-by: Maxim Levitsky
> > ---
> > arch/x86/kvm/x86.c | 57 ++
> > 1 file changed, 42 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 00c88c2f34e4..a6bed4670b7f 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -10670,27 +10670,54 @@ bool kvm_arch_no_poll(struct kvm_vcpu *vcpu)
> > }
> > EXPORT_SYMBOL_GPL(kvm_arch_no_poll);
> >
> > -u64 kvm_spec_ctrl_valid_bits(struct kvm_vcpu *vcpu)
> > +
> > +static u64 kvm_spec_ctrl_valid_bits_host(void)
> > +{
> > + uint64_t bits = 0;
> > +
> > + if (boot_cpu_has(X86_FEATURE_SPEC_CTRL))
> > + bits |= SPEC_CTRL_IBRS;
> > + if (boot_cpu_has(X86_FEATURE_INTEL_STIBP))
> > + bits |= SPEC_CTRL_STIBP;
> > + if (boot_cpu_has(X86_FEATURE_SPEC_CTRL_SSBD))
> > + bits |= SPEC_CTRL_SSBD;
> > +
> > + if (boot_cpu_has(X86_FEATURE_AMD_IBRS) ||
> > boot_cpu_has(X86_FEATURE_AMD_STIBP))
> > + bits |= SPEC_CTRL_STIBP | SPEC_CTRL_IBRS;
> > +
> > + if (boot_cpu_has(X86_FEATURE_AMD_SSBD))
> > + bits |= SPEC_CTRL_STIBP | SPEC_CTRL_IBRS | SPEC_CTRL_SSBD;
> > +
> > + return bits;
> > +}
>
> Rather than compute the mask every time, it can be computed once on module
> load and stashed in a global.
[v2 PATCH] drm/panel: auo,b116xw03: fix flash backlight when power on
Delay the backlight on to make sure the video stable.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/panel/panel-simple.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 3ad828eaefe1..61781ffa7840 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -724,6 +724,7 @@ static const struct drm_display_mode auo_b116xw03_mode = {
.vsync_end = 768 + 10 + 12,
.vtotal = 768 + 10 + 12 + 6,
.vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
};
static const struct panel_desc auo_b116xw03 = {
@@ -734,6 +735,12 @@ static const struct panel_desc auo_b116xw03 = {
.width = 256,
.height = 144,
},
+ .delay = {
+ .enable = 400,
+ },
+ .bus_flags = DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_eDP,
};
static const struct drm_display_mode auo_b133xtn01_mode = {
--
2.25.1
Re: [PATCH] drm/panel: auo,b116xw03: fix flash backlight when power on
On Sun, 2020-07-05 at 10:06 +0200, Sam Ravnborg wrote:
> Hi Jitao.
>
> On Fri, Jul 03, 2020 at 05:51:13PM +0800, Jitao Shi wrote:
> > Delay the backlight on to make sure the video stable.
> >
> > Signed-off-by: Jitao Shi
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 3ad828eaefe1..18f34f286d3d 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -734,6 +734,9 @@ static const struct panel_desc auo_b116xw03 = {
> > .width = 256,
> > .height = 144,
> > },
> > + .delay = {
> > + .enable = 400,
> > + },
> > };
> >
> > static const struct drm_display_mode auo_b133xtn01_mode = {
>
> Patch did not apply to drm-misc-next.
> Please update - and when you do so also add:
> .bus_flags
> .bus_format
> .connector_type
>
> So we have this panel properly defined.
>
> Sam
Thanks for your review.
I'll add those next version.
Jitao
Re: [PATCH 3/3] selftests: add readfile(2) selftests
On 7/5/20 9:34 AM, Greg Kroah-Hartman wrote: > On Sun, Jul 05, 2020 at 03:41:48AM +0200, Heinrich Schuchardt wrote: >> On 7/4/20 4:02 PM, Greg Kroah-Hartman wrote: >>> Test the functionality of readfile(2) in various ways. >> >> Hello Greg, >> >> I expect readfile() to generate fanotify events FAN_OPEN_PERM, FAN_OPEN, >> FAN_ACCESS_PERM, FAN_ACCESS, FAN_CLOSE_NOWRITE in this sequence. > > Yes, it should, I don't think I do anything unique here when it comes to > vfs accesses that would go around those events. > >> Looking at patch 1/3 you took care of notifications. Would this deserve >> testing here? > > Possibly, do we have other in-tree tests of syscalls that validate those > events properly being created? There is an inotify test in tools/testing/selftests/cgroup/test_freezer.c There is no fanotify test in tree test. An fanotify test will require running with CAP_SYS_ADMIN. The kselftest documentation does not describe that tests should be run as root. So it may be preferable to test that the inotify events IN_OPEN, IN_ACCESS, IN_CLOSE_NOWRITE are created for readfile(). Example coding is included in the inotify.7 and fanotify.7 manpages. Best regards Heinrich
Re: [PATCH V3 0/3] ARM: imx: move cpu code to drivers/soc/imx
On 7/3/2020 3:25 PM, Peng Fan wrote: > Sorry to break LS1021A. But I wonder why i.MX code would affect LS? > imx_soc_device_init() was modified to be called for all SoCs under ARCH_MXC. multi_v7_defconfig, which is used for LS1021A, selects ARCH_MXC. Previously imx_soc_device_init() was called only for i.MX (and Vybrid) SoCs. Horia
Re: [PATCH] MIPS: Do not use smp_processor_id() in preemptible code
On Fri, Jul 03, 2020 at 12:11:58PM +0800, Xingxing Su wrote: > Use preempt_disable() to fix the following bug under CONFIG_DEBUG_PREEMPT. > > [ 21.915305] BUG: using smp_processor_id() in preemptible [] code: > qemu-system-mip/1056 > [ 21.923996] caller is do_ri+0x1d4/0x690 > [ 21.927921] CPU: 0 PID: 1056 Comm: qemu-system-mip Not tainted 5.8.0-rc2 #3 > [ 21.934913] Stack : 0001 8137 8071cd60 > a80f926d5ac95694 > [ 21.942984] a80f926d5ac95694 9807f0043c88 > 80f2fe40 > [ 21.951054] 0001 > > [ 21.959123] 802d60cc 9807f0043dd8 81f4b1e8 > 81f6 > [ 21.967192] 81f6 80fe > > [ 21.975261] f500cce1 0001 0002 > > [ 21.983331] 80fe1a40 0006 8077f940 > > [ 21.991401] 8146 9807f004 9807f0043c80 > 00fffba8cf20 > [ 21.999471] 8071cd60 > > [ 22.007541] 80212ab4 > a80f926d5ac95694 > [ 22.015610] ... > [ 22.018086] Call Trace: > [ 22.020562] [] show_stack+0xa4/0x138 > [ 22.025732] [] dump_stack+0xf0/0x150 > [ 22.030903] [] check_preemption_disabled+0xf4/0x100 > [ 22.037375] [] do_ri+0x1d4/0x690 > [ 22.042198] [] handle_ri_int+0x44/0x5c > [ 24.359386] BUG: using smp_processor_id() in preemptible [] code: > qemu-system-mip/1072 > [ 24.368204] caller is do_ri+0x1a8/0x690 > [ 24.372169] CPU: 4 PID: 1072 Comm: qemu-system-mip Not tainted 5.8.0-rc2 #3 > [ 24.379170] Stack : 0001 8137 8071cd60 > a80f926d5ac95694 > [ 24.387246] a80f926d5ac95694 98001007ef06bc88 > 80f2fe40 > [ 24.395318] 0001 > > [ 24.403389] 802d60cc 98001007ef06bdd8 81f4b818 > 81f6 > [ 24.411461] 81f6 80fe > > [ 24.419533] f500cce1 0001 0002 > > [ 24.427603] 80fe 0006 8077f940 > 0020 > [ 24.435673] 81460020 98001007ef068000 98001007ef06bc80 > 00fff370 > [ 24.443745] 8071cd60 > > [ 24.451816] 80212ab4 > a80f926d5ac95694 > [ 24.459887] ... > [ 24.462367] Call Trace: > [ 24.464846] [] show_stack+0xa4/0x138 > [ 24.470029] [] dump_stack+0xf0/0x150 > [ 24.475208] [] check_preemption_disabled+0xf4/0x100 > [ 24.481682] [] do_ri+0x1a8/0x690 > [ 24.486509] [] handle_ri_int+0x44/0x5c > > Signed-off-by: Xingxing Su > --- > arch/mips/kernel/traps.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) applied to mips-fixes. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
memory leak in qdisc_create_dflt
Hello, syzbot found the following crash on: HEAD commit:9ebcfadb Linux 5.8-rc3 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1577525b10 kernel config: https://syzkaller.appspot.com/x/.config?x=5ee23b9caef4e07a dashboard link: https://syzkaller.appspot.com/bug?extid=d411cff6ab29cc2c311b compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10e579e310 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1007c45b10 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d411cff6ab29cc2c3...@syzkaller.appspotmail.com BUG: memory leak unreferenced object 0x888115aa8c00 (size 512): comm "syz-executor530", pid 6646, jiffies 4294943517 (age 13.870s) hex dump (first 32 bytes): a0 0c be 82 ff ff ff ff f0 0b be 82 ff ff ff ff 04 00 00 00 e8 03 00 00 40 c6 72 84 ff ff ff ff @.r. backtrace: [] kmalloc_node include/linux/slab.h:578 [inline] [ ] kzalloc_node include/linux/slab.h:680 [inline] [ ] qdisc_alloc+0x45/0x260 net/sched/sch_generic.c:818 [<2852d256>] qdisc_create_dflt+0x3d/0x170 net/sched/sch_generic.c:893 [<2108f663>] atm_tc_init+0x96/0x150 net/sched/sch_atm.c:551 [<0988e5f0>] qdisc_create+0x1ae/0x670 net/sched/sch_api.c:1246 [ ] tc_modify_qdisc+0x198/0xb10 net/sched/sch_api.c:1662 [ ] rtnetlink_rcv_msg+0x17e/0x460 net/core/rtnetlink.c:5460 [ ] netlink_rcv_skb+0x5b/0x180 net/netlink/af_netlink.c:2469 [<69fa5fbe>] netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] [<69fa5fbe>] netlink_unicast+0x2b6/0x3c0 net/netlink/af_netlink.c:1329 [<49c303c5>] netlink_sendmsg+0x2ba/0x570 net/netlink/af_netlink.c:1918 [<17755dda>] sock_sendmsg_nosec net/socket.c:652 [inline] [<17755dda>] sock_sendmsg+0x4c/0x60 net/socket.c:672 [<294b696a>] sys_sendmsg+0x118/0x2f0 net/socket.c:2352 [ ] ___sys_sendmsg+0x81/0xc0 net/socket.c:2406 [ ] __sys_sendmmsg+0xda/0x230 net/socket.c:2496 [<82fdecc3>] __do_sys_sendmmsg net/socket.c:2525 [inline] [<82fdecc3>] __se_sys_sendmmsg net/socket.c:2522 [inline] [<82fdecc3>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2522 [<9da3552a>] do_syscall_64+0x4c/0xe0 arch/x86/entry/common.c:359 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x888115aa8a00 (size 512): comm "syz-executor530", pid 6647, jiffies 4294944100 (age 8.040s) hex dump (first 32 bytes): a0 0c be 82 ff ff ff ff f0 0b be 82 ff ff ff ff 04 00 00 00 e8 03 00 00 40 c6 72 84 ff ff ff ff @.r. backtrace: [ ] kmalloc_node include/linux/slab.h:578 [inline] [ ] kzalloc_node include/linux/slab.h:680 [inline] [ ] qdisc_alloc+0x45/0x260 net/sched/sch_generic.c:818 [<2852d256>] qdisc_create_dflt+0x3d/0x170 net/sched/sch_generic.c:893 [<2108f663>] atm_tc_init+0x96/0x150 net/sched/sch_atm.c:551 [<0988e5f0>] qdisc_create+0x1ae/0x670 net/sched/sch_api.c:1246 [ ] tc_modify_qdisc+0x198/0xb10 net/sched/sch_api.c:1662 [ ] rtnetlink_rcv_msg+0x17e/0x460 net/core/rtnetlink.c:5460 [ ] netlink_rcv_skb+0x5b/0x180 net/netlink/af_netlink.c:2469 [<69fa5fbe>] netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] [<69fa5fbe>] netlink_unicast+0x2b6/0x3c0 net/netlink/af_netlink.c:1329 [<49c303c5>] netlink_sendmsg+0x2ba/0x570 net/netlink/af_netlink.c:1918 [<17755dda>] sock_sendmsg_nosec net/socket.c:652 [inline] [<17755dda>] sock_sendmsg+0x4c/0x60 net/socket.c:672 [<294b696a>] sys_sendmsg+0x118/0x2f0 net/socket.c:2352 [ ] ___sys_sendmsg+0x81/0xc0 net/socket.c:2406 [ ] __sys_sendmmsg+0xda/0x230 net/socket.c:2496 [<82fdecc3>] __do_sys_sendmmsg net/socket.c:2525 [inline] [<82fdecc3>] __se_sys_sendmmsg net/socket.c:2522 [inline] [<82fdecc3>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2522 [<9da3552a>] do_syscall_64+0x4c/0xe0 arch/x86/entry/common.c:359 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
[PATCH net-next] net: phy: add a Kconfig option for mdio_devres
From: Bartosz Golaszewski
If phylib is built as a module and CONFIG_MDIO_DEVICE is 'y', the
mdio_device and mdio_bus code will be in the phylib module, not in the
kernel image. Meanwhile we build mdio_devres depending on the
CONFIG_MDIO_DEVICE symbol, so if it's 'y', it will go into the kernel
and we'll hit the following linker error:
ld: drivers/net/phy/mdio_devres.o: in function `devm_mdiobus_alloc_size':
>> drivers/net/phy/mdio_devres.c:38: undefined reference to `mdiobus_alloc_size'
ld: drivers/net/phy/mdio_devres.o: in function `devm_mdiobus_free':
>> drivers/net/phy/mdio_devres.c:16: undefined reference to `mdiobus_free'
ld: drivers/net/phy/mdio_devres.o: in function `__devm_mdiobus_register':
>> drivers/net/phy/mdio_devres.c:87: undefined reference to `__mdiobus_register'
ld: drivers/net/phy/mdio_devres.o: in function `devm_mdiobus_unregister':
>> drivers/net/phy/mdio_devres.c:53: undefined reference to `mdiobus_unregister'
ld: drivers/net/phy/mdio_devres.o: in function `devm_of_mdiobus_register':
>> drivers/net/phy/mdio_devres.c:120: undefined reference to
>> `of_mdiobus_register'
Add a hidden Kconfig option for MDIO_DEVRES which will be currently
selected by CONFIG_PHYLIB as there are no non-phylib users of these
helpers.
Reported-by: kernel test robot
Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()")
Signed-off-by: Bartosz Golaszewski
---
drivers/net/phy/Kconfig | 4
drivers/net/phy/Makefile | 3 +--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index e351d65533aa..7ffa8a4529a8 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -21,6 +21,9 @@ config MDIO_BUS
if MDIO_BUS
+config MDIO_DEVRES
+ tristate
+
config MDIO_ASPEED
tristate "ASPEED MDIO bus controller"
depends on ARCH_ASPEED || COMPILE_TEST
@@ -252,6 +255,7 @@ menuconfig PHYLIB
tristate "PHY Device support and infrastructure"
depends on NETDEVICES
select MDIO_DEVICE
+ select MDIO_DEVRES
help
Ethernet controllers are usually attached to PHY
devices. This option provides infrastructure for
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index c9a9adf194d5..d84bab489a53 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -4,7 +4,6 @@
libphy-y := phy.o phy-c45.o phy-core.o phy_device.o \
linkmode.o
mdio-bus-y += mdio_bus.o mdio_device.o
-mdio-devres-y += mdio_devres.o
ifdef CONFIG_MDIO_DEVICE
obj-y += mdio-boardinfo.o
@@ -18,7 +17,7 @@ libphy-y += $(mdio-bus-y)
else
obj-$(CONFIG_MDIO_DEVICE) += mdio-bus.o
endif
-obj-$(CONFIG_MDIO_DEVICE) += mdio-devres.o
+obj-$(CONFIG_MDIO_DEVRES) += mdio_devres.o
libphy-$(CONFIG_SWPHY) += swphy.o
libphy-$(CONFIG_LED_TRIGGER_PHY) += phy_led_triggers.o
--
2.26.1
Re: [PATCH] tty: serial: meson_uart: Init port lock early
On Sun, Jul 5, 2020 at 12:32 PM Marc Zyngier wrote:
>
> The meson UART driver triggers a lockdep splat at boot time, due
> to the new expectation that the driver has to initialize the
> per-port spinlock itself.
>
> It remains unclear why a double initialization of the port
> spinlock is a desirable outcome, but in the meantime let's
> fix the splat.
>
Thanks!
Can you test patch from [1] if it helps and doesn't break anything in your case?
[1]:
https://lore.kernel.org/linux-serial/20200217114016.49856-1-andriy.shevche...@linux.intel.com/T/#m9255e2a7474b160e66c7060fca5323ca3df49cfd
> Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for
> console")
> Cc: Andy Shevchenko
> Cc: Greg Kroah-Hartman
> Signed-off-by: Marc Zyngier
> ---
> drivers/tty/serial/meson_uart.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
> index d2c08b760f83..386e39c90628 100644
> --- a/drivers/tty/serial/meson_uart.c
> +++ b/drivers/tty/serial/meson_uart.c
> @@ -759,6 +759,9 @@ static int meson_uart_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + /* Init the spinlock early in case this is the console */
> + spin_lock_init(&port->lock);
> +
> port->iotype = UPIO_MEM;
> port->mapbase = res_mem->start;
> port->mapsize = resource_size(res_mem);
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2] clk: rockchip: use separate compatibles for rk3288w-cru
On Fri, 3 Jul 2020 17:49:48 +0200, Heiko Stuebner wrote:
> Commit 1627f683636d ("clk: rockchip: Handle clock tree for rk3288w variant")
> added the check for rk3288w-specific clock-tree changes but in turn would
> require a double-compatible due to re-using the main rockchip,rk3288-cru
> compatible as entry point.
>
> The binding change actually describes the compatibles as one or the other
> so adapt the code accordingly and add a real second entry-point for the
> clock controller.
Applied, thanks!
[1/1] clk: rockchip: use separate compatibles for rk3288w-cru
commit: 0a7f99aad259d223ce69c03e792c7e2bfcf8c2c6
Best regards,
--
Heiko Stuebner
Re: [PATCH] tty: serial: meson_uart: Init port lock early
On 2020-07-05 11:07, Andy Shevchenko wrote: On Sun, Jul 5, 2020 at 12:32 PM Marc Zyngier wrote: The meson UART driver triggers a lockdep splat at boot time, due to the new expectation that the driver has to initialize the per-port spinlock itself. It remains unclear why a double initialization of the port spinlock is a desirable outcome, but in the meantime let's fix the splat. Thanks! Can you test patch from [1] if it helps and doesn't break anything in your case? [1]: https://lore.kernel.org/linux-serial/20200217114016.49856-1-andriy.shevche...@linux.intel.com/T/#m9255e2a7474b160e66c7060fca5323ca3df49cfd On its own, this patch doesn't seem to cure the issue (and it adds a compile-time warning due to unused flags). Or did you mean to test it in complement of my patch? M. -- Jazz is not dead. It just smells funny...
RE: [PATCH 1/2] habanalabs: block WREG_BULK packet on PDMA
On Tue, Jul 5, 2020 at 00:30 AM, Oded Gabbay wrote: > WREG_BULK is a special packet that has a variable length. Therefore, we can't > parse it when validating CBs that go to the PCI DMA queue. In case the user > needs to use it, it can put multiple WREG32 packets instead. > > Signed-off-by: Oded Gabbay Reviewed-by: Omer Shpigelman
Re: [PATCH] Replace HTTP links with HTTPS ones: CAN network drivers
On 7/5/20 9:56 AM, Alexander A. Klimov wrote: > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > > Deterministic algorithm: > For each file: > If not .svg: > For each line: > If doesn't contain `\bxmlns\b`: > For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: > If both the HTTP and HTTPS versions > return 200 OK and serve the same content: > Replace HTTP with HTTPS. > > Signed-off-by: Alexander A. Klimov Acked-by: Marc Kleine-Budde regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
RE: [PATCH 2/2] habanalabs: set clock gating per engine
On Tue, Jul 5, 2020 at 00:30 AM, Oded Gabbay wrote: > For debugging purposes, we need to allow the root user better control of the > clock gating feature of the DMA and compute engines. Therefore, change > the clock gating debugfs interface to be bitmask instead of true/false. > Each bit represents a different engine, according to gaudi_engine_id enum. > > See debugfs documentation for more details. > > Signed-off-by: Oded Gabbay Reviewed-by: Omer Shpigelman
[GIT PULL] MIPS fixes for v5.8
Hi Linus, please pull the few MIPS fixes. Thomas. The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407: Linux 5.8-rc1 (2020-06-14 12:45:04 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/ tags/mips_fixes_5.8_1 for you to fetch changes up to 5868347a192afb99b189d72946ab6a321b6115ac: MIPS: Do not use smp_processor_id() in preemptible code (2020-07-05 11:43:52 +0200) A few MIPS fixes: - fix for missing hazard barrier - DT fix for ingenic - DT fix of GPHY names for lantiq - fix usage of smp_processor_id() while preemption is enabled Hauke Mehrtens (1): MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen João H. Spies (1): MIPS: ingenic: gcw0: Fix HP detection GPIO. Martin Blumenstingl (1): MIPS: lantiq: xway: sysctrl: fix the GPHY clock alias names Xingxing Su (1): MIPS: Do not use smp_processor_id() in preemptible code arch/mips/boot/dts/ingenic/gcw0.dts | 2 +- arch/mips/kernel/traps.c| 9 ++--- arch/mips/lantiq/xway/sysctrl.c | 8 3 files changed, 11 insertions(+), 8 deletions(-) -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v3 3/4] thermal: core: genetlink support for events/cmd/sampling
On 05/07/2020 08:03, Zhang Rui wrote:
> On Fri, 2020-07-03 at 10:53 +0200, Daniel Lezcano wrote:
>> Initially the thermal framework had a very simple notification
>> mechanism to send generic netlink messages to the userspace.
>>
>> The notification function was never called from anywhere and the
>> corresponding dead code was removed. It was probably a first attempt
>> to introduce the netlink notification.
>>
>> At LPC2018, the presentation "Linux thermal: User kernel interface",
>> proposed to create the notifications to the userspace via a kfifo.
>>
>> The advantage of the kfifo is the performance. It is usually used
>> from
>> a 1:1 communication channel where a driver captures data and sends it
>> as fast as possible to a userspace process.
>>
>> The drawback is that only one process uses the notification channel
>> exclusively, thus no other process is allowed to use the channel to
>> get temperature or notifications.
>>
>> This patch defines a generic netlink API to discover the current
>> thermal setup and adds event notifications as well as temperature
>> sampling. As any genetlink protocol, it can evolve and the versioning
>> allows to keep the backward compatibility.
>>
>> In order to prevent the user from getting flooded with data on a
>> single channel, there are two multicast channels, one for the
>> temperature sampling when the thermal zone is updated and another one
>> for the events, so the user can get the events only without the
>> thermal zone temperature sampling.
>>
>> Also, a list of commands to discover the thermal setup is added and
>> can be extended when needed.
>>
>> Signed-off-by: Daniel Lezcano
[ ... ]
>> +static int thermal_genl_event_cdev_update(struct param *p)
>> +{
>> +if (nla_put_u32(p->msg, THERMAL_GENL_ATTR_CDEV_ID,
>> +p->cdev_id) ||
>> +nla_put_u32(p->msg, THERMAL_GENL_ATTR_CDEV_CUR_STATE,
>> +p->cdev_state) ||
>> +nla_put_u32(p->msg, THERMAL_GENL_ATTR_CDEV_MAX_STATE,
>> +p->cdev_max_state))
>> +return -EMSGSIZE;
>> +
>> +return 0;
>> +}
>
>> +int thermal_notify_cdev_update(int cdev_id, int cdev_state)
>>> +{
>>> + struct param p = { .cdev_id = cdev_id, .cdev_state = cdev_state
>>> };
>>
>
> .cdev_max_state is not set here.
> I think we need to add a second parameter for cdev_max_state when
> invoking thermal_nofify_cdev_update().
Ah, right. I forgot to add the parameter, thanks for pointing this out.
-- Daniel
[ ... ]
--
Facebook |
Twitter |
[PATCH] Replace HTTP links with HTTPS ones: MMU gather and TLB invalidation
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov --- Continuing my work started at 93431e0607e5. If there are any URLs to be removed completely or at least not HTTPSified: Just clearly say so and I'll *undo my change*. See also https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See https://lkml.org/lkml/2020/6/26/837 include/asm-generic/tlb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h index 3f1649a8cf55..f27861f2df4a 100644 --- a/include/asm-generic/tlb.h +++ b/include/asm-generic/tlb.h @@ -584,7 +584,7 @@ static inline void tlb_end_vma(struct mmu_gather *tlb, struct vm_area_struct *vm * So if we ever find an architecture * that would want something that odd, I think it is up to that * architecture to do its own odd thing, not cause pain for others - * http://lkml.kernel.org/r/ca+55afzbggoxtnxqeng5d_mrodnambe5y+urs+phr67nupm...@mail.gmail.com + * https://lkml.kernel.org/r/ca+55afzbggoxtnxqeng5d_mrodnambe5y+urs+phr67nupm...@mail.gmail.com * * For now w.r.t page table cache, mark the range_size as PAGE_SIZE */ -- 2.27.0
[PATCH] MIPS: CI20: DTS: Correcting IW8103 Wifi binding
From: Alexandre GRIVEAUX
Use brcm,bcm4329-fmac instead of brcm,bcm4330-fmac.
Signed-off-by: Alexandre GRIVEAUX
---
arch/mips/boot/dts/ingenic/ci20.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
b/arch/mips/boot/dts/ingenic/ci20.dts
index 75f5bfbf2c37..82a1f126b778 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -116,8 +116,8 @@
pinctrl-0 = <&pins_mmc1>;
brcmf: wifi@1 {
-/* reg = <4>;*/
- compatible = "brcm,bcm4330-fmac";
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
vcc-supply = <&wlan0_power>;
device-wakeup-gpios = <&gpd 9 GPIO_ACTIVE_HIGH>;
shutdown-gpios = <&gpf 7 GPIO_ACTIVE_LOW>;
--
2.20.1
[ANNOUNCE] Reiser5: Selective File Migration - User Interface
Reiser5: selective file migration. Setting/clearing file "immobile" status Earlier any migration of data blocks in reiser5 logical volumes occurred only in the context of some volume balancing procedure, which actually is a massive migration, aiming to keep fairness of distribution on the whole logical volume. Typically such migrations complete some volume operations, e.g. adding a device to a logical volume, removing a device from a logical volume, increasing data capacity of a device, flushing a proxy-device, etc). Now user can perform selective data migration. That is, migrate only data of some specified regular file to any specified device-component of the logical volume. Also, for any specified regular file user can mark it as "immobile", so that volume balancing procedures will ignore that file. Finally, for any specified regular file user can clear its "immobile" status, so that the file will be movable again by volume balancing procedures. In particular, using this functionality, user is able to push out "hot" files on any high-performance device (e.g. proxy device) and pin them there. To test the new functionality use reiser4-for-5.7.4.patch of v5-unstable branch(*) and reiser4progs-2.0.2 (or newer stuff) (*) https://sourceforge.net/projects/reiser4/files/v5-unstable/ File Migration: API - /* * Migrate file to specified target device. * @fd: file descriptor * @idx: serial number of target device in the logical volume */ /* * Provide correct path here. * This header file can be found in reiser4 kernel module, or * reiser4progs sources */ #include "reiser4/ioctl.h" struct reiser4_vol_op_args args; memset(&args, 0, sizeof(args)); args.opcode = REISER4_MIGRATE_FILE; args.val = idx; result = ioctl(fd, REISER4_IOC_VOLUME, &args); -- COMMENT. After ioctl successful completion the file is not necessarily written to the target device! To make sure of it, call fsync(2) after successful ioctl completion, or open the file with O_SYNC flag before migration. COMMENT. File migration is a volume operation (like adding, removing a device to/from a logical volumes), and all volume operations are serialized. So, any attempt to migrate a file, while performing other operation on that volume will fail. If some file migration procedure fails (with EBUSY, or other errors), or was interrupted by user, then it should be repeated in the current mount session. File migration procedures interrupted by system crash, hared reset, etc) should be repeated in the next mount sessions. -- Set file immobile status: API - /* * Set file "immobile". * @fd: file descriptor */ /* * Provide correct path here. * This header file can be found in reiser4 kernel module, or * reiser4progs sources */ #include "reiser4/ioctl.h" struct reiser4_vol_op_args args; memset(&args, 0, sizeof(args)); args.opcode = REISER4_SET_FILE_IMMOBILE; result = ioctl(fd, REISER4_IOC_VOLUME, &args); COMMENT. The immobile status guarantees that any data block of that file won't migrate to another device-component of the logical volume. Note, however, that such block can be easily relocated within device where it currently resides (once the file system finds better location for that block, etc). -- NOTE: All balancing procedures, which complete device removal, will ignore "immobile" status of any file. After device removal successful completion all data blocks of "immobile" files will be relocated to the remaining devices in accordance with current distribution policy. NOTE: Any selective file migration described above will ignore "immobile" status of the file! So the "immobile" status is honored only by volume balancing procedures, completing some operations such as adding a device to the logical volume, changing capacity of some device or flushing a proxy device. - Clear File immobile status: API /* * Clear file "immobile" status. * @fd: file descriptor */ /* * Provide correct path here. * This header file can be found in reiser4 kernel module, or * reiser4progs sources */ #include "reiser4/ioctl.h" struct reiser4_vol_op_args args; memset(&args, 0, sizeof(args)); args.opcode = REISER4_CLR_FILE_IMMOBILE; result = ioctl(fd, REISER4_IOC_VOLUME, &args); -- NOTE: Selective file migration can make your distribution unfair! Currently it is strongly recommended to migrate files only to devices, which don't participate in regular data distribution e.g. proxy device In the future it will be possible to turn off builtin distribution on any volume. in this case user will be responsible for appointing a destination device for any file on that volume.
arch/powerpc/platforms/powernv/pci-ioda.c:1889:13: warning: function 'pnv_ioda_setup_bus_dma' is not needed and will not be emitted
Hi Oliver,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 35e884f89df4c48566d745dc5a97a0d058d04263
commit: dc3d8f85bb571c3640ebba24b82a527cf2cb3f24 powerpc/powernv/pci: Re-work
bus PE configuration
date: 5 weeks ago
config: powerpc64-randconfig-r035-20200705 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
f804bd586ee58199db4cfb2da8e9ef067425900b)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
git checkout dc3d8f85bb571c3640ebba24b82a527cf2cb3f24
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross
ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
arch/powerpc/platforms/powernv/pci-ioda.c:1494:6: warning: no previous
prototype for function 'pnv_pci_sriov_disable' [-Wmissing-prototypes]
void pnv_pci_sriov_disable(struct pci_dev *pdev)
^
arch/powerpc/platforms/powernv/pci-ioda.c:1494:1: note: declare 'static' if
the function is not intended to be used outside of this translation unit
void pnv_pci_sriov_disable(struct pci_dev *pdev)
^
static
arch/powerpc/platforms/powernv/pci-ioda.c:1604:5: warning: no previous
prototype for function 'pnv_pci_sriov_enable' [-Wmissing-prototypes]
int pnv_pci_sriov_enable(struct pci_dev *pdev, u16 num_vfs)
^
arch/powerpc/platforms/powernv/pci-ioda.c:1604:1: note: declare 'static' if
the function is not intended to be used outside of this translation unit
int pnv_pci_sriov_enable(struct pci_dev *pdev, u16 num_vfs)
^
static
arch/powerpc/platforms/powernv/pci-ioda.c:1719:5: warning: no previous
prototype for function 'pnv_pcibios_sriov_disable' [-Wmissing-prototypes]
int pnv_pcibios_sriov_disable(struct pci_dev *pdev)
^
arch/powerpc/platforms/powernv/pci-ioda.c:1719:1: note: declare 'static' if
the function is not intended to be used outside of this translation unit
int pnv_pcibios_sriov_disable(struct pci_dev *pdev)
^
static
arch/powerpc/platforms/powernv/pci-ioda.c:1728:5: warning: no previous
prototype for function 'pnv_pcibios_sriov_enable' [-Wmissing-prototypes]
int pnv_pcibios_sriov_enable(struct pci_dev *pdev, u16 num_vfs)
^
arch/powerpc/platforms/powernv/pci-ioda.c:1728:1: note: declare 'static' if
the function is not intended to be used outside of this translation unit
int pnv_pcibios_sriov_enable(struct pci_dev *pdev, u16 num_vfs)
^
static
>> arch/powerpc/platforms/powernv/pci-ioda.c:1889:13: warning: function
>> 'pnv_ioda_setup_bus_dma' is not needed and will not be emitted
>> [-Wunneeded-internal-declaration]
static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus
*bus)
^
5 warnings generated.
vim +/pnv_ioda_setup_bus_dma +1889 arch/powerpc/platforms/powernv/pci-ioda.c
fe7e85c6f5ff63 Gavin Shan 2014-09-30 1888
5eada8a3f087df Alexey Kardashevskiy 2018-12-19 @1889 static void
pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1890 {
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1891 struct pci_dev
*dev;
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1892
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1893
list_for_each_entry(dev, &bus->devices, bus_list) {
b348aa65297659 Alexey Kardashevskiy 2015-06-05 1894
set_iommu_table_base(&dev->dev, pe->table_group.tables[0]);
0617fc0ca412b5 Christoph Hellwig 2019-02-13 1895
dev->dev.archdata.dma_offset = pe->tce_bypass_base;
dff4a39e880062 Gavin Shan 2014-07-15 1896
5c89a87d13d168 Alexey Kardashevskiy 2015-06-18 1897 if
((pe->flags & PNV_IODA_PE_BUS_ALL) && dev->subordinate)
5eada8a3f087df Alexey Kardashevskiy 2018-12-19 1898
pnv_ioda_setup_bus_dma(pe, dev->subordinate);
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1899 }
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1900 }
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1901
:: The code at line 1889 was first introduced by commit
:: 5eada8a3f087df74af1c2797770a3e2249374fe1 powerpc/iommu_api: Move IOMMU
groups setup to a single place
:: TO: Alexey Kardashevskiy
:: CC: Michael Ellerman
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] Replace HTTP links with HTTPS ones: input drivers
Hi Alexander, thanks for the patch. On 20-07-05 09:49, Alexander A. Klimov wrote: > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > > Deterministic algorithm: > For each file: > If not .svg: > For each line: > If doesn't contain `\bxmlns\b`: > For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: > If both the HTTP and HTTPS versions > return 200 OK and serve the same content: > Replace HTTP with HTTPS. > > Signed-off-by: Alexander A. Klimov for the "edt-ft5x06": Reviewed-by: Marco Felsch > --- > Continuing my work started at 93431e0607e5. > > If there are any URLs to be removed completely or at least not HTTPSified: > Just clearly say so and I'll *undo my change*. > See also https://lkml.org/lkml/2020/6/27/64 > > If there are any valid, but yet not changed URLs: > See https://lkml.org/lkml/2020/6/26/837 > > .../devicetree/bindings/input/ps2keyb-mouse-apbps2.txt| 2 +- > .../devicetree/bindings/input/rmi4/rmi_2d_sensor.txt | 2 +- > Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt | 2 +- > Documentation/devicetree/bindings/input/ti,drv260x.txt| 2 +- > Documentation/devicetree/bindings/input/ti,drv2665.txt| 2 +- > Documentation/devicetree/bindings/input/ti,drv2667.txt| 2 +- > Documentation/input/devices/appletouch.rst| 2 +- > Documentation/input/devices/bcm5974.rst | 4 ++-- > Documentation/input/devices/iforce-protocol.rst | 2 +- > Documentation/input/devices/joystick-parport.rst | 2 +- > Documentation/input/devices/ntrig.rst | 2 +- > Documentation/input/devices/pxrc.rst | 2 +- > Documentation/input/multi-touch-protocol.rst | 2 +- > drivers/input/keyboard/Kconfig| 2 +- > drivers/input/keyboard/lkkbd.c| 2 +- > drivers/input/keyboard/opencores-kbd.c| 2 +- > drivers/input/keyboard/tca8418_keypad.c | 2 +- > drivers/input/misc/Kconfig| 2 +- > drivers/input/misc/cm109.c| 2 +- > drivers/input/misc/gpio_decoder.c | 2 +- > drivers/input/misc/palmas-pwrbutton.c | 2 +- > drivers/input/misc/powermate.c| 2 +- > drivers/input/misc/tps65218-pwrbutton.c | 2 +- > drivers/input/misc/yealink.c | 2 +- > drivers/input/mouse/vsxxxaa.c | 2 +- > drivers/input/serio/apbps2.c | 2 +- > drivers/input/touchscreen/edt-ft5x06.c| 2 +- > drivers/input/touchscreen/iqs5xx.c| 2 +- > drivers/input/touchscreen/mc13783_ts.c| 2 +- > drivers/input/touchscreen/ti_am335x_tsc.c | 2 +- > drivers/input/touchscreen/usbtouchscreen.c| 2 +- > include/uapi/linux/input-event-codes.h| 2 +- > 32 files changed, 33 insertions(+), 33 deletions(-) > > diff --git a/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt > b/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt > index 3029c5694cf6..4606b07317ff 100644 > --- a/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt > +++ b/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt > @@ -13,4 +13,4 @@ Required properties: > - interrupts : Interrupt numbers for this device > > For further information look in the documentation for the GLIB IP core > library: > -http://www.gaisler.com/products/grlib/grip.pdf > +https://www.gaisler.com/products/grlib/grip.pdf > diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt > b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt > index 9afffbdf6e28..f0906e90cb35 100644 > --- a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt > +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt > @@ -9,7 +9,7 @@ Documentation/devicetree/bindings/input/rmi4. > > RMI4 Function 11 and Function 12 are for 2D touch position sensing. > Additional documentation for F11 can be found at: > -http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf > +https://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf > > Optional Touch Properties: > Description in Documentation/devicetree/bindings/input/touchscreen > diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt > b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt > index 079cad2b6843..23186fce40a1 100644 > --- a/Documentation/devicetree/bindings/input/rmi4/rmi
[PATCH] Replace HTTP links with HTTPS ones: Doubletalk driver
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov --- Continuing my work started at 93431e0607e5. If there are any URLs to be removed completely or at least not HTTPSified: Just clearly say so and I'll *undo my change*. See also https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See https://lkml.org/lkml/2020/6/26/837 drivers/char/dtlk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/dtlk.c b/drivers/char/dtlk.c index 6946c1cad9f6..5ec8185cb76b 100644 --- a/drivers/char/dtlk.c +++ b/drivers/char/dtlk.c @@ -13,7 +13,7 @@ */ /* This driver is for the DoubleTalk PC, a speech synthesizer - manufactured by RC Systems (http://www.rcsys.com/). It was written + manufactured by RC Systems (https://www.rcsys.com/). It was written based on documentation in their User's Manual file and Developer's Tools disk. -- 2.27.0
Re: [PATCH] tty: serial: meson_uart: Init port lock early
On Sun, Jul 05, 2020 at 11:28:56AM +0100, Marc Zyngier wrote: > On 2020-07-05 11:07, Andy Shevchenko wrote: > > On Sun, Jul 5, 2020 at 12:32 PM Marc Zyngier wrote: > > > > > > The meson UART driver triggers a lockdep splat at boot time, due > > > to the new expectation that the driver has to initialize the > > > per-port spinlock itself. > > > > > > It remains unclear why a double initialization of the port > > > spinlock is a desirable outcome, but in the meantime let's > > > fix the splat. > > > > > > > Thanks! > > > > Can you test patch from [1] if it helps and doesn't break anything in > > your case? > > > > [1]: > > https://lore.kernel.org/linux-serial/20200217114016.49856-1-andriy.shevche...@linux.intel.com/T/#m9255e2a7474b160e66c7060fca5323ca3df49cfd > > On its own, this patch doesn't seem to cure the issue (and it > adds a compile-time warning due to unused flags). Ah, sorry, I didn't compile it. And after second though I think we simple need to initialise spin lock there. Can you try below (compile-tested only): >From ed4c882e7dc3fdfcea706ada0678c060c36163b3 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Sat, 4 Jul 2020 19:30:39 +0300 Subject: [PATCH 1/1] serial: core: Initialise spin lock before use in uart_configure_port() In case of the port to be used as a console we must initialise a spin lock before use. Signed-off-by: Andy Shevchenko --- drivers/tty/serial/serial_core.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 3cc183acf7ba..a81b4900eb60 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -2371,6 +2371,13 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state, /* Power up port for set_mctrl() */ uart_change_pm(state, UART_PM_STATE_ON); + /* +* If this driver supports console, and it hasn't been +* successfully registered yet, initialise spin lock for it. +*/ + if (port->cons && !(port->cons->flags & CON_ENABLED)) + spin_lock_init(&port->lock); + /* * Ensure that the modem control lines are de-activated. * keep the DTR setting that is set in uart_set_options() -- 2.27.0 > Or did you mean to test it in complement of my patch? No, the idea to avoid "fixing" driver as you rightfully noticed a double init issue. -- With Best Regards, Andy Shevchenko
Re: [PATCH 3/3] selftests: add readfile(2) selftests
Hi Greg,
On Sun, Jul 5, 2020 at 8:55 AM Greg Kroah-Hartman
wrote:
> On Sat, Jul 04, 2020 at 08:38:26PM +0200, Geert Uytterhoeven wrote:
> > On Sat, Jul 4, 2020 at 4:05 PM Greg Kroah-Hartman
> > wrote:
> > > Test the functionality of readfile(2) in various ways.
> > >
> > > Also provide a simple speed test program to benchmark using readfile()
> > > instead of using open()/read()/close().
> > >
> > > Signed-off-by: Greg Kroah-Hartman
> > > --- /dev/null
> > > +++ b/tools/testing/selftests/readfile/readfile.c
> >
> > > +static void readfile(const char *filename)
> > > +{
> > > +// int root_fd;
> >
> > ???
>
> Ugh, sorry about that, I obviously didn't clean up my last tests from
> this file, thanks for catching that.
Reading about seq_file behavior, did the commented-out test for
"/sys/kernel/debug/usb/devices" work?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] MAINTAINERS: adjust entry to renaming and conversion
Hello Lukas,
On Sun, Jul 05, 2020 at 08:59:17AM +0200, Lukas Bulwahn wrote:
> Commit a74e81a56405 ("drm/panel: rocktech-jh057n00900: Rename the driver to
> st7703") and commit 7317f4574492 ("dt-bindings: panel: Convert
> rocktech,jh057n00900 to yaml") renamed and converted the files mentioned in
> DRM DRIVER FOR ROCKTECH JH057N00900 PANELS, but did not adjust the entries
> in MAINTAINERS.
A similar patch was already posted:
https://lkml.kernel.org/lkml/20200701184640.1674969-1-meg...@megous.com/
thank you and regards,
o.
> Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
>
> warning: no file matches F: \
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> warning: no file matches F: \
> drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
>
> Adjust entries after this file renaming and devicetree conversion.
>
> Signed-off-by: Lukas Bulwahn
> ---
> applies cleanly on next-20200703
>
> Ondrej, please ack this patch.
> Sam, please pick this minor non-urgent patch into your -next tree.
>
> This is the minimal change to address the warning. You might consider
> changing the name of the section from ROCKTECH to ST7703, change
> maintainers etc.
>
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9375edaef11f..8a7b92faff99 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5493,8 +5493,8 @@ DRM DRIVER FOR ROCKTECH JH057N00900 PANELS
> M: Guido Günther
> R: Purism Kernel Team
> S: Maintained
> -F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> -F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> +F:
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> +F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
>
> DRM DRIVER FOR SAVAGE VIDEO CARDS
> S: Orphan / Obsolete
> --
> 2.17.1
>
Re: [PATCH 3/3] selftests: add readfile(2) selftests
On Sun, Jul 05, 2020 at 01:24:07PM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Sun, Jul 5, 2020 at 8:55 AM Greg Kroah-Hartman
> wrote:
> > On Sat, Jul 04, 2020 at 08:38:26PM +0200, Geert Uytterhoeven wrote:
> > > On Sat, Jul 4, 2020 at 4:05 PM Greg Kroah-Hartman
> > > wrote:
> > > > Test the functionality of readfile(2) in various ways.
> > > >
> > > > Also provide a simple speed test program to benchmark using readfile()
> > > > instead of using open()/read()/close().
> > > >
> > > > Signed-off-by: Greg Kroah-Hartman
>
> > > > --- /dev/null
> > > > +++ b/tools/testing/selftests/readfile/readfile.c
> > >
> > > > +static void readfile(const char *filename)
> > > > +{
> > > > +// int root_fd;
> > >
> > > ???
> >
> > Ugh, sorry about that, I obviously didn't clean up my last tests from
> > this file, thanks for catching that.
>
> Reading about seq_file behavior, did the commented-out test for
> "/sys/kernel/debug/usb/devices" work?
Yes it did, which means I need to go dig to try to find a "problem"
seq_file procfs file to try to debug that behavior...
thanks,
greg k-h
Re: [PATCH v4 07/15] arm64: kvm: Move hyp-init.S to nVHE
Hi David, On Thu, 25 Jun 2020 14:14:12 +0100, David Brazdil wrote: > > From: Andrew Scull > > hyp-init.S contains the identity mapped initialisation code for the > non-VHE code that runs at EL2. It is only used for non-VHE. > > Adjust code that calls into this to use the prefixed symbol name. > > Signed-off-by: Andrew Scull > > [David: pass idmap_t0sz as an argument] It is unclear to me why moving the way idmap_t0sz is passed is required at this stage. I understand that you want to minimise the amount of shared data between EL1 and EL2, but it hardly seems relevant here. Or is it, as I expect, to avoid yet another symbol renaming issue? If so, it would be preferable to have the symbol alias, keep the setup hypercall as is, and have a later, separate patch that deals with the the idmap. And I am pretty sure that, as we move to a more autonomous EL2, we won't have to deal with it at all and we'll simply delete this code. I'm planning to squash the following diff into this patch, effectively reverting the idmap_t0sz related changes. Let me know if you're OK with it. diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h index 8ba32bff7bb2..9e897c500237 100644 --- a/arch/arm64/kernel/image-vars.h +++ b/arch/arm64/kernel/image-vars.h @@ -83,6 +83,9 @@ KVM_NVHE_ALIAS(panic); /* Vectors installed by hyp-init on reset HVC. */ KVM_NVHE_ALIAS(__hyp_stub_vectors); +/* IDMAP TCR_EL1.T0SZ as computed by the EL1 init code */ +KVM_NVHE_ALIAS(idmap_t0sz); + /* Kernel symbol used by icache_is_vpipt(). */ KVM_NVHE_ALIAS(__icache_flags); diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index 8ca2c111cec2..0bf2cf5614c6 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -1296,7 +1296,7 @@ static void cpu_init_hyp_mode(void) * cpus_have_const_cap() wrapper. */ BUG_ON(!system_capabilities_finalized()); - __kvm_call_hyp((void *)pgd_ptr, hyp_stack_ptr, vector_ptr, tpidr_el2, idmap_t0sz); + __kvm_call_hyp((void *)pgd_ptr, hyp_stack_ptr, vector_ptr, tpidr_el2); /* * Disabling SSBD on a non-VHE system requires us to enable SSBS diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S index 7bb75acbede0..6e6ed5581eed 100644 --- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S @@ -47,24 +47,23 @@ __invalid: * x1: HYP stack * x2: HYP vectors * x3: per-CPU offset -* x4: idmap_t0sz */ __do_hyp_init: /* Check for a stub HVC call */ cmp x0, #HVC_STUB_HCALL_NR b.lo__kvm_handle_stub_hvc - phys_to_ttbr x5, x0 + phys_to_ttbr x4, x0 alternative_if ARM64_HAS_CNP - orr x5, x5, #TTBR_CNP_BIT + orr x4, x4, #TTBR_CNP_BIT alternative_else_nop_endif - msr ttbr0_el2, x5 + msr ttbr0_el2, x4 - mrs x5, tcr_el1 - mov_q x6, TCR_EL2_MASK - and x5, x5, x6 - mov x6, #TCR_EL2_RES1 - orr x5, x5, x6 + mrs x4, tcr_el1 + mov_q x5, TCR_EL2_MASK + and x4, x4, x5 + mov x5, #TCR_EL2_RES1 + orr x4, x4, x5 /* * The ID map may be configured to use an extended virtual address @@ -80,14 +79,15 @@ alternative_else_nop_endif * * So use the same T0SZ value we use for the ID map. */ - bfi x5, x4, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH + ldr_l x5, idmap_t0sz + bfi x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH /* * Set the PS bits in TCR_EL2. */ - tcr_compute_pa_size x5, #TCR_EL2_PS_SHIFT, x4, x6 + tcr_compute_pa_size x4, #TCR_EL2_PS_SHIFT, x5, x6 - msr tcr_el2, x5 + msr tcr_el2, x4 mrs x4, mair_el1 msr mair_el2, x4 Thanks, M. -- Without deviation from the norm, progress is not possible.
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 05, 2020 at 01:07:14AM -0700, Vito Caputo wrote: > On Sun, Jul 05, 2020 at 04:27:32AM +0100, Matthew Wilcox wrote: > > On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote: > > > On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox wrote: > > > > > > > > You should probably take a look at io_uring. That has the level of > > > > complexity of this proposal and supports open/read/close along with many > > > > other opcodes. > > > > > > Then glibc can implement readfile using io_uring and there is no need > > > for a new single-file readfile syscall. > > > > It could, sure. But there's also a value in having a simple interface > > to accomplish a simple task. Your proposed API added a very complex > > interface to satisfy needs that clearly aren't part of the problem space > > that Greg is looking to address. > > I disagree re: "aren't part of the problem space". > > Reading small files from procfs was specifically called out in the > rationale for the syscall. > > In my experience you're rarely monitoring a single proc file in any > situation where you care about the syscall overhead. You're > monitoring many of them, and any serious effort to do this efficiently > in a repeatedly sampled situation has cached the open fds and already > uses pread() to simply restart from 0 on every sample and not > repeatedly pay for the name lookup. That's your use case, but many other use cases are just "read a bunch of sysfs files in one shot". Examples of that are tools that monitor uevents and lots of hardware-information gathering tools. Also not all tools sem to be as smart as you think they are, look at util-linux for loads of the "open/read/close" lots of files pattern. I had a half-baked patch to convert it to use readfile which I need to polish off and post with the next series to show how this can be used to both make userspace simpler as well as use less cpu time. > Basically anything optimally using the existing interfaces for > sampling proc files needs a way to read multiple open file descriptors > in a single syscall to move the needle. Is psutils using this type of interface, or do they constantly open different files? What about fun tools like bashtop: https://github.com/aristocratos/bashtop.git which thankfully now relies on python's psutil package to parse proc in semi-sane ways, but that package does loads of constant open/read/close of proc files all the time from what I can tell. And lots of people rely on python's psutil, right? > This syscall doesn't provide that. It doesn't really give any > advantage over what we can achieve already. It seems basically > pointless to me, from a monitoring proc files perspective. What "good" monitoring programs do you suggest follow the pattern you recommend? thanks, greg k-h
Re: [PATCH 0/3] Documentation: arm64: eliminate duplicated words
On Fri, Jul 03, 2020 at 01:51:07PM -0700, Randy Dunlap wrote: > Drop doubled words in Documentation/arm64/. > > > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Lorenzo Pieralisi > Cc: Hanjun Guo > Cc: Sudeep Holla > Cc: linux-a...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Dave Martin Acked-by: Mike Rapoport > > Documentation/arm64/acpi_object_usage.rst |2 +- > Documentation/arm64/arm-acpi.rst |2 +- > Documentation/arm64/sve.rst |2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) -- Sincerely yours, Mike.
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sat, Jul 04, 2020 at 08:30:40PM +0100, Al Viro wrote: > On Sat, Jul 04, 2020 at 04:02:46PM +0200, Greg Kroah-Hartman wrote: > > Here is a tiny new syscall, readfile, that makes it simpler to read > > small/medium sized files all in one shot, no need to do open/read/close. > > This is especially helpful for tools that poke around in procfs or > > sysfs, making a little bit of a less system load than before, especially > > as syscall overheads go up over time due to various CPU bugs being > > addressed. > > Nice series, but you are 3 months late with it... Next AFD, perhaps? Perhaps :) > Seriously, the rationale is bollocks. If the overhead of 2 extra > syscalls is anywhere near the costs of the real work being done by > that thing, we have already lost and the best thing to do is to > throw the system away and start with saner hardware. The real-work the kernel does is almost neglegant compared to the open/close overhead of the syscalls on some platforms today. I'll post benchmarks with the next version of this patch series to hopefully show that. If not, then yeah, this isn't worth it, but it was fun to write. thanks, greg k-h
Re: [PATCH 0/5] Documenation: hwmon: eliminate doubled words
On Fri, Jul 03, 2020 at 01:56:44PM -0700, Randy Dunlap wrote: > Eliminate duplicated words in Documentation/hwmon/ files. > > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Jean Delvare > Cc: Guenter Roeck > Cc: linux-hw...@vger.kernel.org Acked-by: Mike Rapoport > > Documentation/hwmon/f71882fg.rst |2 +- > Documentation/hwmon/lm93.rst |2 +- > Documentation/hwmon/nct6775.rst |2 +- > Documentation/hwmon/w83627ehf.rst |2 +- > Documentation/hwmon/w83l786ng.rst |2 +- > 5 files changed, 5 insertions(+), 5 deletions(-) -- Sincerely yours, Mike.
Re: [PATCH 0/4] Documentation: PCI: eliminate doubled words
On Fri, Jul 03, 2020 at 02:21:52PM -0700, Randy Dunlap wrote: > Fix doubled (duplicated) words in Documentation/PCI/. > > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Bjorn Helgaas > Cc: Kishon Vijay Abraham I > Cc: Lorenzo Pieralisi > Cc: linux-...@vger.kernel.org > Cc: Linas Vepstas Acked-by: Mike Rapoport > Documentation/PCI/endpoint/pci-endpoint-cfs.rst |2 +- > Documentation/PCI/endpoint/pci-endpoint.rst |2 +- > Documentation/PCI/pci-error-recovery.rst|2 +- > Documentation/PCI/pci.rst |2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) -- Sincerely yours, Mike.
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote: > Hello > > At first, I thought that the proposed system call is capable of > reading *multiple* small files using a single system call - which > would help increase HDD/SSD queue utilization and increase IOPS (I/O > operations per second) - but that isn't the case and the proposed > system call can read just a single file. If you want to do this for multple files, use io_ring, that's what it was designed for. I think Jens was going to be adding support for the open/read/close pattern to it as well, after some other more pressing features/fixes were finished. > Without the ability to read multiple small files using a single system > call, it is impossible to increase IOPS (unless an application is > using multiple reader threads or somehow instructs the kernel to > prefetch multiple files into memory). There's not much (but it is mesurable) need to prefetch virtual files into memory first, which is primarily what this syscall is for (procfs, sysfs, securityfs, etc.) If you are dealing with real-disks, then yes, the overhead of the syscall might be in the noise compared to the i/o path of the data. > While you are at it, why not also add a readfiles system call to read > multiple, presumably small, files? The initial unoptimized > implementation of readfiles syscall can simply call readfile > sequentially. Again, that's what io_uring is for. thanks, greg k-h
INFO: trying to register non-static key in red_destroy
Hello, syzbot found the following crash on: HEAD commit:2b04a661 Merge branch 'cxgb4-add-mirror-action-support-for.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=161887bb10 kernel config: https://syzkaller.appspot.com/x/.config?x=2172f4d0dbc37e27 dashboard link: https://syzkaller.appspot.com/bug?extid=6e95a4fabf88dc217145 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13809e6d10 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1527be6d10 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+6e95a4fabf88dc217...@syzkaller.appspotmail.com batman_adv: batadv0: Interface activated: batadv_slave_1 INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 1 PID: 6788 Comm: syz-executor510 Not tainted 5.8.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 assign_lock_key kernel/locking/lockdep.c:894 [inline] register_lock_class+0x157d/0x1630 kernel/locking/lockdep.c:1206 __lock_acquire+0xfa/0x56e0 kernel/locking/lockdep.c:4259 lock_acquire+0x1f1/0xad0 kernel/locking/lockdep.c:4959 del_timer_sync+0xab/0x270 kernel/time/timer.c:1354 red_destroy+0x33/0x70 net/sched/sch_red.c:219 qdisc_create+0xcd9/0x12e0 net/sched/sch_api.c:1294 tc_modify_qdisc+0x4c8/0x1990 net/sched/sch_api.c:1661 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5460 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2469 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1329 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1918 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x331/0x810 net/socket.c:2352 ___sys_sendmsg+0xf3/0x170 net/socket.c:2406 __sys_sendmmsg+0x195/0x480 net/socket.c:2496 __do_sys_sendmmsg net/socket.c:2525 [inline] __se_sys_sendmmsg net/socket.c:2522 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2522 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4434e9 Code: Bad RIP value. RSP: 002b:7ffc7993dc38 EFLAGS: 0246 ORIG_RAX: 0133 RAX: ffda RBX: 0003 RCX: 004434e9 RDX: 0492492492492642 RSI: 2180 RDI: 0004 RBP: 7ffc7993dc40 R08: 01bb R09: 01bb R10: R11: 0246 R12: 7ffc7993dc50 R13: R14: R15: [ cut here ] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: 0x0 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 05, 2020 at 06:09:03AM +0200, Jan Ziak wrote: > On Sun, Jul 5, 2020 at 5:27 AM Matthew Wilcox wrote: > > > > On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote: > > > On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox wrote: > > > > > > > > You should probably take a look at io_uring. That has the level of > > > > complexity of this proposal and supports open/read/close along with many > > > > other opcodes. > > > > > > Then glibc can implement readfile using io_uring and there is no need > > > for a new single-file readfile syscall. > > > > It could, sure. But there's also a value in having a simple interface > > to accomplish a simple task. Your proposed API added a very complex > > interface to satisfy needs that clearly aren't part of the problem space > > that Greg is looking to address. > > I believe that we should look at the single-file readfile syscall from > a performance viewpoint. If an application is expecting to read a > couple of small/medium-size files per second, then neither readfile > nor readfiles makes sense in terms of improving performance. The > benefits start to show up only in case an application is expecting to > read at least a hundred of files per second. The "per second" part is > important, it cannot be left out. Because readfile only improves > performance for many-file reads, the syscall that applications > performing many-file reads actually want is the multi-file version, > not the single-file version. It also is a measurable increase over reading just a single file. Here's my really really fast AMD system doing just one call to readfile vs. one call sequence to open/read/close: $ ./readfile_speed -l 1 Running readfile test on file /sys/devices/system/cpu/vulnerabilities/meltdown for 1 loops... Took 3410 ns Running open/read/close test on file /sys/devices/system/cpu/vulnerabilities/meltdown for 1 loops... Took 3780 ns 370ns isn't all that much, yes, but it is 370ns that could have been used for something else :) Look at the overhead these days of a syscall using something like perf to see just how bad things have gotten on Intel-based systems (above was AMD which doesn't suffer all the syscall slowdowns, only some). I'm going to have to now dig up my old rpi to get the stats on that thing, as well as some Intel boxes to show the problem I'm trying to help out with here. I'll post that for the next round of this patch series. > I am not sure I understand why you think that a pointer to an array of > readfile_t structures is very complex. If it was very complex then it > would be a deep tree or a large graph. Of course you can make it more complex if you want, but look at the existing tools that currently do many open/read/close sequences. The apis there don't lend themselves very well to knowing the larger list of files ahead of time. But I could be looking at the wrong thing, what userspace programs are you thinking of that could be easily converted into using something like this? thanks, greg k-h
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 05, 2020 at 09:25:39AM +0200, Jan Ziak wrote:
> On Sun, Jul 5, 2020 at 8:32 AM Andreas Dilger wrote:
> >
> > On Jul 4, 2020, at 8:46 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
> > >
> > > On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox wrote:
> > >>
> > >> On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
> > >>> Hello
> > >>>
> > >>> At first, I thought that the proposed system call is capable of
> > >>> reading *multiple* small files using a single system call - which
> > >>> would help increase HDD/SSD queue utilization and increase IOPS (I/O
> > >>> operations per second) - but that isn't the case and the proposed
> > >>> system call can read just a single file.
> > >>>
> > >>> Without the ability to read multiple small files using a single system
> > >>> call, it is impossible to increase IOPS (unless an application is
> > >>> using multiple reader threads or somehow instructs the kernel to
> > >>> prefetch multiple files into memory).
> > >>
> > >> What API would you use for this?
> > >>
> > >> ssize_t readfiles(int dfd, char **files, void **bufs, size_t *lens);
> > >>
> > >> I pretty much hate this interface, so I hope you have something better
> > >> in mind.
> > >
> > > I am proposing the following:
> > >
> > > struct readfile_t {
> > > int dirfd;
> > > const char *pathname;
> > > void *buf;
> > > size_t count;
> > > int flags;
> > > ssize_t retval; // set by kernel
> > > int reserved; // not used by kernel
> > > };
> >
> > If you are going to pass a struct from userspace to the kernel, it
> > should not mix int and pointer types (which may be 64-bit values,
> > so that there are not structure packing issues, like:
> >
> > struct readfile {
> > int dirfd;
> > int flags;
> > const char *pathname;
> > void*buf;
> > size_t count;
> > ssize_t retval;
> > };
> >
> > It would be better if "retval" was returned in "count", so that
> > the structure fits nicely into 32 bytes on a 64-bit system, instead
> > of being 40 bytes per entry, which adds up over many entries, like.
>
> I know what you mean and it is a valid point, but in my opinion it
> shouldn't (in most cases) be left to the programmer to decide what the
> binary layout of a data structure is - instead it should be left to an
> optimizing compiler to decide it.
We don't get that luxury when creating user/kernel apis in C, sorry.
I suggest using the pahole tool if you are interested in seeing the
"best" way a structure can be layed out, it can perform that
optimization for you so that you know how to fix your code.
thanks,
greg k-h
Re: [PATCH v4 08/15] arm64: kvm: Duplicate hyp/tlb.c for VHE/nVHE
On Thu, 25 Jun 2020 14:14:13 +0100,
David Brazdil wrote:
>
> tlb.c contains code for flushing the TLB, with code shared between VHE/nVHE.
> Because common code is small, duplicate tlb.c and specialize each copy for
> VHE/nVHE.
>
> Signed-off-by: David Brazdil
> ---
> arch/arm64/kernel/image-vars.h | 14 +--
> arch/arm64/kvm/hyp/Makefile | 2 +-
> arch/arm64/kvm/hyp/nvhe/Makefile| 2 +-
> arch/arm64/kvm/hyp/{ => nvhe}/tlb.c | 94 +---
> arch/arm64/kvm/hyp/vhe/Makefile | 2 +-
> arch/arm64/kvm/hyp/vhe/tlb.c| 162
> 6 files changed, 178 insertions(+), 98 deletions(-)
> rename arch/arm64/kvm/hyp/{ => nvhe}/tlb.c (62%)
> create mode 100644 arch/arm64/kvm/hyp/vhe/tlb.c
[...]
> diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/nvhe/tlb.c
> similarity index 62%
> rename from arch/arm64/kvm/hyp/tlb.c
> rename to arch/arm64/kvm/hyp/nvhe/tlb.c
> index d063a576d511..9513ad41db9a 100644
> --- a/arch/arm64/kvm/hyp/tlb.c
> +++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
> @@ -4,8 +4,6 @@
> * Author: Marc Zyngier
> */
>
> -#include
> -
> #include
> #include
> #include
> @@ -16,52 +14,8 @@ struct tlb_inv_context {
> u64 sctlr;
> };
nit: You seem to have overlooked that some of the tlb_inv_context
fields are now unused. I plan to squash the following patch in:
diff --git a/arch/arm64/kvm/hyp/nvhe/tlb.c b/arch/arm64/kvm/hyp/nvhe/tlb.c
index 6fe190bb930a..d4475f8340c4 100644
--- a/arch/arm64/kvm/hyp/nvhe/tlb.c
+++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
@@ -9,9 +9,7 @@
#include
struct tlb_inv_context {
- unsigned long flags;
u64 tcr;
- u64 sctlr;
};
static void __tlb_switch_to_guest(struct kvm *kvm, struct tlb_inv_context *cxt)
Otherwise, this looks good to me.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Re: [PATCH] iio: adc: ad7780: Fix a resource handling path in 'ad7780_probe()'
On Sun, 17 May 2020 23:21:29 -0300
Renato Lui Geh wrote:
> Acked-by: Renato Lui Geh
>
> On 05/17, Christophe JAILLET wrote:
> >If 'ad7780_init_gpios()' fails, we must not release some resources that
> >have not been allocated yet. Return directly instead.
> >
> >Fixes: 5bb30e7daf00 ("staging: iio: ad7780: move regulator to after GPIO
> >init")
> >Fixes: 9085daa4abcc ("staging: iio: ad7780: add gain & filter gpio support")
> >Signed-off-by: Christophe JAILLET
Applied to the fixes-togreg branch of iio.git.
Thanks,
Jonathan
> >---
> > drivers/iio/adc/ad7780.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/iio/adc/ad7780.c b/drivers/iio/adc/ad7780.c
> >index f47606ee..b33fe6c3907e 100644
> >--- a/drivers/iio/adc/ad7780.c
> >+++ b/drivers/iio/adc/ad7780.c
> >@@ -329,7 +329,7 @@ static int ad7780_probe(struct spi_device *spi)
> >
> > ret = ad7780_init_gpios(&spi->dev, st);
> > if (ret)
> >-goto error_cleanup_buffer_and_trigger;
> >+return ret;
> >
> > st->reg = devm_regulator_get(&spi->dev, "avdd");
> > if (IS_ERR(st->reg))
> >--
> >2.25.1
> >
Re: [PATCH 1/3] iio: adc: ti_am335x_adc: alloc channels via devm_kcalloc()
On Tue, 28 Apr 2020 14:14:28 +0300
Alexandru Ardelean wrote:
> This change attaches the life-cycle of the channels array to the parent
> device object that is attached to the IIO device.
> This way we can remove from the cleanup code, the explicit
> tiadc_channels_remove() which simply does a kfree() on the channels array.
>
> Signed-off-by: Alexandru Ardelean
Still not sure on patch 3 but I'll pick up the first 2 so we can forget
about those.
Applied to the togreg branch of iio.git and pushed out as testing for
all the usual reasons.
Thanks,
Jonathan
> ---
>
> The reason I'm targetting this driver, is because it's among the few
> places where 'indio_dev->buffer' is accessed directly in the driver, and
> that makes it difficult to think of a sane-backwards-compatible way to
> do multiple IIO buffers.
>
> drivers/iio/adc/ti_am335x_adc.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index 9d984f2a8ba7..d932fe383a24 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -428,7 +428,8 @@ static const char * const chan_name_ain[] = {
> "AIN7",
> };
>
> -static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
> +static int tiadc_channel_init(struct device *dev, struct iio_dev *indio_dev,
> + int channels)
> {
> struct tiadc_device *adc_dev = iio_priv(indio_dev);
> struct iio_chan_spec *chan_array;
> @@ -436,7 +437,8 @@ static int tiadc_channel_init(struct iio_dev *indio_dev,
> int channels)
> int i;
>
> indio_dev->num_channels = channels;
> - chan_array = kcalloc(channels, sizeof(*chan_array), GFP_KERNEL);
> + chan_array = devm_kcalloc(dev, channels, sizeof(*chan_array),
> + GFP_KERNEL);
> if (chan_array == NULL)
> return -ENOMEM;
>
> @@ -459,11 +461,6 @@ static int tiadc_channel_init(struct iio_dev *indio_dev,
> int channels)
> return 0;
> }
>
> -static void tiadc_channels_remove(struct iio_dev *indio_dev)
> -{
> - kfree(indio_dev->channels);
> -}
> -
> static int tiadc_read_raw(struct iio_dev *indio_dev,
> struct iio_chan_spec const *chan,
> int *val, int *val2, long mask)
> @@ -635,7 +632,7 @@ static int tiadc_probe(struct platform_device *pdev)
> tiadc_writel(adc_dev, REG_FIFO1THR, FIFO1_THRESHOLD);
> mutex_init(&adc_dev->fifo1_lock);
>
> - err = tiadc_channel_init(indio_dev, adc_dev->channels);
> + err = tiadc_channel_init(&pdev->dev, indio_dev, adc_dev->channels);
> if (err < 0)
> return err;
>
> @@ -666,7 +663,6 @@ static int tiadc_probe(struct platform_device *pdev)
> err_buffer_unregister:
> tiadc_iio_buffered_hardware_remove(indio_dev);
> err_free_channels:
> - tiadc_channels_remove(indio_dev);
> return err;
> }
>
> @@ -684,7 +680,6 @@ static int tiadc_remove(struct platform_device *pdev)
> }
> iio_device_unregister(indio_dev);
> tiadc_iio_buffered_hardware_remove(indio_dev);
> - tiadc_channels_remove(indio_dev);
>
> step_en = get_adc_step_mask(adc_dev);
> am335x_tsc_se_clr(adc_dev->mfd_tscadc, step_en);
Re: [PATCH 2/3] iio: adc: ti_am335x_adc: alloc kfifo & IRQ via devm_ functions
On Tue, 28 Apr 2020 14:14:29 +0300
Alexandru Ardelean wrote:
> This change attaches the life-cycle of the kfifo buffer & IRQ to the
> parent-device. This in turn cleans up the exit & error paths, since we
> don't need to explicitly cleanup these resources.
>
> The main intent here is to remove the explicit cleanup of the
> 'indio_dev->buffer' via 'iio_kfifo_free(indio_dev->buffer);'.
>
> As we want to add support for multiple buffers per IIO device, having it
> exposed like this makes it tricky to consider a safe backwards compatible
> approach for it.
>
> Signed-off-by: Alexandru Ardelean
Applied.
> ---
> drivers/iio/adc/ti_am335x_adc.c | 20 +---
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index d932fe383a24..03b2ab649cc3 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -377,7 +377,8 @@ static const struct iio_buffer_setup_ops
> tiadc_buffer_setup_ops = {
> .postdisable = &tiadc_buffer_postdisable,
> };
>
> -static int tiadc_iio_buffered_hardware_setup(struct iio_dev *indio_dev,
> +static int tiadc_iio_buffered_hardware_setup(struct device *dev,
> + struct iio_dev *indio_dev,
> irqreturn_t (*pollfunc_bh)(int irq, void *p),
> irqreturn_t (*pollfunc_th)(int irq, void *p),
> int irq,
> @@ -387,13 +388,13 @@ static int tiadc_iio_buffered_hardware_setup(struct
> iio_dev *indio_dev,
> struct iio_buffer *buffer;
> int ret;
>
> - buffer = iio_kfifo_allocate();
> + buffer = devm_iio_kfifo_allocate(dev);
> if (!buffer)
> return -ENOMEM;
>
> iio_device_attach_buffer(indio_dev, buffer);
>
> - ret = request_threaded_irq(irq, pollfunc_th, pollfunc_bh,
> + ret = devm_request_threaded_irq(dev, irq, pollfunc_th, pollfunc_bh,
> flags, indio_dev->name, indio_dev);
> if (ret)
> goto error_kfifo_free;
> @@ -408,15 +409,6 @@ static int tiadc_iio_buffered_hardware_setup(struct
> iio_dev *indio_dev,
> return ret;
> }
>
> -static void tiadc_iio_buffered_hardware_remove(struct iio_dev *indio_dev)
> -{
> - struct tiadc_device *adc_dev = iio_priv(indio_dev);
> -
> - free_irq(adc_dev->mfd_tscadc->irq, indio_dev);
> - iio_kfifo_free(indio_dev->buffer);
> -}
> -
> -
> static const char * const chan_name_ain[] = {
> "AIN0",
> "AIN1",
> @@ -636,7 +628,7 @@ static int tiadc_probe(struct platform_device *pdev)
> if (err < 0)
> return err;
>
> - err = tiadc_iio_buffered_hardware_setup(indio_dev,
> + err = tiadc_iio_buffered_hardware_setup(&pdev->dev, indio_dev,
> &tiadc_worker_h,
> &tiadc_irq_h,
> adc_dev->mfd_tscadc->irq,
> @@ -661,7 +653,6 @@ static int tiadc_probe(struct platform_device *pdev)
> err_dma:
> iio_device_unregister(indio_dev);
> err_buffer_unregister:
> - tiadc_iio_buffered_hardware_remove(indio_dev);
> err_free_channels:
> return err;
> }
> @@ -679,7 +670,6 @@ static int tiadc_remove(struct platform_device *pdev)
> dma_release_channel(dma->chan);
> }
> iio_device_unregister(indio_dev);
> - tiadc_iio_buffered_hardware_remove(indio_dev);
>
> step_en = get_adc_step_mask(adc_dev);
> am335x_tsc_se_clr(adc_dev->mfd_tscadc, step_en);
[PATCH 0/4] Make Frame Skip Mode control a standard
Hello, Suggested by Hans at [1], this patchset is promoting a standard control for frame skip mode. The original private V4L2_CID_MPEG_MFC51_VIDEO_FRAME_SKIP_MODE control is applicable and can be used by Venus driver too (and probably other drivers). In order to make that possible make a new V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE standard menu control (a copy of the private one). Also, to keep mfc driver backward compatible kept the private one, and mark it as depricated in docs. regards, Stan [1] https://lkml.org/lkml/2020/5/19/122 Stanimir Varbanov (4): media: v4l2-ctrl: Add frame-skip std encoder control venus: venc: Add support for frame-skip mode v4l2 control media: s5p-mfc: Use standard frame skip mode control media: docs: Depricate mfc frame skip control .../media/v4l/ext-ctrls-codec.rst | 37 +++ drivers/media/platform/qcom/venus/core.h | 1 + drivers/media/platform/qcom/venus/venc.c | 6 ++- .../media/platform/qcom/venus/venc_ctrls.c| 12 +- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 6 +++ drivers/media/v4l2-core/v4l2-ctrls.c | 10 + include/uapi/linux/v4l2-controls.h| 6 +++ 7 files changed, 75 insertions(+), 3 deletions(-) -- 2.17.1
[PATCH 1/4] media: v4l2-ctrl: Add frame-skip std encoder control
Adds encoders standard v4l2 control for frame-skip. The control
is a copy of a custom encoder control so that other v4l2 encoder
drivers can use it.
Signed-off-by: Stanimir Varbanov
---
.../media/v4l/ext-ctrls-codec.rst | 32 +++
drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++
include/uapi/linux/v4l2-controls.h| 6
3 files changed, 48 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index d0d506a444b1..a8b4c0b40747 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -592,6 +592,38 @@ enum v4l2_mpeg_video_bitrate_mode -
the average video bitrate. It is ignored if the video bitrate mode
is set to constant bitrate.
+``V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE (enum)``
+
+enum v4l2_mpeg_video_frame_skip_mode -
+Indicates in what conditions the encoder should skip frames. If
+encoding a frame would cause the encoded stream to be larger then a
+chosen data limit then the frame will be skipped. Possible values
+are:
+
+
+.. tabularcolumns:: |p{9.2cm}|p{8.3cm}|
+
+.. raw:: latex
+
+\small
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* - ``V4L2_MPEG_FRAME_SKIP_MODE_DISABLED``
+ - Frame skip mode is disabled.
+* - ``V4L2_MPEG_FRAME_SKIP_MODE_LEVEL_LIMIT``
+ - Frame skip mode enabled and buffer limit is set by the chosen
+ level and is defined by the standard.
+* - ``V4L2_MPEG_FRAME_SKIP_MODE_BUF_LIMIT``
+ - Frame skip mode enabled and buffer limit is set by the VBV
+ (MPEG1/2/4) or CPB (H264) buffer size control.
+
+.. raw:: latex
+
+\normalsize
+
``V4L2_CID_MPEG_VIDEO_TEMPORAL_DECIMATION (integer)``
For every captured frame, skip this many subsequent frames (default
0).
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 3f3fbcd60cc6..d088acfa6dd8 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -590,6 +590,12 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"External",
NULL,
};
+ static const char * const mpeg_video_frame_skip[] = {
+ "Disabled",
+ "Level Limit",
+ "VBV/CPB Limit",
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -651,6 +657,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return flash_strobe_source;
case V4L2_CID_MPEG_VIDEO_HEADER_MODE:
return header_mode;
+ case V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE:
+ return mpeg_video_frame_skip;
case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE:
return multi_slice;
case V4L2_CID_MPEG_VIDEO_H264_ENTROPY_MODE:
@@ -844,6 +852,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE: return "H264 MB
Level Rate Control";
case V4L2_CID_MPEG_VIDEO_HEADER_MODE: return
"Sequence Header Mode";
case V4L2_CID_MPEG_VIDEO_MAX_REF_PIC: return "Max
Number of Reference Pics";
+ case V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE: return "Frame
Skip Mode";
case V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP: return "H263
I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP: return "H263
P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_H263_B_FRAME_QP: return "H263
B-Frame QP Value";
@@ -1265,6 +1274,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_FLASH_LED_MODE:
case V4L2_CID_FLASH_STROBE_SOURCE:
case V4L2_CID_MPEG_VIDEO_HEADER_MODE:
+ case V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE:
case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE:
case V4L2_CID_MPEG_VIDEO_H264_ENTROPY_MODE:
case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 62271418c1be..4e1526175a4c 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -742,6 +742,12 @@ enum v4l2_cid_mpeg_video_hevc_size_of_length_field {
#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_BR (V4L2_CID_MPEG_BASE +
642)
#define V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES (V4L2_CID_MPEG_BASE +
643)
#define V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR (V4L2_CID_MPEG_BASE +
644)
+#define V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE(V4L2_CID_MPEG_BASE +
645)
+enum v4l2_mpeg_video_frame_skip_mode {
+ V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED= 0,
+ V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_LEVEL_LIMIT = 1,
+ V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT = 2,
+};
/* MPEG-class contro
[PATCH 3/4] media: s5p-mfc: Use standard frame skip mode control
Use the standard menu control for frame skip mode in the MFC
driver. The legacy private menu control is kept for backward
compatibility.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 912fe0c5ab18..3092eb6777a5 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -261,6 +261,11 @@ static struct mfc_control controls[] = {
.menu_skip_mask = 0,
.default_value = V4L2_MPEG_MFC51_VIDEO_FRAME_SKIP_MODE_DISABLED,
},
+ {
+ .id = V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE,
+ .maximum = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT,
+ .default_value = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED,
+ },
{
.id = V4L2_CID_MPEG_MFC51_VIDEO_RC_FIXED_TARGET_BIT,
.type = V4L2_CTRL_TYPE_BOOLEAN,
@@ -1849,6 +1854,7 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
p->seq_hdr_mode = ctrl->val;
break;
case V4L2_CID_MPEG_MFC51_VIDEO_FRAME_SKIP_MODE:
+ case V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE:
p->frame_skip_mode = ctrl->val;
break;
case V4L2_CID_MPEG_MFC51_VIDEO_RC_FIXED_TARGET_BIT:
--
2.17.1
[PATCH 4/4] media: docs: Depricate mfc frame skip control
Depricate mfc private frame skip mode control for new clients and use the standard one instead. Signed-off-by: Stanimir Varbanov --- Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index a8b4c0b40747..c0760bfc54d4 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -2805,6 +2805,11 @@ MFC 5.1 Control IDs ``V4L2_CID_MPEG_MFC51_VIDEO_FRAME_SKIP_MODE`` (enum) +.. note:: + + This control is depricated. Use the standard one + ``V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE`` instead. + enum v4l2_mpeg_mfc51_video_frame_skip_mode - Indicates in what conditions the encoder should skip frames. If encoding a frame would cause the encoded stream to be larger then a -- 2.17.1
[PATCH 2/4] venus: venc: Add support for frame-skip mode v4l2 control
This adds support for frame-skip-mode standard v4l2 control in
encoder driver. The control is implemented based on the
combination of client selected bitrate-mode and frame-skip-mode.
Once The client selected bitrate-mode (constant or variable) and
the frame-skip-mode is not disabled we set variable framerate for
rate controller.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/core.h | 1 +
drivers/media/platform/qcom/venus/venc.c | 6 --
drivers/media/platform/qcom/venus/venc_ctrls.c | 12 +++-
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 7118612673c9..5e74d0441592 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -201,6 +201,7 @@ struct venc_controls {
u32 bitrate;
u32 bitrate_peak;
u32 rc_enable;
+ u32 frame_skip_mode;
u32 h264_i_period;
u32 h264_entropy_mode;
diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index 513bbc07f7bc..2279596d4d60 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -739,9 +739,11 @@ static int venc_set_properties(struct venus_inst *inst)
if (!ctr->rc_enable)
rate_control = HFI_RATE_CONTROL_OFF;
else if (ctr->bitrate_mode == V4L2_MPEG_VIDEO_BITRATE_MODE_VBR)
- rate_control = HFI_RATE_CONTROL_VBR_CFR;
+ rate_control = ctr->frame_skip_mode ? HFI_RATE_CONTROL_VBR_VFR :
+ HFI_RATE_CONTROL_VBR_CFR;
else
- rate_control = HFI_RATE_CONTROL_CBR_CFR;
+ rate_control = ctr->frame_skip_mode ? HFI_RATE_CONTROL_CBR_VFR :
+ HFI_RATE_CONTROL_CBR_CFR;
ptype = HFI_PROPERTY_PARAM_VENC_RATE_CONTROL;
ret = hfi_session_set_property(inst, ptype, &rate_control);
diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c
b/drivers/media/platform/qcom/venus/venc_ctrls.c
index 8362dde7949e..a418d7d6db0c 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -202,6 +202,9 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE:
ctr->rc_enable = ctrl->val;
break;
+ case V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE:
+ ctr->frame_skip_mode = ctrl->val;
+ break;
default:
return -EINVAL;
}
@@ -217,7 +220,7 @@ int venc_ctrl_init(struct venus_inst *inst)
{
int ret;
- ret = v4l2_ctrl_handler_init(&inst->ctrl_handler, 31);
+ ret = v4l2_ctrl_handler_init(&inst->ctrl_handler, 32);
if (ret)
return ret;
@@ -357,6 +360,13 @@ int venc_ctrl_init(struct venus_inst *inst)
v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE, 0, 1, 1, 1);
+ v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE,
+ V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT,
+ ~((1 << V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED) |
+ (1 << V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT)),
+ V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED);
+
ret = inst->ctrl_handler.error;
if (ret)
goto err;
--
2.17.1
Re: [mm] 4e2c82a409: ltp.overcommit_memory01.fail
> On Jul 5, 2020, at 12:45 AM, Feng Tang wrote: > > I did reproduce the problem, and from the debugging, this should > be the same root cause as lore.kernel.org/lkml/20200526181459.gd...@lca.pw/ > that loosing the batch cause some accuracy problem, and the solution of > adding some sync is still needed, which is dicussed in Well, before taking any of those patches now to fix the regression, we will need some performance data first. If it turned out the original performance gain is no longer relevant anymore due to this regression fix on top, it is best to drop this patchset and restore that VM_WARN_ONCE, so you can retry later once you found a better way to optimize.
[PATCH v4 0/2] Add support for the OST in Ingenic X1000.
v3->v4: 1.Rename "ingenic,ost.yaml" to "ingenic,sysost.yaml". 2.Rename "ingenic,ost.h" to "ingenic,sysost.h". 3.Remove ost_clock_parent enum. 4.Remove ost->percpu_timer_channel/ost->global_timer_channel. 5.Set up independent .recalc_rate/.set_rate for percpu/global timer. 6.No longer call functions in variable declarations. 周琰杰 (Zhou Yanjie) (2): dt-bindings: timer: Add Ingenic X1000 OST bindings. clocksource: Ingenic: Add support for the Ingenic X1000 OST. .../devicetree/bindings/timer/ingenic,sysost.yaml | 60 +++ drivers/clocksource/Kconfig| 11 + drivers/clocksource/Makefile | 1 + drivers/clocksource/ingenic-sysost.c | 539 + include/dt-bindings/clock/ingenic,sysost.h | 12 + 5 files changed, 623 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/ingenic,sysost.yaml create mode 100755 drivers/clocksource/ingenic-sysost.c create mode 100644 include/dt-bindings/clock/ingenic,sysost.h -- 2.11.0
[PATCH v4 1/2] dt-bindings: timer: Add Ingenic X1000 OST bindings.
Add the OST bindings for the X1 SoC from Ingenic.
Tested-by: 周正 (Zhou Zheng)
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
Notes:
v1->v2:
No change.
v2->v3:
Fix wrong parameters in "clocks".
v3->v4:
1.Rename "ingenic,ost.yaml" to "ingenic,sysost.yaml".
2.Rename "ingenic,ost.h" to "ingenic,sysost.h".
3.Modify the description in "ingenic,sysost.yaml".
.../devicetree/bindings/timer/ingenic,sysost.yaml | 60 ++
include/dt-bindings/clock/ingenic,sysost.h | 12 +
2 files changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
create mode 100644 include/dt-bindings/clock/ingenic,sysost.h
diff --git a/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
b/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
new file mode 100644
index ..03257ed806fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/ingenic,sysost.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for SYSOST in Ingenic XBurst family SoCs
+
+maintainers:
+ - 周琰杰 (Zhou Yanjie)
+
+description:
+ The SYSOST in an Ingenic SoC provides one 64bit timer for clocksource
+ and one or more 32bit timers for clockevent.
+
+properties:
+ compatible:
+oneOf:
+
+ - enum:
+ - ingenic,x1000-ost
+ - ingenic,x2000-ost
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: ost
+
+ interrupts:
+maxItems: 1
+
+required:
+ - "#clock-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+examples:
+ - |
+#include
+
+ost: timer@1200 {
+ compatible = "ingenic,x1000-ost";
+ reg = <0x1200 0x3c>;
+
+ #clock-cells = <1>;
+
+ clocks = <&cgu X1000_CLK_OST>;
+ clock-names = "ost";
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <3>;
+ };
+...
diff --git a/include/dt-bindings/clock/ingenic,sysost.h
b/include/dt-bindings/clock/ingenic,sysost.h
new file mode 100644
index ..9ac88e90babf
--- /dev/null
+++ b/include/dt-bindings/clock/ingenic,sysost.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides clock numbers for the ingenic,tcu DT binding.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_INGENIC_OST_H__
+#define __DT_BINDINGS_CLOCK_INGENIC_OST_H__
+
+#define OST_CLK_PERCPU_TIMER 0
+#define OST_CLK_GLOBAL_TIMER 1
+
+#endif /* __DT_BINDINGS_CLOCK_INGENIC_OST_H__ */
--
2.11.0
[PATCH v4 2/2] clocksource: Ingenic: Add support for the Ingenic X1000 OST.
X1000 and SoCs after X1000 (such as X1500 and X1830) had a separate
OST, it no longer belongs to TCU. This driver will register both a
clocksource and a sched_clock to the system.
Tested-by: 周正 (Zhou Zheng)
Co-developed-by: 漆鹏振 (Qi Pengzhen)
Signed-off-by: 漆鹏振 (Qi Pengzhen)
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
Notes:
v1->v2:
Fix compile warnings.
Reported-by: kernel test robot
v2->v3:
No change.
v3->v4:
1.Remove unrelated changes.
2.Remove ost_clock_parent enum.
3.Remove ost->percpu_timer_channel/ost->global_timer_channel.
4.Set up independent .recalc_rate/.set_rate for percpu/global timer.
5.No longer call functions in variable declarations.
drivers/clocksource/Kconfig | 11 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/ingenic-sysost.c | 539 +++
3 files changed, 551 insertions(+)
create mode 100644 drivers/clocksource/ingenic-sysost.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 91418381fcd4..1bca8b8fb30f 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -696,6 +696,17 @@ config INGENIC_TIMER
help
Support for the timer/counter unit of the Ingenic JZ SoCs.
+config INGENIC_SYSOST
+ bool "Clocksource/timer using the SYSOST in Ingenic X SoCs"
+ default MACH_INGENIC
+ depends on MIPS || COMPILE_TEST
+ depends on COMMON_CLK
+ select MFD_SYSCON
+ select TIMER_OF
+ select IRQ_DOMAIN
+ help
+ Support for the SYSOST of the Ingenic X Series SoCs.
+
config INGENIC_OST
bool "Clocksource for Ingenic OS Timer"
depends on MIPS || COMPILE_TEST
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index bdda1a2e4097..3994e221e262 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_H8300_TMR8) += h8300_timer8.o
obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
obj-$(CONFIG_INGENIC_OST) += ingenic-ost.o
+obj-$(CONFIG_INGENIC_SYSOST) += ingenic-sysost.o
obj-$(CONFIG_INGENIC_TIMER)+= ingenic-timer.o
obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
obj-$(CONFIG_X86_NUMACHIP) += numachip.o
diff --git a/drivers/clocksource/ingenic-sysost.c
b/drivers/clocksource/ingenic-sysost.c
new file mode 100644
index ..f6dab3da68fb
--- /dev/null
+++ b/drivers/clocksource/ingenic-sysost.c
@@ -0,0 +1,539 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Ingenic XBurst SoCs SYSOST clocks driver
+ * Copyright (c) 2020 周琰杰 (Zhou Yanjie)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* OST register offsets */
+#define OST_REG_OSTCCR 0x00
+#define OST_REG_OSTCR 0x08
+#define OST_REG_OSTFR 0x0c
+#define OST_REG_OSTMR 0x10
+#define OST_REG_OST1DFR0x14
+#define OST_REG_OST1CNT0x18
+#define OST_REG_OST2CNTL 0x20
+#define OST_REG_OSTCNT2HBUF0x24
+#define OST_REG_OSTESR 0x34
+#define OST_REG_OSTECR 0x38
+
+/* bits within the OSTCCR register */
+#define OSTCCR_PRESCALE1_MASK 0x3
+#define OSTCCR_PRESCALE2_MASK 0xc
+#define OSTCCR_PRESCALE1_LSB 0
+#define OSTCCR_PRESCALE2_LSB 2
+
+/* bits within the OSTCR register */
+#define OSTCR_OST1CLR BIT(0)
+#define OSTCR_OST2CLR BIT(1)
+
+/* bits within the OSTFR register */
+#define OSTFR_FFLAGBIT(0)
+
+/* bits within the OSTMR register */
+#define OSTMR_FMASKBIT(0)
+
+/* bits within the OSTESR register */
+#define OSTESR_OST1ENS BIT(0)
+#define OSTESR_OST2ENS BIT(1)
+
+/* bits within the OSTECR register */
+#define OSTECR_OST1ENC BIT(0)
+#define OSTECR_OST2ENC BIT(1)
+
+struct ingenic_soc_info {
+ unsigned int num_channels;
+};
+
+struct ingenic_ost_clk_info {
+ struct clk_init_data init_data;
+ u8 ostccr_reg;
+};
+
+struct ingenic_ost_clk {
+ struct clk_hw hw;
+ unsigned int idx;
+ struct ingenic_ost *ost;
+ const struct ingenic_ost_clk_info *info;
+};
+
+struct ingenic_ost {
+ void __iomem *base;
+ const struct ingenic_soc_info *soc_info;
+ struct clk *clk, *percpu_timer_clk, *global_timer_clk;
+ struct clock_event_device cevt;
+ struct clocksource cs;
+ char name[20];
+
+ struct clk_hw_onecell_data *clocks;
+};
+
+static struct ingenic_ost *ingenic_ost;
+
+static inline struct ingenic_ost_clk *to_ost_clk(struct clk_hw *hw)
+{
+ return container_of(hw, struct ingenic_ost_clk, hw);
+}
+
+static
[PATCH v2] hung_task:add detecting task in D state milliseconds timeout
current hung_task_check_interval_secs and hung_task_timeout_secs
only supports seconds. In some cases,the TASK_UNINTERRUPTIBLE state
takes less than 1 second,may need to hung task trigger panic
get ramdump or print all cpu task.
modify hung_task_check_interval_secs to hung_task_check_interval_millisecs,
check interval use milliseconds. Add hung_task_timeout_millisecs file to
set milliseconds.
task timeout = hung_task_timeout_secs * 1000 + hung_task_timeout_millisecs.
(timeout * HZ / 1000) calculate how many are generated jiffies
in timeout milliseconds.
Signed-off-by: yang che
---
v1->v2:
add hung_task_check_interval_millisecs,hung_task_timeout_millisecs.
fix writing to the millisecond file silently overrides the setting in
the seconds file.
[1]https://lore.kernel.org/lkml/CAN_w4MWMfoDGfpON-bYHrU=kujg2vpfj01zbn4r-iwm4ayy...@mail.gmail.com
include/linux/sched/sysctl.h | 3 ++-
kernel/hung_task.c | 25 ++---
kernel/sysctl.c | 12 ++--
3 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index 660ac49..179c331 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -16,8 +16,9 @@ extern unsigned int sysctl_hung_task_all_cpu_backtrace;
extern int sysctl_hung_task_check_count;
extern unsigned int sysctl_hung_task_panic;
+extern unsigned long sysctl_hung_task_timeout_millisecs;
extern unsigned long sysctl_hung_task_timeout_secs;
-extern unsigned long sysctl_hung_task_check_interval_secs;
+extern unsigned long sysctl_hung_task_check_interval_millisecs;
extern int sysctl_hung_task_warnings;
int proc_dohung_task_timeout_secs(struct ctl_table *table, int write,
void *buffer, size_t *lenp, loff_t *ppos);
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index ce76f49..809c999 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -37,6 +37,7 @@ int __read_mostly sysctl_hung_task_check_count =
PID_MAX_LIMIT;
* the RCU grace period. So it needs to be upper-bound.
*/
#define HUNG_TASK_LOCK_BREAK (HZ / 10)
+#define SECONDS 1000
/*
* Zero means infinite timeout - no checking done:
@@ -44,9 +45,14 @@ int __read_mostly sysctl_hung_task_check_count =
PID_MAX_LIMIT;
unsigned long __read_mostly sysctl_hung_task_timeout_secs =
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT;
/*
+ * Zero means only use sysctl_hung_task_timeout_secs
+ */
+unsigned long __read_mostly sysctl_hung_task_timeout_millisecs;
+
+/*
* Zero (default value) means use sysctl_hung_task_timeout_secs:
*/
-unsigned long __read_mostly sysctl_hung_task_check_interval_secs;
+unsigned long __read_mostly sysctl_hung_task_check_interval_millisecs;
int __read_mostly sysctl_hung_task_warnings = 10;
@@ -108,7 +114,8 @@ static void check_hung_task(struct task_struct *t, unsigned
long timeout)
t->last_switch_time = jiffies;
return;
}
- if (time_is_after_jiffies(t->last_switch_time + timeout * HZ))
+
+ if (time_is_after_jiffies(t->last_switch_time + (timeout * HZ) /
SECONDS))
return;
trace_sched_process_hang(t);
@@ -126,13 +133,16 @@ static void check_hung_task(struct task_struct *t,
unsigned long timeout)
if (sysctl_hung_task_warnings) {
if (sysctl_hung_task_warnings > 0)
sysctl_hung_task_warnings--;
- pr_err("INFO: task %s:%d blocked for more than %ld seconds.\n",
- t->comm, t->pid, (jiffies - t->last_switch_time) / HZ);
+
+ pr_err("INFO: task %s:%d blocked for more than %ld seconds %ld
milliseconds.\n",
+ t->comm, t->pid, (jiffies - t->last_switch_time) / HZ,
+ (jiffies - t->last_switch_time) % HZ * (SECONDS / HZ));
pr_err(" %s %s %.*s\n",
print_tainted(), init_utsname()->release,
(int)strcspn(init_utsname()->version, " "),
init_utsname()->version);
pr_err("\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\""
+ "\"echo 0 >
/proc/sys/kernel/hung_task_timeout_millisecs\""
" disables this message.\n");
sched_show_task(t);
hung_task_show_lock = true;
@@ -217,7 +227,7 @@ static long hung_timeout_jiffies(unsigned long last_checked,
unsigned long timeout)
{
/* timeout of 0 will disable the watchdog */
- return timeout ? last_checked - jiffies + timeout * HZ :
+ return timeout ? last_checked - jiffies + (timeout * HZ) / SECONDS :
MAX_SCHEDULE_TIMEOUT;
}
@@ -281,8 +291,9 @@ static int watchdog(void *dummy)
set_user_nice(current, 0);
for ( ; ; ) {
- unsigned long timeout = sysctl_hung_task_timeout_secs;
- unsigned long interval = sysctl_hung_task_che
Re: [PATCH v4 1/2] dt-bindings: timer: Add Ingenic X1000 OST bindings.
Hi Zhou,
Le dim. 5 juil. 2020 à 20:34, 周琰杰 (Zhou Yanjie)
a écrit :
Add the OST bindings for the X1 SoC from Ingenic.
Tested-by: 周正 (Zhou Zheng)
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Paul Cercueil
Cheers,
-Paul
---
Notes:
v1->v2:
No change.
v2->v3:
Fix wrong parameters in "clocks".
v3->v4:
1.Rename "ingenic,ost.yaml" to "ingenic,sysost.yaml".
2.Rename "ingenic,ost.h" to "ingenic,sysost.h".
3.Modify the description in "ingenic,sysost.yaml".
.../devicetree/bindings/timer/ingenic,sysost.yaml | 60
++
include/dt-bindings/clock/ingenic,sysost.h | 12 +
2 files changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
create mode 100644 include/dt-bindings/clock/ingenic,sysost.h
diff --git
a/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
b/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
new file mode 100644
index ..03257ed806fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/ingenic,sysost.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for SYSOST in Ingenic XBurst family SoCs
+
+maintainers:
+ - 周琰杰 (Zhou Yanjie)
+
+description:
+ The SYSOST in an Ingenic SoC provides one 64bit timer for
clocksource
+ and one or more 32bit timers for clockevent.
+
+properties:
+ compatible:
+oneOf:
+
+ - enum:
+ - ingenic,x1000-ost
+ - ingenic,x2000-ost
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: ost
+
+ interrupts:
+maxItems: 1
+
+required:
+ - "#clock-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+examples:
+ - |
+#include
+
+ost: timer@1200 {
+ compatible = "ingenic,x1000-ost";
+ reg = <0x1200 0x3c>;
+
+ #clock-cells = <1>;
+
+ clocks = <&cgu X1000_CLK_OST>;
+ clock-names = "ost";
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <3>;
+ };
+...
diff --git a/include/dt-bindings/clock/ingenic,sysost.h
b/include/dt-bindings/clock/ingenic,sysost.h
new file mode 100644
index ..9ac88e90babf
--- /dev/null
+++ b/include/dt-bindings/clock/ingenic,sysost.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides clock numbers for the ingenic,tcu DT binding.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_INGENIC_OST_H__
+#define __DT_BINDINGS_CLOCK_INGENIC_OST_H__
+
+#define OST_CLK_PERCPU_TIMER 0
+#define OST_CLK_GLOBAL_TIMER 1
+
+#endif /* __DT_BINDINGS_CLOCK_INGENIC_OST_H__ */
--
2.11.0
Re: [PATCH v4 2/2] clocksource: Ingenic: Add support for the Ingenic X1000 OST.
Hi Zhou,
Le dim. 5 juil. 2020 à 20:34, 周琰杰 (Zhou Yanjie)
a écrit :
X1000 and SoCs after X1000 (such as X1500 and X1830) had a separate
OST, it no longer belongs to TCU. This driver will register both a
clocksource and a sched_clock to the system.
Tested-by: 周正 (Zhou Zheng)
Co-developed-by: 漆鹏振 (Qi Pengzhen)
Signed-off-by: 漆鹏振 (Qi Pengzhen)
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
Notes:
v1->v2:
Fix compile warnings.
Reported-by: kernel test robot
v2->v3:
No change.
v3->v4:
1.Remove unrelated changes.
2.Remove ost_clock_parent enum.
3.Remove ost->percpu_timer_channel/ost->global_timer_channel.
4.Set up independent .recalc_rate/.set_rate for percpu/global
timer.
5.No longer call functions in variable declarations.
drivers/clocksource/Kconfig | 11 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/ingenic-sysost.c | 539
+++
3 files changed, 551 insertions(+)
create mode 100644 drivers/clocksource/ingenic-sysost.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 91418381fcd4..1bca8b8fb30f 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -696,6 +696,17 @@ config INGENIC_TIMER
help
Support for the timer/counter unit of the Ingenic JZ SoCs.
+config INGENIC_SYSOST
+ bool "Clocksource/timer using the SYSOST in Ingenic X SoCs"
+ default MACH_INGENIC
+ depends on MIPS || COMPILE_TEST
+ depends on COMMON_CLK
+ select MFD_SYSCON
+ select TIMER_OF
+ select IRQ_DOMAIN
+ help
+ Support for the SYSOST of the Ingenic X Series SoCs.
+
config INGENIC_OST
bool "Clocksource for Ingenic OS Timer"
depends on MIPS || COMPILE_TEST
diff --git a/drivers/clocksource/Makefile
b/drivers/clocksource/Makefile
index bdda1a2e4097..3994e221e262 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_H8300_TMR8) += h8300_timer8.o
obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
obj-$(CONFIG_INGENIC_OST) += ingenic-ost.o
+obj-$(CONFIG_INGENIC_SYSOST) += ingenic-sysost.o
obj-$(CONFIG_INGENIC_TIMER)+= ingenic-timer.o
obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
obj-$(CONFIG_X86_NUMACHIP) += numachip.o
diff --git a/drivers/clocksource/ingenic-sysost.c
b/drivers/clocksource/ingenic-sysost.c
new file mode 100644
index ..f6dab3da68fb
--- /dev/null
+++ b/drivers/clocksource/ingenic-sysost.c
@@ -0,0 +1,539 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Ingenic XBurst SoCs SYSOST clocks driver
+ * Copyright (c) 2020 周琰杰 (Zhou Yanjie)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* OST register offsets */
+#define OST_REG_OSTCCR 0x00
+#define OST_REG_OSTCR 0x08
+#define OST_REG_OSTFR 0x0c
+#define OST_REG_OSTMR 0x10
+#define OST_REG_OST1DFR0x14
+#define OST_REG_OST1CNT0x18
+#define OST_REG_OST2CNTL 0x20
+#define OST_REG_OSTCNT2HBUF0x24
+#define OST_REG_OSTESR 0x34
+#define OST_REG_OSTECR 0x38
+
+/* bits within the OSTCCR register */
+#define OSTCCR_PRESCALE1_MASK 0x3
+#define OSTCCR_PRESCALE2_MASK 0xc
+#define OSTCCR_PRESCALE1_LSB 0
+#define OSTCCR_PRESCALE2_LSB 2
+
+/* bits within the OSTCR register */
+#define OSTCR_OST1CLR BIT(0)
+#define OSTCR_OST2CLR BIT(1)
+
+/* bits within the OSTFR register */
+#define OSTFR_FFLAGBIT(0)
+
+/* bits within the OSTMR register */
+#define OSTMR_FMASKBIT(0)
+
+/* bits within the OSTESR register */
+#define OSTESR_OST1ENS BIT(0)
+#define OSTESR_OST2ENS BIT(1)
+
+/* bits within the OSTECR register */
+#define OSTECR_OST1ENC BIT(0)
+#define OSTECR_OST2ENC BIT(1)
+
+struct ingenic_soc_info {
+ unsigned int num_channels;
+};
+
+struct ingenic_ost_clk_info {
+ struct clk_init_data init_data;
+ u8 ostccr_reg;
+};
+
+struct ingenic_ost_clk {
+ struct clk_hw hw;
+ unsigned int idx;
+ struct ingenic_ost *ost;
+ const struct ingenic_ost_clk_info *info;
+};
+
+struct ingenic_ost {
+ void __iomem *base;
+ const struct ingenic_soc_info *soc_info;
+ struct clk *clk, *percpu_timer_clk, *global_timer_clk;
+ struct clock_event_device cevt;
+ struct clocksource cs;
+ char name[20];
+
+ struct clk_hw_onecell_data *clocks;
+};
+
+static struct ingenic_ost *ingenic_ost;
+
+static inline struct ingenic_ost_clk *to_ost_clk(struct clk_hw *hw)
+{
+
Re: [mm] 4e2c82a409: ltp.overcommit_memory01.fail
On Sun, Jul 05, 2020 at 08:15:03AM -0400, Qian Cai wrote: > > > > On Jul 5, 2020, at 12:45 AM, Feng Tang wrote: > > > > I did reproduce the problem, and from the debugging, this should > > be the same root cause as lore.kernel.org/lkml/20200526181459.gd...@lca.pw/ > > that loosing the batch cause some accuracy problem, and the solution of > > adding some sync is still needed, which is dicussed in > > Well, before taking any of those patches now to fix the regression, we will > need some performance data first. If it turned out the original performance > gain is no longer relevant anymore due to this regression fix on top, it is > best to drop this patchset and restore that VM_WARN_ONCE, so you can retry > later once you found a better way to optimize. The fix of adding sync only happens when the memory policy is being changed to OVERCOMMIT_NEVER, which is not a frequent operation in normal cases. For the performance improvment data both in commit log and 0day report https://lore.kernel.org/lkml/20200622132548.GS5535@shao2-debian/ it is for the will-it-scale's mmap testcase, which will not runtime change memory overcommit policy, so the data should be still valid with this fix. Thanks, Feng
[GIT PULL] io_uring fix for 5.8-rc4
Hi Linus, Andres reported a regression with the fix that was merged earlier this week, where his setup of using signals to interrupt io_uring CQ waits no longer worked correctly. Fix this, and also limit our use of TWA_SIGNAL to the case where we need it, and continue using TWA_RESUME for task_work as before. Since the original is marked for 5.7 stable, let's flush this one out before -rc4 is tagged. Please pull! The following changes since commit ce593a6c480a22acba08795be313c0c6d49dd35d: io_uring: use signal based task_work running (2020-06-30 12:39:05 -0600) are available in the Git repository at: git://git.kernel.dk/linux-block.git tags/io_uring-5.8-2020-07-05 for you to fetch changes up to b7db41c9e03b5189bc94993bd50e4506ac9e34c1: io_uring: fix regression with always ignoring signals in io_cqring_wait() (2020-07-04 13:44:45 -0600) io_uring-5.8-2020-07-05 Jens Axboe (1): io_uring: fix regression with always ignoring signals in io_cqring_wait() fs/io_uring.c | 29 ++--- 1 file changed, 22 insertions(+), 7 deletions(-) -- Jens Axboe
[PATCH 5/9] habanalabs: Extract ECC information from FW
ECC (Error Correcting Code) interrupts are going to be handled
by the FW. Hence, we define an interface in which the driver can
obtain the relevant ECC information.
This information is needed for monitoring and can also lead
to a hard reset if ECC error is not correctable.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/gaudi/gaudi.c | 366 ++
drivers/misc/habanalabs/include/armcp_if.h| 12 +-
.../include/gaudi/asic_reg/gaudi_regs.h | 19 +-
3 files changed, 146 insertions(+), 251 deletions(-)
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c
b/drivers/misc/habanalabs/gaudi/gaudi.c
index aa4139626a04..888f42adee6a 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -316,6 +316,13 @@ static enum hl_queue_type
gaudi_queue_type[GAUDI_QUEUE_ID_SIZE] = {
QUEUE_TYPE_NA, /* GAUDI_QUEUE_ID_NIC_9_3 */
};
+struct ecc_info_extract_params {
+ u64 block_address;
+ u32 num_memories;
+ bool derr;
+ bool disable_clock_gating;
+};
+
static int gaudi_mmu_update_asid_hop0_addr(struct hl_device *hdev, u32 asid,
u64 phys_addr);
static int gaudi_send_job_on_qman0(struct hl_device *hdev,
@@ -5117,62 +5124,75 @@ static void gaudi_print_mmu_error_info(struct hl_device
*hdev)
* | |0xF4C memory wrappers 127:96
|
*
+---+--+
*/
-static void gaudi_print_ecc_info_generic(struct hl_device *hdev,
- const char *block_name,
- u64 block_address, int num_memories,
- bool derr, bool disable_clock_gating)
+static int gaudi_extract_ecc_info(struct hl_device *hdev,
+ struct ecc_info_extract_params *params, u64 *ecc_address,
+ u64 *ecc_syndrom, u8 *memory_wrapper_idx)
{
struct gaudi_device *gaudi = hdev->asic_specific;
- int num_mem_regs = num_memories / 32 + ((num_memories % 32) ? 1 : 0);
+ u32 i, num_mem_regs, reg, err_bit;
+ u64 err_addr, err_word = 0;
+ int rc = 0;
- if (block_address >= CFG_BASE)
- block_address -= CFG_BASE;
+ num_mem_regs = params->num_memories / 32 +
+ ((params->num_memories % 32) ? 1 : 0);
- if (derr)
- block_address += GAUDI_ECC_DERR0_OFFSET;
+ if (params->block_address >= CFG_BASE)
+ params->block_address -= CFG_BASE;
+
+ if (params->derr)
+ err_addr = params->block_address + GAUDI_ECC_DERR0_OFFSET;
else
- block_address += GAUDI_ECC_SERR0_OFFSET;
+ err_addr = params->block_address + GAUDI_ECC_SERR0_OFFSET;
- if (disable_clock_gating) {
+ if (params->disable_clock_gating) {
mutex_lock(&gaudi->clk_gate_mutex);
hdev->asic_funcs->disable_clock_gating(hdev);
}
- switch (num_mem_regs) {
- case 1:
- dev_err(hdev->dev,
- "%s ECC indication: 0x%08x\n",
- block_name, RREG32(block_address));
- break;
- case 2:
- dev_err(hdev->dev,
- "%s ECC indication: 0x%08x 0x%08x\n",
- block_name,
- RREG32(block_address), RREG32(block_address + 4));
- break;
- case 3:
- dev_err(hdev->dev,
- "%s ECC indication: 0x%08x 0x%08x 0x%08x\n",
- block_name,
- RREG32(block_address), RREG32(block_address + 4),
- RREG32(block_address + 8));
- break;
- case 4:
- dev_err(hdev->dev,
- "%s ECC indication: 0x%08x 0x%08x 0x%08x 0x%08x\n",
- block_name,
- RREG32(block_address), RREG32(block_address + 4),
- RREG32(block_address + 8), RREG32(block_address + 0xc));
- break;
- default:
- break;
+ /* Set invalid wrapper index */
+ *memory_wrapper_idx = 0xFF;
+
+ /* Iterate through memory wrappers, a single bit must be set */
+ for (i = 0 ; i > num_mem_regs ; i++) {
+ err_addr += i * 4;
+ err_word = RREG32(err_addr);
+ if (err_word) {
+ err_bit = __ffs(err_word);
+ *memory_wrapper_idx = err_bit + (32 * i);
+ break;
+ }
+ }
+ if (*memory_wrapper_idx == 0xFF) {
+ dev_err(hdev->dev, "ECC error information cannot be found\n");
+ rc = -EINVAL;
+ goto enable_clk_gate;
}
- if (disable_
[PATCH 3/9] habanalabs: extract cpu boot status lookup
From: Christine Gharzuzi
Extract detection of the cpu boot status to a function
to allow code reuse
Signed-off-by: Christine Gharzuzi
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/firmware_if.c | 92 ++-
1 file changed, 48 insertions(+), 44 deletions(-)
diff --git a/drivers/misc/habanalabs/firmware_if.c
b/drivers/misc/habanalabs/firmware_if.c
index 9e7f203a09d7..3be1549cd137 100644
--- a/drivers/misc/habanalabs/firmware_if.c
+++ b/drivers/misc/habanalabs/firmware_if.c
@@ -393,6 +393,53 @@ static void fw_read_errors(struct hl_device *hdev, u32
boot_err0_reg)
"Device boot error - NIC F/W initialization failed\n");
}
+static void hl_detect_cpu_boot_status(struct hl_device *hdev, u32 status)
+{
+ switch (status) {
+ case CPU_BOOT_STATUS_NA:
+ dev_err(hdev->dev,
+ "Device boot error - BTL did NOT run\n");
+ break;
+ case CPU_BOOT_STATUS_IN_WFE:
+ dev_err(hdev->dev,
+ "Device boot error - Stuck inside WFE loop\n");
+ break;
+ case CPU_BOOT_STATUS_IN_BTL:
+ dev_err(hdev->dev,
+ "Device boot error - Stuck in BTL\n");
+ break;
+ case CPU_BOOT_STATUS_IN_PREBOOT:
+ dev_err(hdev->dev,
+ "Device boot error - Stuck in Preboot\n");
+ break;
+ case CPU_BOOT_STATUS_IN_SPL:
+ dev_err(hdev->dev,
+ "Device boot error - Stuck in SPL\n");
+ break;
+ case CPU_BOOT_STATUS_IN_UBOOT:
+ dev_err(hdev->dev,
+ "Device boot error - Stuck in u-boot\n");
+ break;
+ case CPU_BOOT_STATUS_DRAM_INIT_FAIL:
+ dev_err(hdev->dev,
+ "Device boot error - DRAM initialization failed\n");
+ break;
+ case CPU_BOOT_STATUS_UBOOT_NOT_READY:
+ dev_err(hdev->dev,
+ "Device boot error - u-boot stopped by user\n");
+ break;
+ case CPU_BOOT_STATUS_TS_INIT_FAIL:
+ dev_err(hdev->dev,
+ "Device boot error - Thermal Sensor initialization
failed\n");
+ break;
+ default:
+ dev_err(hdev->dev,
+ "Device boot error - Invalid status code %d\n",
+ status);
+ break;
+ }
+}
+
int hl_fw_init_cpu(struct hl_device *hdev, u32 cpu_boot_status_reg,
u32 msg_to_cpu_reg, u32 cpu_msg_status_reg,
u32 boot_err0_reg, bool skip_bmc,
@@ -466,50 +513,7 @@ int hl_fw_init_cpu(struct hl_device *hdev, u32
cpu_boot_status_reg,
* versions but we keep them here for backward compatibility
*/
if (rc) {
- switch (status) {
- case CPU_BOOT_STATUS_NA:
- dev_err(hdev->dev,
- "Device boot error - BTL did NOT run\n");
- break;
- case CPU_BOOT_STATUS_IN_WFE:
- dev_err(hdev->dev,
- "Device boot error - Stuck inside WFE loop\n");
- break;
- case CPU_BOOT_STATUS_IN_BTL:
- dev_err(hdev->dev,
- "Device boot error - Stuck in BTL\n");
- break;
- case CPU_BOOT_STATUS_IN_PREBOOT:
- dev_err(hdev->dev,
- "Device boot error - Stuck in Preboot\n");
- break;
- case CPU_BOOT_STATUS_IN_SPL:
- dev_err(hdev->dev,
- "Device boot error - Stuck in SPL\n");
- break;
- case CPU_BOOT_STATUS_IN_UBOOT:
- dev_err(hdev->dev,
- "Device boot error - Stuck in u-boot\n");
- break;
- case CPU_BOOT_STATUS_DRAM_INIT_FAIL:
- dev_err(hdev->dev,
- "Device boot error - DRAM initialization
failed\n");
- break;
- case CPU_BOOT_STATUS_UBOOT_NOT_READY:
- dev_err(hdev->dev,
- "Device boot error - u-boot stopped by user\n");
- break;
- case CPU_BOOT_STATUS_TS_INIT_FAIL:
- dev_err(hdev->dev,
- "Device boot error - Thermal Sensor
initialization failed\n");
- break;
- default:
- dev_err(hdev->dev,
- "Device boot error - Invalid status code %d\n",
- status);
- break;
- }
-
+
[PATCH 2/9] habanalabs: rephrase error messages
rephrase some error/warning/notice messages to make them more accessible to
ordinary users.
There is no need to print context ASID as the driver currently doesn't
support multiple contexts.
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/command_submission.c | 20 +---
drivers/misc/habanalabs/context.c| 3 +--
drivers/misc/habanalabs/firmware_if.c| 4 ++--
drivers/misc/habanalabs/memory.c | 3 +--
4 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/misc/habanalabs/command_submission.c
b/drivers/misc/habanalabs/command_submission.c
index 62dab99dda98..f81d6685e011 100644
--- a/drivers/misc/habanalabs/command_submission.c
+++ b/drivers/misc/habanalabs/command_submission.c
@@ -373,9 +373,9 @@ static void cs_timedout(struct work_struct *work)
hdev = cs->ctx->hdev;
ctx_asid = cs->ctx->asid;
- /* TODO: add information about last signaled seq and last emitted seq */
- dev_err(hdev->dev, "User %d command submission %llu got stuck!\n",
- ctx_asid, cs->sequence);
+ dev_err(hdev->dev,
+ "Command submission %llu has not finished in time!\n",
+ cs->sequence);
cs_put(cs);
@@ -1130,7 +1130,7 @@ static long _hl_cs_wait_ioctl(struct hl_device *hdev,
rc = PTR_ERR(fence);
if (rc == -EINVAL)
dev_notice_ratelimited(hdev->dev,
- "Can't wait on seq %llu because current CS is
at seq %llu\n",
+ "Can't wait on CS %llu because current CS is at
seq %llu\n",
seq, ctx->cs_sequence);
} else if (fence) {
rc = dma_fence_wait_timeout(fence, true, timeout);
@@ -1163,15 +1163,21 @@ int hl_cs_wait_ioctl(struct hl_fpriv *hpriv, void *data)
memset(args, 0, sizeof(*args));
if (rc < 0) {
- dev_err_ratelimited(hdev->dev,
- "Error %ld on waiting for CS handle %llu\n",
- rc, seq);
if (rc == -ERESTARTSYS) {
+ dev_err_ratelimited(hdev->dev,
+ "user process got signal while waiting for CS
handle %llu\n",
+ seq);
args->out.status = HL_WAIT_CS_STATUS_INTERRUPTED;
rc = -EINTR;
} else if (rc == -ETIMEDOUT) {
+ dev_err_ratelimited(hdev->dev,
+ "CS %llu has timed-out while user process is
waiting for it\n",
+ seq);
args->out.status = HL_WAIT_CS_STATUS_TIMEDOUT;
} else if (rc == -EIO) {
+ dev_err_ratelimited(hdev->dev,
+ "CS %llu has been aborted while user process is
waiting for it\n",
+ seq);
args->out.status = HL_WAIT_CS_STATUS_ABORTED;
}
return rc;
diff --git a/drivers/misc/habanalabs/context.c
b/drivers/misc/habanalabs/context.c
index 1b96fefa4a65..1e3e5b19ecd9 100644
--- a/drivers/misc/habanalabs/context.c
+++ b/drivers/misc/habanalabs/context.c
@@ -112,8 +112,7 @@ void hl_ctx_free(struct hl_device *hdev, struct hl_ctx *ctx)
return;
dev_warn(hdev->dev,
- "Context %d closed or terminated but its CS are executing\n",
- ctx->asid);
+ "user process released device but its command submissions are
still executing\n");
}
int hl_ctx_init(struct hl_device *hdev, struct hl_ctx *ctx, bool is_kernel_ctx)
diff --git a/drivers/misc/habanalabs/firmware_if.c
b/drivers/misc/habanalabs/firmware_if.c
index 6900c01d060f..9e7f203a09d7 100644
--- a/drivers/misc/habanalabs/firmware_if.c
+++ b/drivers/misc/habanalabs/firmware_if.c
@@ -289,7 +289,7 @@ int hl_fw_armcp_info_get(struct hl_device *hdev)
HL_ARMCP_INFO_TIMEOUT_USEC, &result);
if (rc) {
dev_err(hdev->dev,
- "Failed to send ArmCP info pkt, error %d\n", rc);
+ "Failed to handle ArmCP info pkt, error %d\n", rc);
goto out;
}
@@ -340,7 +340,7 @@ int hl_fw_get_eeprom_data(struct hl_device *hdev, void
*data, size_t max_size)
if (rc) {
dev_err(hdev->dev,
- "Failed to send ArmCP EEPROM packet, error %d\n", rc);
+ "Failed to handle ArmCP EEPROM packet, error %d\n", rc);
goto out;
}
diff --git a/drivers/misc/habanalabs/memory.c b/drivers/misc/habanalabs/memory.c
index 47da84a17719..e4e1693e5c6c 100644
--- a/drivers/misc/habanalabs/memory.c
+++ b/drivers/misc/habanalabs/memory.c
@@ -1730,8 +1730,7 @@ void hl_vm_ctx_fini(struct hl_ctx *ctx)
*/
if (!hdev->hard_reset_
[PATCH 1/9] habanalabs: Increase queues depth
From: Ofir Bitton
After recent concurrent cs amount increase, we must also
increase queues depth since much more concurrent work can be done.
All external queue depths were increased to 4096 as gaudi's
internal queue depths were also increased to 1024.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/gaudi/gaudiP.h | 6 ++---
drivers/misc/habanalabs/habanalabs.h | 31 --
drivers/misc/habanalabs/hw_queue.c | 2 --
drivers/misc/habanalabs/irq.c | 4
4 files changed, 7 insertions(+), 36 deletions(-)
diff --git a/drivers/misc/habanalabs/gaudi/gaudiP.h
b/drivers/misc/habanalabs/gaudi/gaudiP.h
index 3958fe38c8ee..bdc5f96085a7 100644
--- a/drivers/misc/habanalabs/gaudi/gaudiP.h
+++ b/drivers/misc/habanalabs/gaudi/gaudiP.h
@@ -123,14 +123,14 @@
/* Internal QMANs PQ sizes */
-#define MME_QMAN_LENGTH64
+#define MME_QMAN_LENGTH1024
#define MME_QMAN_SIZE_IN_BYTES (MME_QMAN_LENGTH * QMAN_PQ_ENTRY_SIZE)
-#define HBM_DMA_QMAN_LENGTH64
+#define HBM_DMA_QMAN_LENGTH1024
#define HBM_DMA_QMAN_SIZE_IN_BYTES \
(HBM_DMA_QMAN_LENGTH * QMAN_PQ_ENTRY_SIZE)
-#define TPC_QMAN_LENGTH64
+#define TPC_QMAN_LENGTH1024
#define TPC_QMAN_SIZE_IN_BYTES (TPC_QMAN_LENGTH * QMAN_PQ_ENTRY_SIZE)
#define SRAM_USER_BASE_OFFSET GAUDI_DRIVER_SRAM_RESERVED_SIZE_FROM_START
diff --git a/drivers/misc/habanalabs/habanalabs.h
b/drivers/misc/habanalabs/habanalabs.h
index 4e68a41cce77..e4d6f7c91194 100644
--- a/drivers/misc/habanalabs/habanalabs.h
+++ b/drivers/misc/habanalabs/habanalabs.h
@@ -378,38 +378,15 @@ struct hl_cb {
struct hl_cs_job;
-/*
- * Currently, there are two limitations on the maximum length of a queue:
- *
- * 1. The memory footprint of the queue. The current allocated space for the
- *queue is PAGE_SIZE. Because each entry in the queue is HL_BD_SIZE,
- *the maximum length of the queue can be PAGE_SIZE / HL_BD_SIZE,
- *which currently is 4096/16 = 256 entries.
- *
- *To increase that, we need either to decrease the size of the
- *BD (difficult), or allocate more than a single page (easier).
- *
- * 2. Because the size of the JOB handle field in the BD CTL / completion queue
- *is 10-bit, we can have up to 1024 open jobs per hardware queue.
- *Therefore, each queue can hold up to 1024 entries.
- *
- * HL_QUEUE_LENGTH is in units of struct hl_bd.
- * HL_QUEUE_LENGTH * sizeof(struct hl_bd) should be <= HL_PAGE_SIZE
- */
-
-#define HL_PAGE_SIZE 4096 /* minimum page size */
-/* Must be power of 2 (HL_PAGE_SIZE / HL_BD_SIZE) */
-#define HL_QUEUE_LENGTH256
+/* Queue length of external and HW queues */
+#define HL_QUEUE_LENGTH4096
#define HL_QUEUE_SIZE_IN_BYTES (HL_QUEUE_LENGTH * HL_BD_SIZE)
-/*
- * HL_CQ_LENGTH is in units of struct hl_cq_entry.
- * HL_CQ_LENGTH should be <= HL_PAGE_SIZE
- */
+/* HL_CQ_LENGTH is in units of struct hl_cq_entry */
#define HL_CQ_LENGTH HL_QUEUE_LENGTH
#define HL_CQ_SIZE_IN_BYTES(HL_CQ_LENGTH * HL_CQ_ENTRY_SIZE)
-/* Must be power of 2 (HL_PAGE_SIZE / HL_EQ_ENTRY_SIZE) */
+/* Must be power of 2 */
#define HL_EQ_LENGTH 64
#define HL_EQ_SIZE_IN_BYTES(HL_EQ_LENGTH * HL_EQ_ENTRY_SIZE)
diff --git a/drivers/misc/habanalabs/hw_queue.c
b/drivers/misc/habanalabs/hw_queue.c
index 27f0c34b63b9..f5a10a5ac300 100644
--- a/drivers/misc/habanalabs/hw_queue.c
+++ b/drivers/misc/habanalabs/hw_queue.c
@@ -780,8 +780,6 @@ static int queue_init(struct hl_device *hdev, struct
hl_hw_queue *q,
{
int rc;
- BUILD_BUG_ON(HL_QUEUE_SIZE_IN_BYTES > HL_PAGE_SIZE);
-
q->hw_queue_id = hw_queue_id;
switch (q->queue_type) {
diff --git a/drivers/misc/habanalabs/irq.c b/drivers/misc/habanalabs/irq.c
index 6981d67153b1..7a4878edb1a3 100644
--- a/drivers/misc/habanalabs/irq.c
+++ b/drivers/misc/habanalabs/irq.c
@@ -220,8 +220,6 @@ int hl_cq_init(struct hl_device *hdev, struct hl_cq *q, u32
hw_queue_id)
{
void *p;
- BUILD_BUG_ON(HL_CQ_SIZE_IN_BYTES > HL_PAGE_SIZE);
-
p = hdev->asic_funcs->asic_dma_alloc_coherent(hdev, HL_CQ_SIZE_IN_BYTES,
&q->bus_address, GFP_KERNEL | __GFP_ZERO);
if (!p)
@@ -282,8 +280,6 @@ int hl_eq_init(struct hl_device *hdev, struct hl_eq *q)
{
void *p;
- BUILD_BUG_ON(HL_EQ_SIZE_IN_BYTES > HL_PAGE_SIZE);
-
p = hdev->asic_funcs->cpu_accessible_dma_pool_alloc(hdev,
HL_EQ_SIZE_IN_BYTES,
&q->bus_address);
--
2.17.1
[PATCH 7/9] habanalabs: remove soft-reset support from GAUDI
Soft-reset isn't supported in GAUDI. Remove the code that performs it and
print error in case the user wants to do it via sysfs.
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/gaudi/gaudi.c | 76 ++-
1 file changed, 27 insertions(+), 49 deletions(-)
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c
b/drivers/misc/habanalabs/gaudi/gaudi.c
index a6e40dec3cd2..d3869209dbc6 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -75,7 +75,6 @@
#define GAUDI_PLDM_RESET_WAIT_MSEC 1000/* 1s */
#define GAUDI_PLDM_HRESET_TIMEOUT_MSEC 2 /* 20s */
-#define GAUDI_PLDM_SRESET_TIMEOUT_MSEC 14000 /* 14s */
#define GAUDI_PLDM_TEST_QUEUE_WAIT_USEC100 /* 1s */
#define GAUDI_PLDM_MMU_TIMEOUT_USEC(MMU_CONFIG_TIMEOUT_USEC * 100)
#define GAUDI_PLDM_QMAN0_TIMEOUT_USEC (HL_DEVICE_TIMEOUT_USEC * 30)
@@ -2969,46 +2968,37 @@ static void gaudi_hw_fini(struct hl_device *hdev, bool
hard_reset)
struct gaudi_device *gaudi = hdev->asic_specific;
u32 status, reset_timeout_ms, boot_strap = 0;
- if (hdev->pldm) {
- if (hard_reset)
- reset_timeout_ms = GAUDI_PLDM_HRESET_TIMEOUT_MSEC;
- else
- reset_timeout_ms = GAUDI_PLDM_SRESET_TIMEOUT_MSEC;
- } else {
- reset_timeout_ms = GAUDI_RESET_TIMEOUT_MSEC;
+ if (!hard_reset) {
+ dev_err(hdev->dev, "GAUDI doesn't support soft-reset\n");
+ return;
}
- if (hard_reset) {
- /* Tell ASIC not to re-initialize PCIe */
- WREG32(mmPREBOOT_PCIE_EN, LKD_HARD_RESET_MAGIC);
+ if (hdev->pldm)
+ reset_timeout_ms = GAUDI_PLDM_HRESET_TIMEOUT_MSEC;
+ else
+ reset_timeout_ms = GAUDI_RESET_TIMEOUT_MSEC;
- boot_strap = RREG32(mmPSOC_GLOBAL_CONF_BOOT_STRAP_PINS);
- /* H/W bug WA:
-* rdata[31:0] = strap_read_val;
-* wdata[31:0] = rdata[30:21],1'b0,rdata[20:0]
-*/
- boot_strap = (((boot_strap & 0x7FE0) << 1) |
- (boot_strap & 0x001F));
- WREG32(mmPSOC_GLOBAL_CONF_BOOT_STRAP_PINS, boot_strap & ~0x2);
-
- /* Restart BTL/BLR upon hard-reset */
- WREG32(mmPSOC_GLOBAL_CONF_BOOT_SEQ_RE_START, 1);
-
- WREG32(mmPSOC_GLOBAL_CONF_SW_ALL_RST,
- 1 << PSOC_GLOBAL_CONF_SW_ALL_RST_IND_SHIFT);
- dev_info(hdev->dev,
- "Issued HARD reset command, going to wait %dms\n",
- reset_timeout_ms);
- } else {
- /* Don't restart BTL/BLR upon soft-reset */
- WREG32(mmPSOC_GLOBAL_CONF_BOOT_SEQ_RE_START, 0);
+ /* Tell ASIC not to re-initialize PCIe */
+ WREG32(mmPREBOOT_PCIE_EN, LKD_HARD_RESET_MAGIC);
- WREG32(mmPSOC_GLOBAL_CONF_SOFT_RST,
- 1 << PSOC_GLOBAL_CONF_SOFT_RST_IND_SHIFT);
- dev_info(hdev->dev,
- "Issued SOFT reset command, going to wait %dms\n",
- reset_timeout_ms);
- }
+ boot_strap = RREG32(mmPSOC_GLOBAL_CONF_BOOT_STRAP_PINS);
+
+ /* H/W bug WA:
+* rdata[31:0] = strap_read_val;
+* wdata[31:0] = rdata[30:21],1'b0,rdata[20:0]
+*/
+ boot_strap = (((boot_strap & 0x7FE0) << 1) |
+ (boot_strap & 0x001F));
+ WREG32(mmPSOC_GLOBAL_CONF_BOOT_STRAP_PINS, boot_strap & ~0x2);
+
+ /* Restart BTL/BLR upon hard-reset */
+ WREG32(mmPSOC_GLOBAL_CONF_BOOT_SEQ_RE_START, 1);
+
+ WREG32(mmPSOC_GLOBAL_CONF_SW_ALL_RST,
+ 1 << PSOC_GLOBAL_CONF_SW_ALL_RST_IND_SHIFT);
+ dev_info(hdev->dev,
+ "Issued HARD reset command, going to wait %dms\n",
+ reset_timeout_ms);
/*
* After hard reset, we can't poll the BTM_FSM register because the PSOC
@@ -3022,18 +3012,6 @@ static void gaudi_hw_fini(struct hl_device *hdev, bool
hard_reset)
"Timeout while waiting for device to reset 0x%x\n",
status);
- if (!hard_reset) {
- gaudi->hw_cap_initialized &= ~(HW_CAP_PCI_DMA | HW_CAP_MME |
- HW_CAP_TPC_MASK |
- HW_CAP_HBM_DMA);
-
- WREG32(mmGIC_DISTRIBUTOR__5_GICD_SETSPI_NSR,
- GAUDI_EVENT_SOFT_RESET);
- return;
- }
-
- /* We continue here only for hard-reset */
-
WREG32(mmPSOC_GLOBAL_CONF_BOOT_STRAP_PINS, boot_strap);
gaudi->hw_cap_initialized &= ~(HW_CAP_CPU | HW_CAP_CPU_Q |
--
2.17.1
powerpc64-linux-ld: mm/page_alloc.o:undefined reference to `node_reclaim_distance'
Hi Matt, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 35e884f89df4c48566d745dc5a97a0d058d04263 commit: a55c7454a8c887b226a01d7eed088ccb5374d81e sched/topology: Improve load balancing on AMD EPYC systems date: 10 months ago config: powerpc-randconfig-r024-20200705 (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout a55c7454a8c887b226a01d7eed088ccb5374d81e # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): powerpc64-linux-ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash' >> powerpc64-linux-ld: mm/page_alloc.o:(.toc+0x0): undefined reference to >> `node_reclaim_distance' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
