Re: [uml-devel] [REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

Sigh I should have Cc'd Martin Partel as well as this bit is his original code. Anton Ivanov writes: > Hi Richard, > > There was a post to uml-devel during the days when the sourceforge mailing > list > was working in random drop mode which claimed that "this

Re: [uml-devel] [REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

Sigh I should have Cc'd Martin Partel as well as this bit is his original code. Anton Ivanov writes: > Hi Richard, > > There was a post to uml-devel during the days when the sourceforge mailing > list > was working in random drop mode which claimed that "this fixes the arm build". > > I have

Re: [PATCH 57/61] video: fbdev: simplify getting .drvdata

On Thursday, April 19, 2018 04:06:27 PM Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Patch queued for 4.18, thanks. Best regards, --

Re: [PATCH 57/61] video: fbdev: simplify getting .drvdata

On Thursday, April 19, 2018 04:06:27 PM Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Patch queued for 4.18, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R

Re: [PATCH] Makefile: Fix typo s/HOST_LOADLIBES/HOST_LOADLIBS

> Masahiro Yamada hat am 24. April 2018 um > 17:51 geschrieben: > > > 2018-04-24 17:44 GMT+09:00 Sedat Dilek : > > Signed-off-by: Sedat Dilek > > --- > > Makefile | 4 ++-- > > 1 file changed, 2 insertions(+), 2

Re: [PATCH] Makefile: Fix typo s/HOST_LOADLIBES/HOST_LOADLIBS

> Masahiro Yamada hat am 24. April 2018 um > 17:51 geschrieben: > > > 2018-04-24 17:44 GMT+09:00 Sedat Dilek : > > Signed-off-by: Sedat Dilek > > --- > > Makefile | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index

Re: [PATCH v5 01/23] soc: qcom dt-bindings: Add APR bus bindings

On 24/04/18 16:57, Mark Brown wrote: On Tue, Apr 24, 2018 at 10:52:26AM -0500, Rob Herring wrote: On Wed, Apr 18, 2018 at 04:31:35PM +0100, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla This patch add dt bindings for Qualcomm APR

Re: [PATCH v5 01/23] soc: qcom dt-bindings: Add APR bus bindings

On 24/04/18 16:57, Mark Brown wrote: On Tue, Apr 24, 2018 at 10:52:26AM -0500, Rob Herring wrote: On Wed, Apr 18, 2018 at 04:31:35PM +0100, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router) bus driver.

Re: [PATCH 3/3] drm/amdgpu: Switch to interrupted wait to recover from ring hang.

On 04/24/2018 11:52 AM, Panariti, David wrote: Hi, It looks like there can be an infinite loop if neither of the if()'s become true. Is that an impossible condition? That intended, we want to wait until either the fence signals or fatal signal received, we don't want to terminate the wait

Re: [PATCH 3/3] drm/amdgpu: Switch to interrupted wait to recover from ring hang.

On 04/24/2018 11:52 AM, Panariti, David wrote: Hi, It looks like there can be an infinite loop if neither of the if()'s become true. Is that an impossible condition? That intended, we want to wait until either the fence signals or fatal signal received, we don't want to terminate the wait

Re: [PATCH v5 01/23] soc: qcom dt-bindings: Add APR bus bindings

On Tue, Apr 24, 2018 at 10:52:26AM -0500, Rob Herring wrote: > On Wed, Apr 18, 2018 at 04:31:35PM +0100, srinivas.kandaga...@linaro.org > wrote: > > From: Srinivas Kandagatla > > This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router) > > bus

Re: [PATCH v5 01/23] soc: qcom dt-bindings: Add APR bus bindings

On Tue, Apr 24, 2018 at 10:52:26AM -0500, Rob Herring wrote: > On Wed, Apr 18, 2018 at 04:31:35PM +0100, srinivas.kandaga...@linaro.org > wrote: > > From: Srinivas Kandagatla > > This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router) > > bus driver. This bus is used for

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

On Tue, 2018-04-10 at 11:32 -0700, Jae Hyun Yoo wrote: > drivers/hwmon/peci-cputemp.c | 783 > ++ > drivers/hwmon/peci-dimmtemp.c | 432 +++ Does it make sense one driver per patch? > +#define CLIENT_CPU_ID_MASK0xf0ff0 /* Mask

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

