Re: [PATCH v2 5/5] powerpc: kprobes: emulate instructions on kprobe handler re-entry

On 2017/04/13 01:37PM, Masami Hiramatsu wrote: > On Wed, 12 Apr 2017 16:28:28 +0530 > "Naveen N. Rao" wrote: > > > On kprobe handler re-entry, try to emulate the instruction rather than > > single stepping always. > > > > > As a related change, remove the

Re: [PATCH v2 5/5] powerpc: kprobes: emulate instructions on kprobe handler re-entry

On 2017/04/13 01:37PM, Masami Hiramatsu wrote: > On Wed, 12 Apr 2017 16:28:28 +0530 > "Naveen N. Rao" wrote: > > > On kprobe handler re-entry, try to emulate the instruction rather than > > single stepping always. > > > > > As a related change, remove the duplicate saving of msr as that is > >

Re: [PATCH v2 4/5] powerpc: kprobes: factor out code to emulate instruction into a helper

On 2017/04/13 01:34PM, Masami Hiramatsu wrote: > On Wed, 12 Apr 2017 16:28:27 +0530 > "Naveen N. Rao" wrote: > > > This helper will be used in a subsequent patch to emulate instructions > > on re-entering the kprobe handler. No functional change. > > In this

Re: [PATCH v2 4/5] powerpc: kprobes: factor out code to emulate instruction into a helper

On 2017/04/13 01:34PM, Masami Hiramatsu wrote: > On Wed, 12 Apr 2017 16:28:27 +0530 > "Naveen N. Rao" wrote: > > > This helper will be used in a subsequent patch to emulate instructions > > on re-entering the kprobe handler. No functional change. > > In this case, please merge this patch into

Re: [PATCH v2 3/5] powerpc: introduce a new helper to obtain function entry points

