Re: [RESEND PATCH] drm/hisilicon: Ensure LDI regs are properly configured.

On Thu, Jun 29, 2017 at 09:54:38PM +0100, Peter Griffin wrote: > This patch fixes the following soft lockup: > BUG: soft lockup - CPU#0 stuck for 23s! [weston:307] > > On weston idle-timeout the IP is powered down and reset > asserted. On weston resume we get a massive vblank > IRQ storm due to

Re: [RESEND PATCH] drm/hisilicon: Ensure LDI regs are properly configured.

On Thu, Jun 29, 2017 at 09:54:38PM +0100, Peter Griffin wrote: > This patch fixes the following soft lockup: > BUG: soft lockup - CPU#0 stuck for 23s! [weston:307] > > On weston idle-timeout the IP is powered down and reset > asserted. On weston resume we get a massive vblank > IRQ storm due to

Re: [PATCH] staging: ks7010: fix styling WARNINGs

On Fri, Jun 30, 2017 at 6:52 AM, Mark Rogers wrote: > Trivial style changes. There are still 3 "line over 80 characters" > checkpatch.pl warnings, but I think they are best left alone as > breaking the first two warning lines could hurt readability. The third > warning is a

Re: [PATCH] staging: ks7010: fix styling WARNINGs

On Fri, Jun 30, 2017 at 6:52 AM, Mark Rogers wrote: > Trivial style changes. There are still 3 "line over 80 characters" > checkpatch.pl warnings, but I think they are best left alone as > breaking the first two warning lines could hurt readability. The third > warning is a message that should

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

* Aaro Koskinen [170629 11:50]: > Is it just me or do other OMAP users fail to see omapdrm changes being > posted to linux-omap for testing or review purposes? Yeah Cc:ing linux-omap in addition to the drm list is a good idea. Hopefully we get few more people to review

Re: [PATCH 1/1] selftests: gpio: use pkg-config to determine libmount CFLAGS/LDLIBS

On 30 June 2017 at 05:20, Bamvor Zhang Jian wrote: > On 29 June 2017 at 19:39, Fathi Boudra wrote: >> On 29 June 2017 at 12:01, Michael Ellerman wrote: >>> Fathi Boudra writes: >>> Fix

Re: [PATCH] ib_isert: prevent NULL pointer dereference in isert_login_recv_done()