On Tue, 2018-04-10 at 11:32 -0700, Jae Hyun Yoo wrote: > drivers/hwmon/peci-cputemp.c | 783 > ++ > drivers/hwmon/peci-dimmtemp.c | 432 +++ Does it make sense one driver per patch? > +#define CLIENT_CPU_ID_MASK0xf0ff0 /* Mask

Re: [PATCH] arm64: export tishift functions to modules

On Tue, Apr 24, 2018 at 5:40 PM, Will Deacon wrote: > On Tue, Apr 24, 2018 at 03:43:04PM +0200, Jason A. Donenfeld wrote: >> On Tue, Apr 24, 2018 at 3:34 PM, Will Deacon wrote: >> > I've not run into any build issues here -- is this specifically with

Re: [PATCH] arm64: export tishift functions to modules

On Tue, Apr 24, 2018 at 5:40 PM, Will Deacon wrote: > On Tue, Apr 24, 2018 at 03:43:04PM +0200, Jason A. Donenfeld wrote: >> On Tue, Apr 24, 2018 at 3:34 PM, Will Deacon wrote: >> > I've not run into any build issues here -- is this specifically with some >> > out-of-tree module? >> >> I

Re: Linux messages full of `random: get_random_u32 called from`

Dear Theodore, On 04/24/18 17:49, Theodore Y. Ts'o wrote: On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote: Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called from` messages. I believe, this

Re: Linux messages full of `random: get_random_u32 called from`

Dear Theodore, On 04/24/18 17:49, Theodore Y. Ts'o wrote: On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote: Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called from` messages. I believe, this

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

On Mon, Apr 23, 2018 at 05:22:44PM -0400, Steven Rostedt wrote: > On Mon, 23 Apr 2018 13:12:21 -0400 (EDT) > Mathieu Desnoyers wrote: > > > > I'm inclined to explicitly declare the tracepoints with their given > > synchronization method. Tracepoint probe callback

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

On Mon, Apr 23, 2018 at 05:22:44PM -0400, Steven Rostedt wrote: > On Mon, 23 Apr 2018 13:12:21 -0400 (EDT) > Mathieu Desnoyers wrote: > > > > I'm inclined to explicitly declare the tracepoints with their given > > synchronization method. Tracepoint probe callback functions for currently > >

Re: [PATCH] kmemleak: Report if we need to tune KMEMLEAK_EARLY_LOG_SIZE

On Tue, Apr 24, 2018 at 05:51:15PM +0200, Jan Kiszka wrote: > ...rather than just mysteriously disabling it. > > Signed-off-by: Jan Kiszka > --- > mm/kmemleak.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index

Re: [PATCH] kmemleak: Report if we need to tune KMEMLEAK_EARLY_LOG_SIZE

On Tue, Apr 24, 2018 at 05:51:15PM +0200, Jan Kiszka wrote: > ...rather than just mysteriously disabling it. > > Signed-off-by: Jan Kiszka > --- > mm/kmemleak.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index 9a085d525bbc..156c0c69cc5c 100644 >

Re: [BUG, PATCH] random: sleep in irq context

On Tue, Apr 24, 2018 at 10:40:36AM +0200, Sebastian Ott wrote: > On Mon, 23 Apr 2018, Sebastian Ott wrote: > > This happend once during boot and I could not reproduce this since, but I > > think the following patch should fix the issue: > > I can now recreate the issue reliably. The following

Re: [BUG, PATCH] random: sleep in irq context

On Tue, Apr 24, 2018 at 10:40:36AM +0200, Sebastian Ott wrote: > On Mon, 23 Apr 2018, Sebastian Ott wrote: > > This happend once during boot and I could not reproduce this since, but I > > think the following patch should fix the issue: > > I can now recreate the issue reliably. The following

Re: [PATCH v5 1/2] media: ov2680: dt: Add bindings for OV2680

Hi Rui, On Thu, Apr 19, 2018 at 8:00 AM, Rui Miguel Silva wrote: > Add device tree binding documentation for the OV2680 camera sensor. > > Reviewed-by: Rob Herring > CC: devicet...@vger.kernel.org > Signed-off-by: Rui Miguel Silva >

Re: [PATCH v5 1/2] media: ov2680: dt: Add bindings for OV2680

