[PATCH] drm/etnaviv: fix runtime pm imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index a31eeff2b297..da3f6ca5849f 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -1691,6 +1691,9 @@ static int etnaviv_gpu_bind(struct device *dev, struct device *master, return 0; out_sched: +#ifdef CONFIG_PM + pm_runtime_put_autosuspend(gpu->dev); +#endif etnaviv_sched_fini(gpu); out_workqueue: -- 2.17.1
Re: [PATCH] of: drop a reference on error in __of_attach_node_sysfs()
Dan Carpenter writes:
> We add a new of_node_get() to this function, but we should drop the
> reference if kobject_add().
^
fails?
>
> Fixes: 5b2c2f5a0ea3 ("of: overlay: add missing of_node_get() in
> __of_attach_node_sysfs")
> Signed-off-by: Dan Carpenter
> ---
> From static analysis. Maybe we should just call of_node_get() right
> before we return 0?
Yeah that would be simpler and equally correct AFAICS.
cheers
> diff --git a/drivers/of/kobj.c b/drivers/of/kobj.c
> index c72eef988041..a90dc4b3b060 100644
> --- a/drivers/of/kobj.c
> +++ b/drivers/of/kobj.c
> @@ -138,8 +138,10 @@ int __of_attach_node_sysfs(struct device_node *np)
>
> rc = kobject_add(>kobj, parent, "%s", name);
> kfree(name);
> - if (rc)
> + if (rc) {
> + of_node_put(np);
> return rc;
> + }
>
> for_each_property_of_node(np, pp)
> __of_add_property_sysfs(np, pp);
> --
> 2.26.2
回复: [PATCH] arm64: Fix PTRACE_SYSEMU semantics
Tested-by: Bin Lu
I have just tested all gVisor syscall test cases with ptrace(Regs, FPRegs, TLS)
on Arm64 platform.
The test results are the same as before there was no patch.
My idea is that this kernel patch has no bad effects on gVisor.
Linux Kernel version: 5.7.0-rc6+
gVisor version: release-20200511.0
> -邮件原件-
> 发件人: linux-arm-kernel 代
> 表 Catalin Marinas
> 发送时间: 2020年5月19日 20:07
> 收件人: Will Deacon
> 抄送: Will Deacon ; linux-kernel@vger.kernel.org;
> o...@redhat.com; Keno Fischer ; Sudeep Holla
> ; linux-arm-ker...@lists.infradead.org
> 主题: Re: [PATCH] arm64: Fix PTRACE_SYSEMU semantics
>
> On Mon, May 18, 2020 at 12:41:20PM +0100, Will Deacon wrote:
> > On Fri, May 15, 2020 at 06:22:53PM -0400, Keno Fischer wrote:
> > > Quoth the man page:
> > > ```
> > >If the tracee was restarted by PTRACE_SYSCALL or PTRACE_SYSEMU,
> the
> > >tracee enters syscall-enter-stop just prior to entering any system
> > >call (which will not be executed if the restart was using
> > >PTRACE_SYSEMU, regardless of any change made to registers at this
> > >point or how the tracee is restarted after this stop).
> > > ```
> > >
> > > The parenthetical comment is currently true on x86 and powerpc, but
> > > not currently true on arm64. arm64 re-checks the _TIF_SYSCALL_EMU
> > > flag after the syscall entry ptrace stop. However, at this point, it
> > > reflects which method was used to re-start the syscall at the entry
> > > stop, rather than the method that was used to reach it.
> > > Fix that by recording the original flag before performing the ptrace
> > > stop, bringing the behavior in line with documentation and x86/powerpc.
> > >
> > > Signed-off-by: Keno Fischer
> > > ---
> > > arch/arm64/kernel/ptrace.c | 8 +---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> > > index b3d3005d9515..b67b4d14aa17 100644
> > > --- a/arch/arm64/kernel/ptrace.c
> > > +++ b/arch/arm64/kernel/ptrace.c
> > > @@ -1829,10 +1829,12 @@ static void tracehook_report_syscall(struct
> > > pt_regs *regs,
> > >
> > > int syscall_trace_enter(struct pt_regs *regs) {
> > > - if (test_thread_flag(TIF_SYSCALL_TRACE) ||
> > > - test_thread_flag(TIF_SYSCALL_EMU)) {
> > > + u32 flags = READ_ONCE(current_thread_info()->flags) &
> > > + (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE);
> > > +
> > > + if (flags) {
> >
> > nit: but I'd rather the '&' operation was in the conditional so that
> > the 'flags' variable holds all of the flags.
> >
> > With that:
> >
> > Acked-by: Will Deacon
> >
> > Also needs:
> >
> > Cc:
> > Fixes: f086f67485c5 ("arm64: ptrace: add support for syscall
> > emulation")
> >
> > Catalin -- can you pick this up for 5.7 please, with my 'nit' addressed?
>
> I'll queue it with the above addressed. I think flags also needs to be
> unsigned
> long rather than u32.
>
> However, before sending the pull request, I'd like Sudeep to confirm that it
> doesn't break his original use-case for this feature.
>
> --
> Catalin
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[PATCH] drm/etnaviv: fix memory leak when mapping prime imported buffers
When using mmap() on a prime imported buffer allocated by a
different driver (such as imx-drm) the later munmap() does
not correctly decrement the refcount of the original enaviv_gem_object,
leading to a leak.
Signed-off-by: Martin Fuzzey
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index f24dd21..28a01b8 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -93,7 +93,25 @@ static void *etnaviv_gem_prime_vmap_impl(struct
etnaviv_gem_object *etnaviv_obj)
static int etnaviv_gem_prime_mmap_obj(struct etnaviv_gem_object *etnaviv_obj,
struct vm_area_struct *vma)
{
- return dma_buf_mmap(etnaviv_obj->base.dma_buf, vma, 0);
+ int ret;
+
+ ret = dma_buf_mmap(etnaviv_obj->base.dma_buf, vma, 0);
+
+ /* drm_gem_mmap_obj() has already been called before this function
+* and has incremented our refcount, expecting it to be decremented
+* on unmap() via drm_gem_vm_close().
+* However dma_buf_mmap() invokes drm_gem_cma_prime_mmap()
+* that ends up updating the vma->vma_private_data to point to the
+* dma_buf's gem object.
+* Hence our gem object here will not have its refcount decremented
+* when userspace does unmap().
+* So decrement the refcount here to avoid a memory leak if the dma
+* buf mapping was successful.
+*/
+ if (!ret)
+ drm_gem_object_put_unlocked(_obj->base);
+
+ return ret;
}
static const struct etnaviv_gem_ops etnaviv_gem_prime_ops = {
--
1.9.1
Re: linux-next: Tree for May 19 (block/rnbd/)
Hi Randy, On Tue, May 19, 2020 at 8:59 PM Randy Dunlap wrote: > > On 5/19/20 11:03 AM, Stephen Rothwell wrote: > > Hi all, > > > > News: there will be no linux-next release tomorrow. > > > > Changes since 20200518: > > > > seen on i386: > > when CONFIG_MODULES is not set/enabled: > > ../drivers/block/rnbd/rnbd-clt-sysfs.c: In function > 'rnbd_clt_remove_dev_symlink': > ../drivers/block/rnbd/rnbd-clt-sysfs.c:435:39: error: implicit declaration of > function 'module_is_live'; did you mean 'module_driver'? > [-Werror=implicit-function-declaration] > if (strlen(dev->blk_symlink_name) && module_is_live(THIS_MODULE)) >^~ >module_driver > > > -- > ~Randy > Reported-by: Randy Dunlap Looking into this, thank you
Re: [PATCH v2 3/4] clk / soc: mediatek: Bind clock and gpu driver for mt2701
Quoting Enric Balletbo i Serra (2020-04-01 13:17:35) > Now that the mmsys driver is the top-level entry point for the > multimedia subsystem, we could bind the clock and the gpu driver on > those devices that is expected to work, so the drm driver is > intantiated by the mmsys driver and display, hopefully, working again. > > Signed-off-by: Enric Balletbo i Serra > Reviewed-by: Chun-Kuang Hu > --- Acked-by: Stephen Boyd
Re: [PATCH v2 2/4] clk / soc: mediatek: Bind clock and gpu driver for mt2712
Quoting Enric Balletbo i Serra (2020-04-01 13:17:34) > Now that the mmsys driver is the top-level entry point for the > multimedia subsystem, we could bind the clock and the gpu driver on > those devices that is expected to work, so the drm driver is > intantiated by the mmsys driver and display, hopefully, working again on > those devices. > > Signed-off-by: Enric Balletbo i Serra > Reviewed-by: Chun-Kuang Hu > --- Acked-by: Stephen Boyd
Re: [PATCH 2/8] radix-tree: Use local_lock for protection
On 2020-05-19 19:05:16 [-0700], Matthew Wilcox wrote: > > https://lore.kernel.org/r/20200519201912.1564477-1-bige...@linutronix.de > > > > With lore and b4, it should now be easy to get full patch series. > > Thats asking too much of the random people cc'd on random patches. Well, other complain that they don't care about the other 20 patches just because one patch affects them. And they can look it up if needed so you can't make everyone happy. > What is b4 anyway? git://git.kernel.org/pub/scm/utils/b4/b4.git It is a tool written by Konstantin which can grab a whole series giving the message-id of one patch in series, save the series as mbox, patch series and collect all the tags (like replies with acked/tested/…-by) and fold those tags it into the right patches. Sebastian
Re: [PATCH glibc 2/3] glibc: sched_getcpu(): use rseq cpu_id TLS on Linux (v7)
* Mathieu Desnoyers via Libc-alpha:
> diff --git a/sysdeps/unix/sysv/linux/sched_getcpu.c
> b/sysdeps/unix/sysv/linux/sched_getcpu.c
> index c019cfb3cf..2269c4f2bd 100644
> --- a/sysdeps/unix/sysv/linux/sched_getcpu.c
> +++ b/sysdeps/unix/sysv/linux/sched_getcpu.c
> @@ -18,10 +18,15 @@
> #include
> #include
> #include
> +#include
> #include
>
> -int
> -sched_getcpu (void)
> +#ifdef HAVE_GETCPU_VSYSCALL
> +# define HAVE_VSYSCALL
> +#endif
I think the #ifdef is a result of an incorrect merge of commit
d0def09ff6bbf1537beec305fdfe96a21174fb31 ("linux: Fix vDSO macros build
with time64 interfaces") and it should be removed.
The commit subject should probably say “Linux: Use rseq in sched_getcpu
if available”.
Thanks,
Florian
Re: [PATCH 1/4] clk/soc: mediatek: mt8183: Bind clock driver from platform device
Quoting matthias@kernel.org (2020-05-18 04:31:53) > From: Matthias Brugger > > The mmsys driver is now the top level entry point for the multimedia > system (mmsys), we bind the clock driver by creating a platform device. > We also bind the MediaTek DRM driver which is not yet implement and > therefor will errror out for now. > > Signed-off-by: Matthias Brugger > --- Acked-by: Stephen Boyd
Re: [PATCH 2/4] clk/soc: mediatek: mt6797: Bind clock driver from platform device
Quoting matthias@kernel.org (2020-05-18 04:31:54) > From: Matthias Brugger > > The mmsys driver is now the top level entry point for the multimedia > system (mmsys), we bind the clock driver by creating a platform device. > We also bind the MediaTek DRM driver which is not yet implement and > therefor will errror out for now. > > Signed-off-by: Matthias Brugger > --- Acked-by: Stephen Boyd
Re: [PATCH] media: staging: tegra-vde: fix runtime pm imbalance on error
20.05.2020 12:51, Dinghao Liu пишет: > pm_runtime_get_sync() increments the runtime PM usage counter even > it returns an error code. Thus a pairing decrement is needed on > the error handling path to keep the counter balanced. > > Signed-off-by: Dinghao Liu > --- > drivers/staging/media/tegra-vde/vde.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/media/tegra-vde/vde.c > b/drivers/staging/media/tegra-vde/vde.c > index d3e63512a765..dd134a3a15c7 100644 > --- a/drivers/staging/media/tegra-vde/vde.c > +++ b/drivers/staging/media/tegra-vde/vde.c > @@ -777,7 +777,7 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde > *vde, > > ret = pm_runtime_get_sync(dev); > if (ret < 0) > - goto unlock; > + goto put_runtime_pm; > > /* >* We rely on the VDE registers reset value, otherwise VDE > Hello Dinghao, Thank you for the patch. I sent out a similar patch a week ago [1]. [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20200514210847.9269-2-dig...@gmail.com/ The pm_runtime_put_noidle() should have the same effect as yours variant, although my variant won't change the last_busy RPM time, which I think is a bit more appropriate behavior.
Re: [PATCH v4 2/4] kasan: record and print the free track
On Wed, 2020-05-20 at 11:44 +0200, 'Dmitry Vyukov' via kasan-dev wrote:
> On Wed, May 20, 2020 at 11:17 AM Walter Wu wrote:
> > > > On Wed, 2020-05-20 at 13:14 +0800, Walter Wu wrote:
> > > > > > On Wed, May 20, 2020 at 6:03 AM Walter Wu
> > > > > > wrote:
> > > > > > >
> > > > > > > > On Tue, May 19, 2020 at 4:25 AM Walter Wu
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Move free track from slub alloc meta-data to slub free
> > > > > > > > > meta-data in
> > > > > > > > > order to make struct kasan_free_meta size is 16 bytes. It is
> > > > > > > > > a good
> > > > > > > > > size because it is the minimal redzone size and a good number
> > > > > > > > > of
> > > > > > > > > alignment.
> > > > > > > > >
> > > > > > > > > For free track in generic KASAN, we do the modification in
> > > > > > > > > struct
> > > > > > > > > kasan_alloc_meta and kasan_free_meta:
> > > > > > > > > - remove free track from kasan_alloc_meta.
> > > > > > > > > - add free track into kasan_free_meta.
> > > > > > > > >
> > > > > > > > > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > > > > > > > >
> > > > > > > > > Signed-off-by: Walter Wu
> > > > > > > > > Suggested-by: Dmitry Vyukov
> > > > > > > > > Cc: Andrey Ryabinin
> > > > > > > > > Cc: Dmitry Vyukov
> > > > > > > > > Cc: Alexander Potapenko
> > > > > > > > > ---
> > > > > > > > > mm/kasan/common.c | 22 ++
> > > > > > > > > mm/kasan/generic.c | 18 ++
> > > > > > > > > mm/kasan/kasan.h | 7 +++
> > > > > > > > > mm/kasan/report.c | 20
> > > > > > > > > mm/kasan/tags.c| 37 +
> > > > > > > > > 5 files changed, 64 insertions(+), 40 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > > > > > > > > index 8bc618289bb1..47b53912f322 100644
> > > > > > > > > --- a/mm/kasan/common.c
> > > > > > > > > +++ b/mm/kasan/common.c
> > > > > > > > > @@ -51,7 +51,7 @@ depot_stack_handle_t kasan_save_stack(gfp_t
> > > > > > > > > flags)
> > > > > > > > > return stack_depot_save(entries, nr_entries, flags);
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > -static inline void set_track(struct kasan_track *track,
> > > > > > > > > gfp_t flags)
> > > > > > > > > +void kasan_set_track(struct kasan_track *track, gfp_t flags)
> > > > > > > > > {
> > > > > > > > > track->pid = current->pid;
> > > > > > > > > track->stack = kasan_save_stack(flags);
> > > > > > > > > @@ -299,24 +299,6 @@ struct kasan_free_meta
> > > > > > > > > *get_free_info(struct kmem_cache *cache,
> > > > > > > > > return (void *)object +
> > > > > > > > > cache->kasan_info.free_meta_offset;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > -
> > > > > > > > > -static void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > > > - void *object, u8 tag)
> > > > > > > > > -{
> > > > > > > > > - struct kasan_alloc_meta *alloc_meta;
> > > > > > > > > - u8 idx = 0;
> > > > > > > > > -
> > > > > > > > > - alloc_meta = get_alloc_info(cache, object);
> > > > > > > > > -
> > > > > > > > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > > > - idx = alloc_meta->free_track_idx;
> > > > > > > > > - alloc_meta->free_pointer_tag[idx] = tag;
> > > > > > > > > - alloc_meta->free_track_idx = (idx + 1) %
> > > > > > > > > KASAN_NR_FREE_STACKS;
> > > > > > > > > -#endif
> > > > > > > > > -
> > > > > > > > > - set_track(_meta->free_track[idx], GFP_NOWAIT);
> > > > > > > > > -}
> > > > > > > > > -
> > > > > > > > > void kasan_poison_slab(struct page *page)
> > > > > > > > > {
> > > > > > > > > unsigned long i;
> > > > > > > > > @@ -492,7 +474,7 @@ static void *__kasan_kmalloc(struct
> > > > > > > > > kmem_cache *cache, const void *object,
> > > > > > > > > KASAN_KMALLOC_REDZONE);
> > > > > > > > >
> > > > > > > > > if (cache->flags & SLAB_KASAN)
> > > > > > > > > - set_track(_alloc_info(cache,
> > > > > > > > > object)->alloc_track, flags);
> > > > > > > > > + kasan_set_track(_alloc_info(cache,
> > > > > > > > > object)->alloc_track, flags);
> > > > > > > > >
> > > > > > > > > return set_tag(object, tag);
> > > > > > > > > }
> > > > > > > > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > > > > > > > > index 3372bdcaf92a..763d8a13e0ac 100644
> > > > > > > > > --- a/mm/kasan/generic.c
> > > > > > > > > +++ b/mm/kasan/generic.c
> > > > > > > > > @@ -344,3 +344,21 @@ void kasan_record_aux_stack(void *addr)
> > > > > > > > > alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
> > > > > > > > > alloc_info->aux_stack[0] =
> > > > > > > > > kasan_save_stack(GFP_NOWAIT);
> > > > > > > > > }
> > > > > > > > > +
> > > > > > > > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > > > + void *object, u8 tag)
[PATCH] drm/nouveau/debugfs: fix runtime pm imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 15a3d40edf02..db3711436577 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -181,8 +181,11 @@ nouveau_debugfs_pstate_set(struct file *file, const char
__user *ubuf,
}
ret = pm_runtime_get_sync(drm->dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ pm_runtime_put_autosuspend(drm->dev);
return ret;
+ }
+
ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, , sizeof(args));
pm_runtime_put_autosuspend(drm->dev);
if (ret < 0)
--
2.17.1
Re: [PATCH 3/4] clk/soc: mediatek: mt6779: Bind clock driver from platform device
Quoting matthias@kernel.org (2020-05-18 04:31:55) > From: Matthias Brugger > > The mmsys driver is now the top level entry point for the multimedia > system (mmsys), we bind the clock driver by creating a platform device. > We also bind the MediaTek DRM driver which is not yet implement and > therefor will errror out for now. > > Signed-off-by: Matthias Brugger > --- Acked-by: Stephen Boyd
This all seems to be happening, maybe I don´t need to do a distro?
I read this today, https://www.phoronix.com/scan.php?page=news_item=Microsoft-DX12-WSL2 Microsoft Announces Direct3D 12 for Linux / WSL2. Games can pull a lot of people, and maybe that is what one needs as the final push, to make an Ubuntu Karmic Koala distro work. + Seam + 0.33ms latency Renoise + Low Jitter Config Kernel 72.7 (x3pass) Doom 3, I think one can really show what "Linux" can do, and establish a standard. Mac OS also now *nix, and Microsoft is getting in on the act. An €-money integration is sure to happen, and EU is optimally located for it, as symbolicness can be in pop-worlds. If still distro guidance should be needed by me, I have now called my system Xyr O-S. Serene Greetings, Ywe Cærlyn https://www.youtube.com/channel/UCR3gmLVjHS5A702wo4bol_Q
[PATCH 2/2] xhci: Poll for U0 after disabling USB2 LPM
USB2 devices with LPM enabled may interrupt the system suspend: [ 932.510475] usb 1-7: usb suspend, wakeup 0 [ 932.510549] hub 1-0:1.0: hub_suspend [ 932.510581] usb usb1: bus suspend, wakeup 0 [ 932.510590] xhci_hcd :00:14.0: port 9 not suspended [ 932.510593] xhci_hcd :00:14.0: port 8 not suspended .. [ 932.520323] xhci_hcd :00:14.0: Port change event, 1-7, id 7, portsc: 0x400e03 .. [ 932.591405] PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -16 [ 932.591414] PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -16 [ 932.591418] PM: Device :00:14.0 failed to suspend async: error -16 During system suspend, USB core will let HC suspends the device if it doesn't have remote wakeup enabled and doesn't have any children. However, from the log above we can see that the usb 1-7 doesn't get bus suspended due to not in U0. After a while the port finished U2 -> U0 transition, interrupts the suspend process. The observation is that after disabling LPM, port doesn't transit to U0 immediately and can linger in U2. xHCI spec 4.23.5.2 states that the maximum exit latency for USB2 LPM should be BESL + 10us. The BESL for the affected device is advertised as 400us, which is still not enough based on my testing result. So let's use the maximum permitted latency, 1, to poll for U0 status to solve the issue. Signed-off-by: Kai-Heng Feng --- drivers/usb/host/xhci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 14181a7ea375..1058f604975b 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4474,6 +4474,9 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd, mutex_lock(hcd->bandwidth_mutex); xhci_change_max_exit_latency(xhci, udev, 0); mutex_unlock(hcd->bandwidth_mutex); + readl_poll_timeout(ports[port_num]->addr, pm_val, + (pm_val & PORT_PLS_MASK) == XDEV_U0, + 100, 1); return 0; } } -- 2.17.1
[PATCH 1/2] xhci: Return if xHCI doesn't support LPM
Just return if xHCI is quirked to disable LPM. We can save some time
from reading registers and doing spinlocks.
Signed-off-by: Kai-Heng Feng
---
drivers/usb/host/xhci.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index bee5deccc83d..14181a7ea375 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4390,6 +4390,9 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
int hird, exit_latency;
int ret;
+ if (xhci->quirks & XHCI_HW_LPM_DISABLE)
+ return -EPERM;
+
if (hcd->speed >= HCD_USB3 || !xhci->hw_lpm_support ||
!udev->lpm_capable)
return -EPERM;
@@ -4412,7 +4415,7 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
enable ? "enable" : "disable", port_num + 1);
- if (enable && !(xhci->quirks & XHCI_HW_LPM_DISABLE)) {
+ if (enable) {
/* Host supports BESL timeout instead of HIRD */
if (udev->usb2_hw_lpm_besl_capable) {
/* if device doesn't have a preferred BESL value use a
--
2.17.1
Re: [RESEND PATCH v7 4/5] ndctl/papr_scm,uapi: Add support for PAPR nvdimm specific methods
Thanks for reviewing this patch Aneesh.
"Aneesh Kumar K.V" writes:
> Vaibhav Jain writes:
>
>
>
> +
>> +/* Papr-scm-header + payload expected with ND_CMD_CALL ioctl from libnvdimm
>> */
>> +struct nd_pdsm_cmd_pkg {
>> +struct nd_cmd_pkg hdr; /* Package header containing sub-cmd */
>> +__s32 cmd_status; /* Out: Sub-cmd status returned back */
>> +__u16 payload_offset; /* In: offset from start of struct */
>> +__u16 payload_version; /* In/Out: version of the payload */
>> +__u8 payload[]; /* In/Out: Sub-cmd data buffer */
>> +} __packed;
>
> that payload_offset can be avoided if we prevent userspace to user a
> different variant of nd_pdsm_cmd_pkg which different header. We can keep
> things simpler if we can always find payload at
> nd_pdsm_cmd_pkg->payload.
Had introduced this member to handle case where new fields are added to
'struct nd_pdsm_cmd_pkg' without having to break the ABI. But agree with
the point that you made later that this can be simplified by replacing
'payload_offset' with a set of reserved variables. Will address this in
next iteration of this patchset.
>
>> +
>> +/*
>> + * Methods to be embedded in ND_CMD_CALL request. These are sent to the
>> kernel
>> + * via 'nd_pdsm_cmd_pkg.hdr.nd_command' member of the ioctl struct
>> + */
>> +enum papr_scm_pdsm {
>> +PAPR_SCM_PDSM_MIN = 0x0,
>> +PAPR_SCM_PDSM_MAX,
>> +};
>> +
>> +/* Convert a libnvdimm nd_cmd_pkg to pdsm specific pkg */
>> +static inline struct nd_pdsm_cmd_pkg *nd_to_pdsm_cmd_pkg(struct nd_cmd_pkg
>> *cmd)
>> +{
>> +return (struct nd_pdsm_cmd_pkg *) cmd;
>> +}
>> +
>> +/* Return the payload pointer for a given pcmd */
>> +static inline void *pdsm_cmd_to_payload(struct nd_pdsm_cmd_pkg *pcmd)
>> +{
>> +if (pcmd->hdr.nd_size_in == 0 && pcmd->hdr.nd_size_out == 0)
>> +return NULL;
>> +else
>> +return (void *)((__u8 *) pcmd + pcmd->payload_offset);
>> +}
>> +
>
> we need to make sure userspace is not passing a wrong payload_offset.
Agree, that this function should have more strict checking for
payload_offset field. However will be getting rid of
'payload_offset' all together in the next iteration as you previously
suggested.
> and in the next patch you do
>
> + /* Copy the health struct to the payload */
> + memcpy(pdsm_cmd_to_payload(pkg), >health, copysize);
> + pkg->hdr.nd_fw_size = copysize;
> +
Yes this is already being done in the patchset and changes proposed to
this pdsm_cmd_to_payload() should not impact other patches as
pdsm_cmd_to_payload() abstracts rest of the code from how to access the
payload.
> All this can be simplified if you can keep payload at
> nd_pdsm_cmd_pkg->payload.
>
> If you still want to have the ability to extend the header, then added a
> reserved field similar to nd_cmd_pkg.
>
Agree to this and will address this in V8.
>
> -aneesh
--
Cheers
~ Vaibhav
Re: [PATCH 3/4] clk/soc: mediatek: mt6779: Bind clock driver from platform device
Quoting matthias@kernel.org (2020-05-18 04:31:55) > From: Matthias Brugger > > The mmsys driver is now the top level entry point for the multimedia > system (mmsys), we bind the clock driver by creating a platform device. > We also bind the MediaTek DRM driver which is not yet implement and > therefor will errror out for now. > > Signed-off-by: Matthias Brugger > --- Acked-by: Stephen Boyd
Re: [PATCH 2/8] radix-tree: Use local_lock for protection
On Tue, May 19, 2020 at 10:19:06PM +0200, Sebastian Andrzej Siewior wrote:
> @@ -64,6 +64,7 @@ struct radix_tree_preload {
> struct radix_tree_node *nodes;
> };
> static DEFINE_PER_CPU(struct radix_tree_preload, radix_tree_preloads) = { 0,
> };
> +static DEFINE_LOCAL_LOCK(radix_tree_preloads_lock);
>
> static inline struct radix_tree_node *entry_to_node(void *ptr)
> {
So I'm all with Andrew on the naming and pass-by-pointer thing, but
also, the above is pretty crap. You want the local_lock to be in the
structure you're actually protecting, and there really isn't anything
stopping you from doing that.
The below builds just fine and is ever so much more sensible.
--- a/include/linux/locallock_internal.h
+++ b/include/linux/locallock_internal.h
@@ -19,7 +19,7 @@ struct local_lock {
# define LL_DEP_MAP_INIT(lockname)
#endif
-#define INIT_LOCAL_LOCK(lockname) LL_DEP_MAP_INIT(lockname)
+#define INIT_LOCAL_LOCK(lockname) { LL_DEP_MAP_INIT(lockname) }
#define local_lock_lockdep_init(lock) \
do { \
@@ -63,35 +63,35 @@ static inline void local_lock_release(st
#define __local_lock(lock) \
do {\
preempt_disable(); \
- local_lock_acquire(this_cpu_ptr(&(lock))); \
+ local_lock_acquire(this_cpu_ptr(lock)); \
} while (0)
#define __local_lock_irq(lock) \
do {\
local_irq_disable();\
- local_lock_acquire(this_cpu_ptr(&(lock))); \
+ local_lock_acquire(this_cpu_ptr(lock)); \
} while (0)
#define __local_lock_irqsave(lock, flags) \
do {\
local_irq_save(flags); \
- local_lock_acquire(this_cpu_ptr(&(lock))); \
+ local_lock_acquire(this_cpu_ptr(lock)); \
} while (0)
#define __local_unlock(lock) \
do {\
- local_lock_release(this_cpu_ptr());\
+ local_lock_release(this_cpu_ptr(lock)); \
preempt_enable(); \
} while (0)
#define __local_unlock_irq(lock) \
do {\
- local_lock_release(this_cpu_ptr());\
+ local_lock_release(this_cpu_ptr(lock)); \
local_irq_enable(); \
} while (0)
#define __local_unlock_irqrestore(lock, flags) \
do {\
- local_lock_release(this_cpu_ptr());\
+ local_lock_release(this_cpu_ptr(lock)); \
local_irq_restore(flags); \
} while (0)
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -59,12 +59,14 @@ struct kmem_cache *radix_tree_node_cache
* Per-cpu pool of preloaded nodes
*/
struct radix_tree_preload {
+ struct local_lock lock;
unsigned nr;
/* nodes->parent points to next preallocated node */
struct radix_tree_node *nodes;
};
-static DEFINE_PER_CPU(struct radix_tree_preload, radix_tree_preloads) = { 0, };
-static DEFINE_LOCAL_LOCK(radix_tree_preloads_lock);
+static DEFINE_PER_CPU(struct radix_tree_preload, radix_tree_preloads) =
+ { .lock = INIT_LOCAL_LOCK(lock),
+ .nr = 0, };
static inline struct radix_tree_node *entry_to_node(void *ptr)
{
@@ -333,14 +335,14 @@ static __must_check int __radix_tree_pre
*/
gfp_mask &= ~__GFP_ACCOUNT;
- local_lock(radix_tree_preloads_lock);
+ local_lock(_tree_preloads.lock);
rtp = this_cpu_ptr(_tree_preloads);
while (rtp->nr < nr) {
- local_unlock(radix_tree_preloads_lock);
+ local_unlock(_tree_preloads.lock);
node = kmem_cache_alloc(radix_tree_node_cachep, gfp_mask);
if (node == NULL)
goto out;
- local_lock(radix_tree_preloads_lock);
+ local_lock(_tree_preloads.lock);
rtp = this_cpu_ptr(_tree_preloads);
if (rtp->nr < nr) {
node->parent = rtp->nodes;
@@ -382,14 +384,14 @@ int radix_tree_maybe_preload(gfp_t gfp_m
if (gfpflags_allow_blocking(gfp_mask))
return __radix_tree_preload(gfp_mask, RADIX_TREE_PRELOAD_SIZE);
/* Preloading doesn't help anything with this gfp mask, skip it */
-
linux-next: Signed-off-by missing for commit in the imx-mxs tree
Hi all,
Commit
089795766399 ("arm64: dts: ls1028a: sl28: keep switch port names consistent")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpA0Prctzvs3.pgp
Description: OpenPGP digital signature
[PATCH v2] printk/kdb: Redirect printk messages into kdb in any context
kdb has to get messages on consoles even when the system is stopped.
It uses kdb_printf() internally and calls console drivers on its own.
It uses a hack to reuse an existing code. It sets "kdb_trap_printk"
global variable to redirect even the normal printk() into the
kdb_printf() variant.
The variable "kdb_trap_printk" is checked in printk_default() and
it is ignored when printk is redirected to printk_safe in NMI context.
Solve this by moving the check into printk_func().
It is obvious that it is not fully safe. But it does not make things
worse. The console drivers are already called in this context by
db_printf() direct calls.
Reported-by: Sumit Garg
Tested-by: Sumit Garg
Signed-off-by: Petr Mladek
---
Changes in v2:
+ more detailed commit message
kernel/printk/printk.c | 14 +-
kernel/printk/printk_safe.c | 7 +++
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 9a9b6156270b..63a1aa377cd9 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -35,7 +35,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -2036,18 +2035,7 @@ EXPORT_SYMBOL(vprintk);
int vprintk_default(const char *fmt, va_list args)
{
- int r;
-
-#ifdef CONFIG_KGDB_KDB
- /* Allow to pass printk() to kdb but avoid a recursion. */
- if (unlikely(kdb_trap_printk && kdb_printf_cpu < 0)) {
- r = vkdb_printf(KDB_MSGSRC_PRINTK, fmt, args);
- return r;
- }
-#endif
- r = vprintk_emit(0, LOGLEVEL_DEFAULT, NULL, 0, fmt, args);
-
- return r;
+ return vprintk_emit(0, LOGLEVEL_DEFAULT, NULL, 0, fmt, args);
}
EXPORT_SYMBOL_GPL(vprintk_default);
diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index d9a659a686f3..7ccb821d0bfe 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -359,6 +360,12 @@ void __printk_safe_exit(void)
__printf(1, 0) int vprintk_func(const char *fmt, va_list args)
{
+#ifdef CONFIG_KGDB_KDB
+ /* Allow to pass printk() to kdb but avoid a recursion. */
+ if (unlikely(kdb_trap_printk && kdb_printf_cpu < 0))
+ return vkdb_printf(KDB_MSGSRC_PRINTK, fmt, args);
+#endif
+
/*
* Try to use the main logbuf even in NMI. But avoid calling console
* drivers that might have their own locks.
--
2.26.1
Re: [PATCH] perf bpf-loader: Add missing '*' for key_scan_pos
在 2020/5/20 15:05, Jiri Olsa 写道:
On Wed, May 20, 2020 at 11:32:16AM +0800, Wang ShaoBo wrote:
key_scan_pos is a pointer for getting scan position in
bpf__obj_config_map() for each BPF map configuration term,
but it's misused when error not happened.
Fixes: 066dacbf2a32 ("perf bpf: Add API to set values to map entries in a bpf
object")
Signed-off-by: Wang ShaoBo
---
tools/perf/util/bpf-loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index 10c187b8b8ea..460056bc072c 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -1225,7 +1225,7 @@ bpf__obj_config_map(struct bpf_object *obj,
out:
free(map_name);
if (!err)
- key_scan_pos += strlen(map_opt);
+ *key_scan_pos += strlen(map_opt);
seems good, was there something failing because of this?
Acked-by: Jiri Olsa
thanks,
jirka
I found this problem when i checked this code, I think it is
an implicit question, but if we delete the two line, the problem
also no longer exists.
thanks,
Wang ShaoBo
[PATCH] asm-generic/sembuf: Update architecture related information in comment
The structure came originally from x86_32 but is used by most of the architectures now. Update the comment which says it is for x86 only. Signed-off-by: Viresh Kumar --- include/uapi/asm-generic/sembuf.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/uapi/asm-generic/sembuf.h b/include/uapi/asm-generic/sembuf.h index 0e709bd3d730..f54e48fc91ae 100644 --- a/include/uapi/asm-generic/sembuf.h +++ b/include/uapi/asm-generic/sembuf.h @@ -6,9 +6,9 @@ #include /* - * The semid64_ds structure for x86 architecture. - * Note extra padding because this structure is passed back and forth - * between kernel and user space. + * The semid64_ds structure for most architectures (though it came from x86_32 + * originally). Note extra padding because this structure is passed back and + * forth between kernel and user space. * * semid64_ds was originally meant to be architecture specific, but * everyone just ended up making identical copies without specific -- 2.25.0.rc1.19.g042ed3e048af
[PATCH] Revert "powerpc/32s: reorder Linux PTE bits to better match Hash PTE bits."
This reverts commit 697ece78f8f749aeea40f2711389901f0974017a.
The implementation of SWAP on powerpc requires page protection
bits to not be one of the least significant PTE bits.
Until the SWAP implementation is changed and this requirement voids,
we have to keep at least _PAGE_RW outside of the 3 last bits.
For now, revert to previous PTE bits order. A further rework
may come later.
Reported-by: Rui Salvaterra
Fixes: 697ece78f8f7 ("powerpc/32s: reorder Linux PTE bits to better match Hash
PTE bits.")
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/hash.h | 8
arch/powerpc/kernel/head_32.S | 9 ++---
arch/powerpc/mm/book3s32/hash_low.S | 14 --
3 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/32/hash.h
b/arch/powerpc/include/asm/book3s/32/hash.h
index 34a7215ae81e..2a0a467d2985 100644
--- a/arch/powerpc/include/asm/book3s/32/hash.h
+++ b/arch/powerpc/include/asm/book3s/32/hash.h
@@ -17,9 +17,9 @@
* updating the accessed and modified bits in the page table tree.
*/
-#define _PAGE_USER 0x001 /* usermode access allowed */
-#define _PAGE_RW 0x002 /* software: user write access allowed */
-#define _PAGE_PRESENT 0x004 /* software: pte contains a translation */
+#define _PAGE_PRESENT 0x001 /* software: pte contains a translation */
+#define _PAGE_HASHPTE 0x002 /* hash_page has made an HPTE for this pte */
+#define _PAGE_USER 0x004 /* usermode access allowed */
#define _PAGE_GUARDED 0x008 /* G: prohibit speculative access */
#define _PAGE_COHERENT 0x010 /* M: enforce memory coherence (SMP systems) */
#define _PAGE_NO_CACHE 0x020 /* I: cache inhibit */
@@ -27,7 +27,7 @@
#define _PAGE_DIRTY0x080 /* C: page changed */
#define _PAGE_ACCESSED 0x100 /* R: page referenced */
#define _PAGE_EXEC 0x200 /* software: exec allowed */
-#define _PAGE_HASHPTE 0x400 /* hash_page has made an HPTE for this pte */
+#define _PAGE_RW 0x400 /* software: user write access allowed */
#define _PAGE_SPECIAL 0x800 /* software: Special page */
#ifdef CONFIG_PTE_64BIT
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index daaa153950c2..97c887950c3c 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -348,7 +348,7 @@ BEGIN_MMU_FTR_SECTION
andis. r0, r5, (DSISR_BAD_FAULT_32S | DSISR_DABRMATCH)@h
#endif
bne handle_page_fault_tramp_2 /* if not, try to put a PTE */
- rlwinm r3, r5, 32 - 24, 30, 30 /* DSISR_STORE -> _PAGE_RW */
+ rlwinm r3, r5, 32 - 15, 21, 21 /* DSISR_STORE -> _PAGE_RW */
bl hash_page
b handle_page_fault_tramp_1
FTR_SECTION_ELSE
@@ -497,6 +497,7 @@ InstructionTLBMiss:
andc. r1,r1,r0/* check access & ~permission */
bne-InstructionAddressInvalid /* return if access not permitted */
/* Convert linux-style PTE to low word of PPC-style PTE */
+ rlwimi r0,r0,32-2,31,31/* _PAGE_USER -> PP lsb */
ori r1, r1, 0xe06 /* clear out reserved bits */
andcr1, r0, r1 /* PP = user? 1 : 0 */
BEGIN_FTR_SECTION
@@ -564,8 +565,9 @@ DataLoadTLBMiss:
* we would need to update the pte atomically with lwarx/stwcx.
*/
/* Convert linux-style PTE to low word of PPC-style PTE */
- rlwinm r1,r0,0,30,30 /* _PAGE_RW -> PP msb */
- rlwimi r0,r0,1,30,30 /* _PAGE_USER -> PP msb */
+ rlwinm r1,r0,32-9,30,30/* _PAGE_RW -> PP msb */
+ rlwimi r0,r0,32-1,30,30/* _PAGE_USER -> PP msb */
+ rlwimi r0,r0,32-1,31,31/* _PAGE_USER -> PP lsb */
ori r1,r1,0xe04 /* clear out reserved bits */
andcr1,r0,r1/* PP = user? rw? 1: 3: 0 */
BEGIN_FTR_SECTION
@@ -643,6 +645,7 @@ DataStoreTLBMiss:
* we would need to update the pte atomically with lwarx/stwcx.
*/
/* Convert linux-style PTE to low word of PPC-style PTE */
+ rlwimi r0,r0,32-2,31,31/* _PAGE_USER -> PP lsb */
li r1,0xe06/* clear out reserved bits & PP msb */
andcr1,r0,r1/* PP = user? 1: 0 */
BEGIN_FTR_SECTION
diff --git a/arch/powerpc/mm/book3s32/hash_low.S
b/arch/powerpc/mm/book3s32/hash_low.S
index 6d236080cb1a..877d880890fe 100644
--- a/arch/powerpc/mm/book3s32/hash_low.S
+++ b/arch/powerpc/mm/book3s32/hash_low.S
@@ -35,7 +35,7 @@ mmu_hash_lock:
/*
* Load a PTE into the hash table, if possible.
* The address is in r4, and r3 contains an access flag:
- * _PAGE_RW (0x002) if a write.
+ * _PAGE_RW (0x400) if a write.
* r9 contains the SRR1 value, from which we use the MSR_PR bit.
* SPRG_THREAD contains the physical address of the current task's thread.
*
@@ -69,7 +69,7 @@ _GLOBAL(hash_page)
blt+112f
Re: [PATCH v4 07/13] firmware: arm_scmi: Add notification dispatch and delivery
Hi Cristian, On 5/20/20 8:09 AM, Cristian Marussi wrote: On Mon, Mar 16, 2020 at 02:46:05PM +, Cristian Marussi wrote: On Thu, Mar 12, 2020 at 09:43:31PM +, Lukasz Luba wrote: Hi Lukasz, I went back looking deeper into the possible race issue you pointed out a while ago understanding it a bit better down below. On 3/12/20 6:34 PM, Cristian Marussi wrote: On 12/03/2020 13:51, Lukasz Luba wrote: Hi Cristian, Hi Lukasz just one comment below... [snip] + eh.timestamp = ts; + eh.evt_id = evt_id; + eh.payld_sz = len; + kfifo_in(_evt->proto->equeue.kfifo, , sizeof(eh)); + kfifo_in(_evt->proto->equeue.kfifo, buf, len); + queue_work(r_evt->proto->equeue.wq, + _evt->proto->equeue.notify_work); Is it safe to ignore the return value from the queue_work here? In fact yes, we do not want to care: it returns true or false depending on the fact that the specific work was or not already queued, and we just rely on this behavior to keep kicking the worker only when needed but never kick more than one instance of it per-queue (so that there's only one reader wq and one writer here in the scmi_notify)...explaining better: 1. we push an event (hdr+payld) to the protocol queue if we found that there was enough space on the queue 2a. if at the time of the kfifo_in( ) the worker was already running (queue not empty) it will process our new event sooner or later and here the queue_work will return false, but we do not care in fact ... we tried to kick it just in case 2b. if instead at the time of the kfifo_in() the queue was empty the worker would have probably already gone to the sleep and this queue_work() will return true and so this time it will effectively wake up the worker to process our items The important thing here is that we are sure to wakeup the worker when needed but we are equally sure we are never causing the scheduling of more than one worker thread consuming from the same queue (because that would break the one reader/one writer assumption which let us use the fifo in a lockless manner): this is possible because queue_work checks if the required work item is already pending and in such a case backs out returning false and we have one work_item (notify_work) defined per-protocol and so per-queue. I see. That's a good assumption: one work_item per protocol and simplify the locking. What if there would be an edge case scenario when the consumer (work_item) has handled the last item (there was NULL from scmi_process_event_header()), while in meantime scmi_notify put into the fifo new event but couldn't kick the queue_work. Would it stay there till the next IRQ which triggers queue_work to consume two events (one potentially a bit old)? Or we can ignore such race situation assuming that cleaning of work item is instant and kfifo_in is slow? In fact, this is a very good point, since between the moment the worker determines that the queue is empty and the moment in which the worker effectively exits (and it's marked as no more pending by the Kernel cmwq) there is a window of opportunity for a race in which the ISR could fill the queue with one more event and then fail to kick with queue_work() since the work is in fact still nominally marked as pending from the point of view of Kernel cmwq, as below: ISR (core N)| WQ (core N+1) cmwq flags queued events | if (queue_is_empty) - WORK_PENDING 0 events queued + ... - WORK_PENDING 0 events queued + } while (scmi_process_event_payload); +}// worker function exit kfifo_in() + ...cmwq backing out - WORK_PENDING 1 events queued kfifo_in() + ...cmwq backing out - WORK_PENDING 1 events queued queue_work()+ ...cmwq backing out - WORK_PENDING 1 events queued -> FALSE (pending)+ ...cmwq backing out - WORK_PENDING 1 events queued + ...cmwq backing out - WORK_PENDING 1 events queued + ...cmwq backing out - WORK_PENDING 1 events queued | WORKER THREAD EXIT - !WORK_PENDING 1 events queued | - !WORK_PENDING 1 events queued kfifo_in() | - !WORK_PENDING 2 events queued kfifo_in() | - !WORK_PENDING 2 events queued queue_work()| - !WORK_PENDING 2 events queued -> TRUE | --- WORKER ENTER - WORK_PENDING
Re: [PATCH 06/11] irqchip/gic-v3: Configure SGIs as standard interrupts
Hi Sumit,
On 2020-05-20 10:52, Sumit Garg wrote:
Hi Marc,
On Tue, 19 May 2020 at 21:48, Marc Zyngier wrote:
Change the way we deal with GICv3 SGIs by turning them into proper
IRQs, and calling into the arch code to register the interrupt range
instead of a callback.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 91
+---
1 file changed, 53 insertions(+), 38 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c
b/drivers/irqchip/irq-gic-v3.c
index 23d7c87da407..d57289057b75 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -36,6 +36,9 @@
#define FLAGS_WORKAROUND_GICR_WAKER_MSM8996(1ULL << 0)
#define FLAGS_WORKAROUND_CAVIUM_ERRATUM_38539 (1ULL << 1)
+#define GIC_IRQ_TYPE_PARTITION (GIC_IRQ_TYPE_LPI + 1)
+#define GIC_IRQ_TYPE_SGI (GIC_IRQ_TYPE_LPI + 2)
+
struct redist_region {
void __iomem*redist_base;
phys_addr_t phys_base;
@@ -657,38 +660,14 @@ static asmlinkage void __exception_irq_entry
gic_handle_irq(struct pt_regs *regs
if ((irqnr >= 1020 && irqnr <= 1023))
return;
- /* Treat anything but SGIs in a uniform way */
- if (likely(irqnr > 15)) {
- int err;
-
- if (static_branch_likely(_deactivate_key))
- gic_write_eoir(irqnr);
- else
- isb();
-
- err = handle_domain_irq(gic_data.domain, irqnr, regs);
- if (err) {
- WARN_ONCE(true, "Unexpected interrupt
received!\n");
- gic_deactivate_unhandled(irqnr);
- }
- return;
- }
- if (irqnr < 16) {
+ if (static_branch_likely(_deactivate_key))
gic_write_eoir(irqnr);
- if (static_branch_likely(_deactivate_key))
- gic_write_dir(irqnr);
-#ifdef CONFIG_SMP
- /*
-* Unlike GICv2, we don't need an smp_rmb() here.
-* The control dependency from gic_read_iar to
-* the ISB in gic_write_eoir is enough to ensure
-* that any shared data read by handle_IPI will
-* be read after the ACK.
-*/
- handle_IPI(irqnr, regs);
-#else
- WARN_ONCE(true, "Unexpected SGI received!\n");
-#endif
+ else
+ isb();
+
+ if (handle_domain_irq(gic_data.domain, irqnr, regs)) {
+ WARN_ONCE(true, "Unexpected interrupt received!\n");
+ gic_deactivate_unhandled(irqnr);
}
}
@@ -1136,11 +1115,11 @@ static void gic_send_sgi(u64 cluster_id, u16
tlist, unsigned int irq)
gic_write_sgi1r(val);
}
-static void gic_raise_softirq(const struct cpumask *mask, unsigned
int irq)
+static void gic_ipi_send_mask(struct irq_data *d, const struct
cpumask *mask)
{
int cpu;
- if (WARN_ON(irq >= 16))
+ if (WARN_ON(d->hwirq >= 16))
return;
/*
@@ -1154,7 +1133,7 @@ static void gic_raise_softirq(const struct
cpumask *mask, unsigned int irq)
u16 tlist;
tlist = gic_compute_target_list(, mask,
cluster_id);
- gic_send_sgi(cluster_id, tlist, irq);
+ gic_send_sgi(cluster_id, tlist, d->hwirq);
}
/* Force the above writes to ICC_SGI1R_EL1 to be executed */
@@ -1163,10 +1142,36 @@ static void gic_raise_softirq(const struct
cpumask *mask, unsigned int irq)
static void gic_smp_init(void)
{
- set_smp_cross_call(gic_raise_softirq);
+ struct irq_fwspec sgi_fwspec = {
+ .fwnode = gic_data.fwnode,
+ };
+ int base_sgi;
+
cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_GIC_STARTING,
"irqchip/arm/gicv3:starting",
gic_starting_cpu, NULL);
+
+ if (is_of_node(gic_data.fwnode)) {
+ /* DT */
+ sgi_fwspec.param_count = 3;
+ sgi_fwspec.param[0] = GIC_IRQ_TYPE_SGI;
+ sgi_fwspec.param[1] = 0;
+ sgi_fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
+ } else {
+ /* ACPI */
+ sgi_fwspec.param_count = 2;
+ sgi_fwspec.param[0] = 0;
+ sgi_fwspec.param[1] = IRQ_TYPE_EDGE_RISING;
+ }
+
+ /* Register all 8 non-secure SGIs */
+ base_sgi = __irq_domain_alloc_irqs(gic_data.domain, -1, 8,
+ NUMA_NO_NODE, _fwspec,
+ false, NULL);
+ if (WARN_ON(base_sgi <= 0))
+ return;
+
+ set_smp_ipi_range(base_sgi, 8);
}
static int gic_set_affinity(struct irq_data *d, const struct cpumask
*mask_val,
@@ -1215,6 +1220,7 @@ static int gic_set_affinity(struct irq_data *d,
const struct cpumask *mask_val,
}
#else
#define gic_set_affinity
Re: [PATCH v11 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
On Wed, May 20, 2020 at 12:51:12PM +0300, Tali Perry wrote:
> Add Nuvoton NPCM BMC I2C controller driver.
...
> +#ifdef CONFIG_DEBUG_FS
Why?!
> +#include
> +#endif
...
> +/* Status of one I2C module */
> +struct npcm_i2c {
> + struct i2c_adapter adap;
> + struct device *dev;
Isn't it adap.dev->parent?
> +};
...
> +static void npcm_i2c_master_abort(struct npcm_i2c *bus)
> +{
> + /* Only current master is allowed to issue a stop condition */
> + if (npcm_i2c_is_master(bus)) {
if (!npcm_i2c_is_master(bus))
return;
?
> + npcm_i2c_eob_int(bus, true);
> + npcm_i2c_master_stop(bus);
> + npcm_i2c_clear_master_status(bus);
> + }
> +}
...
> +/* SDA status is set - TX or RX, master */
> +static void npcm_i2c_irq_handle_sda(struct npcm_i2c *bus, u8 i2cst)
> +{
> + u8 fif_cts;
> + if (bus->state == I2C_IDLE) {
> + if (npcm_i2c_is_master(bus)) {
if (a) {
if (b) {
...
}
}
==
if (a && b) {
...
}
Check whole code for such pattern.
> + }
> +
> + /* SDA interrupt, after start\restart */
> + } else {
> + if (NPCM_I2CST_XMIT & i2cst) {
> + bus->operation = I2C_WRITE_OPER;
> + npcm_i2c_irq_master_handler_write(bus);
> + } else {
> + bus->operation = I2C_READ_OPER;
> + npcm_i2c_irq_master_handler_read(bus);
> + }
> + }
> +}
...
> + }
> +
+ /* 1MHz */ ?
> + else if (bus_freq_hz <= I2C_MAX_FAST_MODE_PLUS_FREQ) {
> + }
> +
> + /* Frequency larger than 1 MHZ is not supported */
> + else
> + return -EINVAL;
...
> + // master and slave modes share a single irq.
It's again being inconsistent with comment style. Choose one and fix all
comments accordingly (SPDX is another story, though)
...
> +static int i2c_debugfs_get(void *data, u64 *val)
> +{
> + *val = *(u64 *)(data);
> + return 0;
> +}
> +DEFINE_DEBUGFS_ATTRIBUTE(i2c_debugfs_ops, i2c_debugfs_get, NULL,
> "0x%02llx\n");
Why not to use debugfs_create_u64(), or how is it called?
> +static void i2c_init_debugfs(struct platform_device *pdev, struct npcm_i2c
> *bus)
> +{
> + if (!npcm_i2c_debugfs_dir)
> + return;
> +
> + if (!pdev || !bus)
> + return;
How is it possible?
> + bus->debugfs = debugfs_create_dir(dev_name(>dev),
> + npcm_i2c_debugfs_dir);
> + if (IS_ERR_OR_NULL(bus->debugfs)) {
> + bus->debugfs = NULL;
> + return;
> + }
struct dentry *d;
d = create(...);
if (IS_ERR_OR_NULL(d))
return;
bus->... = d;
> +
> + debugfs_create_file("ber_count", 0444, bus->debugfs,
> + >ber_count,
> + _debugfs_ops);
> +
> + debugfs_create_file("rec_succ_count", 0444, bus->debugfs,
> + >rec_succ_count,
> + _debugfs_ops);
> +
> + debugfs_create_file("rec_fail_count", 0444, bus->debugfs,
> + >rec_fail_count,
> + _debugfs_ops);
> +
> + debugfs_create_file("nack_count", 0444, bus->debugfs,
> + >nack_count,
> + _debugfs_ops);
> +
> + debugfs_create_file("timeout_count", 0444, bus->debugfs,
> + >timeout_count,
> + _debugfs_ops);
> +}
...
> +#ifdef CONFIG_DEBUG_FS
Why?!
> + i2c_init_debugfs(pdev, bus);
> +#endif
...
> +#ifdef CONFIG_DEBUG_FS
Ditto.
> + debugfs_remove_recursive(bus->debugfs);
> +#endif
> +static int __init npcm_i2c_init(void)
> +{
> + npcm_i2c_debugfs_dir = debugfs_create_dir("i2c", NULL);
You didn't compile this with !CONFIG_DEBUG_FS?
> + if (IS_ERR_OR_NULL(npcm_i2c_debugfs_dir)) {
> + pr_warn("i2c init of debugfs failed\n");
> + npcm_i2c_debugfs_dir = NULL;
> + }
See above for the better pattern. Why do you need noisy warning? What does it
say to user? Can they use device or not?
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
[PATCH] drm/nouveau: fix runtime pm imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index f5ece1f94973..6697f960dd89 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -76,8 +76,10 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct
drm_file *file_priv)
return ret;
ret = pm_runtime_get_sync(dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ pm_runtime_put_autosuspend(dev);
goto out;
+ }
ret = nouveau_vma_new(nvbo, vmm, );
pm_runtime_mark_last_busy(dev);
--
2.17.1
Re: [PATCH 8/8] mm/zswap: Use local lock to protect per-CPU data
On 2020-05-19 21:46:06 [+], Song Bao Hua wrote:
> Hi Luis,
> In the below patch, in order to use the acomp APIs to leverage the power of
> hardware compressors. I have moved to mutex:
> https://marc.info/?l=linux-crypto-vger=158941285830302=2
> https://marc.info/?l=linux-crypto-vger=158941287930311=2
>
> so once we get some progress on that one, I guess we don't need a special
> patch for RT any more.
If you convert this way from the current concept then we could drop it
from the series.
The second patch shows the following hunk:
|@@ -1075,11 +1124,20 @@ static int zswap_frontswap_store(unsigned type,
pgoff_t offset,
|
| /* compress */
| dst = get_cpu_var(zswap_dstmem);
| acomp_ctx = *this_cpu_ptr(entry->pool->acomp_ctx);
| put_cpu_var(zswap_dstmem);
So here you get per-CPU version of `dst' and `acomp_ctx' and then allow
preemption again.
| mutex_lock(_ctx->mutex);
|
| src = kmap(page);
| sg_init_one(, src, PAGE_SIZE);
| /* zswap_dstmem is of size (PAGE_SIZE * 2). Reflect same in sg_list */
| sg_init_one(, dst, PAGE_SIZE * 2);
and here you use `dst' and `acomp_ctx' after the preempt_disable() has
been dropped so I don't understand why you used get_cpu_var(). It is
either protected by the mutex and doesn't require get_cpu_var() or it
isn't (and should have additional protection).
| acomp_request_set_params(acomp_ctx->req, , , PAGE_SIZE,
dlen);
| ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req),
_ctx->wait);
| dlen = acomp_ctx->req->dlen;
| kunmap(page);
|
| if (ret) {
| ret = -EINVAL;
| goto put_dstmem;
|
Sebastian
Re: [PATCH 3/8] srcu: Use local_lock() for per-CPU struct srcu_data access
On Tue, May 19, 2020 at 10:19:07PM +0200, Sebastian Andrzej Siewior wrote:
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index 0c71505f0e19c..8d2b5f75145d7 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include "rcu.h"
> #include "rcu_segcblist.h"
> @@ -735,6 +736,7 @@ static void srcu_flip(struct srcu_struct *ssp)
> smp_mb(); /* D */ /* Pairs with C. */
> }
>
> +static DEFINE_LOCAL_LOCK(sda_lock);
> /*
> * If SRCU is likely idle, return true, otherwise return false.
> *
> @@ -765,13 +767,13 @@ static bool srcu_might_be_idle(struct srcu_struct *ssp)
> unsigned long tlast;
>
> /* If the local srcu_data structure has callbacks, not idle. */
> - local_irq_save(flags);
> + local_lock_irqsave(sda_lock, flags);
> sdp = this_cpu_ptr(ssp->sda);
> if (rcu_segcblist_pend_cbs(>srcu_cblist)) {
> - local_irq_restore(flags);
> + local_unlock_irqrestore(sda_lock, flags);
> return false; /* Callbacks already present, so not idle. */
> }
> - local_irq_restore(flags);
> + local_unlock_irqrestore(sda_lock, flags);
Would it perhaps make sense to stick the local_lock in struct srcu_data ?
Re: [PATCH] drm/etnaviv: fix memory leak when mapping prime imported buffers
Hi Martin,
Am Mittwoch, den 20.05.2020, 12:10 +0200 schrieb Martin Fuzzey:
> When using mmap() on a prime imported buffer allocated by a
> different driver (such as imx-drm) the later munmap() does
> not correctly decrement the refcount of the original enaviv_gem_object,
> leading to a leak.
>
> Signed-off-by: Martin Fuzzey
> Cc: sta...@vger.kernel.org
What's the use-case where you did hit this issue? mmap'ing of imported
buffers through the etnaviv DRM device is currently not well defined
and I was pondering the idea of forbidding it completely by not
returning a mmap offset for those objects.
Regards,
Lucas
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> index f24dd21..28a01b8 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> @@ -93,7 +93,25 @@ static void *etnaviv_gem_prime_vmap_impl(struct
> etnaviv_gem_object *etnaviv_obj)
> static int etnaviv_gem_prime_mmap_obj(struct etnaviv_gem_object *etnaviv_obj,
> struct vm_area_struct *vma)
> {
> - return dma_buf_mmap(etnaviv_obj->base.dma_buf, vma, 0);
> + int ret;
> +
> + ret = dma_buf_mmap(etnaviv_obj->base.dma_buf, vma, 0);
> +
> + /* drm_gem_mmap_obj() has already been called before this function
> + * and has incremented our refcount, expecting it to be decremented
> + * on unmap() via drm_gem_vm_close().
> + * However dma_buf_mmap() invokes drm_gem_cma_prime_mmap()
> + * that ends up updating the vma->vma_private_data to point to the
> + * dma_buf's gem object.
> + * Hence our gem object here will not have its refcount decremented
> + * when userspace does unmap().
> + * So decrement the refcount here to avoid a memory leak if the dma
> + * buf mapping was successful.
> + */
> + if (!ret)
> + drm_gem_object_put_unlocked(_obj->base);
> +
> + return ret;
> }
>
> static const struct etnaviv_gem_ops etnaviv_gem_prime_ops = {
[PATCH v1] drivers property: When no children in primary, try secondary
Software firmware nodes can provide a child node to its parent.
Since software node can be secondary, we need a mechanism to access
the children. The idea is to list children of the primary node first
and when they are finished, continue with secondary node if available.
Signed-off-by: Andy Shevchenko
---
drivers/base/property.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 5f35c0ccf5e0..1e6d75e65938 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -708,14 +708,23 @@ struct fwnode_handle *device_get_next_child_node(struct
device *dev,
struct fwnode_handle *child)
{
struct acpi_device *adev = ACPI_COMPANION(dev);
- struct fwnode_handle *fwnode = NULL;
+ struct fwnode_handle *fwnode = NULL, *next;
if (dev->of_node)
fwnode = >of_node->fwnode;
else if (adev)
fwnode = acpi_fwnode_handle(adev);
- return fwnode_get_next_child_node(fwnode, child);
+ /* Try to find a child in primary fwnode */
+ next = fwnode_get_next_child_node(fwnode, child);
+ if (next)
+ return next;
+
+ /* When no more children in primary, continue with secondary */
+ if (!IS_ERR_OR_NULL(fwnode->secondary))
+ next = fwnode_get_next_child_node(fwnode->secondary, child);
+
+ return next;
}
EXPORT_SYMBOL_GPL(device_get_next_child_node);
--
2.26.2
Re: [PATCH v2] sched/pelt: sync util/runnable_sum with PELT window when propagating
On 19/05/2020 17:41, Vincent Guittot wrote:
> On Tue, 19 May 2020 at 12:28, Dietmar Eggemann
> wrote:
>>
>> On 06/05/2020 17:53, Vincent Guittot wrote:
[...]
>>> diff --git a/kernel/sched/pelt.c b/kernel/sched/pelt.c
>>> index b647d04d9c8b..1feff80e7e45 100644
>>> --- a/kernel/sched/pelt.c
>>> +++ b/kernel/sched/pelt.c
>>> @@ -237,6 +237,30 @@ ___update_load_sum(u64 now, struct sched_avg *sa,
>>> return 1;
>>> }
>>>
>>> +/*
>>> + * When syncing *_avg with *_sum, we must take into account the current
>>> + * position in the PELT segment otherwise the remaining part of the segment
>>> + * will be considered as idle time whereas it's not yet elapsed and this
>>> will
>>> + * generate unwanted oscillation in the range [1002..1024[.
>>> + *
>>> + * The max value of *_sum varies with the position in the time segment and
>>> is
>>> + * equals to :
>>> + *
>>> + * LOAD_AVG_MAX*y + sa->period_contrib
>>> + *
>>> + * which can be simplified into:
>>> + *
>>> + * LOAD_AVG_MAX - 1024 + sa->period_contrib
>>> + *
>>> + * because LOAD_AVG_MAX*y == LOAD_AVG_MAX-1024
>>
>> Isn't this rather '~' instead of '==', even for y^32 = 0.5 ?
>>
>> 47742 * 0.5^(1/32) ~ 47742 - 1024
>
> With integer precision and the runnable_avg_yN_inv array, you've got
> exactly 1024
Ah, OK, I forgot about this and that this is related to commit
625ed2bf049d ("sched/cfs: Make util/load_avg more stable").
Re: [PATCH 0/3] arm64: perf: Add support for Perf NMI interrupts
Hi, On 5/18/20 12:17 PM, Alexandru Elisei wrote: > Hi, > > On 5/18/20 11:45 AM, Mark Rutland wrote: >> Hi all, >> >> On Mon, May 18, 2020 at 02:26:00PM +0800, Lecopzer Chen wrote: >>> HI Sumit, >>> >>> Thanks for your information. >>> >>> I've already implemented IPI (same as you did [1], little difference >>> in detail), hardlockup detector and perf in last year(2019) for >>> debuggability. >>> And now we tend to upstream to reduce kernel maintaining effort. >>> I'm glad if someone in ARM can do this work :) >>> >>> Hi Julien, >>> >>> Does any Arm maintainers can proceed this action? >> Alexandru (Cc'd) has been rebasing and reworking Julien's patches, which >> is my preferred approach. >> >> I understand that's not quite ready for posting since he's investigating >> some of the nastier subtleties (e.g. mutual exclusion with the NMI), but >> maybe we can put the work-in-progress patches somewhere in the mean >> time. >> >> Alexandru, do you have an idea of what needs to be done, and/or when you >> expect you could post that? > I'm currently working on rebasing the patches on top of 5.7-rc5, when I have > something usable I'll post a link (should be a couple of days). After that I > will > address the review comments, and I plan to do a thorough testing because I'm > not > 100% confident that some of the assumptions around the locks that were > removed are > correct. My guess is this will take a few weeks. Pushed a WIP branch on linux-arm.org [1]: git clone -b WIP-pmu-nmi git://linux-arm.org/linux-ae Practically untested, I only did perf record on a defconfig kernel running on the model. [1] http://www.linux-arm.org/git?p=linux-ae.git;a=shortlog;h=refs/heads/WIP-pmu-nmi Thanks, Alex > > Thanks, > Alex >> Thanks, >> Mark. >> >>> This is really useful in debugging. >>> Thank you!! >>> >>> >>> >>> [1] https://lkml.org/lkml/2020/4/24/328 >>> >>> >>> Lecopzer >>> >>> Sumit Garg 於 2020年5月18日 週一 下午1:46寫道： + Julien Hi Lecopzer, On Sat, 16 May 2020 at 18:20, Lecopzer Chen wrote: > These series implement Perf NMI funxtionality and depends on > Pseudo NMI [1] which has been upstreamed. > > In arm64 with GICv3, Pseudo NMI was implemented for NMI-like interruts. > That can be extended to Perf NMI which is the prerequisite for hard-lockup > detector which had already a standard interface inside Linux. > > Thus the first step we need to implement perf NMI interface and make sure > it works fine. > This is something that is already implemented via Julien's patch-set [1]. Its v4 has been floating since July, 2019 and I couldn't find any major blocking comments but not sure why things haven't progressed further. Maybe Julien or Arm maintainers can provide updates on existing patch-set [1] and how we should proceed further with this interesting feature. And regarding hard-lockup detection, I have been able to enable it based on perf NMI events using Julien's perf patch-set [1]. Have a look at the patch here [2]. [1] https://patchwork.kernel.org/cover/11047407/ [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/732227.html -Sumit > Perf NMI has been test by dd if=/dev/urandom of=/dev/null like the link > [2] > did. > > [1] https://lkml.org/lkml/2019/1/31/535 > [2] https://www.linaro.org/blog/debugging-arm-kernels-using-nmifiq > > > Lecopzer Chen (3): > arm_pmu: Add support for perf NMI interrupts registration > arm64: perf: Support NMI context for perf event ISR > arm64: Kconfig: Add support for the Perf NMI > > arch/arm64/Kconfig | 10 +++ > arch/arm64/kernel/perf_event.c | 36 ++-- > drivers/perf/arm_pmu.c | 51 ++ > include/linux/perf/arm_pmu.h | 6 > 4 files changed, 88 insertions(+), 15 deletions(-) > > -- > 2.25.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH] perf bpf-loader: Add missing '*' for key_scan_pos
On Wed, May 20, 2020 at 06:22:12PM +0800, Wangshaobo (bobo) wrote:
>
> 在 2020/5/20 15:05, Jiri Olsa 写道:
> > On Wed, May 20, 2020 at 11:32:16AM +0800, Wang ShaoBo wrote:
> > > key_scan_pos is a pointer for getting scan position in
> > > bpf__obj_config_map() for each BPF map configuration term,
> > > but it's misused when error not happened.
> > >
> > > Fixes: 066dacbf2a32 ("perf bpf: Add API to set values to map entries in a
> > > bpf object")
> > > Signed-off-by: Wang ShaoBo
> > > ---
> > > tools/perf/util/bpf-loader.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
> > > index 10c187b8b8ea..460056bc072c 100644
> > > --- a/tools/perf/util/bpf-loader.c
> > > +++ b/tools/perf/util/bpf-loader.c
> > > @@ -1225,7 +1225,7 @@ bpf__obj_config_map(struct bpf_object *obj,
> > > out:
> > > free(map_name);
> > > if (!err)
> > > - key_scan_pos += strlen(map_opt);
> > > + *key_scan_pos += strlen(map_opt);
> > seems good, was there something failing because of this?
> >
> > Acked-by: Jiri Olsa
> >
> > thanks,
> > jirka
>
> I found this problem when i checked this code, I think it is
>
> an implicit question, but if we delete the two line, the problem
>
> also no longer exists.
and what's the actual problem, what's broken?
jirka
>
> thanks,
>
> Wang ShaoBo
>
>
[next] i2c: mediatek: Use div_u64 for 64-bit division to fix 32-bit kernels
From: Qii Wang Use div_u64 for 64-bit division, and change sample_ns type to unsigned int. Otherwise, the module will reference __udivdi3 under 32-bit kernels, which is not allowed in kernel space. Signed-off-by: Qii Wang --- drivers/i2c/busses/i2c-mt65xx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 7020618..deef69e 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -551,7 +551,8 @@ static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c, const struct i2c_spec_values *spec; unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt; unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f; - long long sample_ns = (10 * (sample_cnt + 1)) / clk_src; + unsigned int sample_ns = div_u64(10ULL * (sample_cnt + 1), +clk_src); if (!i2c->dev_comp->timing_adjust) return 0; -- 1.9.1
Re: [PATCH v1] drivers property: When no children in primary, try secondary
On Wed, May 20, 2020 at 12:30 PM Andy Shevchenko
wrote:
>
> Software firmware nodes can provide a child node to its parent.
> Since software node can be secondary, we need a mechanism to access
> the children. The idea is to list children of the primary node first
> and when they are finished, continue with secondary node if available.
Makes sense.
> Signed-off-by: Andy Shevchenko
Greg, do you want me to apply it?
If you'd rather take it yourself, please feel free to add
Reviewed-by: Rafael J. Wysocki
> ---
> drivers/base/property.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 5f35c0ccf5e0..1e6d75e65938 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -708,14 +708,23 @@ struct fwnode_handle *device_get_next_child_node(struct
> device *dev,
> struct fwnode_handle *child)
> {
> struct acpi_device *adev = ACPI_COMPANION(dev);
> - struct fwnode_handle *fwnode = NULL;
> + struct fwnode_handle *fwnode = NULL, *next;
>
> if (dev->of_node)
> fwnode = >of_node->fwnode;
> else if (adev)
> fwnode = acpi_fwnode_handle(adev);
>
> - return fwnode_get_next_child_node(fwnode, child);
> + /* Try to find a child in primary fwnode */
> + next = fwnode_get_next_child_node(fwnode, child);
> + if (next)
> + return next;
> +
> + /* When no more children in primary, continue with secondary */
> + if (!IS_ERR_OR_NULL(fwnode->secondary))
> + next = fwnode_get_next_child_node(fwnode->secondary, child);
> +
> + return next;
> }
> EXPORT_SYMBOL_GPL(device_get_next_child_node);
>
> --
> 2.26.2
>
Re: [PATCH] kgdboc: Disable all the early code when kgdboc is a module
On Tue, May 19, 2020 at 08:44:02AM -0700, Douglas Anderson wrote:
> When kgdboc is compiled as a module all of the "ekgdboc" and
> "kgdb_earlycon" code isn't useful and, in fact, breaks compilation.
> This is because early_param() isn't defined for modules and that's how
> this code gets configured.
>
> It turns out that this was broken by commit eae3e19ca930 ("kgdboc:
> Remove useless #ifdef CONFIG_KGDB_SERIAL_CONSOLE in kgdboc") and then
> made worse by commit 220995622da5 ("kgdboc: Add kgdboc_earlycon to
> support early kgdb using boot consoles"). I guess the #ifdef wasn't
> so useless, even if it wasn't obvious why it was useful. When kgdboc
> was compiled as a module only "CONFIG_KGDB_SERIAL_CONSOLE_MODULE" was
> defined, not "CONFIG_KGDB_SERIAL_CONSOLE". That meant that the old
> module.
>
> Let's basically do the same thing that the old code (pre-removal of
> the #ifdef) did but use "IS_BUILTIN(CONFIG_KGDB_SERIAL_CONSOLE)" to
> make it more obvious what the point of the check is. We'll fix
> kgdboc_earlycon in a similar way.
>
> Fixes: 220995622da5 ("kgdboc: Add kgdboc_earlycon to support early kgdb using
> boot consoles")
> Fixes: eae3e19ca930 ("kgdboc: Remove useless #ifdef
> CONFIG_KGDB_SERIAL_CONSOLE in kgdboc")
> Reported-by: Stephen Rothwell
> Signed-off-by: Douglas Anderson
Applied, thanks!
Daniel.
> ---
>
> drivers/tty/serial/kgdboc.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c
> index 34b5e91dd245..fa6f7a3e73b9 100644
> --- a/drivers/tty/serial/kgdboc.c
> +++ b/drivers/tty/serial/kgdboc.c
> @@ -43,9 +43,11 @@ static int kgdb_tty_line;
>
> static struct platform_device *kgdboc_pdev;
>
> +#if IS_BUILTIN(CONFIG_KGDB_SERIAL_CONSOLE)
> static struct kgdb_iokgdboc_earlycon_io_ops;
> static struct console*earlycon;
> static int (*earlycon_orig_exit)(struct console *con);
> +#endif /* IS_BUILTIN(CONFIG_KGDB_SERIAL_CONSOLE) */
>
> #ifdef CONFIG_KDB_KEYBOARD
> static int kgdboc_reset_connect(struct input_handler *handler,
> @@ -140,10 +142,19 @@ static void kgdboc_unregister_kbd(void)
> #define kgdboc_restore_input()
> #endif /* ! CONFIG_KDB_KEYBOARD */
>
> -static void cleanup_kgdboc(void)
> +#if IS_BUILTIN(CONFIG_KGDB_SERIAL_CONSOLE)
> +static void cleanup_earlycon(void)
> {
> if (earlycon)
> kgdb_unregister_io_module(_earlycon_io_ops);
> +}
> +#else /* !IS_BUILTIN(CONFIG_KGDB_SERIAL_CONSOLE) */
> +static inline void cleanup_earlycon(void) { }
> +#endif /* !IS_BUILTIN(CONFIG_KGDB_SERIAL_CONSOLE) */
> +
> +static void cleanup_kgdboc(void)
> +{
> + cleanup_earlycon();
>
> if (configured != 1)
> return;
> @@ -388,6 +399,7 @@ static struct kgdb_io kgdboc_io_ops = {
> .post_exception = kgdboc_post_exp_handler,
> };
>
> +#if IS_BUILTIN(CONFIG_KGDB_SERIAL_CONSOLE)
> static int kgdboc_option_setup(char *opt)
> {
> if (!opt) {
> @@ -544,6 +556,7 @@ static int __init kgdboc_earlycon_init(char *opt)
> }
>
> early_param("kgdboc_earlycon", kgdboc_earlycon_init);
> +#endif /* IS_BUILTIN(CONFIG_KGDB_SERIAL_CONSOLE) */
>
> module_init(init_kgdboc);
> module_exit(exit_kgdboc);
> --
> 2.26.2.761.g0e0b3e54be-goog
>
Re: [PATCH] arm64: Fix PTRACE_SYSEMU semantics
From: Bin Lu
On Tue, May 19, 2020 at 01:07:27PM +0100, Catalin Marinas wrote:
> On Mon, May 18, 2020 at 12:41:20PM +0100, Will Deacon wrote:
> > On Fri, May 15, 2020 at 06:22:53PM -0400, Keno Fischer wrote:
> > > Quoth the man page:
> > > ```
> > >If the tracee was restarted by PTRACE_SYSCALL or PTRACE_SYSEMU, the
> > >tracee enters syscall-enter-stop just prior to entering any system
> > >call (which will not be executed if the restart was using
> > >PTRACE_SYSEMU, regardless of any change made to registers at this
> > >point or how the tracee is restarted after this stop).
> > > ```
> > >
> > > The parenthetical comment is currently true on x86 and powerpc,
> > > but not currently true on arm64. arm64 re-checks the _TIF_SYSCALL_EMU
> > > flag after the syscall entry ptrace stop. However, at this point,
> > > it reflects which method was used to re-start the syscall
> > > at the entry stop, rather than the method that was used to reach it.
> > > Fix that by recording the original flag before performing the ptrace
> > > stop, bringing the behavior in line with documentation and x86/powerpc.
> > >
> > > Signed-off-by: Keno Fischer
> > > ---
> > > arch/arm64/kernel/ptrace.c | 8 +---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> > > index b3d3005d9515..b67b4d14aa17 100644
> > > --- a/arch/arm64/kernel/ptrace.c
> > > +++ b/arch/arm64/kernel/ptrace.c
> > > @@ -1829,10 +1829,12 @@ static void tracehook_report_syscall(struct
> > > pt_regs *regs,
> > >
> > > int syscall_trace_enter(struct pt_regs *regs)
> > > {
> > > - if (test_thread_flag(TIF_SYSCALL_TRACE) ||
> > > - test_thread_flag(TIF_SYSCALL_EMU)) {
> > > + u32 flags = READ_ONCE(current_thread_info()->flags) &
> > > + (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE);
> > > +
> > > + if (flags) {
> >
> > nit: but I'd rather the '&' operation was in the conditional so that the
> > 'flags' variable holds all of the flags.
> >
> > With that:
> >
> > Acked-by: Will Deacon
> >
> > Also needs:
> >
> > Cc:
> > Fixes: f086f67485c5 ("arm64: ptrace: add support for syscall emulation")
> >
> > Catalin -- can you pick this up for 5.7 please, with my 'nit' addressed?
>
> I'll queue it with the above addressed. I think flags also needs to be
> unsigned long rather than u32.
>
> However, before sending the pull request, I'd like Sudeep to confirm
> that it doesn't break his original use-case for this feature.
>
Tested-by: Bin Lu (for gVisor)
I have just tested all gVisor syscall test cases with ptrace(Regs, FPRegs, TLS)
on Arm64 platform.
The test results are the same as before there was no patch.
My idea is that this kernel patch has no bad effects on gVisor.
Linux Kernel version: 5.7.0-rc6+
gVisor version: release-20200511.0
[PATCH] drm/nouveau: fix runtime pm imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index f5ece1f94973..125cefbb6210 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -157,8 +157,8 @@ nouveau_gem_object_close(struct drm_gem_object *gem, struct
drm_file *file_priv)
if (!WARN_ON(ret < 0 && ret != -EACCES)) {
nouveau_gem_object_unmap(nvbo, vma);
pm_runtime_mark_last_busy(dev);
- pm_runtime_put_autosuspend(dev);
}
+ pm_runtime_put_autosuspend(dev);
}
}
ttm_bo_unreserve(>bo);
--
2.17.1
[PATCH v2] MAINTAINERS: add files related to kdump
Kdump is implemented based on kexec, however some files are only related to crash dumping and missing, add them to KDUMP entry. Signed-off-by: Baoquan He Acked-by: Dave Young --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 83cf5c43242a..29c26e7a7a47 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9251,6 +9251,11 @@ L: ke...@lists.infradead.org S: Maintained W: http://lse.sourceforge.net/kdump/ F: Documentation/admin-guide/kdump/ +F: fs/proc/vmcore.c +F: include/linux/crash_core.h +F: include/linux/crash_dump.h +F: include/uapi/linux/vmcore.h +F: kernel/crash_*.c KEENE FM RADIO TRANSMITTER DRIVER M: Hans Verkuil -- 2.17.2
Re: [PATCH v1] drivers property: When no children in primary, try secondary
Thanks, Andy! On Wed, May 20, 2020 at 01:29:59PM +0300, Andy Shevchenko wrote: > Software firmware nodes can provide a child node to its parent. > Since software node can be secondary, we need a mechanism to access > the children. The idea is to list children of the primary node first > and when they are finished, continue with secondary node if available. > > Signed-off-by: Andy Shevchenko Acked-by: Sakari Ailus -- Sakari Ailus
Re: [RFC PATCH 0/4] DirectX on Linux
On Tuesday 2020-05-19 22:36, Sasha Levin wrote: > >> - Why DX12 on linux? Looking at this feels like classic divide and > > There is a single usecase for this: WSL2 developer who wants to run > machine learning on his GPU. The developer is working on his laptop, > which is running Windows and that laptop has a single GPU that Windows > is using. It does not feel right conceptually. If the target is a Windows API (DX12/ML), why bother with Linux environments? Make it a Windows executable, thereby skipping the WSL translation layer and passthrough.
Re: [RFC PATCH v3 1/2] cpufreq: change '.set_boost' to act on only one policy
On Wed, May 20, 2020 at 6:59 AM Viresh Kumar wrote:
>
> On 19-05-20, 19:41, Xiongfeng Wang wrote:
> > Macro 'for_each_active_policy()' is defined internally. To avoid some
> > cpufreq driver needing this macro to iterate over all the policies in
> > '.set_boost' callback, we redefine '.set_boost' to act on only one
> > policy and pass the policy as an argument.
> > 'cpufreq_boost_trigger_state()' iterate over all the policies to set
> > boost for the system. This is preparation for adding SW BOOST support
> > for CPPC.
> >
> > Signed-off-by: Xiongfeng Wang
> > ---
> > drivers/cpufreq/acpi-cpufreq.c | 4 ++--
> > drivers/cpufreq/cpufreq.c | 53
> > +-
> > include/linux/cpufreq.h| 2 +-
> > 3 files changed, 30 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> > index 289e8ce..b0a9eb5 100644
> > --- a/drivers/cpufreq/acpi-cpufreq.c
> > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > @@ -126,7 +126,7 @@ static void boost_set_msr_each(void *p_en)
> > boost_set_msr(enable);
> > }
> >
> > -static int set_boost(int val)
> > +static int set_boost(struct cpufreq_policy *policy, int val)
> > {
> > get_online_cpus();
> > on_each_cpu(boost_set_msr_each, (void *)(long)val, 1);
>
> I think (Rafael can confirm), that you need to update this as well. You don't
> need to run for each cpu now, but for each CPU in the policy.
Right, the caller will iterate over policies.
Accordingly, the CPU hotplug locking needs to go to the caller too.
Re: [PATCH v5 09/19] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
On 20/05/20 05:40PM, masonccy...@mxic.com.tw wrote:
>
> Hi Pratyush,
>
> > > > +/**
> > > > + * spi_nor_parse_profile1() - parse the xSPI Profile 1.0 table
> > > > + * @nor: pointer to a 'struct spi_nor'
> > > > + * @param_header: pointer to the 'struct sfdp_parameter_header'
> > > describing
> > > > + * the 4-Byte Address Instruction Table length and version.
> > > > + * @params: pointer to the 'struct spi_nor_flash_parameter' to
> be.
> > > > + *
> > > > + * Return: 0 on success, -errno otherwise.
> > > > + */
> > > > +static int spi_nor_parse_profile1(struct spi_nor *nor,
> > > > + const struct sfdp_parameter_header *profile1_header,
> > > > + struct spi_nor_flash_parameter *params)
> > > > +{
> > > > + u32 *table, opcode, addr;
> > > > + size_t len;
> > > > + int ret, i;
> > > > +
> > > > + len = profile1_header->length * sizeof(*table);
> > > > + table = kmalloc(len, GFP_KERNEL);
> > > > + if (!table)
> > > > + return -ENOMEM;
> > > > +
> > > > + addr = SFDP_PARAM_HEADER_PTP(profile1_header);
> > > > + ret = spi_nor_read_sfdp(nor, addr, len, table);
> > > > + if (ret)
> > > > + goto out;
> > > > +
> > > > + /* Fix endianness of the table DWORDs. */
> > > > + for (i = 0; i < profile1_header->length; i++)
> > > > + table[i] = le32_to_cpu(table[i]);
> > > > +
> > > > + /* Get 8D-8D-8D fast read opcode and dummy cycles. */
> > > > + opcode = FIELD_GET(PROFILE1_DWORD1_RD_FAST_CMD, table[0]);
> > > > +
> > > > + /*
> > > > +* Update the fast read settings. We set the default dummy
> cycles to
> > > 20
> > > > +* here. Flashes can change this value if they need to when
> enabling
> > > > +* octal mode.
> > > > +*/
> > > > + spi_nor_set_read_settings(>reads[SNOR_CMD_READ_8_8_8_DTR],
> > > > + 0, 20, opcode,
> > > > + SNOR_PROTO_8_8_8_DTR);
> > > > +
> > >
> > >
> > > I thought we have a agreement that only do parse here, no other read
> > > parameters setting.
> >
> > Yes, and I considered it. But it didn't make much sense to me to
> > introduce an extra member in struct spi_nor just to make this call in
> > some other function later.
> >
> > Why exactly do you think doing this here is bad? The way I see it, we
> > avoid carrying around an extra member in spi_nor and this also allows
> > flashes to change the read settings easily in a post-sfdp hook. The
> > 4bait parsing function does something similar.
>
> I think it's not a question for good or bad.
>
> 4bait parsing function parse the 4-Byte Address Instruction Table
> and set up read/pp parameters there for sure.
>
> Here we give the function name spi_nor_parse_profile1() but also
But the function that parses 4bait table is also called
spi_nor_parse_4bait().
> do others setting that has nothing to do with it,
Why has setting read opcode and dummy cycles got nothing to do with it?
The purpose of the Profile 1.0 table is to tell us the Read Fast command
and dummy cycles, among other things. I think it _does_ have something
to do with it.
Just like the 4bait table tells us the 4-byte opcodes and we set them up
in our data structures, the profile 1.0 table tells us the 8D read
opcode and dummy cycles, and we set them up in our data structures.
> it seems not good for SW module design.
> oh, it's my humble opinion.
>
> >
> > What are the benefits of doing it otherwise?
>
> For other Octal Flash like mx25*
I mean from a design perspective. How does it make the code better, or
the job of people who need to read/change it easier?
> >
> > Note that I did remove HWCAPS selection from here, which did seem like a
>
> > sane idea.
> >
> > > Driver should get dummy cycles used for various frequencies
> > > from 4th and 5th DWORD of xSPI table.[1]
> > >
> > > [1]
> > >
> https://patchwork.ozlabs.org/project/linux-mtd/patch/1587451187-6889-3-git-
>
> > send-email-masonccy...@mxic.com.tw/
> > >
> > >
> > > In addition, 20 dummy cycles is for 200MHz but not for 100MHz, 133MHz
> and
> > > 166MHz
> > > in case of read performance concern.
> > >
> > > Given a correct dummy cycles for a specific device. [2]
> > >
> > > [2]
> > >
> https://patchwork.ozlabs.org/project/linux-mtd/patch/1587451187-6889-5-git-
>
> > send-email-masonccy...@mxic.com.tw/
> >
> > The problem is that we don't know what speed the controller is driving
> > the flash at, and whether it is using Data Strobe. BFPT tells us the
> > maximum speed of the flash based on if Data Strobe is being used. The
> > controller can also drive it slower than the maximum. And it can drive
> > it with or without DS.
>
> This is for flash, not every Octal flash could work in 200MHz,
> The Max operation speeds for other Octal Flash is 100, 133 , or 166MHz.
>
> If a specific Octal Flash could work in 166MHz(Max), and driver setup the
> correct 16 dummy cycles for it rather than 20 dummy cycles.
> it's for performance concern.
Re: [PATCH v1] drivers property: When no children in primary, try secondary
On Wed, May 20, 2020 at 01:29:59PM +0300, Andy Shevchenko wrote:
> Software firmware nodes can provide a child node to its parent.
> Since software node can be secondary, we need a mechanism to access
> the children. The idea is to list children of the primary node first
> and when they are finished, continue with secondary node if available.
>
> Signed-off-by: Andy Shevchenko
FWIW:
Reviewed-by: Heikki Krogerus
> ---
> drivers/base/property.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 5f35c0ccf5e0..1e6d75e65938 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -708,14 +708,23 @@ struct fwnode_handle *device_get_next_child_node(struct
> device *dev,
>struct fwnode_handle *child)
> {
> struct acpi_device *adev = ACPI_COMPANION(dev);
> - struct fwnode_handle *fwnode = NULL;
> + struct fwnode_handle *fwnode = NULL, *next;
>
> if (dev->of_node)
> fwnode = >of_node->fwnode;
> else if (adev)
> fwnode = acpi_fwnode_handle(adev);
>
> - return fwnode_get_next_child_node(fwnode, child);
> + /* Try to find a child in primary fwnode */
> + next = fwnode_get_next_child_node(fwnode, child);
> + if (next)
> + return next;
> +
> + /* When no more children in primary, continue with secondary */
> + if (!IS_ERR_OR_NULL(fwnode->secondary))
> + next = fwnode_get_next_child_node(fwnode->secondary, child);
> +
> + return next;
> }
> EXPORT_SYMBOL_GPL(device_get_next_child_node);
Thanks Andy,
--
heikki
Re: [RFC PATCH v3 1/2] cpufreq: change '.set_boost' to act on only one policy
On 20-05-20, 12:36, Rafael J. Wysocki wrote:
> On Wed, May 20, 2020 at 6:59 AM Viresh Kumar wrote:
> >
> > On 19-05-20, 19:41, Xiongfeng Wang wrote:
> > > Macro 'for_each_active_policy()' is defined internally. To avoid some
> > > cpufreq driver needing this macro to iterate over all the policies in
> > > '.set_boost' callback, we redefine '.set_boost' to act on only one
> > > policy and pass the policy as an argument.
> > > 'cpufreq_boost_trigger_state()' iterate over all the policies to set
> > > boost for the system. This is preparation for adding SW BOOST support
> > > for CPPC.
> > >
> > > Signed-off-by: Xiongfeng Wang
> > > ---
> > > drivers/cpufreq/acpi-cpufreq.c | 4 ++--
> > > drivers/cpufreq/cpufreq.c | 53
> > > +-
> > > include/linux/cpufreq.h| 2 +-
> > > 3 files changed, 30 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/cpufreq/acpi-cpufreq.c
> > > b/drivers/cpufreq/acpi-cpufreq.c
> > > index 289e8ce..b0a9eb5 100644
> > > --- a/drivers/cpufreq/acpi-cpufreq.c
> > > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > > @@ -126,7 +126,7 @@ static void boost_set_msr_each(void *p_en)
> > > boost_set_msr(enable);
> > > }
> > >
> > > -static int set_boost(int val)
> > > +static int set_boost(struct cpufreq_policy *policy, int val)
> > > {
> > > get_online_cpus();
> > > on_each_cpu(boost_set_msr_each, (void *)(long)val, 1);
> >
> > I think (Rafael can confirm), that you need to update this as well. You
> > don't
> > need to run for each cpu now, but for each CPU in the policy.
>
> Right, the caller will iterate over policies.
>
> Accordingly, the CPU hotplug locking needs to go to the caller too.
Hmm, why is that required ? Can't we call boost_set_msr_each() for all
CPUs of a policy under the locks ? And then let the next call take the
lock again ? I thought we don't want a CPU to disappear while we are
trying to run boost_set_msr_each() for it (or miss one that just got
added) and that should work with the locks being there in this routine.
--
viresh
[tip:x86/entry 4/80] drivers/xen/events/events_base.c:1664:6: warning: no previous prototype for 'xen_setup_callback_vector'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry
head: 095b7a3e7745e6fb7cf0a1c09967c4f43e76f8f4
commit: fad1940a6a856f59b073e8650e02052ce531154c [4/80] x86/xen: Split HVM
vector callback setup and interrupt gate allocation
config: arm-randconfig-r013-20200519 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout fad1940a6a856f59b073e8650e02052ce531154c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/xen/events/events_base.c:1664:6: warning: no previous prototype for
>> 'xen_setup_callback_vector' [-Wmissing-prototypes]
1664 | void xen_setup_callback_vector(void) {}
| ^
vim +/xen_setup_callback_vector +1664 drivers/xen/events/events_base.c
1654
1655 static __init void xen_alloc_callback_vector(void)
1656 {
1657 if (!xen_have_vector_callback)
1658 return;
1659
1660 pr_info("Xen HVM callback vector for event delivery is
enabled\n");
1661 alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
xen_hvm_callback_vector);
1662 }
1663 #else
> 1664 void xen_setup_callback_vector(void) {}
1665 static inline void xen_alloc_callback_vector(void) {}
1666 #endif
1667
---
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 v2 1/2] hwrng: iproc-rng200 - Set the quality value
It was <2020-05-20 śro 11:18>, when Stephan Mueller wrote: > Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach: >> It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote: >>> Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach: The value was estimaded with ea_iid[1] using on 10485760 bytes read from the RNG via /dev/hwrng. The min-entropy value calculated using the most common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464. >>> >>> I am sorry, but I think I did not make myself clear: testing random >>> numbers post-processing with the statistical tools does NOT give any >>> idea about the entropy rate. Thus, all that was calculated is the >>> proper implementation of the post-processing operation and not the >>> actual noise source. >>> >>> What needs to happen is that we need access to raw, unconditioned >>> data from the noise source that is analyzed with the statistical >>> methods. >> >> I did understand you and I assure you the data I tested were obtained >> directly from RNGs. As I pointed before[1], that is how /dev/hwrng >> works[2]. > > I understand that /dev/hwrng pulls the data straight from the > hardware. But the data from the hardware usually is not obtained > straight from the noise source. > > Typically you have a noise source (e.g. a ring oscillator) whose data > is digitized then fed into a compression function like an LFSR or a > hash. Then a cryptographic operation like a CBC-MAC, hash or even a > DRBG is applied to that data when the caller wants to have random > numbers. I do understand your point (but not entirely, see below). [opinion] However, I am really not sure that this is a "typical" setting for a HW RNG, at least not among RNGs supported by Linux. Otherwise there would be no hw_random framework and no rngd(8) which are suppsed to post-process imperfectly random data from HW. [/opinion] > In order to estimate entropy, we need the raw unconditioned data from > the, say, ring oscillator and not from the (cryptographic) output > operation. Can you tell, why it matters in this case? If I understand correctly, the quality field describes not the randomness created by the noise generator but the one delivered by the driver to other software components. > That said, the illustrated example is typical for hardware RNGs. Yet > it is never guaranteed to work that way. Thus, if you can point to > architecture documentation of your specific hardware RNGs showing that > the data read from the hardware is pure unconditioned noise data, then > I have no objections to the patch. I can tell for sure that this is the case for exynos-trng[1]. There is a post-processor which I have forgotten about since writing the driver, because from the very beginning I didn't intend to use it. I knew there is the software framework for post-processing and simply didn't bother. With regards to iproc-rng200 I cannot be sure. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/hw_random/exynos-trng.c?h=v5.6#n100 Kind regards, -- Łukasz Stelmach Samsung R Institute Poland Samsung Electronics signature.asc Description: PGP signature
hello
helloone.pdf Description: Adobe PDF document
Re: [PATCH v1] drivers property: When no children in primary, try secondary
On Wed, May 20, 2020 at 12:34:06PM +0200, Rafael J. Wysocki wrote: > On Wed, May 20, 2020 at 12:30 PM Andy Shevchenko > wrote: > > > > Software firmware nodes can provide a child node to its parent. > > Since software node can be secondary, we need a mechanism to access > > the children. The idea is to list children of the primary node first > > and when they are finished, continue with secondary node if available. > > Makes sense. > > > Signed-off-by: Andy Shevchenko > > Greg, do you want me to apply it? > > If you'd rather take it yourself, please feel free to add > > Reviewed-by: Rafael J. Wysocki I can take it, there's other driver core patches in my tree already :) thanks, greg k-h
Re: [PATCH v1 13/25] dma-buf: Use sequence counter with associated wound/wait mutex
Am 19.05.20 um 23:45 schrieb Ahmed S. Darwish:
A sequence counter write side critical section must be protected by some
form of locking to serialize writers. If the serialization primitive is
not disabling preemption implicitly, preemption has to be explicitly
disabled before entering the sequence counter write side critical
section.
The dma-buf reservation subsystem uses plain sequence counters to manage
updates to reservations. Writer serialization is accomplished through a
wound/wait mutex.
Acquiring a wound/wait mutex does not disable preemption, so this needs
to be done manually before and after the write side critical section.
Use the newly-added seqcount_ww_mutex_t instead:
- It associates the ww_mutex with the sequence count, which enables
lockdep to validate that the write side critical section is properly
serialized.
- It removes the need to explicitly add preempt_disable/enable()
around the write side critical section because the write_begin/end()
functions for this new data type automatically do this.
If lockdep is disabled this ww_mutex lock association is compiled out
and has neither storage size nor runtime overhead.
Mhm, is the dma_resv object the only user of this new seqcount_ww_mutex
variant ?
If yes we are trying to get rid of this sequence counter for quite some
time, so I would rather invest the additional time to finish this.
Regards,
Christian.
Signed-off-by: Ahmed S. Darwish
---
drivers/dma-buf/dma-resv.c | 8 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 --
include/linux/dma-resv.h | 2 +-
3 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 590ce7ad60a0..3aba2b2bfc48 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -128,7 +128,7 @@ subsys_initcall(dma_resv_lockdep);
void dma_resv_init(struct dma_resv *obj)
{
ww_mutex_init(>lock, _ww_class);
- seqcount_init(>seq);
+ seqcount_ww_mutex_init(>seq, >lock);
RCU_INIT_POINTER(obj->fence, NULL);
RCU_INIT_POINTER(obj->fence_excl, NULL);
@@ -259,7 +259,6 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct
dma_fence *fence)
fobj = dma_resv_get_list(obj);
count = fobj->shared_count;
- preempt_disable();
write_seqcount_begin(>seq);
for (i = 0; i < count; ++i) {
@@ -281,7 +280,6 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct
dma_fence *fence)
smp_store_mb(fobj->shared_count, count);
write_seqcount_end(>seq);
- preempt_enable();
dma_fence_put(old);
}
EXPORT_SYMBOL(dma_resv_add_shared_fence);
@@ -308,14 +306,12 @@ void dma_resv_add_excl_fence(struct dma_resv *obj, struct
dma_fence *fence)
if (fence)
dma_fence_get(fence);
- preempt_disable();
write_seqcount_begin(>seq);
/* write_seqcount_begin provides the necessary memory barrier */
RCU_INIT_POINTER(obj->fence_excl, fence);
if (old)
old->shared_count = 0;
write_seqcount_end(>seq);
- preempt_enable();
/* inplace update, no shared fences */
while (i--)
@@ -393,13 +389,11 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct
dma_resv *src)
src_list = dma_resv_get_list(dst);
old = dma_resv_get_excl(dst);
- preempt_disable();
write_seqcount_begin(>seq);
/* write_seqcount_begin provides the necessary memory barrier */
RCU_INIT_POINTER(dst->fence_excl, new);
RCU_INIT_POINTER(dst->fence, dst_list);
write_seqcount_end(>seq);
- preempt_enable();
dma_resv_list_free(src_list);
dma_fence_put(old);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9dff792c9290..87fd32aae8f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -258,11 +258,9 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct
amdgpu_bo *bo,
new->shared_count = k;
/* Install the new fence list, seqcount provides the barriers */
- preempt_disable();
write_seqcount_begin(>seq);
RCU_INIT_POINTER(resv->fence, new);
write_seqcount_end(>seq);
- preempt_enable();
/* Drop the references to the removed fences or move them to ef_list */
for (i = j, k = 0; i < old->shared_count; ++i) {
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index a6538ae7d93f..d44a77e8a7e3 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -69,7 +69,7 @@ struct dma_resv_list {
*/
struct dma_resv {
struct ww_mutex lock;
- seqcount_t seq;
+ seqcount_ww_mutex_t seq;
struct dma_fence __rcu *fence_excl;
struct dma_resv_list __rcu *fence;
[PATCH] drm/nouveau/dispnv50: fix runtime pm imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 6be9df1820c5..e670756664ff 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1123,8 +1123,10 @@ nv50_mstc_detect(struct drm_connector *connector,
return connector_status_disconnected;
ret = pm_runtime_get_sync(connector->dev->dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ pm_runtime_put_autosuspend(connector->dev->dev);
return connector_status_disconnected;
+ }
ret = drm_dp_mst_detect_port(connector, ctx, mstc->port->mgr,
mstc->port);
--
2.17.1
Re: [PATCH v3 01/19] mm: memcg: factor out memcg- and lruvec-level changes out of __mod_lruvec_state()
On 4/22/20 10:46 PM, Roman Gushchin wrote:
> To convert memcg and lruvec slab counters to bytes there must be
> a way to change these counters without touching node counters.
> Factor out __mod_memcg_lruvec_state() out of __mod_lruvec_state().
>
> Signed-off-by: Roman Gushchin
Reviewed-by: Vlastimil Babka
Nit below:
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -713,30 +713,14 @@ parent_nodeinfo(struct mem_cgroup_per_node *pn, int nid)
> return mem_cgroup_nodeinfo(parent, nid);
> }
>
> -/**
> - * __mod_lruvec_state - update lruvec memory statistics
> - * @lruvec: the lruvec
> - * @idx: the stat item
> - * @val: delta to add to the counter, can be negative
> - *
> - * The lruvec is the intersection of the NUMA node and a cgroup. This
> - * function updates the all three counters that are affected by a
> - * change of state at this level: per-node, per-cgroup, per-lruvec.
> - */
> -void __mod_lruvec_state(struct lruvec *lruvec, enum node_stat_item idx,
> - int val)
> +void __mod_memcg_lruvec_state(struct lruvec *lruvec, enum node_stat_item idx,
> + int val)
> {
> pg_data_t *pgdat = lruvec_pgdat(lruvec);
Looks like the pgdat can now be moved into the MEMCG_CHARGE_BATCH if().
Re: [PATCH 1/2] mfd: constify properties in mfd_cell
On Sat, 16 May 2020, Tomas Winkler wrote: > Constify 'struct property_entry *properties' in > mfd_cell It is always passed > around as a pointer const struct. Apart from the odd commit log formatting ... > Signed-off-by: Tomas Winkler > --- > include/linux/mfd/core.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) ... patch seems fine. Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [tip:x86/entry 4/80] drivers/xen/events/events_base.c:1664:6: warning: no previous prototype for 'xen_setup_callback_vector'
kbuild test robot writes:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry
> head: 095b7a3e7745e6fb7cf0a1c09967c4f43e76f8f4
> commit: fad1940a6a856f59b073e8650e02052ce531154c [4/80] x86/xen: Split HVM
> vector callback setup and interrupt gate allocation
> config: arm-randconfig-r013-20200519 (attached as .config)
> compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout fad1940a6a856f59b073e8650e02052ce531154c
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> ARCH=arm
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot
>
> All warnings (new ones prefixed by >>, old ones prefixed by <<):
>
>>> drivers/xen/events/events_base.c:1664:6: warning: no previous prototype for
>>> 'xen_setup_callback_vector' [-Wmissing-prototypes]
> 1664 | void xen_setup_callback_vector(void) {}
> | ^
>
> vim +/xen_setup_callback_vector +1664 drivers/xen/events/events_base.c
>
> 1654
> 1655static __init void xen_alloc_callback_vector(void)
> 1656{
> 1657if (!xen_have_vector_callback)
> 1658return;
> 1659
> 1660pr_info("Xen HVM callback vector for event delivery is
> enabled\n");
> 1661alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
> xen_hvm_callback_vector);
> 1662}
> 1663#else
>> 1664 void xen_setup_callback_vector(void) {}
This isn't new in the patch as it just renames 'xen_callback_vector()'
to 'xen_setup_callback_vector()' but we likely need to add 'static'
here. I'll send a patch.
> 1665static inline void xen_alloc_callback_vector(void) {}
> 1666#endif
> 1667
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
--
Vitaly
Re: [PATCH v2 2/4] clk / soc: mediatek: Bind clock and gpu driver for mt2712
On 20/05/2020 12:13, Stephen Boyd wrote: > Quoting Enric Balletbo i Serra (2020-04-01 13:17:34) >> Now that the mmsys driver is the top-level entry point for the >> multimedia subsystem, we could bind the clock and the gpu driver on >> those devices that is expected to work, so the drm driver is >> intantiated by the mmsys driver and display, hopefully, working again on >> those devices. >> >> Signed-off-by: Enric Balletbo i Serra >> Reviewed-by: Chun-Kuang Hu >> --- > > Acked-by: Stephen Boyd > Now queued for v5.7-next/soc Thanks!
Re: [PATCH v2 1/4] soc: mediatek: Enable mmsys driver by default if Mediatek arch is selected
On 01/04/2020 22:17, Enric Balletbo i Serra wrote: > The mmsys driver supports only MT8173 device for now, but like other system > controllers is an important piece for other Mediatek devices. Actually > it depends on the mt8173 clock specific driver but that dependency is > not real as it can build without the clock driver. Instead of depends on > a specific model, make the driver depends on the generic ARCH_MEDIATEK and > enable by default so other Mediatek devices can start using it without > flood the Kconfig. > > Signed-off-by: Enric Balletbo i Serra > --- Now queued for v5.7-next/soc Thanks! > > Changes in v2: None > > drivers/soc/mediatek/Kconfig | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig > index e84513318725..59a56cd790ec 100644 > --- a/drivers/soc/mediatek/Kconfig > +++ b/drivers/soc/mediatek/Kconfig > @@ -46,8 +46,7 @@ config MTK_SCPSYS > > config MTK_MMSYS > bool "MediaTek MMSYS Support" > - depends on COMMON_CLK_MT8173_MMSYS > - default COMMON_CLK_MT8173_MMSYS > + default ARCH_MEDIATEK > help > Say yes here to add support for the MediaTek Multimedia > Subsystem (MMSYS). >
Re: [PATCH v2 3/4] clk / soc: mediatek: Bind clock and gpu driver for mt2701
On 20/05/2020 12:13, Stephen Boyd wrote: > Quoting Enric Balletbo i Serra (2020-04-01 13:17:35) >> Now that the mmsys driver is the top-level entry point for the >> multimedia subsystem, we could bind the clock and the gpu driver on >> those devices that is expected to work, so the drm driver is >> intantiated by the mmsys driver and display, hopefully, working again. >> >> Signed-off-by: Enric Balletbo i Serra >> Reviewed-by: Chun-Kuang Hu >> --- > > Acked-by: Stephen Boyd > Now queued for v5.7-next/soc Thanks!
Re: [PATCH 1/2] MAINTAINERS: Add entry for ROHM power management ICs
Hi, On Wed, May 20, 2020 at 09:11:28AM +0300, Matti Vaittinen wrote: > Add entry for maintaining power management IC drivers for ROHM > BD71837, BD71847, BD71850, BD71828, BD71878, BD70528 and BD99954. > > Signed-off-by: Matti Vaittinen > --- Acked-by: Sebastian Reichel -- Sebastian > MAINTAINERS | 30 ++ > 1 file changed, 30 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ecc0749810b0..63a2ca70540e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -14490,6 +14490,12 @@ L: linux-ser...@vger.kernel.org > S: Odd Fixes > F: drivers/tty/serial/rp2.* > > +ROHM BD99954 CHARGER IC > +R: Matti Vaittinen > +S: Supported > +F: drivers/power/supply/bd99954-charger.c > +F: drivers/power/supply/bd99954-charger.h > + > ROHM BH1750 AMBIENT LIGHT SENSOR DRIVER > M: Tomasz Duszynski > S: Maintained > @@ -14507,6 +14513,30 @@ F: drivers/mfd/bd9571mwv.c > F: drivers/regulator/bd9571mwv-regulator.c > F: include/linux/mfd/bd9571mwv.h > > +ROHM POWER MANAGEMENT IC DEVICE DRIVERS > +R: Matti Vaittinen > +S: Supported > +F: Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt > +F: Documentation/devicetree/bindings/regulator/rohm,bd70528-regulator.txt > +F: drivers/clk/clk-bd718x7.c > +F: drivers/gpio/gpio-bd70528.c > +F: drivers/gpio/gpio-bd71828.c > +F: drivers/mfd/rohm-bd70528.c > +F: drivers/mfd/rohm-bd71828.c > +F: drivers/mfd/rohm-bd718x7.c > +F: drivers/power/supply/bd70528-charger.c > +F: drivers/regulator/bd70528-regulator.c > +F: drivers/regulator/bd71828-regulator.c > +F: drivers/regulator/bd718x7-regulator.c > +F: drivers/regulator/rohm-regulator.c > +F: drivers/rtc/rtc-bd70528.c > +F: drivers/watchdog/bd70528_wdt.c > +F: include/linux/mfd/rohm-shared.h > +F: include/linux/mfd/rohm-bd71828.h > +F: include/linux/mfd/rohm-bd70528.h > +F: include/linux/mfd/rohm-generic.h > +F: include/linux/mfd/rohm-bd718x7.h > + > ROSE NETWORK LAYER > M: Ralf Baechle > L: linux-h...@vger.kernel.org > -- > 2.21.0 > > > -- > Matti Vaittinen, Linux device drivers > ROHM Semiconductors, Finland SWDC > Kiviharjunlenkki 1E > 90220 OULU > FINLAND > > ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ > Simon says - in Latin please. > ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ > Thanks to Simon Glass for the translation =] signature.asc Description: PGP signature
Re: [PATCH v3] vsprintf: don't obfuscate NULL and error pointers
On Tue 2020-05-19 11:36:52, Linus Torvalds wrote: > On Tue, May 19, 2020 at 4:27 AM Ilya Dryomov wrote: > > > > This just came up again, please consider sending this to Linus > > for 5.7. > > I just took it directly, since I like it and it looks trivial. Great, I am happy that it has got resolved. I am sorry for the inconvenience. I have started working again last week. But I am still fighting with many pending mails. BTW: printk maintainers are switching to a git repo with shared write access to avoid these delays in the future. Best Regards, Petr
Re: [PATCH v2 4/4] arm64: dts: mt8173: Fix mmsys node name
On 01/04/2020 22:17, Enric Balletbo i Serra wrote:
> Node names are supposed to match the class of the device, mmsys is a
> system controller (syscon) not a clock controller, so change the node
> name accordingly.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Chun-Kuang Hu
> ---
Now queued for v5.7-next/dts64
Thanks!
>
> Changes in v2: None
>
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 8b4e806d5119..a55e8c177832 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -908,7 +908,7 @@ u2port1: usb-phy@11291000 {
> };
> };
>
> - mmsys: clock-controller@1400 {
> + mmsys: syscon@1400 {
> compatible = "mediatek,mt8173-mmsys", "syscon";
> reg = <0 0x1400 0 0x1000>;
> power-domains = < MT8173_POWER_DOMAIN_MM>;
>
Re: [PATCH 4/8] mm/swap: Use local_lock for protection
On Tue, May 19, 2020 at 10:19:08PM +0200, Sebastian Andrzej Siewior wrote:
> diff --git a/mm/swap.c b/mm/swap.c
> index bf9a79fed62d7..03c97d15fcd69 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -44,8 +44,14 @@
> /* How many pages do we try to swap or page in/out together? */
> int page_cluster;
>
> -static DEFINE_PER_CPU(struct pagevec, lru_add_pvec);
> +
> +/* Protecting lru_rotate_pvecs */
> +static DEFINE_LOCAL_LOCK(rotate_lock);
> static DEFINE_PER_CPU(struct pagevec, lru_rotate_pvecs);
> +
> +/* Protecting the following struct pagevec */
> +DEFINE_LOCAL_LOCK(swapvec_lock);
> +static DEFINE_PER_CPU(struct pagevec, lru_add_pvec);
> static DEFINE_PER_CPU(struct pagevec, lru_deactivate_file_pvecs);
> static DEFINE_PER_CPU(struct pagevec, lru_deactivate_pvecs);
> static DEFINE_PER_CPU(struct pagevec, lru_lazyfree_pvecs);
So personally I'd prefer to have this look like:
struct lru_vecs {
struct local_lock lock;
struct pagevec add;
struct pagevec rotate;
struct pagevec deact_file;
struct pagevec deact;
struct pagevec lazyfree;
#ifdef CONFIG_SMP
struct pagevec active;
#endif
};
DEFINE_PER_CPU(struct lru_pvec, lru_pvec);
or something, but I realize that is a lot of churn (although highly
automated), so I'll leave that to the mm folks.
Re: [PATCH 1/4] clk/soc: mediatek: mt8183: Bind clock driver from platform device
On 20/05/2020 12:14, Stephen Boyd wrote: > Quoting matthias@kernel.org (2020-05-18 04:31:53) >> From: Matthias Brugger >> >> The mmsys driver is now the top level entry point for the multimedia >> system (mmsys), we bind the clock driver by creating a platform device. >> We also bind the MediaTek DRM driver which is not yet implement and >> therefor will errror out for now. >> >> Signed-off-by: Matthias Brugger >> --- > > Acked-by: Stephen Boyd > Now queued for v5.7-next/soc
Re: [PATCH 2/4] clk/soc: mediatek: mt6797: Bind clock driver from platform device
On 20/05/2020 12:15, Stephen Boyd wrote: > Quoting matthias@kernel.org (2020-05-18 04:31:54) >> From: Matthias Brugger >> >> The mmsys driver is now the top level entry point for the multimedia >> system (mmsys), we bind the clock driver by creating a platform device. >> We also bind the MediaTek DRM driver which is not yet implement and >> therefor will errror out for now. >> >> Signed-off-by: Matthias Brugger >> --- > > Acked-by: Stephen Boyd > Now queued for v5.7-next/soc
Re: [PATCH 3/4] clk/soc: mediatek: mt6779: Bind clock driver from platform device
On 20/05/2020 12:15, Stephen Boyd wrote: > Quoting matthias@kernel.org (2020-05-18 04:31:55) >> From: Matthias Brugger >> >> The mmsys driver is now the top level entry point for the multimedia >> system (mmsys), we bind the clock driver by creating a platform device. >> We also bind the MediaTek DRM driver which is not yet implement and >> therefor will errror out for now. >> >> Signed-off-by: Matthias Brugger >> --- > > Acked-by: Stephen Boyd > Now queued for v5.7-next/soc
Re: [PATCH v6 0/5] perf stat: Support overall statistics for interval mode
On Wed, May 20, 2020 at 12:27:32PM +0800, Jin Yao wrote: > Currently perf-stat supports to print counts at regular interval (-I), > but it's not very easy for user to get the overall statistics. > > With this patchset, it supports to report the summary at the end of > interval output. > > For example, > > root@kbl-ppc:~# perf stat -e cycles -I1000 --interval-count 2 > # time counts unit events > 1.000412064 2,281,114 cycles > 2.001383658 2,547,880 cycles > > Performance counter stats for 'system wide': > > 4,828,994 cycles > > 2.002860349 seconds time elapsed > > root@kbl-ppc:~# perf stat -e cycles,instructions -I1000 --interval-count 2 > # time counts unit events > 1.000389902 1,536,093 cycles > 1.000389902420,226 instructions #0.27 > insn per cycle > 2.001433453 2,213,952 cycles > 2.001433453735,465 instructions #0.33 > insn per cycle > > Performance counter stats for 'system wide': > > 3,750,045 cycles > 1,155,691 instructions #0.31 insn per cycle > > 2.003023361 seconds time elapsed > > root@kbl-ppc:~# perf stat -M CPI,IPC -I1000 --interval-count 2 > # time counts unit events > 1.000435121905,303 inst_retired.any # > 2.9 CPI > 1.000435121 2,663,333 cycles > 1.000435121914,702 inst_retired.any # > 0.3 IPC > 1.000435121 2,676,559 cpu_clk_unhalted.thread > 2.001615941 1,951,092 inst_retired.any # > 1.8 CPI > 2.001615941 3,551,357 cycles > 2.001615941 1,950,837 inst_retired.any # > 0.5 IPC > 2.001615941 3,551,044 cpu_clk_unhalted.thread > > Performance counter stats for 'system wide': > > 2,856,395 inst_retired.any # 2.2 CPI > 6,214,690 cycles > 2,865,539 inst_retired.any # 0.5 IPC > 6,227,603 cpu_clk_unhalted.thread > > 2.003403078 seconds time elapsed > > v6: > --- > 1. Add comments in perf_evlist__save_aggr_prev_raw_counts. > 2. Move init_stats(_nsecs_stats) under interval condition check. > > Following patches are changed in v6. > perf stat: Save aggr value to first member of prev_raw_counts > perf stat: Report summary for interval mode Reviewed-by: Jiri Olsa thanks, jirka
Re: [PATCH 4/4] arm64: dts: mt6797: Fix mmsys node name
On 19/05/2020 17:06, Chun-Kuang Hu wrote:
> Hi, Matthias:
>
> 於 2020年5月18日 週一 下午7:33寫道：
>>
>> From: Matthias Brugger
>>
>> Node names are supposed to match the class of the device. The
>> mmsys node is a syscon as it provides more then just a clock controller.
>> Update the name.
>
> Reviewed-by: Chun-Kuang Hu
>
Now queued for v5.7-next/dts64
>>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> arch/arm64/boot/dts/mediatek/mt6797.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
>> index 136ef9527a0d..3efd032481ce 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
>> @@ -233,7 +233,7 @@ uart3: serial@11005000 {
>> status = "disabled";
>> };
>>
>> - mmsys: mmsys_config@1400 {
>> + mmsys: syscon@1400 {
>> compatible = "mediatek,mt6797-mmsys", "syscon";
>> reg = <0 0x1400 0 0x1000>;
>> #clock-cells = <1>;
>> --
>> 2.26.2
>>
>>
>> ___
>> Linux-mediatek mailing list
>> linux-media...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v3 0/9] perf: support enable and disable commands in stat and record modes
On Mon, May 18, 2020 at 11:08:43AM +0300, Alexey Budankov wrote: > Hi, > > Is there anything else that could be done from my side to move this forward? sorry I did not get to this yet.. will check jirka
Re: [PATCH 5/8] squashfs: make use of local lock in multi_cpu decompressor
On Tue, May 19, 2020 at 10:19:09PM +0200, Sebastian Andrzej Siewior wrote:
> diff --git a/fs/squashfs/decompressor_multi_percpu.c
> b/fs/squashfs/decompressor_multi_percpu.c
> index 2a2a2d106440e..8a77a2741c176 100644
> --- a/fs/squashfs/decompressor_multi_percpu.c
> +++ b/fs/squashfs/decompressor_multi_percpu.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
>
> #include "squashfs_fs.h"
> #include "squashfs_fs_sb.h"
> @@ -23,6 +24,8 @@ struct squashfs_stream {
> void*stream;
> };
>
> +static DEFINE_LOCAL_LOCK(stream_lock);
As per the others, you can stick it in struct squashfs_stream.
Re: [PATCH] powerpc: Replace zero-length array with flexible-array
On Thu, 7 May 2020 13:57:49 -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Replace zero-length array with flexible-array
https://git.kernel.org/powerpc/c/0f6be41c60699fd8cdfa93e5e85a306cec1ac1d0
cheers
Re: [PATCH] powerpc/mm: Replace zero-length array with flexible-array
On Thu, 7 May 2020 13:57:55 -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/mm: Replace zero-length array with flexible-array
https://git.kernel.org/powerpc/c/02bddf21c34d0a918acc8647195ba4507e3db8fc
cheers
Re: [PATCH] powerpc/kasan: Fix stack overflow by increasing THREAD_SHIFT
On Wed, 8 Apr 2020 15:58:49 + (UTC), Christophe Leroy wrote: > When CONFIG_KASAN is selected, the stack usage is increased. > > In the same way as x86 and arm64 architectures, increase > THREAD_SHIFT when CONFIG_KASAN is selected. Applied to powerpc/next. [1/1] powerpc/kasan: Fix stack overflow by increasing THREAD_SHIFT https://git.kernel.org/powerpc/c/edbadaf0671072298e506074128b64e003c5812c cheers
Re: [PATCH] powerpc/8xx: Update email address in MAINTAINERS
On Wed, 6 May 2020 06:51:59 + (UTC), Christophe Leroy wrote: > Since 01 May 2020, our email adresses have changed to @csgroup.eu > > Update MAINTAINERS accordingly. Applied to powerpc/next. [1/1] powerpc/8xx: Update email address in MAINTAINERS https://git.kernel.org/powerpc/c/679d74abc4e14cb369e46f080d90f4dc8c143e65 cheers
Re: [PATCH v6 00/16] powerpc/watchpoint: Preparation for more than one watchpoint
On Thu, 14 May 2020 16:47:25 +0530, Ravi Bangoria wrote: > So far, powerpc Book3S code has been written with an assumption of > only one watchpoint. But Power10[1] is introducing second watchpoint > register (DAWR). Even though this patchset does not enable 2nd DAWR, > it makes the infrastructure ready so that enabling 2nd DAWR should > just be a matter of changing count. > > Existing functionality works fine with the patchset. I've tested it > with perf, ptrace(gdb), xmon. All hw-breakpoint selftests are passing > as well. And I've build tested for 8xx and 'AMCC 44x, 46x or 47x'. > > [...] Applied to powerpc/next. [01/16] powerpc/watchpoint: Rename current DAWR macros https://git.kernel.org/powerpc/c/09f82b063aa9c248a3ef919aeec361054e7b044a [02/16] powerpc/watchpoint: Add SPRN macros for second DAWR https://git.kernel.org/powerpc/c/4a4ec2289a5d748cb64ff67ca8d74535a76a8436 [03/16] powerpc/watchpoint: Introduce function to get nr watchpoints dynamically https://git.kernel.org/powerpc/c/a6ba44e8799230e36c8ab06fda7f77f421e9e795 [04/16] powerpc/watchpoint/ptrace: Return actual num of available watchpoints https://git.kernel.org/powerpc/c/45093b382e0ac25c206b4dcd210c6be1f5e56e60 [05/16] powerpc/watchpoint: Provide DAWR number to set_dawr https://git.kernel.org/powerpc/c/a18b834625d345bfa89c4e2754dd6cbb0133c4d7 [06/16] powerpc/watchpoint: Provide DAWR number to __set_breakpoint https://git.kernel.org/powerpc/c/4a8a9379f2af4c9928529b3959bc2d8f7023c6bc [07/16] powerpc/watchpoint: Get watchpoint count dynamically while disabling them https://git.kernel.org/powerpc/c/c2919132734f29a7a33e1339bef8a67b11f322eb [08/16] powerpc/watchpoint: Disable all available watchpoints when !dawr_force_enable https://git.kernel.org/powerpc/c/22a214e461c5cc9428b86915d9cfcf84c6e11ad7 [09/16] powerpc/watchpoint: Convert thread_struct->hw_brk to an array https://git.kernel.org/powerpc/c/303e6a9ddcdc168e92253c78cdb4bbe1e10d78b3 [10/16] powerpc/watchpoint: Use loop for thread_struct->ptrace_bps https://git.kernel.org/powerpc/c/6b424efa119d5ea06b15ff240dddc3b4b9f9cdfb [11/16] powerpc/watchpoint: Introduce is_ptrace_bp() function https://git.kernel.org/powerpc/c/c9e82aeb197df2d93b1b4234bc0c80943fa594e8 [12/16] powerpc/watchpoint: Use builtin ALIGN*() macros https://git.kernel.org/powerpc/c/e68ef121c1f4c38edf87a3354661ceb99d522729 [13/16] powerpc/watchpoint: Prepare handler to handle more than one watchpoint https://git.kernel.org/powerpc/c/74c6881019b7d56c327fffc268d97adb5eb1b4f9 [14/16] powerpc/watchpoint: Don't allow concurrent perf and ptrace events https://git.kernel.org/powerpc/c/29da4f91c0c1fbda12b8a31be0d564930208c92e [15/16] powerpc/watchpoint/xmon: Don't allow breakpoint overwriting https://git.kernel.org/powerpc/c/514db915e7b33e7eaf8e40192b93380f79b319b5 [16/16] powerpc/watchpoint/xmon: Support 2nd DAWR https://git.kernel.org/powerpc/c/30df74d67d48949da87e3a5b57c381763e8fd526 cheers
Re: [PATCH 1/5] drivers/powerpc: Replace _ALIGN_UP() by ALIGN()
On Mon, 20 Apr 2020 18:36:34 + (UTC), Christophe Leroy wrote: > _ALIGN_UP() is specific to powerpc > ALIGN() is generic and does the same > > Replace _ALIGN_UP() by ALIGN() Applied to powerpc/next. [1/5] drivers/powerpc: Replace _ALIGN_UP() by ALIGN() https://git.kernel.org/powerpc/c/7bfc3c84cbf5167d943cff9b3d2619dab0b7894c [2/5] powerpc: Replace _ALIGN_DOWN() by ALIGN_DOWN() https://git.kernel.org/powerpc/c/e96d904ede6756641563d27daa746875b478a6c8 [3/5] powerpc: Replace _ALIGN_UP() by ALIGN() https://git.kernel.org/powerpc/c/b711531641038f3ff3723914f3d5ba79848d347e [4/5] powerpc: Replace _ALIGN() by ALIGN() https://git.kernel.org/powerpc/c/d3f3d3bf76cfb04e73436a15e3987d3573e7523a [5/5] powerpc: Remove _ALIGN_UP(), _ALIGN_DOWN() and _ALIGN() https://git.kernel.org/powerpc/c/4cdb2da654033d76e1b1cb4ac427d9193dce816b cheers
Re: [PATCH] powerpc/5200: update contact email
On Sat, 2 May 2020 16:26:42 +0200, Wolfram Sang wrote: > My 'pengutronix' address is defunct for years. Merge the entries and use > the proper contact address. Applied to powerpc/next. [1/1] powerpc/5200: update contact email https://git.kernel.org/powerpc/c/ad0f522df1b2f4fe5d4ae6418e1ea216154a0662 cheers
Re: [PATCH 20/20] maccess: return -ERANGE when copy_from_kernel_nofault_allowed fails
On Tue, 19 May 2020 15:44:49 +0200
Christoph Hellwig wrote:
> Allow the callers to distinguish a real unmapped address vs a range
> that can't be probed.
>
> Suggested-by: Masami Hiramatsu
> Signed-off-by: Christoph Hellwig
Hi Christoph,
Can you also update the kerneldoc comment too?
Other than that, this looks good to me.
Reviewed-by: Masami Hiramatsu
Thank you!
> ---
> mm/maccess.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/mm/maccess.c b/mm/maccess.c
> index 1e7d77656c596..4010d64189d21 100644
> --- a/mm/maccess.c
> +++ b/mm/maccess.c
> @@ -25,7 +25,7 @@ bool __weak copy_from_kernel_nofault_allowed(void *dst,
> const void *unsafe_src,
> long copy_from_kernel_nofault(void *dst, const void *src, size_t size)
> {
> if (!copy_from_kernel_nofault_allowed(dst, src, size))
> - return -EFAULT;
> + return -ERANGE;
>
> pagefault_disable();
> copy_from_kernel_nofault_loop(dst, src, size, u64, Efault);
> @@ -69,7 +69,7 @@ long strncpy_from_kernel_nofault(char *dst, const void
> *unsafe_addr, long count)
> if (unlikely(count <= 0))
> return 0;
> if (!copy_from_kernel_nofault_allowed(dst, unsafe_addr, count))
> - return -EFAULT;
> + return -ERANGE;
>
> pagefault_disable();
> do {
> @@ -107,7 +107,7 @@ long copy_from_kernel_nofault(void *dst, const void *src,
> size_t size)
> mm_segment_t old_fs = get_fs();
>
> if (!copy_from_kernel_nofault_allowed(dst, src, size))
> - return -EFAULT;
> + return -ERANGE;
>
> set_fs(KERNEL_DS);
> pagefault_disable();
> @@ -174,7 +174,7 @@ long strncpy_from_kernel_nofault(char *dst, const void
> *unsafe_addr, long count)
> if (unlikely(count <= 0))
> return 0;
> if (!copy_from_kernel_nofault_allowed(dst, unsafe_addr, count))
> - return -EFAULT;
> + return -ERANGE;
>
> set_fs(KERNEL_DS);
> pagefault_disable();
> --
> 2.26.2
>
--
Masami Hiramatsu
Re: [PATCH 6/8] connector/cn_proc: Protect send_msg() with a local lock
On Tue, May 19, 2020 at 10:19:10PM +0200, Sebastian Andrzej Siewior wrote:
> @@ -40,10 +41,11 @@ static struct cb_id cn_proc_event_id = { CN_IDX_PROC,
> CN_VAL_PROC };
>
> /* proc_event_counts is used as the sequence number of the netlink message */
> static DEFINE_PER_CPU(__u32, proc_event_counts) = { 0 };
> +static DEFINE_LOCAL_LOCK(send_msg_lock);
Put it in a struct ?
Re: [PATCH] dma-fence: add might_sleep annotation to _wait()
On Wed, May 20, 2020 at 08:54:36AM +0200, Christian König wrote: > Am 19.05.20 um 15:27 schrieb Daniel Vetter: > > Do it uncontionally, there's a separate peek function with > > dma_fence_is_signalled() which can be called from atomic context. > > > > v2: Consensus calls for an unconditional might_sleep (Chris, > > Christian) > > > > Full audit: > > - dma-fence.h: Uses MAX_SCHEDULE_TIMOUT, good chance this sleeps > > - dma-resv.c: Timeout always at least 1 > > - st-dma-fence.c: Save to sleep in testcases > > - amdgpu_cs.c: Both callers are for variants of the wait ioctl > > - amdgpu_device.c: Two callers in vram recover code, both right next > >to mutex_lock. > > - amdgpu_vm.c: Use in the vm_wait ioctl, next to _reserve/unreserve > > - remaining functions in amdgpu: All for test_ib implementations for > >various engines, caller for that looks all safe (debugfs, driver > >load, reset) > > - etnaviv: another wait ioctl > > - habanalabs: another wait ioctl > > - nouveau_fence.c: hardcoded 15*HZ ... glorious > > - nouveau_gem.c: hardcoded 2*HZ ... so not even super consistent, but > >this one does have a WARN_ON :-/ At least this one is only a > >fallback path for when kmalloc fails. Maybe this should be put onto > >some worker list instead, instead of a work per unamp ... > > - i915/selftests: Hardecoded HZ / 4 or HZ / 8 > > - i915/gt/selftests: Going up the callchain looks safe looking at > >nearby callers > > - i915/gt/intel_gt_requests.c. Wrapped in a mutex_lock > > - i915/gem_i915_gem_wait.c: The i915-version which is called instead > >for i915 fences already has a might_sleep() annotation, so all good > > > > Cc: Alex Deucher > > Cc: Lucas Stach > > Cc: Jani Nikula > > Cc: Joonas Lahtinen > > Cc: Rodrigo Vivi > > Cc: Ben Skeggs > > Cc: "VMware Graphics" > > Cc: Oded Gabbay > > Cc: linux-me...@vger.kernel.org > > Cc: linaro-mm-...@lists.linaro.org > > Cc: linux-r...@vger.kernel.org > > Cc: amd-...@lists.freedesktop.org > > Cc: intel-...@lists.freedesktop.org > > Cc: Chris Wilson > > Cc: Maarten Lankhorst > > Cc: Christian König > > Signed-off-by: Daniel Vetter > > Reviewed-by: Christian König intel-gfx-ci approves too, thanks to both of you for reviews, patch merged to drm-misc-next. -Daniel > > > --- > > drivers/dma-buf/dma-fence.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > > index 90edf2b281b0..656e9ac2d028 100644 > > --- a/drivers/dma-buf/dma-fence.c > > +++ b/drivers/dma-buf/dma-fence.c > > @@ -208,6 +208,8 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool > > intr, signed long timeout) > > if (WARN_ON(timeout < 0)) > > return -EINVAL; > > + might_sleep(); > > + > > trace_dma_fence_wait_start(fence); > > if (fence->ops->wait) > > ret = fence->ops->wait(fence, intr, timeout); > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/panfrost: fix runtime pm imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/panfrost/panfrost_job.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 7914b1570841..5719e356c969 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -146,8 +146,10 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
int ret;
ret = pm_runtime_get_sync(pfdev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_sync_autosuspend(pfdev->dev);
return;
+ }
if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js {
pm_runtime_put_sync_autosuspend(pfdev->dev);
--
2.17.1
Re: [PATCH] PCI: dwc: Warn only for non-prefetchable memory resource size >4GB
On Tue, May 19, 2020 at 10:08:54PM +, Gustavo Pimentel wrote: [...] > > > > > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c > > > > > > b/drivers/pci/controller/dwc/pcie-designware-host.c > > > > > > index 42fbfe2a1b8f..a29396529ea4 100644 > > > > > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c > > > > > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c > > > > > > @@ -366,7 +366,8 @@ int dw_pcie_host_init(struct pcie_port *pp) > > > > > > pp->mem = win->res; > > > > > > pp->mem->name = "MEM"; > > > > > > mem_size = resource_size(pp->mem); > > > > > > - if (upper_32_bits(mem_size)) > > > > > > + if (upper_32_bits(mem_size) && > > > > > > + !(win->res->flags & IORESOURCE_PREFETCH)) > > > > > > dev_warn(dev, "MEM resource size > > > > > > exceeds max for 32 bits\n"); > > > > > > pp->mem_size = mem_size; > > > > > > pp->mem_bus_addr = pp->mem->start - > > > > > > win->offset; > > > > > > > > That warning was added for a reason - why should not we log legitimate > > > > warnings ? AFAIU having resources larger than 4GB can lead to undefined > > > > behaviour given the current ATU programming API. > > > Yeah. I'm all for a warning if the size is larger than 4GB in case of > > > non-prefetchable window as one of the ATU outbound translation > > > channels is being used, > > > > Is it true for all DWC host controllers ? Or there may be another > > exception whereby we would be forced to disable this warning altogether > > ? > > > > > but, we are not employing any ATU outbound translation channel for > > > > What does this mean ? "we are not employing any ATU outbound...", is > > this the tegra driver ? And what guarantees that this warning is not > > legitimate on DWC host controllers that do use the ATU outbound > > translation for prefetchable windows ? > > > > Can DWC maintainers chime in and clarify please ? > > Before this code section, there is the following function call > pci_parse_request_of_pci_ranges(), which performs a simple validation for > the IORESOURCE_MEM resource type. > This validation checks if the resource is marked as prefetchable, if so, > an error message "non-prefetchable memory resource required" is given and > a return code with the -EINVAL value. That code checks if there is *at least* a non-prefetchable resource, that's all it does. > In other words, to reach the code that Vidya is changing, it can be only > if the resource is a non-prefetchable, any prefetchable resource will be > blocked by the previous call, if I'm not mistaken. I think you are mistaken sorry. > Having this in mind, Vidya's change will not make the expected result > aimed by him. I think Vidya's patch does what he expects, the question is whether it is widely applicable to ALL DWC hosts, that's what I want to know. > I don't see any problem by having resources larger than 4GB, from what > I'm seeing in the databook there isn't any restricting related to that as > long they don't consume the maximum space that is addressable by the > system (depending on if they are 32-bit or 64-bit system address). > > To be honest, I'm not seeing a system that could have this resource > larger than 4GB, but it might exist some exception that I don't know of, > that's why I accepted Alan's patch to warn the user that the resource > exceeds the maximum for the 32 bits so that he can be aware that he > *might* be consuming the maximum space addressable. I think it is most certainly a possibility to have > 4GB prefetchable address spaces so we ought to fix this for good. I still have to understand how the DWC host detects the memory region to be programmed into the ATU given that there is more than one but only 1 ATU memory region AFAICS. Lorenzo
Re: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux
Hi Steve, thank you for the fast reply. Am 20.05.20 um 09:42 schrieb Steve Pronovost: >> Echoing what others said, you're not making a DRM driver. The driver should >> live outside of the DRM code. > > Agreed, please see my earlier reply. We'll be moving the driver to > drivers/hyperv node or something similar. Apology for the confusion here. > >> I have one question about the driver API: on Windows, DirectX versions are >> loosly tied to Windows releases. So I guess you can change the kernel >> interface among DirectX versions? >> If so, how would this work on Linux in the long term? If there ever is a >> DirectX 13 or 14 with incompatible kernel interfaces, how would you plan to >> update the Linux driver? > > You should think of the communication over the VM Bus for the vGPU projection > as a strongly versioned interface. We will be keeping compatibility with > older version of that interface as it evolves over time so we can continue to > run older guest (we already do). This protocol isn't actually tied to the DX > API. It is a generic abstraction for the GPU that can be used for any APIs > (for example the NVIDIA CUDA driver that we announced is going over the same > protocol to access the GPU). > > New version of user mode DX can either take advantage or sometime require new > services from this kernel abstraction. This mean that pulling a new version > of user mode DX can mean having to also pull a new version of this vGPU > kernel driver. For WSL, these essentially ships together. The kernel driver > ships as part of our WSL2 Linux Kernel integration. User mode DX bits ships > with Windows. Just a friendly advise: maintaining a proprietary component within a Linux environment is tough. You will need a good plan for long-term interface stability and compatibility with the other components. Best regards Thomas > > -Original Message- > From: Thomas Zimmermann > Sent: Wednesday, May 20, 2020 12:11 AM > To: Sasha Levin ; alexander.deuc...@amd.com; > ch...@chris-wilson.co.uk; ville.syrj...@linux.intel.com; > hawking.zh...@amd.com; tvrtko.ursu...@intel.com > Cc: linux-kernel@vger.kernel.org; linux-hyp...@vger.kernel.org; KY Srinivasan > ; Haiyang Zhang ; Stephen > Hemminger ; wei@kernel.org; Steve Pronovost > ; Iouri Tarassov ; > dri-de...@lists.freedesktop.org; linux-fb...@vger.kernel.org; > gre...@linuxfoundation.org > Subject: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux > > Hi > > Am 19.05.20 um 18:32 schrieb Sasha Levin: >> There is a blog post that goes into more detail about the bigger >> picture, and walks through all the required pieces to make this work. >> It is available here: >> https://devblogs.microsoft.com/directx/directx-heart-linux . The rest >> of this cover letter will focus on the Linux Kernel bits. > > That's quite a surprise. Thanks for your efforts to contribute. > >> >> Overview >> >> >> This is the first draft of the Microsoft Virtual GPU (vGPU) driver. >> The driver exposes a paravirtualized GPU to user mode applications >> running in a virtual machine on a Windows host. This enables hardware >> acceleration in environment such as WSL (Windows Subsystem for Linux) >> where the Linux virtual machine is able to share the GPU with the >> Windows host. >> >> The projection is accomplished by exposing the WDDM (Windows Display >> Driver Model) interface as a set of IOCTL. This allows APIs and user >> mode driver written against the WDDM GPU abstraction on Windows to be >> ported to run within a Linux environment. This enables the port of the >> D3D12 and DirectML APIs as well as their associated user mode driver >> to Linux. This also enables third party APIs, such as the popular >> NVIDIA Cuda compute API, to be hardware accelerated within a WSL environment. >> >> Only the rendering/compute aspect of the GPU are projected to the >> virtual machine, no display functionality is exposed. Further, at this >> time there are no presentation integration. So although the D3D12 API >> can be use to render graphics offscreen, there is no path (yet) for >> pixel to flow from the Linux environment back onto the Windows host >> desktop. This GPU stack is effectively side-by-side with the native >> Linux graphics stack. >> >> The driver creates the /dev/dxg device, which can be opened by user >> mode application and handles their ioctls. The IOCTL interface to the >> driver is defined in dxgkmthk.h (Dxgkrnl Graphics Port Driver ioctl >> definitions). The interface matches the D3DKMT interface on Windows. >> Ioctls are implemented in ioctl.c. > > Echoing what others said, you're not making a DRM driver. The driver should > live outside of the DRM code. > > I have one question about the driver API: on Windows, DirectX versions are > loosly tied to Windows releases. So I guess you can change the kernel > interface among DirectX versions? > > If so, how would this work on Linux in the long term? If there
Re: [PATCH 7/8] zram: Use local lock to protect per-CPU data
On Tue, May 19, 2020 at 10:19:11PM +0200, Sebastian Andrzej Siewior wrote:
> +static DEFINE_LOCAL_LOCK(zcomp_lock);
> +
> struct zcomp_strm *zcomp_stream_get(struct zcomp *comp)
> {
> - return *get_cpu_ptr(comp->stream);
> + local_lock(zcomp_lock);
> + return *this_cpu_ptr(comp->stream);
> }
put it in struct czomp_strm ?
[PATCH 2/3] switchdev: mrp: Remove the variable mrp_ring_state
Remove the variable mrp_ring_state from switchdev_attr because is not
used anywhere.
The ring state is set using SWITCHDEV_OBJ_ID_RING_STATE_MRP.
Fixes: c284b5459008 ("switchdev: mrp: Extend switchdev API to offload MRP")
Signed-off-by: Horatiu Vultur
---
include/net/switchdev.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index ae7aeb0d1f9ca..db519957e134b 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -62,7 +62,6 @@ struct switchdev_attr {
#if IS_ENABLED(CONFIG_BRIDGE_MRP)
u8 mrp_port_state; /* MRP_PORT_STATE */
u8 mrp_port_role; /* MRP_PORT_ROLE */
- u8 mrp_ring_state; /* MRP_RING_STATE */
#endif
} u;
};
--
2.26.2
Re: [EXT] Re: [PATCH net-next 3/5] net: mvpp2: cls: Use RSS contexts to handle RSS tables
On Tue, May 19, 2020 at 07:05:34PM +0200, Matteo Croce wrote: > On Tue, 19 May 2020 12:05:20 +0200 > Matteo Croce wrote: > > Hi, > > The patch seems to work. I'm generating traffic with random MAC and IP > addresses, to have many flows: > > # tcpdump -tenni eth2 > 9a:a9:b1:3a:b1:6b > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: > 10.0.0.4.0 > 192.168.0.4.0: UDP, length 12 > 9e:92:fd:f8:7f:0a > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: > 10.0.0.4.0 > 192.168.0.4.0: UDP, length 12 > 66:b7:11:8a:c2:1f > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: > 10.0.0.1.0 > 192.168.0.1.0: UDP, length 12 > 7a:ba:58:bd:9a:62 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: > 10.0.0.1.0 > 192.168.0.1.0: UDP, length 12 > 7e:78:a9:97:70:3a > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: > 10.0.0.2.0 > 192.168.0.2.0: UDP, length 12 > b2:81:91:34:ce:42 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: > 10.0.0.2.0 > 192.168.0.2.0: UDP, length 12 > 2a:05:52:d0:d9:3f > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: > 10.0.0.3.0 > 192.168.0.3.0: UDP, length 12 > ee:ee:47:35:fa:81 > 00:51:82:11:22:02, ethertype IPv4 (0x0800), length 60: > 10.0.0.3.0 > 192.168.0.3.0: UDP, length 12 > > This is the default rate, with rxhash off: > > # utraf eth2 > tx: 0 bps 0 pps rx: 397.4 Mbps 827.9 Kpps > tx: 0 bps 0 pps rx: 396.3 Mbps 825.7 Kpps > tx: 0 bps 0 pps rx: 396.6 Mbps 826.3 Kpps > tx: 0 bps 0 pps rx: 396.5 Mbps 826.1 Kpps > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > 9 root 20 0 0 0 0 R 99.7 0.0 7:02.58 > ksoftirqd/0 > 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 > ksoftirqd/1 > 20 root 20 0 0 0 0 S 0.0 0.0 2:01.48 > ksoftirqd/2 > 25 root 20 0 0 0 0 S 0.0 0.0 0:32.86 > ksoftirqd/3 > > and this with rx hashing enabled: > > # ethtool -K eth2 rxhash on > # utraf eth2 > tx: 0 bps 0 pps rx: 456.4 Mbps 950.8 Kpps > tx: 0 bps 0 pps rx: 458.4 Mbps 955.0 Kpps > tx: 0 bps 0 pps rx: 457.6 Mbps 953.3 Kpps > tx: 0 bps 0 pps rx: 462.2 Mbps 962.9 Kpps > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > 20 root 20 0 0 0 0 R 0.7 0.0 2:02.34 > ksoftirqd/2 > 25 root 20 0 0 0 0 S 0.3 0.0 0:33.25 > ksoftirqd/3 > 9 root 20 0 0 0 0 S 0.0 0.0 7:52.57 > ksoftirqd/0 > 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 > ksoftirqd/1 > > > The throughput doesn't increase so much, maybe we hit an HW limit of > the gigabit port. The interesting thing is how the global CPU usage > drops from 25% to 1%. > I can't explain this, it could be due to the reduced contention? Hi Matteo, Can I take that as a Tested-by ? Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
Re: [PATCH 13/20] maccess: always use strict semantics for probe_kernel_read
On Tue, 19 May 2020 15:44:42 +0200
Christoph Hellwig wrote:
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index 2f6737cc53e6c..82da20e712507 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -1208,7 +1208,13 @@ fetch_store_strlen(unsigned long addr)
> u8 c;
>
> do {
> - ret = probe_kernel_read(, (u8 *)addr + len, 1);
> + if (IS_ENABLED(CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE) &&
> + (unsigned long)addr < TASK_SIZE) {
> + ret = probe_user_read(,
> + (__force u8 __user *)addr + len, 1);
> + } else {
> + ret = probe_kernel_read(, (u8 *)addr + len, 1);
> + }
> len++;
> } while (c && ret == 0 && len < MAX_STRING_SIZE);
To avoid redundant check in the loop, we can use strnlen_user_nofault() out of
the loop. Something like below.
...
u8 c;
if (IS_ENABLED(CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE) &&
(unsigned long)addr < TASK_SIZE) {
return strnlen_user_nofault((__force u8 __user *)addr,
MAX_STRING_SIZE);
do {
ret = probe_kernel_read(, (u8 *)addr + len, 1);
len++;
} while (c && ret == 0 && len < MAX_STRING_SIZE);
...
This must work because we must not have a string that continues across
kernel space and user space.
Thank you,
--
Masami Hiramatsu
[PATCH 1/3] bridge: mrp: Add br_mrp_unique_ifindex function
It is not allow to have the same net bridge port part of multiple MRP
rings. Therefore add a check if the port is used already in a different
MRP. In that case return failure.
Fixes: 9a9f26e8f7ea ("bridge: mrp: Connect MRP API with the switchdev API")
Signed-off-by: Horatiu Vultur
---
net/bridge/br_mrp.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/net/bridge/br_mrp.c b/net/bridge/br_mrp.c
index d7bc09de4c139..a5a3fa59c078a 100644
--- a/net/bridge/br_mrp.c
+++ b/net/bridge/br_mrp.c
@@ -37,6 +37,32 @@ static struct br_mrp *br_mrp_find_id(struct net_bridge *br,
u32 ring_id)
return res;
}
+static bool br_mrp_unique_ifindex(struct net_bridge *br, u32 ifindex)
+{
+ struct br_mrp *mrp;
+ bool res = true;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(mrp, >mrp_list, list,
+ lockdep_rtnl_is_held()) {
+ struct net_bridge_port *p;
+
+ p = rcu_dereference(mrp->p_port);
+ if (p && p->dev->ifindex == ifindex) {
+ res = false;
+ break;
+ }
+
+ p = rcu_dereference(mrp->s_port);
+ if (p && p->dev->ifindex == ifindex) {
+ res = false;
+ break;
+ }
+ }
+ rcu_read_unlock();
+ return res;
+}
+
static struct br_mrp *br_mrp_find_port(struct net_bridge *br,
struct net_bridge_port *p)
{
@@ -255,6 +281,11 @@ int br_mrp_add(struct net_bridge *br, struct
br_mrp_instance *instance)
!br_mrp_get_port(br, instance->s_ifindex))
return -EINVAL;
+ /* It is not possible to have the same port part of multiple rings */
+ if (!br_mrp_unique_ifindex(br, instance->p_ifindex) ||
+ !br_mrp_unique_ifindex(br, instance->s_ifindex))
+ return -EINVAL;
+
mrp = kzalloc(sizeof(*mrp), GFP_KERNEL);
if (!mrp)
return -ENOMEM;
--
2.26.2
[PATCH 3/3] bridge: mrp: Restore port state when deleting MRP instance
When a MRP instance is deleted, then restore the port according to the
bridge state. If the bridge is up then the ports will be in forwarding
state otherwise will be in disabled state.
Fixes: 9a9f26e8f7ea ("bridge: mrp: Connect MRP API with the switchdev API")
Signed-off-by: Horatiu Vultur
---
net/bridge/br_mrp.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/net/bridge/br_mrp.c b/net/bridge/br_mrp.c
index a5a3fa59c078a..bdd8920c15053 100644
--- a/net/bridge/br_mrp.c
+++ b/net/bridge/br_mrp.c
@@ -229,6 +229,7 @@ static void br_mrp_test_work_expired(struct work_struct
*work)
static void br_mrp_del_impl(struct net_bridge *br, struct br_mrp *mrp)
{
struct net_bridge_port *p;
+ u8 state;
/* Stop sending MRP_Test frames */
cancel_delayed_work_sync(>test_work);
@@ -240,20 +241,24 @@ static void br_mrp_del_impl(struct net_bridge *br, struct
br_mrp *mrp)
p = rtnl_dereference(mrp->p_port);
if (p) {
spin_lock_bh(>lock);
- p->state = BR_STATE_FORWARDING;
+ state = netif_running(br->dev) ?
+ BR_STATE_FORWARDING : BR_STATE_DISABLED;
+ p->state = state;
p->flags &= ~BR_MRP_AWARE;
spin_unlock_bh(>lock);
- br_mrp_port_switchdev_set_state(p, BR_STATE_FORWARDING);
+ br_mrp_port_switchdev_set_state(p, state);
rcu_assign_pointer(mrp->p_port, NULL);
}
p = rtnl_dereference(mrp->s_port);
if (p) {
spin_lock_bh(>lock);
- p->state = BR_STATE_FORWARDING;
+ state = netif_running(br->dev) ?
+ BR_STATE_FORWARDING : BR_STATE_DISABLED;
+ p->state = state;
p->flags &= ~BR_MRP_AWARE;
spin_unlock_bh(>lock);
- br_mrp_port_switchdev_set_state(p, BR_STATE_FORWARDING);
+ br_mrp_port_switchdev_set_state(p, state);
rcu_assign_pointer(mrp->s_port, NULL);
}
--
2.26.2
[PATCH 0/3] net: bridge: mrp: Add small fixes to MRP
This patch series adds small fixes to MRP implementation. The following are fixed in this patch series: - now is not allow to add the same port to multiple MRP rings - remove unused variable - restore the port state according to the bridge state when the MRP instance is deleted Horatiu Vultur (3): bridge: mrp: Add br_mrp_unique_ifindex function switchdev: mrp: Remove the variable mrp_ring_state bridge: mrp: Restore port state when deleting MRP instance include/net/switchdev.h | 1 - net/bridge/br_mrp.c | 44 + 2 files changed, 40 insertions(+), 5 deletions(-) -- 2.26.2
next-0519 on thinkpad x60: sound related? window manager crash
Hi! My window manager stopped responding. I was able to recover machine using sysrq-k. I started writing nice report, when session failed second time. And then third time on next attempt. Any ideas? I'll send this out before this locks up... Best regards, Pavel [ 2801.147411] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 2801.187449] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 2801.192260] usb 1-2: new high-speed USB device number 5 using ehci-pci [ 2801.240241] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 2801.300663] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 2801.352181] usb 1-2: New USB device found, idVendor=0525, idProduct=a4a1, bcdDevice= 5.07 [ 2801.352192] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2801.352200] usb 1-2: Product: Ethernet Gadget [ 2801.352207] usb 1-2: Manufacturer: Linux 5.7.0-rc4-00046-g6d7c0f75a522 with musb-hdrc [ 2801.419872] e1000e :02:00.0 eth1: NIC Link is Down [ 2801.428760] cdc_ether 1-2:1.0 usb0: register 'cdc_ether' at usb-:00:1d.7-2, CDC Ethernet Device, 72:ed:12:23:c9:c2 [ 2804.020289] wlan0: authenticate with 5c:f4:ab:10:d2:bb [ 2804.020451] wlan0: send auth to 5c:f4:ab:10:d2:bb (try 1/3) [ 2804.022385] wlan0: authenticated [ 2804.024243] wlan0: associate with 5c:f4:ab:10:d2:bb (try 1/3) [ 2804.026985] wlan0: RX AssocResp from 5c:f4:ab:10:d2:bb (capab=0x411 status=0 aid=2) [ 2804.028961] wlan0: associated [ 2874.520955] perf: interrupt took too long (2507 > 2500), lowering kernel.perf_event_max_sample_rate to 79750 [ 3730.016148] perf: interrupt took too long (3135 > 3133), lowering kernel.perf_event_max_sample_rate to 63750 [ 4274.984810] BUG: unable to handle page fault for address: f860 [ 4274.984821] #PF: supervisor write access in kernel mode [ 4274.984827] #PF: error_code(0x0002) - not-present page [ 4274.984833] *pdpt = 2c0b2001 *pde = [ 4274.984843] Oops: 0002 [#1] PREEMPT SMP PTI [ 4274.984853] CPU: 1 PID: 3351 Comm: marco Not tainted 5.7.0-rc6-next-20200519+ #115 [ 4274.984859] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011 [ 4274.984871] EIP: memset+0xb/0x20 [ 4274.984878] Code: f9 01 72 0b 8a 0e 88 0f 8d b4 26 00 00 00 00 8b 45 f0 83 c4 04 5b 5e 5f 5d c3 8d 74 26 00 90 55 89 e5 57 89 c7 53 89 c3 89 d0 aa 89 d8 5b 5f 5d c3 cc cc cc cc cc cc cc cc cc cc cc cc cc 89 [ 4274.984885] EAX: EBX: f85fe000 ECX: 0001e000 EDX: [ 4274.984892] ESI: ed158400 EDI: f860 EBP: edcc9e6c ESP: edcc9e64 [ 4274.984898] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246 [ 4274.984905] CR0: 80050033 CR2: f860 CR3: 2c114000 CR4: 06b0 [ 4274.984910] Call Trace: [ 4274.984923] snd_pcm_hw_params+0x38d/0x400 [ 4274.984930] snd_pcm_ioctl+0x187/0xe80 [ 4274.984940] ? __fget_files+0x86/0xc0 [ 4274.984947] ? __fget_light+0x6b/0x80 [ 4274.984954] ? snd_pcm_status_user64+0x90/0x90 [ 4274.984962] ksys_ioctl+0x1cd/0x880 [ 4274.984971] ? ksys_mmap_pgoff+0x81/0xc0 [ 4274.984978] ? fput+0xd/0x10 [ 4274.984984] ? ksys_mmap_pgoff+0x8d/0xc0 [ 4274.984991] __ia32_sys_ioctl+0x10/0x12 [ 4274.985000] do_int80_syscall_32+0x3c/0x100 [ 4274.985010] entry_INT80_32+0x116/0x116 [ 4274.985016] EIP: 0xb7f17092 [ 4274.985023] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00 [ 4274.985030] EAX: ffda EBX: 0011 ECX: c25c4111 EDX: bf8d5280 [ 4274.985036] ESI: 08250880 EDI: bf8d5280 EBP: 082a4150 ESP: bf8d50a4 [ 4274.985042] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: 00200292 [ 4274.985051] ? nmi+0xcc/0x2bc [ 4274.985055] Modules linked in: [ 4274.985063] CR2: f860 [ 4274.985072] ---[ end trace 61b0852711d6de1d ]--- [ 4274.985079] EIP: memset+0xb/0x20 [ 4274.985086] Code: f9 01 72 0b 8a 0e 88 0f 8d b4 26 00 00 00 00 8b 45 f0 83 c4 04 5b 5e 5f 5d c3 8d 74 26 00 90 55 89 e5 57 89 c7 53 89 c3 89 d0 aa 89 d8 5b 5f 5d c3 cc cc cc cc cc cc cc cc cc cc cc cc cc 89 [ 4274.985092] EAX: EBX: f85fe000 ECX: 0001e000 EDX: [ 4274.985099] ESI: ed158400 EDI: f860 EBP: edcc9e6c ESP: edcc9e64 [ 4274.985105] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246 [ 4274.985112] CR0: 80050033 CR2: f860 CR3: 2c114000 CR4: 06b0 [ 4337.396551] sysrq: SAK [ 4337.397010] tty tty7: SAK: killed process 2963 (Xorg): by session [ 4337.397282] tty tty7: SAK: killed process 2963 (Xorg): by controlling tty [ 4337.397621] tty tty7: SAK: killed process 3484 (console-kit-dae): by fd#9 [ 4337.397934] tty tty7: SAK: killed process 3485 (console-kit-dae): by fd#9 [ 4337.397940] tty tty7: SAK: killed process 3486
[PATCH v2 0/4] arm64: Introduce new IPI as IPI_CALL_NMI_FUNC
With pseudo NMIs support available its possible to configure SGIs to be triggered as pseudo NMIs running in NMI context. And kernel features such as kgdb relies on NMI support to round up CPUs which are stuck in hard lockup state with interrupts disabled. This patch-set adds support for IPI_CALL_NMI_FUNC which can be triggered as a pseudo NMI which in turn is leveraged via kgdb to round up CPUs. After this patch-set we should be able to get a backtrace for a CPU stuck in HARDLOCKUP. Have a look at an example below from a testcase run on Developerbox: $ echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT # Enter kdb via Magic SysRq [11]kdb> btc btc: cpu status: Currently on cpu 10 Available cpus: 0-7(I), 8, 9(I), 10, 11-23(I) Stack traceback for pid 619 0x000871bc9c00 619 618 18 R 0x000871bca5c0 bash CPU: 8 PID: 619 Comm: bash Not tainted 5.7.0-rc6-00762-g3804420 #77 Hardware name: Socionext SynQuacer E-series DeveloperBox, BIOS build #73 Apr 6 2020 Call trace: dump_backtrace+0x0/0x198 show_stack+0x18/0x28 dump_stack+0xb8/0x100 kgdb_cpu_enter+0x5c0/0x5f8 kgdb_nmicallback+0xa0/0xa8 ipi_kgdb_nmicallback+0x24/0x30 ipi_handler+0x160/0x1b8 handle_percpu_devid_fasteoi_ipi+0x44/0x58 generic_handle_irq+0x30/0x48 handle_domain_nmi+0x44/0x80 gic_handle_irq+0x140/0x2a0 el1_irq+0xcc/0x180 lkdtm_HARDLOCKUP+0x10/0x18 direct_entry+0x124/0x1c0 full_proxy_write+0x60/0xb0 __vfs_write+0x1c/0x48 vfs_write+0xe4/0x1d0 ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 el0_svc_common.constprop.0+0x74/0x1f0 do_el0_svc+0x24/0x90 el0_sync_handler+0x178/0x2b8 el0_sync+0x158/0x180 Changes since RFC version [1]: - Switch to use generic interrupt framework to turn an IPI as NMI. - Dependent on Marc's patch-set [2] which turns IPIs into normal interrupts. - Addressed misc. comments from Doug on patch #4. - Posted kgdb NMI printk() fixup separately which has evolved since to be solved using different approach via changing kgdb interception of printk() in common printk() code (see patch [3]). [1] https://lkml.org/lkml/2020/4/24/328 [2] https://lkml.org/lkml/2020/5/19/710 [3] https://lkml.org/lkml/2020/5/20/418 Sumit Garg (4): arm64: smp: Introduce a new IPI as IPI_CALL_NMI_FUNC irqchip/gic-v3: Enable support for SGIs to act as NMIs arm64: smp: Setup IPI_CALL_NMI_FUNC as a pseudo NMI arm64: kgdb: Round up cpus using IPI_CALL_NMI_FUNC arch/arm64/include/asm/hardirq.h | 2 +- arch/arm64/include/asm/kgdb.h| 8 +++ arch/arm64/include/asm/smp.h | 1 + arch/arm64/kernel/kgdb.c | 21 + arch/arm64/kernel/smp.c | 49 drivers/irqchip/irq-gic-v3.c | 13 +-- 6 files changed, 81 insertions(+), 13 deletions(-) -- 2.7.4
[PATCH v2 1/4] arm64: smp: Introduce a new IPI as IPI_CALL_NMI_FUNC
Introduce a new inter processor interrupt as IPI_CALL_NMI_FUNC that
can be invoked to run special handlers in NMI context. One such handler
example is kgdb_nmicallback() which is invoked in order to round up CPUs
to enter kgdb context.
As currently pseudo NMIs are supported on specific arm64 platforms which
incorporates GICv3 or later version of interrupt controller. In case a
particular platform doesn't support pseudo NMIs, IPI_CALL_NMI_FUNC will
act as a normal IPI which can still be used to invoke special handlers.
Signed-off-by: Sumit Garg
---
arch/arm64/include/asm/hardirq.h | 2 +-
arch/arm64/include/asm/smp.h | 1 +
arch/arm64/kernel/smp.c | 13 -
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/hardirq.h b/arch/arm64/include/asm/hardirq.h
index 87ad961..abaa23a 100644
--- a/arch/arm64/include/asm/hardirq.h
+++ b/arch/arm64/include/asm/hardirq.h
@@ -13,7 +13,7 @@
#include
#include
-#define NR_IPI 7
+#define NR_IPI 8
typedef struct {
unsigned int __softirq_pending;
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index bec6ef0..b4602de 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -106,6 +106,7 @@ extern void secondary_entry(void);
extern void arch_send_call_function_single_ipi(int cpu);
extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
+extern void arch_send_call_nmi_func_ipi_mask(const struct cpumask *mask);
#ifdef CONFIG_ARM64_ACPI_PARKING_PROTOCOL
extern void arch_send_wakeup_ipi_mask(const struct cpumask *mask);
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d29823a..236784e 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -81,7 +81,8 @@ enum ipi_msg_type {
IPI_CPU_CRASH_STOP,
IPI_TIMER,
IPI_IRQ_WORK,
- IPI_WAKEUP
+ IPI_WAKEUP,
+ IPI_CALL_NMI_FUNC
};
#ifdef CONFIG_HOTPLUG_CPU
@@ -802,6 +803,7 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
S(IPI_TIMER, "Timer broadcast interrupts"),
S(IPI_IRQ_WORK, "IRQ work interrupts"),
S(IPI_WAKEUP, "CPU wake-up interrupts"),
+ S(IPI_CALL_NMI_FUNC, "NMI function call interrupts"),
};
static void smp_cross_call(const struct cpumask *target, unsigned int ipinr);
@@ -855,6 +857,11 @@ void arch_irq_work_raise(void)
}
#endif
+void arch_send_call_nmi_func_ipi_mask(const struct cpumask *mask)
+{
+ smp_cross_call(mask, IPI_CALL_NMI_FUNC);
+}
+
static void local_cpu_stop(void)
{
set_cpu_online(smp_processor_id(), false);
@@ -949,6 +956,10 @@ static void do_handle_IPI(int ipinr)
break;
#endif
+ case IPI_CALL_NMI_FUNC:
+ /* nop, IPI handlers for special features can be added here. */
+ break;
+
default:
pr_crit("CPU%u: Unknown IPI message 0x%x\n", cpu, ipinr);
break;
--
2.7.4
[PATCH v2 3/4] arm64: smp: Setup IPI_CALL_NMI_FUNC as a pseudo NMI
Setup IPI_CALL_NMI_FUNC as a pseudo NMI using generic interrupt framework
APIs. In case a plarform doesn't provide support for pseudo NMIs, switch
back to IPI_CALL_NMI_FUNC being a normal interrupt.
Signed-off-by: Sumit Garg
---
arch/arm64/kernel/smp.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 236784e..c5e42a1 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -68,6 +68,7 @@ struct secondary_data secondary_data;
int cpus_stuck_in_kernel;
static int ipi_irq_base;
+static int ipi_nmi = -1;
static int nr_ipi = NR_IPI;
static struct irq_desc *ipi_desc[NR_IPI];
@@ -986,8 +987,14 @@ static void ipi_setup(int cpu)
if (ipi_irq_base) {
int i;
- for (i = 0; i < nr_ipi; i++)
- enable_percpu_irq(ipi_irq_base + i, 0);
+ for (i = 0; i < nr_ipi; i++) {
+ if (ipi_nmi == ipi_irq_base + i) {
+ if (!prepare_percpu_nmi(ipi_nmi))
+ enable_percpu_nmi(ipi_nmi, 0);
+ } else {
+ enable_percpu_irq(ipi_irq_base + i, 0);
+ }
+ }
}
}
@@ -997,23 +1004,33 @@ static void ipi_teardown(int cpu)
int i;
for (i = 0; i < nr_ipi; i++)
- disable_percpu_irq(ipi_irq_base + i);
+ if (ipi_nmi == ipi_irq_base + i) {
+ disable_percpu_nmi(ipi_nmi);
+ teardown_percpu_nmi(ipi_nmi);
+ } else {
+ disable_percpu_irq(ipi_irq_base + i);
+ }
}
}
void __init set_smp_ipi_range(int ipi_base, int n)
{
- int i;
+ int i, err;
WARN_ON(n < NR_IPI);
nr_ipi = min(n, NR_IPI);
- for (i = 0; i < nr_ipi; i++) {
- int err;
+ err = request_percpu_nmi(ipi_base + IPI_CALL_NMI_FUNC,
+ipi_handler, "IPI", _stat);
+ if (!err)
+ ipi_nmi = ipi_base + IPI_CALL_NMI_FUNC;
- err = request_percpu_irq(ipi_base + i, ipi_handler,
-"IPI", _stat);
- WARN_ON(err);
+ for (i = 0; i < nr_ipi; i++) {
+ if (ipi_base + i != ipi_nmi) {
+ err = request_percpu_irq(ipi_base + i, ipi_handler,
+"IPI", _stat);
+ WARN_ON(err);
+ }
ipi_desc[i] = irq_to_desc(ipi_base + i);
irq_set_status_flags(ipi_base + i, IRQ_NO_ACCOUNTING);
--
2.7.4
Re: [PATCH 13/20] maccess: always use strict semantics for probe_kernel_read
On Wed, May 20, 2020 at 08:11:26PM +0900, Masami Hiramatsu wrote:
> > - ret = probe_kernel_read(, (u8 *)addr + len, 1);
> > + if (IS_ENABLED(CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE) &&
> > + (unsigned long)addr < TASK_SIZE) {
> > + ret = probe_user_read(,
> > + (__force u8 __user *)addr + len, 1);
> > + } else {
> > + ret = probe_kernel_read(, (u8 *)addr + len, 1);
> > + }
> > len++;
> > } while (c && ret == 0 && len < MAX_STRING_SIZE);
>
> To avoid redundant check in the loop, we can use strnlen_user_nofault() out of
> the loop. Something like below.
Yes, I've done something very similar in response to Linus' comment (just
using an ifdef instead).
RE: [PATCH 8/8] mm/zswap: Use local lock to protect per-CPU data
> On 2020-05-19 21:46:06 [+], Song Bao Hua wrote:
> > Hi Luis,
> > In the below patch, in order to use the acomp APIs to leverage the power of
> hardware compressors. I have moved to mutex:
> > https://marc.info/?l=linux-crypto-vger=158941285830302=2
> > https://marc.info/?l=linux-crypto-vger=158941287930311=2
> >
> > so once we get some progress on that one, I guess we don't need a special
> patch for RT any more.
>
> If you convert this way from the current concept then we could drop it from
> the series.
> The second patch shows the following hunk:
>
> |@@ -1075,11 +1124,20 @@ static int zswap_frontswap_store(unsigned
> type,
> |pgoff_t offset,
> |
> | /* compress */
> | dst = get_cpu_var(zswap_dstmem);
> | acomp_ctx = *this_cpu_ptr(entry->pool->acomp_ctx);
> | put_cpu_var(zswap_dstmem);
>
> So here you get per-CPU version of `dst' and `acomp_ctx' and then allow
> preemption again.
>
> | mutex_lock(_ctx->mutex);
> |
> | src = kmap(page);
> | sg_init_one(, src, PAGE_SIZE);
> | /* zswap_dstmem is of size (PAGE_SIZE * 2). Reflect same in sg_list */
> | sg_init_one(, dst, PAGE_SIZE * 2);
>
> and here you use `dst' and `acomp_ctx' after the preempt_disable() has been
> dropped so I don't understand why you used get_cpu_var(). It is either
> protected by the mutex and doesn't require get_cpu_var() or it isn't (and
> should have additional protection).
The old code was like:
For each cpu, there is one percpu comp and one percpu pages for compression
destination - zswap_dstmem.
For example, on cpu1, once you begin to compress, you hold the percpu comp and
percpu destination buffer. Meanwhile, preemption is disabled. So decompression
won't be able to work at the same core in parallel. And two compressions won't
be able to do at the same core in parallel as well. At the same time, the
thread won't be able to migrate to another core. Other cores might can do
compression/decompression in parallel
The new code is like:
For each cpu, there is still one percpu acomp-ctx and one percpu pages for
compression destination. Here acomp replaces comp, and acomp requires sleep
during compressing and decompressing.
For example, on cpu1, once you begin to compress, you hold the percpu acomp-ctx
and percpu destination buffer of CPU1, the below code makes sure you get the
acomp and dstmem from the same core by disabling preemption with get_cpu_var
and put_cpu_var:
dst = get_cpu_var(zswap_dstmem);
acomp_ctx = *this_cpu_ptr(entry->pool->acomp_ctx);
put_cpu_var(zswap_dstmem);
then there are two cases:
1. after getting dst and acomp_ctx of cpu1, you might always work in cpu1, the
mutex in per-cpu acomp-ctx will guarantee two compressions won't do at the same
core in parallel, and it also makes certain compression and decompression won't
do at the same core in parallel. Everything is like before.
2. after getting dst and acomp_ctx of cpu1, you might migrate to cpu2, but even
you move to cpu2, you are still holding the mutex of cpu1's acomp-ctx.
If at that time, cpu1 has another request to do compression, it will be blocked
by the mutex held by cpu2.
If at that time, cpu1 wants to do decompression, it wil be blocked by the mutex
held by cpu2.
Everything is like before. No matter which core you have migrated to, once you
hold the mutex of core N, another compression/decompression who wants to hold
the mutex of core N will be blocked. So mostly, if you have M cores, you can do
M compression/decompression in parallel like before.
My basic idea is keeping the work model unchanged like before.
>
> | acomp_request_set_params(acomp_ctx->req, , ,
> PAGE_SIZE, dlen);
> | ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req),
> _ctx->wait);
> | dlen = acomp_ctx->req->dlen;
> | kunmap(page);
> |
> | if (ret) {
> | ret = -EINVAL;
> | goto put_dstmem;
> |
>
> Sebastian
Barry
[PATCH v2 2/4] irqchip/gic-v3: Enable support for SGIs to act as NMIs
Add support to handle SGIs as regular NMIs. As SGIs or IPIs defaults to a
special flow handler: handle_percpu_devid_fasteoi_ipi(), so skip NMI
handler update in case of SGIs.
Also, enable NMI support prior to gic_smp_init() as allocation of SGIs
as IRQs/NMIs happen as part of this routine.
Signed-off-by: Sumit Garg
---
drivers/irqchip/irq-gic-v3.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 82095b8..ceef63b 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -477,6 +477,11 @@ static int gic_irq_nmi_setup(struct irq_data *d)
if (WARN_ON(gic_irq(d) >= 8192))
return -EINVAL;
+ if (get_intid_range(d) == SGI_RANGE) {
+ gic_irq_set_prio(d, GICD_INT_NMI_PRI);
+ return 0;
+ }
+
/* desc lock should already be held */
if (gic_irq_in_rdist(d)) {
u32 idx = gic_get_ppi_index(d);
@@ -514,6 +519,11 @@ static void gic_irq_nmi_teardown(struct irq_data *d)
if (WARN_ON(gic_irq(d) >= 8192))
return;
+ if (get_intid_range(d) == SGI_RANGE) {
+ gic_irq_set_prio(d, GICD_INT_DEF_PRI);
+ return;
+ }
+
/* desc lock should already be held */
if (gic_irq_in_rdist(d)) {
u32 idx = gic_get_ppi_index(d);
@@ -1675,6 +1685,7 @@ static int __init gic_init_bases(void __iomem *dist_base,
gic_dist_init();
gic_cpu_init();
+ gic_enable_nmi_support();
gic_smp_init();
gic_cpu_pm_init();
@@ -1686,8 +1697,6 @@ static int __init gic_init_bases(void __iomem *dist_base,
gicv2m_init(handle, gic_data.domain);
}
- gic_enable_nmi_support();
-
return 0;
out_free:
--
2.7.4
[PATCH v2 4/4] arm64: kgdb: Round up cpus using IPI_CALL_NMI_FUNC
arm64 platforms with GICv3 or later supports pseudo NMIs which can be
leveraged to round up CPUs which are stuck in hard lockup state with
interrupts disabled that wouldn't be possible with a normal IPI.
So instead switch to round up CPUs using IPI_CALL_NMI_FUNC. And in
case a particular arm64 platform doesn't supports pseudo NMIs,
IPI_CALL_NMI_FUNC will act as a normal IPI which maintains existing
kgdb functionality.
Signed-off-by: Sumit Garg
---
arch/arm64/include/asm/kgdb.h | 8
arch/arm64/kernel/kgdb.c | 21 +
arch/arm64/kernel/smp.c | 3 ++-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kgdb.h b/arch/arm64/include/asm/kgdb.h
index 21fc85e..6f3d3af 100644
--- a/arch/arm64/include/asm/kgdb.h
+++ b/arch/arm64/include/asm/kgdb.h
@@ -24,6 +24,14 @@ static inline void arch_kgdb_breakpoint(void)
extern void kgdb_handle_bus_error(void);
extern int kgdb_fault_expected;
+#ifdef CONFIG_KGDB
+extern void ipi_kgdb_nmicallback(int cpu, void *regs);
+#else
+static inline void ipi_kgdb_nmicallback(int cpu, void *regs)
+{
+}
+#endif
+
#endif /* !__ASSEMBLY__ */
/*
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index 4311992..ee932ba 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -353,3 +354,23 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
return aarch64_insn_write((void *)bpt->bpt_addr,
*(u32 *)bpt->saved_instr);
}
+
+void ipi_kgdb_nmicallback(int cpu, void *regs)
+{
+ if (atomic_read(_active) != -1)
+ kgdb_nmicallback(cpu, regs);
+}
+
+#ifdef CONFIG_SMP
+void kgdb_roundup_cpus(void)
+{
+ struct cpumask mask;
+
+ cpumask_copy(, cpu_online_mask);
+ cpumask_clear_cpu(raw_smp_processor_id(), );
+ if (cpumask_empty())
+ return;
+
+ arch_send_call_nmi_func_ipi_mask();
+}
+#endif
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index c5e42a1..3baace7 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -958,7 +959,7 @@ static void do_handle_IPI(int ipinr)
#endif
case IPI_CALL_NMI_FUNC:
- /* nop, IPI handlers for special features can be added here. */
+ ipi_kgdb_nmicallback(cpu, get_irq_regs());
break;
default:
--
2.7.4