On Thu, 2017-06-29 at 11:28 +0300, Sagi Grimberg wrote: > >> Can you test just the one liner fix below? > >> > @@ -1452,7 +1452,7 @@ > isert_login_recv_done(struct ib_cq *cq, struct ib_wc *wc) > { > struct isert_conn *isert_conn = wc->qp->qp_context; > -

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

* Aaro Koskinen [170629 11:50]: > Is it just me or do other OMAP users fail to see omapdrm changes being > posted to linux-omap for testing or review purposes? Yeah Cc:ing linux-omap in addition to the drm list is a good idea. Hopefully we get few more people to review changes that way. What

Re: [PATCH 1/1] selftests: gpio: use pkg-config to determine libmount CFLAGS/LDLIBS

On 30 June 2017 at 05:20, Bamvor Zhang Jian wrote: > On 29 June 2017 at 19:39, Fathi Boudra wrote: >> On 29 June 2017 at 12:01, Michael Ellerman wrote: >>> Fathi Boudra writes: >>> Fix hardcoded and misplaced libmount headers. Use pkg-config instead to figure out CFLAGS/LDLIBS,

Re: [PATCH] ib_isert: prevent NULL pointer dereference in isert_login_recv_done()

On Thu, 2017-06-29 at 11:28 +0300, Sagi Grimberg wrote: > >> Can you test just the one liner fix below? > >> > @@ -1452,7 +1452,7 @@ > isert_login_recv_done(struct ib_cq *cq, struct ib_wc *wc) > { > struct isert_conn *isert_conn = wc->qp->qp_context; > -

Re: [PATCH] clocksource: em_sti: fix error return codes in em_sti_probe()

Hi Frans, Quoting Frans Klaver : On Fri, Jun 30, 2017 at 6:42 AM, Gustavo A. R. Silva wrote: Propagate the return values of platform_get_irq and devm_request_irq on failure. Signed-off-by: Gustavo A. R. Silva ---

Re: [PATCH] clocksource: em_sti: fix error return codes in em_sti_probe()

Hi Frans, Quoting Frans Klaver : On Fri, Jun 30, 2017 at 6:42 AM, Gustavo A. R. Silva wrote: Propagate the return values of platform_get_irq and devm_request_irq on failure. Signed-off-by: Gustavo A. R. Silva --- drivers/clocksource/em_sti.c | 9 + 1 file changed, 5 insertions(+),

[PATCH v4] staging: lustre: lnet: remove dead code and crc32_le() wrapper

After removing code which was permanently disabled with ifdefs, the function ksocknal_csum() becomes just a wrapper for crc32_le(). Remove this useless wrapper and instead call crc32_le() directly. This also resolves the following checkpatch warning which was triggered by the dead code: WARNING:

[PATCH v4] staging: lustre: lnet: remove dead code and crc32_le() wrapper

After removing code which was permanently disabled with ifdefs, the function ksocknal_csum() becomes just a wrapper for crc32_le(). Remove this useless wrapper and instead call crc32_le() directly. This also resolves the following checkpatch warning which was triggered by the dead code: WARNING:

Re: [RFC PATCH v3] acpi: indicate to platform when hot remove returns busy

Hi Rafael, On Thu, Jun 29, 2017 at 12:13:18AM +0200, Rafael J. Wysocki wrote: > On Wednesday, June 21, 2017 03:45:44 PM Lee, Chun-Yi wrote: > > In hotplug logic, it always indicates non-specific failure to > > platform through _OST when handing acpi hot-remove event failed. Then > > platform

Re: [RFC PATCH v3] acpi: indicate to platform when hot remove returns busy

Hi Rafael, On Thu, Jun 29, 2017 at 12:13:18AM +0200, Rafael J. Wysocki wrote: > On Wednesday, June 21, 2017 03:45:44 PM Lee, Chun-Yi wrote: > > In hotplug logic, it always indicates non-specific failure to > > platform through _OST when handing acpi hot-remove event failed. Then > > platform

[PATCH for-4.4 08/16] MIPS: ralink: fix MT7628 pinmux typos

From: Álvaro Fernández Rojas commit d7146829c9da24e285cb1b1f2156b5b3e2d40c07 upstream. Signed-off-by: Álvaro Fernández Rojas Cc: j...@phrozen.org Cc: linux-m...@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork:

[PATCH for-4.4 08/16] MIPS: ralink: fix MT7628 pinmux typos

From: Álvaro Fernández Rojas commit d7146829c9da24e285cb1b1f2156b5b3e2d40c07 upstream. Signed-off-by: Álvaro Fernández Rojas Cc: j...@phrozen.org Cc: linux-m...@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13306/ Signed-off-by: Ralf Baechle

[PATCH] sata_rcar: fix error return code in sata_rcar_probe()

Print error message and propagate the return value of platform_get_irq on failure. Signed-off-by: Gustavo A. R. Silva --- drivers/ata/sata_rcar.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/ata/sata_rcar.c b/drivers/ata/sata_rcar.c

[PATCH] sata_rcar: fix error return code in sata_rcar_probe()

Print error message and propagate the return value of platform_get_irq on failure. Signed-off-by: Gustavo A. R. Silva --- drivers/ata/sata_rcar.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/ata/sata_rcar.c b/drivers/ata/sata_rcar.c index ee98447..c936b2a

[PATCH for-4.4 09/16] MIPS: ralink: fix MT7628 wled_an pinmux gpio

From: Álvaro Fernández Rojas commit 07b50db6e685172a41b9978aebffb2438166d9b6 upstream. Signed-off-by: Álvaro Fernández Rojas Cc: j...@phrozen.org Cc: linux-m...@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork:

[PATCH for-4.4 09/16] MIPS: ralink: fix MT7628 wled_an pinmux gpio

From: Álvaro Fernández Rojas commit 07b50db6e685172a41b9978aebffb2438166d9b6 upstream. Signed-off-by: Álvaro Fernández Rojas Cc: j...@phrozen.org Cc: linux-m...@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13307/ Signed-off-by: Ralf Baechle

Re: [PATCH] clocksource: em_sti: fix error return codes in em_sti_probe()

On Fri, Jun 30, 2017 at 6:42 AM, Gustavo A. R. Silva wrote: > Propagate the return values of platform_get_irq and > devm_request_irq on failure. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/clocksource/em_sti.c | 9 + > 1 file

Re: [PATCH] clocksource: em_sti: fix error return codes in em_sti_probe()

On Fri, Jun 30, 2017 at 6:42 AM, Gustavo A. R. Silva wrote: > Propagate the return values of platform_get_irq and > devm_request_irq on failure. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/clocksource/em_sti.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

On Thu, Jun 29, 2017 at 10:05 PM, Andy Lutomirski wrote: > Hmm. There's another option that might be considerably nicer, though: > put the IRQ stack at a known (at link time) position *in percpu > space*. (Presumably it already is -- I haven't checked.) Then we do: > > .macro

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

On Thu, Jun 29, 2017 at 10:05 PM, Andy Lutomirski wrote: > Hmm. There's another option that might be considerably nicer, though: > put the IRQ stack at a known (at link time) position *in percpu > space*. (Presumably it already is -- I haven't checked.) Then we do: > > .macro ENTER_IRQ_STACK

Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