Hi Rui, On Thu, Apr 19, 2018 at 8:00 AM, Rui Miguel Silva wrote: > Add device tree binding documentation for the OV2680 camera sensor. > > Reviewed-by: Rob Herring > CC: devicet...@vger.kernel.org > Signed-off-by: Rui Miguel Silva > --- > .../devicetree/bindings/media/i2c/ov2680.txt | 40

RE: [PATCH 3/3] drm/amdgpu: Switch to interrupted wait to recover from ring hang.

Hi, It looks like there can be an infinite loop if neither of the if()'s become true. Is that an impossible condition? -Original Message- From: Andrey Grodzovsky Sent: Tuesday, April 24, 2018 11:31 AM To: linux-kernel@vger.kernel.org;

RE: [PATCH 3/3] drm/amdgpu: Switch to interrupted wait to recover from ring hang.

Hi, It looks like there can be an infinite loop if neither of the if()'s become true. Is that an impossible condition? -Original Message- From: Andrey Grodzovsky Sent: Tuesday, April 24, 2018 11:31 AM To: linux-kernel@vger.kernel.org; amd-...@lists.freedesktop.org Cc: Deucher,

Re: [PATCH v5 01/23] soc: qcom dt-bindings: Add APR bus bindings

On Wed, Apr 18, 2018 at 04:31:35PM +0100, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router) > bus driver. This bus is used for communicating with DSP which provides >

Re: [PATCH v5 01/23] soc: qcom dt-bindings: Add APR bus bindings

On Wed, Apr 18, 2018 at 04:31:35PM +0100, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router) > bus driver. This bus is used for communicating with DSP which provides > audio and various other services to

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24/2018 11:46 AM, Michel Dänzer wrote: Adding the dri-devel list, since this is driver independent code. Thanks, so many addresses that this one slipped out... On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: Avoid calling wait_event_killable when you are possibly being called from

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24/2018 11:46 AM, Michel Dänzer wrote: Adding the dri-devel list, since this is driver independent code. Thanks, so many addresses that this one slipped out... On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: Avoid calling wait_event_killable when you are possibly being called from

Re: [PATCH] Makefile: Fix typo s/HOST_LOADLIBES/HOST_LOADLIBS

2018-04-24 17:44 GMT+09:00 Sedat Dilek : > Signed-off-by: Sedat Dilek > --- > Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index 83b6c541565a..e1869dc08288 100644 > --- a/Makefile >

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24/2018 11:46 AM, Michel Dänzer wrote: Adding the dri-devel list, since this is driver independent code. Thanks, so many addresses that this one slipped out... On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: Avoid calling wait_event_killable when you are possibly being called from

Re: [PATCH] Makefile: Fix typo s/HOST_LOADLIBES/HOST_LOADLIBS

2018-04-24 17:44 GMT+09:00 Sedat Dilek : > Signed-off-by: Sedat Dilek > --- > Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index 83b6c541565a..e1869dc08288 100644 > --- a/Makefile > +++ b/Makefile > @@ -366,7 +366,7 @@ HOSTCFLAGS

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24/2018 11:46 AM, Michel Dänzer wrote: Adding the dri-devel list, since this is driver independent code. Thanks, so many addresses that this one slipped out... On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: Avoid calling wait_event_killable when you are possibly being called from

Re: [PATCH] video: fbdev: aty: radeon_pm: Replace mdelay with msleep in radeonfb_pci_suspend

On Tuesday, April 10, 2018 09:47:20 AM Jia-Ju Bai wrote: > radeonfb_pci_suspend() is never called in atomic context. > > radeonfb_pci_suspend() is only set as ".suspend" in struct pci_driver. > This function is not called in atomic context. > > Despite never getting called from atomic context,

Re: [PATCH] video: fbdev: aty: radeon_pm: Replace mdelay with msleep in radeonfb_pci_suspend

On Tuesday, April 10, 2018 09:47:20 AM Jia-Ju Bai wrote: > radeonfb_pci_suspend() is never called in atomic context. > > radeonfb_pci_suspend() is only set as ".suspend" in struct pci_driver. > This function is not called in atomic context. > > Despite never getting called from atomic context,

[PATCH] kmemleak: Report if we need to tune KMEMLEAK_EARLY_LOG_SIZE