On 2017/04/13 01:32PM, Masami Hiramatsu wrote: > On Wed, 12 Apr 2017 16:28:26 +0530 > "Naveen N. Rao" wrote: > > > kprobe_lookup_name() is specific to the kprobe subsystem and may not > > always return the function entry point (in a subsequent patch for > >

Re: [PATCH v2 3/5] powerpc: introduce a new helper to obtain function entry points

On 2017/04/13 01:32PM, Masami Hiramatsu wrote: > On Wed, 12 Apr 2017 16:28:26 +0530 > "Naveen N. Rao" wrote: > > > kprobe_lookup_name() is specific to the kprobe subsystem and may not > > always return the function entry point (in a subsequent patch for > > KPROBES_ON_FTRACE). > > If so, please

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 12-04-17, 18:05, Sudeep Holla wrote: > > > On 20/03/17 09:32, Viresh Kumar wrote: > [...] > > > + > > +Example 7: domain-Performance-state: > > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require > > state 2) > > + > > +/ { > > + domain_opp_table: opp_table0 { > > +

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 12-04-17, 18:05, Sudeep Holla wrote: > > > On 20/03/17 09:32, Viresh Kumar wrote: > [...] > > > + > > +Example 7: domain-Performance-state: > > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require > > state 2) > > + > > +/ { > > + domain_opp_table: opp_table0 { > > +

Re: [PATCH v2 0/5] powerpc: a few kprobe fixes and refactoring

On 2017/04/13 12:02PM, Masami Hiramatsu wrote: > Hi Naveen, Hi Masami, > > BTW, I saw you sent 3 different series, are there any > conflict each other? or can we pick those independently? Yes, all these three patch series are based off powerpc/next and they do depend on each other, as they

Re: [PATCH v2 0/5] powerpc: a few kprobe fixes and refactoring

On 2017/04/13 12:02PM, Masami Hiramatsu wrote: > Hi Naveen, Hi Masami, > > BTW, I saw you sent 3 different series, are there any > conflict each other? or can we pick those independently? Yes, all these three patch series are based off powerpc/next and they do depend on each other, as they

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

On (04/12/17 01:19), Sergey Senozhatsky wrote: [..] > it does offloading after X printed lines by the same process. > if we reschedule, then the counter resets. which is probably OK, > we don't really want any process, except for printk_kthread, to > stay in console_unlock() forever. may be this

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

On (04/12/17 01:19), Sergey Senozhatsky wrote: [..] > it does offloading after X printed lines by the same process. > if we reschedule, then the counter resets. which is probably OK, > we don't really want any process, except for printk_kthread, to > stay in console_unlock() forever. may be this

Re: [patch 05/13] powerpc/smp: Replace open coded task affinity logic

Thomas Gleixner writes: > Init task invokes smp_ops->setup_cpu() from smp_cpus_done(). Init task can > run on any online CPU at this point, but the setup_cpu() callback requires > to be invoked on the boot CPU. This is achieved by temporarily setting the > affinity of the

Re: [patch 05/13] powerpc/smp: Replace open coded task affinity logic

Thomas Gleixner writes: > Init task invokes smp_ops->setup_cpu() from smp_cpus_done(). Init task can > run on any online CPU at this point, but the setup_cpu() callback requires > to be invoked on the boot CPU. This is achieved by temporarily setting the > affinity of the calling user space

Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update

On 04/11/2017 07:36 PM, Vlastimil Babka wrote: > Commit e47483bca2cc ("mm, page_alloc: fix premature OOM when racing with > cpuset > mems update") has fixed known recent regressions found by LTP's cpuset01 > testcase. I have however found that by modifying the testcase to use per-vma >

Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update

On 04/11/2017 07:36 PM, Vlastimil Babka wrote: > Commit e47483bca2cc ("mm, page_alloc: fix premature OOM when racing with > cpuset > mems update") has fixed known recent regressions found by LTP's cpuset01 > testcase. I have however found that by modifying the testcase to use per-vma >

linux-next: Tree for Apr 13

Hi all, News: There will be no linux-next releases until next Tuesday (next-20170418). Changes since 20170412: New trees: imx-drm, etnaviv The kvm-ppc tree lost its build failure. The tty tree gained conflicts against the bluetooth tree. The rtc tree still had its build failure for which I

linux-next: Tree for Apr 13

Hi all, News: There will be no linux-next releases until next Tuesday (next-20170418). Changes since 20170412: New trees: imx-drm, etnaviv The kvm-ppc tree lost its build failure. The tty tree gained conflicts against the bluetooth tree. The rtc tree still had its build failure for which I

Re: [patch 13/13] crypto: n2 - Replace racy task affinity logic

On Wed, Apr 12, 2017 at 10:07:39PM +0200, Thomas Gleixner wrote: > spu_queue_register() needs to invoke setup functions on a particular > CPU. This is achieved by temporarily setting the affinity of the > calling user space thread to the requested CPU and reset it to the original > affinity

Re: [patch 13/13] crypto: n2 - Replace racy task affinity logic

On Wed, Apr 12, 2017 at 10:07:39PM +0200, Thomas Gleixner wrote: > spu_queue_register() needs to invoke setup functions on a particular > CPU. This is achieved by temporarily setting the affinity of the > calling user space thread to the requested CPU and reset it to the original > affinity

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 12-04-17, 17:49, Sudeep Holla wrote: > On 20/03/17 09:32, Viresh Kumar wrote: > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt > > b/Documentation/devicetree/bindings/opp/opp.txt > > index 63725498bd20..d0b95c9e1011 100644 > > --- a/Documentation/devicetree/bindings/opp/opp.txt >

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 12-04-17, 17:49, Sudeep Holla wrote: > On 20/03/17 09:32, Viresh Kumar wrote: > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt > > b/Documentation/devicetree/bindings/opp/opp.txt > > index 63725498bd20..d0b95c9e1011 100644 > > --- a/Documentation/devicetree/bindings/opp/opp.txt >

Re: [PATCH] arm64: enable ARCH_WANT_RELAX_ORDER for aarch64

On 2017/4/7 23:57, Gabriele Paoloni wrote: > Hi Robin and all > >> -Original Message- >> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >> ow...@vger.kernel.org] On Behalf Of Robin Murphy >> Sent: 20 March 2017 14:00 >> To: Dingtianhong; Catalin Marinas; Will Deacon;

Re: [PATCH] arm64: enable ARCH_WANT_RELAX_ORDER for aarch64

On 2017/4/7 23:57, Gabriele Paoloni wrote: > Hi Robin and all > >> -Original Message- >> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >> ow...@vger.kernel.org] On Behalf Of Robin Murphy >> Sent: 20 March 2017 14:00 >> To: Dingtianhong; Catalin Marinas; Will Deacon;

Re: [v3] PCI: Add an option to control probing of VFs before enabling SR-IOV

On Wed, Apr 12, 2017 at 08:56:14PM -0600, Alex Williamson wrote: >On Thu, 13 Apr 2017 01:51:40 +0300 >bod...@mellanox.com wrote: > >> From: Bodong Wang >> >> Sometimes it is not desirable to probe the virtual functions after >> SRIOV is enabled. This can save host side

Re: [v3] PCI: Add an option to control probing of VFs before enabling SR-IOV

On Wed, Apr 12, 2017 at 08:56:14PM -0600, Alex Williamson wrote: >On Thu, 13 Apr 2017 01:51:40 +0300 >bod...@mellanox.com wrote: > >> From: Bodong Wang >> >> Sometimes it is not desirable to probe the virtual functions after >> SRIOV is enabled. This can save host side resource usage by VF >>

[PATCH v2] mm, x86: Add ARCH_HAS_ZONE_DEVICE to Kconfig

Currently ZONE_DEVICE depends on X86_64 and this will get unwieldly as new architectures (and platforms) get ZONE_DEVICE support. Move to an arch selected Kconfig option to save us the trouble. Cc: linux...@kvack.org Signed-off-by: Oliver O'Halloran --- v2: add missing hunk ---

[PATCH v2] mm, x86: Add ARCH_HAS_ZONE_DEVICE to Kconfig

Currently ZONE_DEVICE depends on X86_64 and this will get unwieldly as new architectures (and platforms) get ZONE_DEVICE support. Move to an arch selected Kconfig option to save us the trouble. Cc: linux...@kvack.org Signed-off-by: Oliver O'Halloran --- v2: add missing hunk --- arch/x86/Kconfig

Re: [PATCH] thermal: core: Allow orderly_poweroff to be called only once

On Thursday 13 April 2017 10:36 AM, Eduardo Valentin wrote: > Hey, > > On Wed, Apr 12, 2017 at 02:42:12PM +0530, Keerthy wrote: >> thermal_zone_device_check --> thermal_zone_device_update --> >> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff >> >> The above sequence happens

Re: [PATCH] thermal: core: Allow orderly_poweroff to be called only once

On Thursday 13 April 2017 10:36 AM, Eduardo Valentin wrote: > Hey, > > On Wed, Apr 12, 2017 at 02:42:12PM +0530, Keerthy wrote: >> thermal_zone_device_check --> thermal_zone_device_update --> >> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff >> >> The above sequence happens

Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.

Stephen Rothwell writes: > Hi Paul, > > On Wed, 12 Apr 2017 20:30:14 -0400 Paul Gortmaker > wrote: >> >> Since ia64 and ppc64 don't set CONFIG_64BIT, they were already >> excluded by the original dependency. > > My powerpc ppc64_defconfig

Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.

Stephen Rothwell writes: > Hi Paul, > > On Wed, 12 Apr 2017 20:30:14 -0400 Paul Gortmaker > wrote: >> >> Since ia64 and ppc64 don't set CONFIG_64BIT, they were already >> excluded by the original dependency. > > My powerpc ppc64_defconfig builds have CONFIG_64BIT set ... > > $ grep

Re: [PATCH] thermal: core: Allow orderly_poweroff to be called only once

Hey, On Wed, Apr 12, 2017 at 02:42:12PM +0530, Keerthy wrote: > thermal_zone_device_check --> thermal_zone_device_update --> > handle_thermal_trip --> handle_critical_trips --> orderly_poweroff > > The above sequence happens every 250/500 mS based on the configuration. > The orderly_poweroff

Re: [PATCH] thermal: core: Allow orderly_poweroff to be called only once

Hey, On Wed, Apr 12, 2017 at 02:42:12PM +0530, Keerthy wrote: > thermal_zone_device_check --> thermal_zone_device_update --> > handle_thermal_trip --> handle_critical_trips --> orderly_poweroff > > The above sequence happens every 250/500 mS based on the configuration. > The orderly_poweroff

[PATCH] ARM: dts: dra7: Add power hold and power controller properties to palmas

Add power hold and power controller properties to palmas node. This is needed to shutdown pmic correctly on boards with powerhold set. Signed-off-by: Keerthy --- arch/arm/boot/dts/dra7-evm.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/dra7-evm.dts

[PATCH] ARM: dts: dra7: Add power hold and power controller properties to palmas

Add power hold and power controller properties to palmas node. This is needed to shutdown pmic correctly on boards with powerhold set. Signed-off-by: Keerthy --- arch/arm/boot/dts/dra7-evm.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/dra7-evm.dts

Re: [PATCH v2 5/5] powerpc: kprobes: emulate instructions on kprobe handler re-entry

On Wed, 12 Apr 2017 16:28:28 +0530 "Naveen N. Rao" wrote: > On kprobe handler re-entry, try to emulate the instruction rather than > single stepping always. > > As a related change, remove the duplicate saving of msr as that is > already done in

Re: [PATCH v2 5/5] powerpc: kprobes: emulate instructions on kprobe handler re-entry

On Wed, 12 Apr 2017 16:28:28 +0530 "Naveen N. Rao" wrote: > On kprobe handler re-entry, try to emulate the instruction rather than > single stepping always. > > As a related change, remove the duplicate saving of msr as that is > already done in set_current_kprobe() If so, this part might be

Re: [PATCH v2 4/5] powerpc: kprobes: factor out code to emulate instruction into a helper

On Wed, 12 Apr 2017 16:28:27 +0530 "Naveen N. Rao" wrote: > This helper will be used in a subsequent patch to emulate instructions > on re-entering the kprobe handler. No functional change. In this case, please merge this patch into the next patch which actually

Re: [PATCH v2 4/5] powerpc: kprobes: factor out code to emulate instruction into a helper

On Wed, 12 Apr 2017 16:28:27 +0530 "Naveen N. Rao" wrote: > This helper will be used in a subsequent patch to emulate instructions > on re-entering the kprobe handler. No functional change. In this case, please merge this patch into the next patch which actually uses the factored out function

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

On (04/12/17 20:43), Pavel Machek wrote: [..] > > when the limit of "number of lines printed" is 0, then no > > offloading takes place. > > And with "number of lines printed" set to 99, it will get us > previous behaviour, right? `atomic_print_limit' set to zero disables offloading

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

On (04/12/17 20:43), Pavel Machek wrote: [..] > > when the limit of "number of lines printed" is 0, then no > > offloading takes place. > > And with "number of lines printed" set to 99, it will get us > previous behaviour, right? `atomic_print_limit' set to zero disables offloading

Re: [PATCH v2 3/5] powerpc: introduce a new helper to obtain function entry points

On Wed, 12 Apr 2017 16:28:26 +0530 "Naveen N. Rao" wrote: > kprobe_lookup_name() is specific to the kprobe subsystem and may not > always return the function entry point (in a subsequent patch for > KPROBES_ON_FTRACE). If so, please move this patch into that

Re: [PATCH v2 3/5] powerpc: introduce a new helper to obtain function entry points

On Wed, 12 Apr 2017 16:28:26 +0530 "Naveen N. Rao" wrote: > kprobe_lookup_name() is specific to the kprobe subsystem and may not > always return the function entry point (in a subsequent patch for > KPROBES_ON_FTRACE). If so, please move this patch into that series. It is hard to review patches

Re: [BUG nohz]: wrong user and system time accounting

2017-04-12 22:57 GMT+08:00 Thomas Gleixner : > On Wed, 12 Apr 2017, Frederic Weisbecker wrote: >> On Tue, Apr 11, 2017 at 04:22:48PM +0200, Thomas Gleixner wrote: >> > It's not different from the current jiffies based stuff at all. Same >> > failure mode. >> >> Yes you're

Re: [BUG nohz]: wrong user and system time accounting

2017-04-12 22:57 GMT+08:00 Thomas Gleixner : > On Wed, 12 Apr 2017, Frederic Weisbecker wrote: >> On Tue, Apr 11, 2017 at 04:22:48PM +0200, Thomas Gleixner wrote: >> > It's not different from the current jiffies based stuff at all. Same >> > failure mode. >> >> Yes you're right, I got confused

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

On Thu, Mar 30, 2017 at 12:40:32PM -0700, Tim Murray wrote: > On Thu, Mar 30, 2017 at 8:51 AM, Johannes Weiner wrote: > > In cgroup2, we've added a memory.low knob, where groups within their > > memory.low setting are not reclaimed. > > > > You can set that knob on foreground

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

On Thu, Mar 30, 2017 at 12:40:32PM -0700, Tim Murray wrote: > On Thu, Mar 30, 2017 at 8:51 AM, Johannes Weiner wrote: > > In cgroup2, we've added a memory.low knob, where groups within their > > memory.low setting are not reclaimed. > > > > You can set that knob on foreground groups to the amount

Re: [PATCH v2 2/5] powerpc: kprobes: fix handling of function offsets on ABIv2

On Wed, 12 Apr 2017 16:28:25 +0530 "Naveen N. Rao" wrote: > commit 239aeba76409 ("perf powerpc: Fix kprobe and kretprobe handling > with kallsyms on ppc64le") changed how we use the offset field in struct > kprobe on ABIv2. perf now offsets from the GEP (Global

Re: [PATCH v2 2/5] powerpc: kprobes: fix handling of function offsets on ABIv2

On Wed, 12 Apr 2017 16:28:25 +0530 "Naveen N. Rao" wrote: > commit 239aeba76409 ("perf powerpc: Fix kprobe and kretprobe handling > with kallsyms on ppc64le") changed how we use the offset field in struct > kprobe on ABIv2. perf now offsets from the GEP (Global entry point) if an > offset is

Re: [PATCH linux 2/2] net sched actions: fix refcount decrement on error

On Wed, Apr 12, 2017 at 7:21 AM, Wolfgang Bumiller wrote: > If memory allocation for nla_memdup_cookie() fails > module_put has to be guarded by the same condition as it was > before the TCA_ACT_COOKIE has been added as stated in the > comment afterwards: > > /* module

Re: [PATCH linux 2/2] net sched actions: fix refcount decrement on error

On Wed, Apr 12, 2017 at 7:21 AM, Wolfgang Bumiller wrote: > If memory allocation for nla_memdup_cookie() fails > module_put has to be guarded by the same condition as it was > before the TCA_ACT_COOKIE has been added as stated in the > comment afterwards: > > /* module count goes up only when

[tip:WIP.sched/cpusallowed 13/13] drivers/crypto/n2_core.c:1659:31: error: passing argument 2 of 'work_on_cpu_safe' from incompatible pointer type

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.sched/cpusallowed head: 4ba98c7ec4094a9123d0d6aabb4497290207b518 commit: 4ba98c7ec4094a9123d0d6aabb4497290207b518 [13/13] crypto: n2 - Use work_on_cpu() instead of affinity games config: sparc64-allyesconfig (attached as

[tip:WIP.sched/cpusallowed 13/13] drivers/crypto/n2_core.c:1659:31: error: passing argument 2 of 'work_on_cpu_safe' from incompatible pointer type

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.sched/cpusallowed head: 4ba98c7ec4094a9123d0d6aabb4497290207b518 commit: 4ba98c7ec4094a9123d0d6aabb4497290207b518 [13/13] crypto: n2 - Use work_on_cpu() instead of affinity games config: sparc64-allyesconfig (attached as

[PATCH] [media] mtk-mdp: Fix g_/s_selection capture/compose logic

From: Daniel Kurtz Experiments show that the: (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets Signed-off-by: Daniel Kurtz Signed-off-by: Minghsiu Tsai

[PATCH] [media] mtk-mdp: Fix g_/s_selection capture/compose logic

From: Daniel Kurtz Experiments show that the: (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets Signed-off-by: Daniel Kurtz Signed-off-by: Minghsiu Tsai --- drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 18

Re: [PATCH] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

On 04/12/2017 10:31 AM, Hoeun Ryu wrote: > vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area > during boot process and those virtually mapped areas are never unmapped. > So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing > existing vmlist entries and

Re: [PATCH] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

On 04/12/2017 10:31 AM, Hoeun Ryu wrote: > vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area > during boot process and those virtually mapped areas are never unmapped. > So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing > existing vmlist entries and

RE: [PATCH 04/16] fpga: intel: pcie: parse feature list and create platform device for features.

> On Wed, Apr 5, 2017 at 6:58 AM, Wu Hao wrote: > > On Mon, Apr 03, 2017 at 04:44:15PM -0500, Alan Tull wrote: > >> On Thu, Mar 30, 2017 at 7:08 AM, Wu Hao wrote: > >> > From: Xiao Guangrong > >> > > >> > Device Featuer List

RE: [PATCH 04/16] fpga: intel: pcie: parse feature list and create platform device for features.

> On Wed, Apr 5, 2017 at 6:58 AM, Wu Hao wrote: > > On Mon, Apr 03, 2017 at 04:44:15PM -0500, Alan Tull wrote: > >> On Thu, Mar 30, 2017 at 7:08 AM, Wu Hao wrote: > >> > From: Xiao Guangrong > >> > > >> > Device Featuer List structure creates a link list of feature headers > >> > within the

Re: [PATCH 3/3] powernv:idle: Set LPCR_UPRT on wakeup from deep-stop

On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote: > >   #endif > >    mtctr   r12 > >    bctrl > > +/* > > + * cur_cpu_spec->cpu_restore would restore LPCR to a > > + * sane value that is set at early boot time, > > + * thereby clearing LPCR_UPRT. > > + * LPCR_UPRT is required if

Re: [PATCH 3/3] powernv:idle: Set LPCR_UPRT on wakeup from deep-stop

On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote: > >   #endif > >    mtctr   r12 > >    bctrl > > +/* > > + * cur_cpu_spec->cpu_restore would restore LPCR to a > > + * sane value that is set at early boot time, > > + * thereby clearing LPCR_UPRT. > > + * LPCR_UPRT is required if

Re: [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

Hi Heiko, On 04/12/2017 09:29 PM, Heiko Stuebner wrote: Hi Kever, Am Montag, 10. April 2017, 11:50:13 CEST schrieb Kever Yang: Firefly-rk3399 is a bord from T-Firefly, you can find detail about it here: http://en.t-firefly.com/en/firenow/Firefly_RK3399/ This patch add basic node for the

Re: [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

Hi Heiko, On 04/12/2017 09:29 PM, Heiko Stuebner wrote: Hi Kever, Am Montag, 10. April 2017, 11:50:13 CEST schrieb Kever Yang: Firefly-rk3399 is a bord from T-Firefly, you can find detail about it here: http://en.t-firefly.com/en/firenow/Firefly_RK3399/ This patch add basic node for the

[PATCH v2] efi: Config options to assign versions in the PE-COFF header

This commit adds the new config options to allow the user to modify the following fields in the PE-COFF header. UINT16 MajorOperatingSystemVersion UINT16 MinorOperatingSystemVersion UINT16 MajorImageVersion UINT16 MinorImageVersion Those fields are mainly for the executables or libraries in

Re: [PATCH 3/3] powernv:idle: Set LPCR_UPRT on wakeup from deep-stop

"Gautham R. Shenoy" writes: > From: "Gautham R. Shenoy" > > On wakeup from a deep-stop used for CPU-Hotplug, we invoke > cur_cpu_spec->cpu_restore() which would set sane default values to > various SPRs including LPCR. > > On POWER9, the

[PATCH v2] efi: Config options to assign versions in the PE-COFF header

This commit adds the new config options to allow the user to modify the following fields in the PE-COFF header. UINT16 MajorOperatingSystemVersion UINT16 MinorOperatingSystemVersion UINT16 MajorImageVersion UINT16 MinorImageVersion Those fields are mainly for the executables or libraries in

Re: [PATCH 3/3] powernv:idle: Set LPCR_UPRT on wakeup from deep-stop

"Gautham R. Shenoy" writes: > From: "Gautham R. Shenoy" > > On wakeup from a deep-stop used for CPU-Hotplug, we invoke > cur_cpu_spec->cpu_restore() which would set sane default values to > various SPRs including LPCR. > > On POWER9, the cpu_restore_power9() call would would restore LPCR to a >

Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.

[Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.] On 13/04/2017 (Thu 13:27) Stephen Rothwell wrote: > Hi Paul, > > On Wed, 12 Apr 2017 20:30:14 -0400 Paul Gortmaker > wrote: > > > > Since ia64 and ppc64 don't set CONFIG_64BIT, they were

Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.

[Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.] On 13/04/2017 (Thu 13:27) Stephen Rothwell wrote: > Hi Paul, > > On Wed, 12 Apr 2017 20:30:14 -0400 Paul Gortmaker > wrote: > > > > Since ia64 and ppc64 don't set CONFIG_64BIT, they were already > > excluded by the

Re: [PATCH] thermal: core: Add a back up thermal shutdown mechanism

On Thursday 13 April 2017 12:13 AM, Tero Kristo wrote: > On 12/04/17 20:24, Eduardo Valentin wrote: >> On Wed, Apr 12, 2017 at 10:41:00PM +0530, Keerthy wrote: >>> >>> >>> On Wednesday 12 April 2017 10:38 PM, Grygorii Strashko wrote: On 04/12/2017 11:44 AM, Keerthy wrote: >

Re: [PATCH] thermal: core: Add a back up thermal shutdown mechanism

On Thursday 13 April 2017 12:13 AM, Tero Kristo wrote: > On 12/04/17 20:24, Eduardo Valentin wrote: >> On Wed, Apr 12, 2017 at 10:41:00PM +0530, Keerthy wrote: >>> >>> >>> On Wednesday 12 April 2017 10:38 PM, Grygorii Strashko wrote: On 04/12/2017 11:44 AM, Keerthy wrote: >

Re: [PATCH v2 0/3] of: Make of_match_node() an inline stub for CONFIG_OF=n

On 04/11/17 21:41, Florian Fainelli wrote: > Hi all, > > This patch series makes of_match_node() an inline stub for CONFIG_OF=n. kbuild > reported two build errors which are fixed as preriquisite patches. > > This is based on Linus' master, not sure which tree would merge this, Frank's? It

Re: [PATCH v2 0/3] of: Make of_match_node() an inline stub for CONFIG_OF=n

On 04/11/17 21:41, Florian Fainelli wrote: > Hi all, > > This patch series makes of_match_node() an inline stub for CONFIG_OF=n. kbuild > reported two build errors which are fixed as preriquisite patches. > > This is based on Linus' master, not sure which tree would merge this, Frank's? It

Re: [BUG] alpha: module xxx: Unknown relocation: 1

On Wed, Apr 12, 2017 at 07:36:36PM +1200, Michael Cree wrote: > On Wed, Apr 12, 2017 at 07:57:52AM +0200, Helge Deller wrote: > > On 12.04.2017 04:59, Bob Tracy wrote: > > > Bottom line is, no kernel I've built since 4.9 can load a module. All > > > attempts to load a module result in the error

Re: [BUG] alpha: module xxx: Unknown relocation: 1

On Wed, Apr 12, 2017 at 07:36:36PM +1200, Michael Cree wrote: > On Wed, Apr 12, 2017 at 07:57:52AM +0200, Helge Deller wrote: > > On 12.04.2017 04:59, Bob Tracy wrote: > > > Bottom line is, no kernel I've built since 4.9 can load a module. All > > > attempts to load a module result in the error

linux-next: manual merge of the tty tree with the bluetooth tree

Hi Greg, Today's linux-next merge of the tty tree got a conflict in: include/linux/serdev.h between commits: b3f80c8f75ef ("serdev: add serdev_device_wait_until_sent") 5659dab26f09 ("serdev: implement get/set tiocm") from the bluetooth tree and commit: 6fe729c4bdae ("serdev: Add

linux-next: manual merge of the tty tree with the bluetooth tree

Hi Greg, Today's linux-next merge of the tty tree got a conflict in: include/linux/serdev.h between commits: b3f80c8f75ef ("serdev: add serdev_device_wait_until_sent") 5659dab26f09 ("serdev: implement get/set tiocm") from the bluetooth tree and commit: 6fe729c4bdae ("serdev: Add

Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation

Benjamin Herrenschmidt writes: > On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote: >> Ok, point taken. BTW, may I ask you guys to have a look into this >> please ? >> >> https://lkml.org/lkml/2017/4/6/743 >> >> It is a side effect of this thread (v2), not

Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation

Benjamin Herrenschmidt writes: > On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote: >> Ok, point taken. BTW, may I ask you guys to have a look into this >> please ? >> >> https://lkml.org/lkml/2017/4/6/743 >> >> It is a side effect of this thread (v2), not sure why >> on powerpc has

Re: [PATCH v5 3/3] blackfin: bf609: let clk_disable() return immediately if clk is NULL

Hi Andrew 2017-03-28 18:17 GMT+09:00 Masahiro Yamada : > In many of clk_disable() implementations, it is a no-op for a NULL > pointer input, but this is one of the exceptions. > > Making it treewide consistent will allow clock consumers to call > clk_disable()

Re: [PATCH v5 3/3] blackfin: bf609: let clk_disable() return immediately if clk is NULL

Hi Andrew 2017-03-28 18:17 GMT+09:00 Masahiro Yamada : > In many of clk_disable() implementations, it is a no-op for a NULL > pointer input, but this is one of the exceptions. > > Making it treewide consistent will allow clock consumers to call > clk_disable() without NULL pointer check. > >

Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.

Hi Paul, On Wed, 12 Apr 2017 20:30:14 -0400 Paul Gortmaker wrote: > > Since ia64 and ppc64 don't set CONFIG_64BIT, they were already > excluded by the original dependency. My powerpc ppc64_defconfig builds have CONFIG_64BIT set ... $ grep CONFIG_64BIT

Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.

Hi Paul, On Wed, 12 Apr 2017 20:30:14 -0400 Paul Gortmaker wrote: > > Since ia64 and ppc64 don't set CONFIG_64BIT, they were already > excluded by the original dependency. My powerpc ppc64_defconfig builds have CONFIG_64BIT set ... $ grep CONFIG_64BIT ~/next/powerpc_ppc64_defconfig/.config

Re: [PATCH v4 0/5] perf report: Show branch type

On 4/13/2017 10:00 AM, Jin, Yao wrote: On 4/12/2017 6:58 PM, Jiri Olsa wrote: On Wed, Apr 12, 2017 at 06:21:01AM +0800, Jin Yao wrote: SNIP 3. Use 2 bits in perf_branch_entry for a "cross" metrics checking for branch cross 4K or 2M area. It's an approximate computing for checking

Re: [PATCH v4 0/5] perf report: Show branch type

On 4/13/2017 10:00 AM, Jin, Yao wrote: On 4/12/2017 6:58 PM, Jiri Olsa wrote: On Wed, Apr 12, 2017 at 06:21:01AM +0800, Jin Yao wrote: SNIP 3. Use 2 bits in perf_branch_entry for a "cross" metrics checking for branch cross 4K or 2M area. It's an approximate computing for checking

[tip:WIP.sched/cpusallowed 12/13] drivers/cpufreq/sparc-us2e-cpufreq.c:270:69: error: expected ';' before ')' token

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.sched/cpusallowed head: 4ba98c7ec4094a9123d0d6aabb4497290207b518 commit: 6c06178b50bf61bf9fd4311e99e1f9f470b31b5d [12/13] cpufreq/sparc-us2e: Remove affinity games config: sparc64-allyesconfig (attached as .config)

[tip:WIP.sched/cpusallowed 12/13] drivers/cpufreq/sparc-us2e-cpufreq.c:270:69: error: expected ';' before ')' token

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.sched/cpusallowed head: 4ba98c7ec4094a9123d0d6aabb4497290207b518 commit: 6c06178b50bf61bf9fd4311e99e1f9f470b31b5d [12/13] cpufreq/sparc-us2e: Remove affinity games config: sparc64-allyesconfig (attached as .config)

[PATCH v6 1/2] video: ARM CLCD: Move registers to a separate header.

We'd like to reuse these register definitions for the DRM CLCD driver, but there's a bunch of fbdev-specific code in the current header. v2: Add #ifndef guard. Signed-off-by: Eric Anholt --- include/linux/amba/clcd-regs.h | 81 ++

[PATCH v6 1/2] video: ARM CLCD: Move registers to a separate header.

We'd like to reuse these register definitions for the DRM CLCD driver, but there's a bunch of fbdev-specific code in the current header. v2: Add #ifndef guard. Signed-off-by: Eric Anholt --- include/linux/amba/clcd-regs.h | 81 ++

[PATCH v6 2/2] drm/pl111: Initial drm/kms driver for pl111

From: Tom Cooksey This is a modesetting driver for the pl111 CLCD display controller found on various ARM platforms such as the Versatile Express. The driver has only been tested on the bcm911360_entphn platform so far, with PRIME-based buffer sharing between vc4 and clcd.

[PATCH v6 2/2] drm/pl111: Initial drm/kms driver for pl111

From: Tom Cooksey This is a modesetting driver for the pl111 CLCD display controller found on various ARM platforms such as the Versatile Express. The driver has only been tested on the bcm911360_entphn platform so far, with PRIME-based buffer sharing between vc4 and clcd. It reuses the

[git pull] drm fixes for 4.11 rc7

Hi Linus, I was away the end of last week, so some of these would have been in rc6, and it's Easter from tomorrow, so I decided I better dequeue what I have now. The nouveau changes, just add a hw enable for GP107 display (like a pci id addition really), and fix a couple of regressions. i915 has

[git pull] drm fixes for 4.11 rc7

Hi Linus, I was away the end of last week, so some of these would have been in rc6, and it's Easter from tomorrow, so I decided I better dequeue what I have now. The nouveau changes, just add a hw enable for GP107 display (like a pci id addition really), and fix a couple of regressions. i915 has

Re: [PATCH v2 1/5] kprobes: convert kprobe_lookup_name() to a function

On Wed, 12 Apr 2017 16:28:24 +0530 "Naveen N. Rao" wrote: > The macro is now pretty long and ugly on powerpc. In the light of > further changes needed here, convert it to a __weak variant to be > over-ridden with a nicer looking function. Looks good to me.

Re: [PATCH v2 1/5] kprobes: convert kprobe_lookup_name() to a function

On Wed, 12 Apr 2017 16:28:24 +0530 "Naveen N. Rao" wrote: > The macro is now pretty long and ugly on powerpc. In the light of > further changes needed here, convert it to a __weak variant to be > over-ridden with a nicer looking function. Looks good to me. Acked-by: Masami Hiramatsu Thanks!

Re: [PATCH] sched/deadline: Throttle a constrained task activated if overflow

On 04/12/2017 at 09:10 PM, luca abeni wrote: > On Wed, 12 Apr 2017 20:30:04 +0800 > Xunlei Pang wrote: > [...] >>> If the relative deadline is different from the period, then the >>> check is an approximation (and this is the big issue here). I am >>> still not sure about what

Re: [PATCH] sched/deadline: Throttle a constrained task activated if overflow

On 04/12/2017 at 09:10 PM, luca abeni wrote: > On Wed, 12 Apr 2017 20:30:04 +0800 > Xunlei Pang wrote: > [...] >>> If the relative deadline is different from the period, then the >>> check is an approximation (and this is the big issue here). I am >>> still not sure about what is the best thing

Re: [PATCH v2 0/5] powerpc: a few kprobe fixes and refactoring

Hi Naveen, BTW, I saw you sent 3 different series, are there any conflict each other? or can we pick those independently? Thanks, On Wed, 12 Apr 2017 16:28:23 +0530 "Naveen N. Rao" wrote: > v1: >

Re: [PATCH v2 0/5] powerpc: a few kprobe fixes and refactoring

Hi Naveen, BTW, I saw you sent 3 different series, are there any conflict each other? or can we pick those independently? Thanks, On Wed, 12 Apr 2017 16:28:23 +0530 "Naveen N. Rao" wrote: > v1: > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1334843.html > > For v2, this

  1   2   3   4   5   6   7   8   9   10   >