On 30-06-17, 06:53, Dominik Brodowski wrote: > On Fri, Jun 30, 2017 at 09:04:25AM +0530, Viresh Kumar wrote: > > On 29-06-17, 20:01, Dominik Brodowski wrote: > > > On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote: > > > > The cpufreq core and governors aren't supposed to set a limit on

Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

On 30-06-17, 06:53, Dominik Brodowski wrote: > On Fri, Jun 30, 2017 at 09:04:25AM +0530, Viresh Kumar wrote: > > On 29-06-17, 20:01, Dominik Brodowski wrote: > > > On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote: > > > > The cpufreq core and governors aren't supposed to set a limit on

Re: [PATCH 00/15] HMM (Heterogeneous Memory Management) v24

On 06/28/2017 11:00 AM, Jérôme Glisse wrote: > > Patchset is on top of git://git.cmpxchg.org/linux-mmotm.git so i > test same kernel as kbuild system, git branch: > > https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-v24 > > Change since v23 is code comment fixes, simplify kernel

Re: [PATCH 00/15] HMM (Heterogeneous Memory Management) v24

On 06/28/2017 11:00 AM, Jérôme Glisse wrote: > > Patchset is on top of git://git.cmpxchg.org/linux-mmotm.git so i > test same kernel as kbuild system, git branch: > > https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-v24 > > Change since v23 is code comment fixes, simplify kernel

[PATCH] fs: GFS2: constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. File size before: textdata bss dec hex filename 52591344 8661119d3

[PATCH] fs: GFS2: constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. File size before: textdata bss dec hex filename 52591344 8661119d3

[PATCH] pata_imx: print error message on platform_get_irq failure

Print error message on platform_get_irq failure before return. Signed-off-by: Gustavo A. R. Silva --- drivers/ata/pata_imx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c index d4caa23..65bbf36

[PATCH] pata_imx: print error message on platform_get_irq failure

Print error message on platform_get_irq failure before return. Signed-off-by: Gustavo A. R. Silva --- drivers/ata/pata_imx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c index d4caa23..65bbf36 100644 ---

Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Fri, 2017-06-30 at 00:45 +1000, Nicholas Piggin wrote: > On Thu, 29 Jun 2017 20:23:05 +1000 > Nicholas Piggin wrote: > > > On Thu, 29 Jun 2017 19:36:14 +1000 > > Nicholas Piggin wrote: > > > > I don't *think* the replay-wakeup-interrupt patch is

Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Fri, 2017-06-30 at 00:45 +1000, Nicholas Piggin wrote: > On Thu, 29 Jun 2017 20:23:05 +1000 > Nicholas Piggin wrote: > > > On Thu, 29 Jun 2017 19:36:14 +1000 > > Nicholas Piggin wrote: > > > > I don't *think* the replay-wakeup-interrupt patch is directly involved, > > > but > > > it's

Re: [PATCH] powerpc: dts: use #include "..." to include local DT

Hi Michael, Ping. Please apply this patch. I need this to clean up Makefiles in the next development cycle. 2017-06-21 18:52 GMT+09:00 Masahiro Yamada : > 2017-06-21 18:48 GMT+09:00 Michael Ellerman : >> Masahiro Yamada