...rather than just mysteriously disabling it. Signed-off-by: Jan Kiszka --- mm/kmemleak.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 9a085d525bbc..156c0c69cc5c 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -863,6 +863,7

[PATCH] kmemleak: Report if we need to tune KMEMLEAK_EARLY_LOG_SIZE

...rather than just mysteriously disabling it. Signed-off-by: Jan Kiszka --- mm/kmemleak.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 9a085d525bbc..156c0c69cc5c 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -863,6 +863,7 @@ static void __init

Re: [PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG

On Tue, 24 Apr 2018, Michal Hocko wrote: > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote: > [...] > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > > */ > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > +#ifdef CONFIG_DEBUG_SG > > + /* Catch bugs

Re: [PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG

On Tue, 24 Apr 2018, Michal Hocko wrote: > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote: > [...] > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > > */ > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > +#ifdef CONFIG_DEBUG_SG > > + /* Catch bugs

Re: [PATCH v3] selftests/livepatch: introduce tests

On 04/23/2018 10:43 AM, Joe Lawrence wrote: > On Fri, Apr 20, 2018 at 02:56:05PM +0200, Libor Pechacek wrote: >> On Thu 12-04-18 10:54:31, Joe Lawrence wrote: >>> + fi >>> + echo "$ret" > /dev/kmsg >>> +} >>> + >>> +# unload_mod(modname) - unload a kernel module >>> +# modname - module name

Re: [PATCH v3] selftests/livepatch: introduce tests

On 04/23/2018 10:43 AM, Joe Lawrence wrote: > On Fri, Apr 20, 2018 at 02:56:05PM +0200, Libor Pechacek wrote: >> On Thu 12-04-18 10:54:31, Joe Lawrence wrote: >>> + fi >>> + echo "$ret" > /dev/kmsg >>> +} >>> + >>> +# unload_mod(modname) - unload a kernel module >>> +# modname - module name

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: > On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote: > > Dear Linux folks, > > > > > > Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called > > from` messages. I believe, this setting should be

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: > On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote: > > Dear Linux folks, > > > > > > Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called > > from` messages. I believe, this setting should be

Re: [PATCH] video: fbdev: aty: aty128fb: Replace mdelay with msleep in aty128_set_suspend

On Tuesday, April 10, 2018 09:40:35 AM Jia-Ju Bai wrote: > aty128_set_suspend() is never called in atomic context. > > The call chains ending up at aty128_set_suspend() are: > [1] aty128_set_suspend() <- aty128_pci_suspend() > [2] aty128_set_suspend() <- aty128_do_resume() <- aty128_pci_resume()

Re: [PATCH] video: fbdev: aty: aty128fb: Replace mdelay with msleep in aty128_set_suspend

On Tuesday, April 10, 2018 09:40:35 AM Jia-Ju Bai wrote: > aty128_set_suspend() is never called in atomic context. > > The call chains ending up at aty128_set_suspend() are: > [1] aty128_set_suspend() <- aty128_pci_suspend() > [2] aty128_set_suspend() <- aty128_do_resume() <- aty128_pci_resume()

Re: [PATCH] sched/fair: Rearrange select_task_rq_fair() to optimize it

On Tue, Apr 24, 2018 at 8:46 AM, Joel Fernandes wrote: > On Tue, Apr 24, 2018 at 5:35 AM, Peter Zijlstra wrote: >> On Tue, Apr 24, 2018 at 12:19:07PM +0100, Valentin Schneider wrote: >>> On 24/04/18 11:43, Peter Zijlstra wrote: >>> > On Tue, Apr 24,

Re: [PATCH] sched/fair: Rearrange select_task_rq_fair() to optimize it