Re: [PATCH] powerpc: dts: use #include "..." to include local DT

Hi Michael, Ping. Please apply this patch. I need this to clean up Makefiles in the next development cycle. 2017-06-21 18:52 GMT+09:00 Masahiro Yamada : > 2017-06-21 18:48 GMT+09:00 Michael Ellerman : >> Masahiro Yamada writes: >>> 2017-06-14 15:45 GMT+09:00 Michael Ellerman :

Re: [RFC] tracing: Add support for critical section event tracing

Hi Steven, Did you have any comments about this patch? It was sent a while ago and if you can provide me your initial thoughts on it, I would appreciate it. (Sorry to ping you about it during the busy merge window time, but I was thinking if I can get any initial early comments from you then I

Re: [RFC] tracing: Add support for critical section event tracing

Hi Steven, Did you have any comments about this patch? It was sent a while ago and if you can provide me your initial thoughts on it, I would appreciate it. (Sorry to ping you about it during the busy merge window time, but I was thinking if I can get any initial early comments from you then I

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Thu, Jun 29, 2017 at 09:02:41PM -0700, Paul E. McKenney wrote: [...] > > > o net/netfilter/nf_conntrack_core.c nf_conntrack_lock() > > > This instance of spin_unlock_wait() interacts with > > > nf_conntrack_all_lock()'s instance of spin_unlock_wait(). > > > Although

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Thu, Jun 29, 2017 at 09:02:41PM -0700, Paul E. McKenney wrote: [...] > > > o net/netfilter/nf_conntrack_core.c nf_conntrack_lock() > > > This instance of spin_unlock_wait() interacts with > > > nf_conntrack_all_lock()'s instance of spin_unlock_wait(). > > > Although

Re: [RFC 0/5] drivers: Add boot constraints core

On 30-06-17, 12:22, Chen-Yu Tsai wrote: > On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar > wrote: > > On 30-06-17, 12:05, Chen-Yu Tsai wrote: > >> I also want to mention that for DT based platforms, this constraint > >> should already be set in the device tree for the

Re: [RFC 0/5] drivers: Add boot constraints core

On 30-06-17, 12:22, Chen-Yu Tsai wrote: > On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar > wrote: > > On 30-06-17, 12:05, Chen-Yu Tsai wrote: > >> I also want to mention that for DT based platforms, this constraint > >> should already be set in the device tree for the regulator, so the > >>

Re: linux-next: build warning after merge of the drivers-x86 tree

Hi, I have push one more patch which does not have this warning. please avoid my first patch. Thanks ~ arvind On Friday 30 June 2017 09:30 AM, Stephen Rothwell wrote: Hi Darren, After merging the drivers-x86 tree, today's linux-next build (x86_64 allmodconfig) produced this warning:

Re: linux-next: build warning after merge of the drivers-x86 tree

Hi, I have push one more patch which does not have this warning. please avoid my first patch. Thanks ~ arvind On Friday 30 June 2017 09:30 AM, Stephen Rothwell wrote: Hi Darren, After merging the drivers-x86 tree, today's linux-next build (x86_64 allmodconfig) produced this warning:

Re: linux-next: manual merge of the target-updates tree with the scsi-mkp tree

Hi all, With the merge window approaching, this is just a reminder that the following conflict still exists. No action is necessarily needed except to maybe mention this to Linus at the appropriate time. James, you have been added since you merged the scsi-mkp tree int the scsi tree. On Tue,

Re: linux-next: manual merge of the target-updates tree with the scsi-mkp tree

Hi all, With the merge window approaching, this is just a reminder that the following conflict still exists. No action is necessarily needed except to maybe mention this to Linus at the appropriate time. James, you have been added since you merged the scsi-mkp tree int the scsi tree. On Tue,

[PATCH v2] sony-laptop: constify spic_attribute_group and sony_laptop_input_index.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. File size before: textdata bss dec hex filename 312735176 372 368218fd5

[PATCH v2] sony-laptop: constify spic_attribute_group and sony_laptop_input_index.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. File size before: textdata bss dec hex filename 312735176 372 368218fd5

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

On Thu, Jun 29, 2017 at 7:12 PM, Josh Poimboeuf wrote: > On Thu, Jun 29, 2017 at 03:59:04PM -0700, Andy Lutomirski wrote: >> > >> > Sorry, I didn't explain it very well. Undwarf can find the regs pointer >> > in rdi, it just doesn't trust its value. >> > >> > See the

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

On Thu, Jun 29, 2017 at 7:12 PM, Josh Poimboeuf wrote: > On Thu, Jun 29, 2017 at 03:59:04PM -0700, Andy Lutomirski wrote: >> > >> > Sorry, I didn't explain it very well. Undwarf can find the regs pointer >> > in rdi, it just doesn't trust its value. >> > >> > See the stack_info.next_sp field,

Re: [PATCH v2 2/2] thermal: core: Allow to disable polling when disabling thermal zone.

On Thu, 2017-06-29 at 18:50 +0200, Enric Balletbo i Serra wrote: > Under each thermal zone there is a optional file called "mode". > Writing > enabled or disabled to this file allows a given thermal zone to be > enabled > or disabled, but in current code, the monitoring queue doesn't stops. > Add

Re: [PATCH v2 2/2] thermal: core: Allow to disable polling when disabling thermal zone.

On Thu, 2017-06-29 at 18:50 +0200, Enric Balletbo i Serra wrote: > Under each thermal zone there is a optional file called "mode". > Writing > enabled or disabled to this file allows a given thermal zone to be > enabled > or disabled, but in current code, the monitoring queue doesn't stops. > Add

[PATCH] sata_highbank: fix error return code in ahci_highbank_probe()

Propagate the return value of platform_get_irq on failure. Signed-off-by: Gustavo A. R. Silva --- drivers/ata/sata_highbank.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ata/sata_highbank.c b/drivers/ata/sata_highbank.c index

[PATCH] sata_highbank: fix error return code in ahci_highbank_probe()

Propagate the return value of platform_get_irq on failure. Signed-off-by: Gustavo A. R. Silva --- drivers/ata/sata_highbank.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ata/sata_highbank.c b/drivers/ata/sata_highbank.c index aafb8cc..2fc451c 100644 ---

[PATCH] staging: ks7010: fix styling WARNINGs

Trivial style changes. There are still 3 "line over 80 characters" checkpatch.pl warnings, but I think they are best left alone as breaking the first two warning lines could hurt readability. The third warning is a message that should not be broken for the sake of grep. All but one of the changes

[PATCH] staging: ks7010: fix styling WARNINGs

Trivial style changes. There are still 3 "line over 80 characters" checkpatch.pl warnings, but I think they are best left alone as breaking the first two warning lines could hurt readability. The third warning is a message that should not be broken for the sake of grep. All but one of the changes

Re: linux-next: build warning after merge of the pinctrl tree

Hi all, [Just adding cc's] On Fri, 30 Jun 2017 14:56:01 +1000 Stephen Rothwell wrote: > > After merging the pinctrl tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/pinctrl/pinctrl-rza1.c: In function 'rza1_pinctrl_probe': >

Re: linux-next: build warning after merge of the pinctrl tree

Hi all, [Just adding cc's] On Fri, 30 Jun 2017 14:56:01 +1000 Stephen Rothwell wrote: > > After merging the pinctrl tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/pinctrl/pinctrl-rza1.c: In function 'rza1_pinctrl_probe': >

linux-next: build warning after merge of the pinctrl tree

Hi Linus, After merging the pinctrl tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/pinctrl/pinctrl-rza1.c: In function 'rza1_pinctrl_probe': drivers/pinctrl/pinctrl-rza1.c:1260:5: warning: 'ret' may be used uninitialized in this function

linux-next: build warning after merge of the pinctrl tree

Hi Linus, After merging the pinctrl tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/pinctrl/pinctrl-rza1.c: In function 'rza1_pinctrl_probe': drivers/pinctrl/pinctrl-rza1.c:1260:5: warning: 'ret' may be used uninitialized in this function

Panic with bochs_drm module on qemu-system-sparc64

Hi all, I'm one of the QEMU SPARC maintainers and I've been investigating why enabling the fb console via the bochs_drm module causes a panic on startup. The reproducer with QEMU 2.9 is easy: $ ./qemu-system-sparc64 -m 512 -kernel rel-sparc/vmlinux -append 'console=ttyS0' -serial stdio This

Panic with bochs_drm module on qemu-system-sparc64

Hi all, I'm one of the QEMU SPARC maintainers and I've been investigating why enabling the fb console via the bochs_drm module causes a panic on startup. The reproducer with QEMU 2.9 is easy: $ ./qemu-system-sparc64 -m 512 -kernel rel-sparc/vmlinux -append 'console=ttyS0' -serial stdio This

Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

On Fri, Jun 30, 2017 at 09:04:25AM +0530, Viresh Kumar wrote: > On 29-06-17, 20:01, Dominik Brodowski wrote: > > On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote: > > > The cpufreq core and governors aren't supposed to set a limit on how > > > fast we want to try changing the

Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

On Fri, Jun 30, 2017 at 09:04:25AM +0530, Viresh Kumar wrote: > On 29-06-17, 20:01, Dominik Brodowski wrote: > > On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote: > > > The cpufreq core and governors aren't supposed to set a limit on how > > > fast we want to try changing the

[PATCH] PM / sleep: constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. File size before: textdata bss dec hex filename 3802 624 324458116a

[PATCH] PM / sleep: constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. File size before: textdata bss dec hex filename 3802 624 324458116a

[PATCH] clocksource: em_sti: fix error return codes in em_sti_probe()

Propagate the return values of platform_get_irq and devm_request_irq on failure. Signed-off-by: Gustavo A. R. Silva --- drivers/clocksource/em_sti.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/clocksource/em_sti.c

[PATCH] clocksource: em_sti: fix error return codes in em_sti_probe()

Propagate the return values of platform_get_irq and devm_request_irq on failure. Signed-off-by: Gustavo A. R. Silva --- drivers/clocksource/em_sti.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/clocksource/em_sti.c b/drivers/clocksource/em_sti.c index

Re: [RFC 0/5] drivers: Add boot constraints core

On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar wrote: > On 30-06-17, 12:05, Chen-Yu Tsai wrote: >> On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar >> wrote: >> > On 30-06-17, 11:33, Chen-Yu Tsai wrote: >> >> AFAIK regulator constraints are

Re: [RFC 0/5] drivers: Add boot constraints core

On Fri, Jun 30, 2017 at 12:12 PM, Viresh Kumar wrote: > On 30-06-17, 12:05, Chen-Yu Tsai wrote: >> On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar >> wrote: >> > On 30-06-17, 11:33, Chen-Yu Tsai wrote: >> >> AFAIK regulator constraints are supposed to satisfy all users of it. >> > >> > Right. >>

Re: [RFC 0/5] drivers: Add boot constraints core

On 30-06-17, 12:05, Chen-Yu Tsai wrote: > On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar > wrote: > > On 30-06-17, 11:33, Chen-Yu Tsai wrote: > >> AFAIK regulator constraints are supposed to satisfy all users of it. > > > > Right. > > > >> >> >Let me try with an example.

Re: [RFC 0/5] drivers: Add boot constraints core

On 30-06-17, 12:05, Chen-Yu Tsai wrote: > On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar > wrote: > > On 30-06-17, 11:33, Chen-Yu Tsai wrote: > >> AFAIK regulator constraints are supposed to satisfy all users of it. > > > > Right. > > > >> >> >Let me try with an example. A regulator is shared

[PATCH v5 02/12] x86/apic: Prepare for unifying the interrupt delivery modes setup

There are three positions for initializing the interrupt delivery modes: 1) In IRQ initial function, may setup the through-local-APIC virtual wire mode. 2) In an SMP-capable system, will try to switch to symmetric I/O model when preparing the cpus in native_smp_prepare_cpus(). 3) In UP

[PATCH v5 02/12] x86/apic: Prepare for unifying the interrupt delivery modes setup

There are three positions for initializing the interrupt delivery modes: 1) In IRQ initial function, may setup the through-local-APIC virtual wire mode. 2) In an SMP-capable system, will try to switch to symmetric I/O model when preparing the cpus in native_smp_prepare_cpus(). 3) In UP