On Tue, Apr 24, 2018 at 8:46 AM, Joel Fernandes wrote: > On Tue, Apr 24, 2018 at 5:35 AM, Peter Zijlstra wrote: >> On Tue, Apr 24, 2018 at 12:19:07PM +0100, Valentin Schneider wrote: >>> On 24/04/18 11:43, Peter Zijlstra wrote: >>> > On Tue, Apr 24, 2018 at 11:02:26AM +0100, Valentin Schneider

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 5:22 PM, Linus Torvalds wrote: > On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote: >> >> $ objdump -S clang-eflag.o >> >> Does this now look good? > > Looks fine to me. The instruction choice is still pretty odd: > >

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Adding the dri-devel list, since this is driver independent code. On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: > Avoid calling wait_event_killable when you are possibly being called > from get_signal routine since in that case you end up in a deadlock > where you are alreay blocked in

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 5:22 PM, Linus Torvalds wrote: > On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote: >> >> $ objdump -S clang-eflag.o >> >> Does this now look good? > > Looks fine to me. The instruction choice is still pretty odd: > > 1a: f6 c3 fftest $0xff,%bl >

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Adding the dri-devel list, since this is driver independent code. On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: > Avoid calling wait_event_killable when you are possibly being called > from get_signal routine since in that case you end up in a deadlock > where you are alreay blocked in

Re: [PATCH] sched/fair: Rearrange select_task_rq_fair() to optimize it

On Tue, Apr 24, 2018 at 5:35 AM, Peter Zijlstra wrote: > On Tue, Apr 24, 2018 at 12:19:07PM +0100, Valentin Schneider wrote: >> On 24/04/18 11:43, Peter Zijlstra wrote: >> > On Tue, Apr 24, 2018 at 11:02:26AM +0100, Valentin Schneider wrote: >> >> I'd argue making things

Re: [PATCH] sched/fair: Rearrange select_task_rq_fair() to optimize it

On Tue, Apr 24, 2018 at 5:35 AM, Peter Zijlstra wrote: > On Tue, Apr 24, 2018 at 12:19:07PM +0100, Valentin Schneider wrote: >> On 24/04/18 11:43, Peter Zijlstra wrote: >> > On Tue, Apr 24, 2018 at 11:02:26AM +0100, Valentin Schneider wrote: >> >> I'd argue making things easier to read is a

Re: [PATCH] arm64: dts: uniphier: fix input delay value for legacy mode of eMMC

2018-04-12 13:45 GMT+09:00 Masahiro Yamada : > 2018-04-12 11:31 GMT+09:00 Masahiro Yamada : >> The property of the legacy mode for the eMMC PHY turned out to >> be worng. Some eMMC devices are unstable due to the set-up/hold >> timing

Re: [PATCH] arm64: dts: uniphier: fix input delay value for legacy mode of eMMC

2018-04-12 13:45 GMT+09:00 Masahiro Yamada : > 2018-04-12 11:31 GMT+09:00 Masahiro Yamada : >> The property of the legacy mode for the eMMC PHY turned out to >> be worng. Some eMMC devices are unstable due to the set-up/hold >> timing violation. Correct the delay value. > > Reminder for myself:

Re: [PATCH v1 2/4] dt-bindings: clock: mediatek: add g3dsys bindings

On Tue, 2018-04-24 at 09:39 -0500, Rob Herring wrote: > On Wed, Apr 18, 2018 at 06:24:54PM +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Add bindings to g3dsys providing necessary clock and reset control to > > Mali-450. > > > > Signed-off-by: Sean

Re: [PATCH v1 2/4] dt-bindings: clock: mediatek: add g3dsys bindings

On Tue, 2018-04-24 at 09:39 -0500, Rob Herring wrote: > On Wed, Apr 18, 2018 at 06:24:54PM +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Add bindings to g3dsys providing necessary clock and reset control to > > Mali-450. > > > > Signed-off-by: Sean Wang > > --- > >

Re: [PATCH v3 1/5] clk: Extract OF clock helpers in

On Fri, Apr 20, 2018 at 08:28:28AM +0200, Geert Uytterhoeven wrote: > Hi Stephen, Rob, > > On Fri, Apr 20, 2018 at 12:25 AM, Stephen Boyd wrote: > > Quoting Geert Uytterhoeven (2018-04-18 07:50:01) > >> The use of of_clk_get_parent_{count,name}() and of_clk_init() is not > >>

Re: [PATCH v3 1/5] clk: Extract OF clock helpers in

On Fri, Apr 20, 2018 at 08:28:28AM +0200, Geert Uytterhoeven wrote: > Hi Stephen, Rob, > > On Fri, Apr 20, 2018 at 12:25 AM, Stephen Boyd wrote: > > Quoting Geert Uytterhoeven (2018-04-18 07:50:01) > >> The use of of_clk_get_parent_{count,name}() and of_clk_init() is not > >> limited to clock

Proof-of-concept: better(?) page-table manipulation API

Hi everybody, I've proposed to talk about page able manipulation API on the LSF/MM'2018, so I need something material to talk about. Below is how better (arguably) API may look like as implemented for x86-64 (both paging modes). It's very incomplete (notably no PTI and paravirt support), not

Proof-of-concept: better(?) page-table manipulation API

Hi everybody, I've proposed to talk about page able manipulation API on the LSF/MM'2018, so I need something material to talk about. Below is how better (arguably) API may look like as implemented for x86-64 (both paging modes). It's very incomplete (notably no PTI and paravirt support), not

Re: [PATCH v1 3/4] clk: mediatek: add g3dsys support for MT2701 and MT7623

On Tue, 2018-04-24 at 09:40 -0500, Rob Herring wrote: > On Wed, Apr 18, 2018 at 06:24:55PM +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Add clock driver support for g3dsys on MT2701 and MT7623, which is > > providing essential clock gate and reset

Re: [PATCH v1 3/4] clk: mediatek: add g3dsys support for MT2701 and MT7623

On Tue, 2018-04-24 at 09:40 -0500, Rob Herring wrote: > On Wed, Apr 18, 2018 at 06:24:55PM +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Add clock driver support for g3dsys on MT2701 and MT7623, which is > > providing essential clock gate and reset controller to Mali-450. > >

Re: [PATCH] video: fbdev: savage: Replace mdelay with usleep_range in savage_init_hw

On Tuesday, April 10, 2018 09:05:59 AM Jia-Ju Bai wrote: > savage_init_hw() is never called in atomic context. > > The call chains ending up at savage_init_hw() are: > [1] savage_init_hw() <- savagefb_probe() > [2] savage_init_hw() <- savagefb_resume() > > savagefb_probe() is only set as

Re: [PATCH] video: fbdev: savage: Replace mdelay with usleep_range in savage_init_hw

On Tuesday, April 10, 2018 09:05:59 AM Jia-Ju Bai wrote: > savage_init_hw() is never called in atomic context. > > The call chains ending up at savage_init_hw() are: > [1] savage_init_hw() <- savagefb_probe() > [2] savage_init_hw() <- savagefb_resume() > > savagefb_probe() is only set as

[RFC PATCH] procfs: proc_pid_files_link_dentry_operations can be static

Fixes: fc3babee0341 ("procfs: share fd/fdinfo with thread group leader when files are shared") Signed-off-by: Fengguang Wu --- base.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index 98a847b..deb0950 100644 ---

[RFC PATCH] procfs: proc_pid_files_link_dentry_operations can be static

Fixes: fc3babee0341 ("procfs: share fd/fdinfo with thread group leader when files are shared") Signed-off-by: Fengguang Wu --- base.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index 98a847b..deb0950 100644 --- a/fs/proc/base.c +++

Re: [PATCH 5/5] procfs: share fd/fdinfo with thread group leader when files are shared

Hi Jeff, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17-rc2 next-20180424] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH 5/5] procfs: share fd/fdinfo with thread group leader when files are shared

Hi Jeff, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17-rc2 next-20180424] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[PATCH 1/6] PCI: Make pci_get_new_domain_nr static

From: Jan Kiszka The only user of that function is of_pci_bus_find_domain_nr. Pure cleanup. Signed-off-by: Jan Kiszka --- drivers/pci/pci.c | 6 ++ include/linux/pci.h | 3 --- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git

[PATCH 1/6] PCI: Make pci_get_new_domain_nr static

From: Jan Kiszka The only user of that function is of_pci_bus_find_domain_nr. Pure cleanup. Signed-off-by: Jan Kiszka --- drivers/pci/pci.c | 6 ++ include/linux/pci.h | 3 --- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index

Re: [PATCH] arm64: export tishift functions to modules

On Tue, Apr 24, 2018 at 03:43:04PM +0200, Jason A. Donenfeld wrote: > On Tue, Apr 24, 2018 at 3:34 PM, Will Deacon wrote: > > I've not run into any build issues here -- is this specifically with some > > out-of-tree module? > > I received a bug report email about this. I'm

Re: [PATCH] arm64: export tishift functions to modules