[PATCH v5 00/12] Unify the interrupt delivery mode and do its setup in advance

[Background] MP specification defines three different interrupt delivery modes as follows: 1. PIC Mode 2. Virtual Wire Mode 3. Symmetric I/O Mode They will be setup in the different periods of booting time: 1. *PIC Mode*, the default interrupt delivery modes, will be set first. 2. *Virtual

[PATCH v5 05/12] x86/apic: Unify interrupt mode setup for SMP-capable system

In the SMP-capable system, enable and setup the interrupt delivery mode in native_smp_prepare_cpus(). This design mixs the APIC and SMP together, it has highly coupling. Make the initialization of interrupt mode independent, Unify and refine it to apic_intr_mode_init() for SMP-capable system.

[PATCH v5 06/12] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

Calling native_smp_prepare_cpus() to prepare for SMP bootup, does some sanity checking, enables APIC mode and disables SMP feature. Now, APIC mode setup has been unified to apic_intr_mode_init(), some sanity checks are redundant and need to be cleanup. Mark the apic_intr_mode extern to refine

[PATCH v5 00/12] Unify the interrupt delivery mode and do its setup in advance

[Background] MP specification defines three different interrupt delivery modes as follows: 1. PIC Mode 2. Virtual Wire Mode 3. Symmetric I/O Mode They will be setup in the different periods of booting time: 1. *PIC Mode*, the default interrupt delivery modes, will be set first. 2. *Virtual