On Tue, Apr 24, 2018 at 03:43:04PM +0200, Jason A. Donenfeld wrote: > On Tue, Apr 24, 2018 at 3:34 PM, Will Deacon wrote: > > I've not run into any build issues here -- is this specifically with some > > out-of-tree module? > > I received a bug report email about this. I'm not sure which

Re: [PATCH v3 2/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Quoting Taniya Das (2018-04-23 09:50:22) > On 4/16/2018 11:08 PM, Stephen Boyd wrote: > > Quoting Taniya Das (2018-04-13 19:36:41) > > >> +struct clk_rpmh { > >> + struct clk_hw hw; > >> + const char *res_name; > >> + u32 res_addr; > >> + u32 res_en_offset; > > > > Why do

Re: [PATCH v3 2/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Quoting Taniya Das (2018-04-23 09:50:22) > On 4/16/2018 11:08 PM, Stephen Boyd wrote: > > Quoting Taniya Das (2018-04-13 19:36:41) > > >> +struct clk_rpmh { > >> + struct clk_hw hw; > >> + const char *res_name; > >> + u32 res_addr; > >> + u32 res_en_offset; > > > > Why do

[PATCH v2] arm64/kernel: rename module_emit_adrp_veneer->module_emit_veneer_for_adrp

Commit a257e02579e ("arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum #843419") introduced a function whose name ends with "_veneer". This clashes with commit bd8b22d2888e ("Kbuild: kallsyms: ignore veneers emitted by the ARM linker"), which removes symbols ending in "_veneer" from

[PATCH v2] arm64/kernel: rename module_emit_adrp_veneer->module_emit_veneer_for_adrp

Commit a257e02579e ("arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum #843419") introduced a function whose name ends with "_veneer". This clashes with commit bd8b22d2888e ("Kbuild: kallsyms: ignore veneers emitted by the ARM linker"), which removes symbols ending in "_veneer" from

Re: [v2 resend 03/10] mfd: mtk-mmsys: Add mmsys driver

On 04/24/2018 02:47 AM, matthias@kernel.org wrote: > From: Matthias Brugger > > The MMSYS subsystem includes clocks and drm components. > This patch adds a MFD device to probe both drivers from the same > device tree compatible. > > Signed-off-by: Matthias Brugger

Re: [v2 resend 03/10] mfd: mtk-mmsys: Add mmsys driver

On 04/24/2018 02:47 AM, matthias@kernel.org wrote: > From: Matthias Brugger > > The MMSYS subsystem includes clocks and drm components. > This patch adds a MFD device to probe both drivers from the same > device tree compatible. > > Signed-off-by: Matthias Brugger > --- >

[PATCH 4/6] PCI: Convert of_pci_get_host_bridge_resources users to devm variant

From: Jan Kiszka Straightforward for all of them, no more leaks afterwards. CC: Jingoo Han CC: Joao Pinto CC: Lorenzo Pieralisi Signed-off-by: Jan Kiszka ---

[PATCH 4/6] PCI: Convert of_pci_get_host_bridge_resources users to devm variant

From: Jan Kiszka Straightforward for all of them, no more leaks afterwards. CC: Jingoo Han CC: Joao Pinto CC: Lorenzo Pieralisi Signed-off-by: Jan Kiszka --- drivers/pci/dwc/pcie-designware-host.c | 2 +- drivers/pci/host/pci-aardvark.c| 5 ++--- drivers/pci/host/pci-ftpci100.c

Re: [RFC 00/13] arm64: allwinner: Add A64 DE2 pipeline support

Hi, Dne torek, 24. april 2018 ob 15:34:12 CEST je Jagan Teki napisal(a): > Allwinner A64 has display engine pipeline like other Allwinner SOC's > A83T/H3/H5. > > A64 DE2 behaviour similar to Allwinner A83T where mixer0, connected to tcon0 > with RGB, LVDS MIPI-DSI and mixer1, connected to tcon1

Re: [RFC 00/13] arm64: allwinner: Add A64 DE2 pipeline support

Hi, Dne torek, 24. april 2018 ob 15:34:12 CEST je Jagan Teki napisal(a): > Allwinner A64 has display engine pipeline like other Allwinner SOC's > A83T/H3/H5. > > A64 DE2 behaviour similar to Allwinner A83T where mixer0, connected to tcon0 > with RGB, LVDS MIPI-DSI and mixer1, connected to tcon1

[PATCH 3/3] drm/amdgpu: Switch to interrupted wait to recover from ring hang.

If the ring is hanging for some reason allow to recover the waiting by sending fatal signal. Originally-by: David Panariti Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 14 ++ 1 file changed, 10

[REVIEW][PATCH 23/22] signal/riscv: Replace do_trap_siginfo with force_sig_fault

The function force_sig_fault is just the generic version of do_trap_siginfo with a (void __user *) instead of an unsigned long parameter for the address. So just use force_sig_fault to simplify the code. Cc: Palmer Dabbelt Cc: Albert Ou Cc:

[PATCH 3/3] drm/amdgpu: Switch to interrupted wait to recover from ring hang.

If the ring is hanging for some reason allow to recover the waiting by sending fatal signal. Originally-by: David Panariti Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git

[REVIEW][PATCH 23/22] signal/riscv: Replace do_trap_siginfo with force_sig_fault

The function force_sig_fault is just the generic version of do_trap_siginfo with a (void __user *) instead of an unsigned long parameter for the address. So just use force_sig_fault to simplify the code. Cc: Palmer Dabbelt Cc: Albert Ou Cc: linux-ri...@lists.infradead.org Suggested-by:

[PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Avoid calling wait_event_killable when you are possibly being called from get_signal routine since in that case you end up in a deadlock where you are alreay blocked in singla processing any trying to wait on a new signal. Signed-off-by: Andrey Grodzovsky ---

[PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Avoid calling wait_event_killable when you are possibly being called from get_signal routine since in that case you end up in a deadlock where you are alreay blocked in singla processing any trying to wait on a new signal. Signed-off-by: Andrey Grodzovsky ---

[PATCH 1/3] signals: Allow generation of SIGKILL to exiting task.

Currently calling wait_event_killable as part of exiting process will stall forever since SIGKILL generation is suppresed by PF_EXITING. In our partilaur case AMDGPU driver wants to flush all GPU jobs in flight before shutting down. But if some job hangs the pipe we still want to be able to kill

[PATCH 1/3] signals: Allow generation of SIGKILL to exiting task.

Currently calling wait_event_killable as part of exiting process will stall forever since SIGKILL generation is suppresed by PF_EXITING. In our partilaur case AMDGPU driver wants to flush all GPU jobs in flight before shutting down. But if some job hangs the pipe we still want to be able to kill

Avoid uninterruptible sleep during process exit

Following 3 patches address an issue we encounter in AMDGPU driver. When GPU pipe is stalling for some reason (shader code error, incorrectly programmed registers e.t.c...) uninterruptible wait in kernel puts the user process in unresponsive state which only can be remedied by system's hard

Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM

On Tue, 24 Apr 2018, Michal Hocko wrote: > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > Fixing __vmalloc code > > is easy and it doesn't require cooperation with maintainers. > > But it is a hack against the intention of the scope api. It is not! You can fix __vmalloc now and you

Avoid uninterruptible sleep during process exit

Following 3 patches address an issue we encounter in AMDGPU driver. When GPU pipe is stalling for some reason (shader code error, incorrectly programmed registers e.t.c...) uninterruptible wait in kernel puts the user process in unresponsive state which only can be remedied by system's hard

Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM

On Tue, 24 Apr 2018, Michal Hocko wrote: > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > Fixing __vmalloc code > > is easy and it doesn't require cooperation with maintainers. > > But it is a hack against the intention of the scope api. It is not! You can fix __vmalloc now and you

[PATCH 6/6] arm: Allow to enable PCI_DOMAINS manually

From: Jan Kiszka Required when running over Jailhouse, and there is already a physical host controller that Jailhouse does not intercept and rather adds a virtual one. That is the case for the Tegra TK1, e.g. Signed-off-by: Jan Kiszka ---

[PATCH 6/6] arm: Allow to enable PCI_DOMAINS manually

From: Jan Kiszka Required when running over Jailhouse, and there is already a physical host controller that Jailhouse does not intercept and rather adds a virtual one. That is the case for the Tegra TK1, e.g. Signed-off-by: Jan Kiszka --- arch/arm/Kconfig | 7 ++- 1 file changed, 6

<    7   8   9   10   11   12   13   14   15   16   >