[PATCH v5 05/12] x86/apic: Unify interrupt mode setup for SMP-capable system

In the SMP-capable system, enable and setup the interrupt delivery mode in native_smp_prepare_cpus(). This design mixs the APIC and SMP together, it has highly coupling. Make the initialization of interrupt mode independent, Unify and refine it to apic_intr_mode_init() for SMP-capable system.

[PATCH v5 06/12] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

Calling native_smp_prepare_cpus() to prepare for SMP bootup, does some sanity checking, enables APIC mode and disables SMP feature. Now, APIC mode setup has been unified to apic_intr_mode_init(), some sanity checks are redundant and need to be cleanup. Mark the apic_intr_mode extern to refine

[PATCH v5 04/12] x86/apic: Move logical APIC ID away from apic_bsp_setup()

apic_bsp_setup() sets and returns logical APIC ID for initializing cpu0_logical_apicid in SMP-capable system. The id has nothing to do with the initialization of local APIC and I/O APIC. And apic_bsp_setup() should be called for interrupt mode setup intently. Move the id setup to

[PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system

xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus which initializes interrupt itself. Touching the intr_mode_init causes unexpected results on the system. Bypass it in enlighten_pv system. Signed-off-by: Dou Liyang --- arch/x86/xen/enlighten_pv.c |

[PATCH v5 04/12] x86/apic: Move logical APIC ID away from apic_bsp_setup()

apic_bsp_setup() sets and returns logical APIC ID for initializing cpu0_logical_apicid in SMP-capable system. The id has nothing to do with the initialization of local APIC and I/O APIC. And apic_bsp_setup() should be called for interrupt mode setup intently. Move the id setup to

[PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system

xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus which initializes interrupt itself. Touching the intr_mode_init causes unexpected results on the system. Bypass it in enlighten_pv system. Signed-off-by: Dou Liyang --- arch/x86/xen/enlighten_pv.c | 1 + 1 file changed, 1

[PATCH v5 09/12] x86/init: add intr_mode_init to x86_init_ops

Add an unconditional x86_init_ops function which defaults to the standard function and can be overridden by the early platform code. Signed-off-by: Dou Liyang --- arch/x86/include/asm/x86_init.h | 2 ++ arch/x86/kernel/apic/apic.c | 2 +- arch/x86/kernel/smpboot.c

[PATCH v5 09/12] x86/init: add intr_mode_init to x86_init_ops

Add an unconditional x86_init_ops function which defaults to the standard function and can be overridden by the early platform code. Signed-off-by: Dou Liyang --- arch/x86/include/asm/x86_init.h | 2 ++ arch/x86/kernel/apic/apic.c | 2 +- arch/x86/kernel/smpboot.c | 2 +-

[PATCH v5 11/12] x86/time: Initialize interrupt mode behind timer init

In start_kernel(), firstly, it works on the default interrupy mode, then switch to the final mode. Normally, Booting with BIOS reset is OK. But, At dump-capture kernel, it boot up without BIOS reset, default mode may not be compatible with the actual registers, that causes the delivery interrupt

[PATCH v5 11/12] x86/time: Initialize interrupt mode behind timer init

In start_kernel(), firstly, it works on the default interrupy mode, then switch to the final mode. Normally, Booting with BIOS reset is OK. But, At dump-capture kernel, it boot up without BIOS reset, default mode may not be compatible with the actual registers, that causes the delivery interrupt

[PATCH v5 08/12] x86/ioapic: Refactor the delay logic in timer_irq_works()

Kernel use timer_irq_works() to detects the timer IRQs. It calls mdelay(10) to delay ten ticks and check whether the timer IRQ work or not. The mdelay() depends on the loops_per_jiffy which is set up in calibrate_delay(). Current kernel defaults the IRQ 0 is available when it calibrates delay.

[PATCH v5 12/12] x86/apic: Remove the init_bsp_APIC()

The init_bsp_APIC() which works for the virtual wire mode is used in ISA irq initialization at the booting time. Currently, enable and setup the interrupt mode has been unified and advanced just behind the timer IRQ setup. Kernel switches to the final interrupt delivery mode directly. So

[PATCH v5 07/12] x86/apic: Unify interrupt mode setup for UP system

In UniProcessor kernel with UP_LATE_INIT=y, it enables and setups interrupt delivery mode in up_late_init(). Unify it to apic_intr_mode_init(), remove APIC_init_uniprocessor(). Signed-off-by: Dou Liyang --- arch/x86/include/asm/apic.h | 1 -

[PATCH v5 08/12] x86/ioapic: Refactor the delay logic in timer_irq_works()

Kernel use timer_irq_works() to detects the timer IRQs. It calls mdelay(10) to delay ten ticks and check whether the timer IRQ work or not. The mdelay() depends on the loops_per_jiffy which is set up in calibrate_delay(). Current kernel defaults the IRQ 0 is available when it calibrates delay.

[PATCH v5 12/12] x86/apic: Remove the init_bsp_APIC()

The init_bsp_APIC() which works for the virtual wire mode is used in ISA irq initialization at the booting time. Currently, enable and setup the interrupt mode has been unified and advanced just behind the timer IRQ setup. Kernel switches to the final interrupt delivery mode directly. So

[PATCH v5 07/12] x86/apic: Unify interrupt mode setup for UP system

In UniProcessor kernel with UP_LATE_INIT=y, it enables and setups interrupt delivery mode in up_late_init(). Unify it to apic_intr_mode_init(), remove APIC_init_uniprocessor(). Signed-off-by: Dou Liyang --- arch/x86/include/asm/apic.h | 1 - arch/x86/kernel/apic/apic.c | 49

[PATCH v5 03/12] x86/apic: Split local APIC timer setup from the APIC setup

apic_bsp_setup() sets up the local APIC, I/O APIC and APIC timer. The local APIC and I/O APIC setup belongs to interrupt delivery mode setup. Setting up the local APIC timer for booting CPU is another job and has nothing to do with interrupt delivery mode setup. Split local APIC timer setup from

[PATCH v5 03/12] x86/apic: Split local APIC timer setup from the APIC setup

apic_bsp_setup() sets up the local APIC, I/O APIC and APIC timer. The local APIC and I/O APIC setup belongs to interrupt delivery mode setup. Setting up the local APIC timer for booting CPU is another job and has nothing to do with interrupt delivery mode setup. Split local APIC timer setup from

[PATCH v5 01/12] x86/apic: Construct a selector for the interrupt delivery mode

Now, there are many switches in kernel which are used to determine the final interrupt delivery mode, as shown below: 1) kconfig: CONFIG_X86_64; CONFIG_X86_LOCAL_APIC; CONFIG_x86_IO_APIC 2) kernel option: disable_apic; skip_ioapic_setup 3) CPU Capability: boot_cpu_has(X86_FEATURE_APIC) 4) MP

[PATCH v5 01/12] x86/apic: Construct a selector for the interrupt delivery mode

Now, there are many switches in kernel which are used to determine the final interrupt delivery mode, as shown below: 1) kconfig: CONFIG_X86_64; CONFIG_X86_LOCAL_APIC; CONFIG_x86_IO_APIC 2) kernel option: disable_apic; skip_ioapic_setup 3) CPU Capability: boot_cpu_has(X86_FEATURE_APIC) 4) MP

  1   2   3   4   5   6   7   8   9   10   >