Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On 20 October 2017 at 03:19, Rafael J. Wysocki wrote: > On Thursday, October 19, 2017 2:21:07 PM CEST Ulf Hansson wrote: >> On 19 October 2017 at 00:12, Rafael J. Wysocki wrote: >> > On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote: >> >>

Re: [RFC PATCH] kbuild: Allow specifying some base host CFLAGS

Hi, On Wed, Oct 18, 2017 at 9:45 AM, Masahiro Yamada wrote: > 2017-10-14 3:02 GMT+09:00 Douglas Anderson : >> Right now there is a way to add some CFLAGS that affect target builds, >> but no way to add CFLAGS that affect host builds. Let's

[RFC PATCH 1/5] gpio: gpiolib: Add core support for maintaining GPIO values on reset

GPIO state reset tolerance is implemented in gpiolib through the addition of a new pinconf parameter. With that, some renaming of helpers is done to clarify the scope of the already existing gpiochip_line_is_persistent(), as it's now ambiguous as to whether that means on suspend, reset or both.

[RFC PATCH 2/5] gpio: gpiolib: Add OF support for maintaining GPIO values on reset

Add flags and the associated flag mappings between interfaces to enable GPIO reset tolerance to be specified via devicetree. Signed-off-by: Andrew Jeffery --- drivers/gpio/gpiolib-of.c | 2 ++ drivers/gpio/gpiolib.c | 5 + include/dt-bindings/gpio/gpio.h | 4

[RFC PATCH 3/5] gpio: gpiolib: Add chardev support for maintaining GPIO values on reset

Similar to devicetree support, add flags and mappings to expose reset tolerance configuration through the chardev interface. Signed-off-by: Andrew Jeffery --- drivers/gpio/gpiolib.c| 14 +- include/uapi/linux/gpio.h | 11 ++- 2 files changed, 19

[RFC PATCH 4/5] gpio: gpiolib: Add sysfs support for maintaining GPIO values on reset

Expose a new 'maintain' sysfs attribute to control both suspend and reset tolerance. Signed-off-by: Andrew Jeffery --- Documentation/gpio/sysfs.txt | 9 + drivers/gpio/gpiolib-sysfs.c | 88 ++-- 2 files changed, 93 insertions(+), 4

[RFC PATCH 5/5] gpio: aspeed: Add support for reset tolerance

Use the new pinconf parameter for reset tolerance to expose the associated capability of the Aspeed GPIO controller. Signed-off-by: Andrew Jeffery --- drivers/gpio/gpio-aspeed.c | 39 +-- 1 file changed, 37 insertions(+), 2 deletions(-) diff

[RFC PATCH 0/5] gpio: Expose reset tolerance capability

Hello, This series exposes a "reset tolerant" property for GPIOs. For example, the controller implemented in Aspeed BMCs provides such a feature to allow the BMC to be reset whilst maintaining necessary state to keep host systems alive or status LEDs in-tact. I'm sending it as an RFC because I'm

Re: [PATCH v6 0/6] Add HiSilicon SoC uncore Performance Monitoring Unit driver

Hi Mark/Will, Thanks. On 2017/10/19 23:32, Mark Rutland wrote: > On Thu, Oct 19, 2017 at 04:28:35PM +0100, Will Deacon wrote: >> On Thu, Oct 19, 2017 at 01:29:18PM +0100, Mark Rutland wrote: >>> Will, are you happy to queue this? >>> >>> There's a minor fixup [1] needed in patch 2, but otherwise

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On Thursday, October 19, 2017 2:21:07 PM CEST Ulf Hansson wrote: > On 19 October 2017 at 00:12, Rafael J. Wysocki wrote: > > On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote: > >> [...] > >> > >> >> > >> >> The reason why pm_runtime_force_* needs to respects

Re: [PATCH 1/3] printk: Introduce per-console loglevel setting

On 09/28/2017 05:43 PM, Calvin Owens wrote: Not all consoles are created equal: depending on the actual hardware, the latency of a printk() call can vary dramatically. The worst examples are serial consoles, where it can spin for tens of milliseconds banging the UART to emit a message, which can

[PATCH doc/rcu 2/2] doc: Fix various RCU docbook comment-header problems

Because many of RCU's files have not been included into docbook, a number of errors have accumulated. This commit fixes them. Signed-off-by: Paul E. McKenney --- include/linux/rculist.h | 2 +- include/linux/rcupdate.h | 22 ++

[PATCH doc/rcu 1/2] doc: Fix RCU's docbook options

Commit 764f80798b95 ("doc: Add RCU files to docbook-generation files") added :external: options for RCU source files in the file Documentation/core-api/kernel-api.rst. However, this now means nothing, so this commit removes them. Reported-by: Randy Dunlap Reported-by:

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On 10/19/2017 01:11 PM, Ulf Hansson wrote: > On 19 October 2017 at 20:04, Ulf Hansson wrote: >> On 19 October 2017 at 19:21, Grygorii Strashko >> wrote: >>> >>> >>> On 10/19/2017 03:33 AM, Ulf Hansson wrote: On 18 October 2017 at 23:48,

[PATCH doc/rcu 2/2] doc: Fix various RCU docbook comment-header problems

Because many of RCU's files have not been included into docbook, a number of errors have accumulated. This commit fixes them. Signed-off-by: Paul E. McKenney --- include/linux/rculist.h | 2 +- include/linux/rcupdate.h | 22 ++

[PATCH doc/rcu 1/2] doc: Fix RCU's docbook options

Commit 764f80798b95 ("doc: Add RCU files to docbook-generation files") added :external: options for RCU source files in the file Documentation/core-api/kernel-api.rst. However, this now means nothing, so this commit removes them. Reported-by: Randy Dunlap Reported-by:

[PATCH doc/rcu 0/2] Fix docbook regression

Hello, Linus, Commit 764f80798b95 ("doc: Add RCU files to docbook-generation files"), which is in v4.14-rc1, added :external: options for RCU source files in the file Documentation/core-api/kernel-api.rst. However, this now means nothing, and furthermore breaks builds of the docbook, which has

Re: [RESEND v12 0/6] cgroup-aware OOM killer

On Thu 19-10-17 15:45:34, Johannes Weiner wrote: > On Thu, Oct 19, 2017 at 07:52:12PM +0100, Roman Gushchin wrote: > > This patchset makes the OOM killer cgroup-aware. > > Hi Andrew, > > I believe this code is ready for merging upstream, and it seems Michal > is in agreement. There are two main

Re: [RESEND v12 0/6] cgroup-aware OOM killer

On Thu, Oct 19, 2017 at 07:52:12PM +0100, Roman Gushchin wrote: > This patchset makes the OOM killer cgroup-aware. Hi Andrew, I believe this code is ready for merging upstream, and it seems Michal is in agreement. There are two main things to consider, however. David would have really liked for

Re: [RESEND v12 3/6] mm, oom: cgroup-aware OOM killer

On Thu 19-10-17 19:52:15, Roman Gushchin wrote: > Traditionally, the OOM killer is operating on a process level. > Under oom conditions, it finds a process with the highest oom score > and kills it. > > This behavior doesn't suit well the system with many running > containers: > > 1) There is no

Re: [PATCH] documentation: kernel-api: add more info on bitmap functions

On Mon, 16 Oct 2017 16:32:51 -0700 Randy Dunlap wrote: > There are some good comments about bitmap operations in lib/bitmap.c > and include/linux/bitmap.h, so format them for document generation and > pull them into core-api/kernel-api.rst. > > I converted the "tables" of

Re: [PATCH 0/8] Documentation: fix invalid Documentation refs (2)

On Thu, 12 Oct 2017 15:23:26 -0500 Tom Saeger wrote: > Batch (2) set of simple document ref fixes. > > > Tom Saeger (8): > Documentation: fix locking rt-mutex doc refs > Documentation: fix ref to sphinx/kerneldoc.py > Documentation: fix ref to workqueue content >

Re: kernel/module: Delete an error message for a failed memory allocation in add_module_usage()

>>> Something like: >>> >>> "because there is a dump_stack() done on allocation failures >>> without __GFP_JNOWARN" >> >> How do you think about to convert such a description into a special format >> for further reference documentation? > > I think it's a bad idea if it's a "special" format.

[RESEND v12 4/6] mm, oom: introduce memory.oom_group

The cgroup-aware OOM killer treats leaf memory cgroups as memory consumption entities and performs the victim selection by comparing them based on their memory footprint. Then it kills the biggest task inside the selected memory cgroup. But there are workloads, which are not tolerant to a such

[RESEND v12 3/6] mm, oom: cgroup-aware OOM killer

Traditionally, the OOM killer is operating on a process level. Under oom conditions, it finds a process with the highest oom score and kills it. This behavior doesn't suit well the system with many running containers: 1) There is no fairness between containers. A small container with few large

[RESEND v12 1/6] mm, oom: refactor the oom_kill_process() function

The oom_kill_process() function consists of two logical parts: the first one is responsible for considering task's children as a potential victim and printing the debug information. The second half is responsible for sending SIGKILL to all tasks sharing the mm struct with the given victim. This

Re: [PATCH] docs: dev-tools: correct Coccinelle version number

On Sun, 15 Oct 2017 11:24:08 +0200 Julia Lawall wrote: > There is no Coccinelle version 1.2. 1.0.2 must be what was intended. > > Signed-off-by: Julia Lawall Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe

[RESEND v12 2/6] mm: implement mem_cgroup_scan_tasks() for the root memory cgroup

Implement mem_cgroup_scan_tasks() functionality for the root memory cgroup to use this function for looking for a OOM victim task in the root memory cgroup by the cgroup-ware OOM killer. The root memory cgroup is treated as a leaf cgroup, so only tasks which are directly belonging to the root

[RESEND v12 0/6] cgroup-aware OOM killer

This patchset makes the OOM killer cgroup-aware. v12: - Root memory cgroup is evaluated based on sum of the oom scores of belonging tasks - Do not fallback to the per-process behavior if there if it wasn't possbile to kill a memcg victim - Rebase on top of mm tree v11: - Fixed an

[RESEND v12 6/6] mm, oom, docs: describe the cgroup-aware OOM killer

Document the cgroup-aware OOM killer. Signed-off-by: Roman Gushchin Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Tetsuo Handa Cc: Andrew Morton

[RESEND v12 5/6] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer

Add a "groupoom" cgroup v2 mount option to enable the cgroup-aware OOM killer. If not set, the OOM selection is performed in a "traditional" per-process way. The behavior can be changed dynamically by remounting the cgroupfs. Signed-off-by: Roman Gushchin Cc: Michal Hocko

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On 19 October 2017 at 20:04, Ulf Hansson wrote: > On 19 October 2017 at 19:21, Grygorii Strashko > wrote: >> >> >> On 10/19/2017 03:33 AM, Ulf Hansson wrote: >>> On 18 October 2017 at 23:48, Rafael J. Wysocki wrote: On

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On 19 October 2017 at 19:21, Grygorii Strashko wrote: > > > On 10/19/2017 03:33 AM, Ulf Hansson wrote: >> On 18 October 2017 at 23:48, Rafael J. Wysocki wrote: >>> On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote: On

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[...] >>> > Say you want to leave the parent suspended after system resume, but the >>> > child drivers use pm_runtime_force_suspend|resume(). The parent would >>> > then >>> > need to use pm_runtime_force_suspend|resume() too, no? >>> >>> Actually no. >>> >>> Currently the other options of

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On 10/19/2017 03:33 AM, Ulf Hansson wrote: > On 18 October 2017 at 23:48, Rafael J. Wysocki wrote: >> On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote: >>> >>> On 10/18/2017 09:11 AM, Ulf Hansson wrote: >> >> [...] >> >> That's the point. We know

Re: [PATCH] kbuild doc: a bundle of fixes on makefiles.txt

2017-10-19 12:17 GMT+09:00 Cao jin : > It does several fixes: > 1. move the displaced ld example to its reasonale place. > 2. add new example for command gzip. > 3. fix 2 number errors. > 4. fix format of chapter 7.x, make it looks the same as other chapters. > >

Re: [PATCH v6 0/6] Add HiSilicon SoC uncore Performance Monitoring Unit driver

On Thu, Oct 19, 2017 at 04:28:35PM +0100, Will Deacon wrote: > On Thu, Oct 19, 2017 at 01:29:18PM +0100, Mark Rutland wrote: > > Will, are you happy to queue this? > > > > There's a minor fixup [1] needed in patch 2, but otherwise this looks > > good to me, and builds cleanly. > > > > I've

Re: [PATCH v6 0/6] Add HiSilicon SoC uncore Performance Monitoring Unit driver

On Thu, Oct 19, 2017 at 01:29:18PM +0100, Mark Rutland wrote: > Will, are you happy to queue this? > > There's a minor fixup [1] needed in patch 2, but otherwise this looks > good to me, and builds cleanly. > > I've pushed out a branch [2] with that fix folded in, in case that's > easier for

Re: [PATCH 1/2] mm, thp: introduce dedicated transparent huge page allocation interfaces

On Wed 18-10-17 19:00:26, Du, Changbin wrote: > Hi Hocko, > > On Tue, Oct 17, 2017 at 12:20:52PM +0200, Michal Hocko wrote: > > [CC Kirill] > > > > On Mon 16-10-17 17:19:16, changbin...@intel.com wrote: > > > From: Changbin Du > > > > > > This patch introduced 4 new

Re: [PATCH v6 0/6] Add HiSilicon SoC uncore Performance Monitoring Unit driver

Will, are you happy to queue this? There's a minor fixup [1] needed in patch 2, but otherwise this looks good to me, and builds cleanly. I've pushed out a branch [2] with that fix folded in, in case that's easier for you. Otherwise, feel free to pick these up with my Ack. Thanks, Mark. [1]

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On 19 October 2017 at 00:12, Rafael J. Wysocki wrote: > On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote: >> [...] >> >> >> >> >> The reason why pm_runtime_force_* needs to respects the hierarchy of >> >> the RPM callbacks, is because otherwise it can't safely

Re: kernel/module: Delete an error message for a failed memory allocation in add_module_usage()

On Thu, 2017-10-19 at 13:35 +0200, SF Markus Elfring wrote: > > > > > Omit an extra message for a memory allocation failure in this > > > > > function. > > > > > > > > > > This issue was detected by using the Coccinelle software. [] > > > Do you see any need that I should extend subsequent

Re: kernel/module: Delete an error message for a failed memory allocation in add_module_usage()

Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring >>> >>> Applied to modules-next, thanks. >> >> Thanks for your acceptance of this

Re: [PATCH v6 2/6] perf: hisi: Add support for HiSilicon SoC uncore PMU driver

On Thu, Oct 19, 2017 at 07:05:17PM +0800, Shaokun Zhang wrote: > This patch adds support HiSilicon SoC uncore PMU driver framework and > interfaces. > +static bool hisi_validate_event_group(struct perf_event *event) > +{ > + struct perf_event *sibling, *leader = event->group_leader; > +

Re: kernel/module: Delete an error message for a failed memory allocation in add_module_usage()

>> This is a small allocation so it can't fail in current kernels.  I can't >> imagine a situation where this could fail and it wasn't dead easy to >> debug.  Most modules are loaded at boot so it's not likely to fail, but >> if it did, it would be easy to reproduce.  If it's not loaded at boot >>

[PATCH v6 2/6] perf: hisi: Add support for HiSilicon SoC uncore PMU driver

This patch adds support HiSilicon SoC uncore PMU driver framework and interfaces. Reviewed-by: Jonathan Cameron Signed-off-by: Shaokun Zhang Signed-off-by: Anurup M --- drivers/perf/Kconfig | 7

[PATCH v6 3/6] perf: hisi: Add support for HiSilicon SoC L3C PMU driver

This patch adds support for L3C PMU driver in HiSilicon SoC chip, Each L3C has own control, counter and interrupt registers and is an separate PMU. For each L3C PMU, it has 8-programable counters and each counter is free-running. Interrupt is supported to handle counter (48-bits) overflow.

[PATCH v6 6/6] arm64: MAINTAINERS: hisi: Add HiSilicon SoC PMU support

Add support HiSilicon SoC uncore PMU driver. Signed-off-by: Shaokun Zhang --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a74227a..96c583c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6242,6 +6242,13 @@ S:

[PATCH v6 5/6] perf: hisi: Add support for HiSilicon SoC DDRC PMU driver

This patch adds support for DDRC PMU driver in HiSilicon SoC chip, Each DDRC has own control, counter and interrupt registers and is an separate PMU. For each DDRC PMU, it has 8-fixed-purpose counters which have been mapped to 8-events by hardware, it assumes that counter index is equal to event

[PATCH v6 4/6] perf: hisi: Add support for HiSilicon SoC HHA PMU driver

L3 cache coherence is maintained by Hydra Home Agent (HHA) in HiSilicon SoC. This patch adds support for HHA PMU driver, Each HHA has own control, counter and interrupt registers and is an separate PMU. For each HHA PMU, it has 16-programable counters and each counter is free-running. Interrupt is

[PATCH v6 0/6] Add HiSilicon SoC uncore Performance Monitoring Unit driver

This patchset adds support for HiSilicon SoC uncore PMUs driver. It includes L3C, Hydra Home Agent (HHA) and DDRC. Changes in v6: * remove redundant member hisi_pmu::oneline_cpus * rename member hisi_pmu::id * add event code check when event init * fix online/offline notifier for L3C/HHA/DDRC

[PATCH v6 1/6] Documentation: perf: hisi: Documentation for HiSilicon SoC PMU driver

This patch adds documentation for the uncore PMUs on HiSilicon SoC. Reviewed-by: Jonathan Cameron Signed-off-by: Shaokun Zhang Signed-off-by: Anurup M --- Documentation/perf/hisi-pmu.txt | 53

[PATCH 3/4] document: change the document for the extended movable_node

Add the document for the change of extended movable_node=nn[KMG]@ss[KMG]. Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Signed-off-by: Chao Fan --- Documentation/admin-guide/kernel-parameters.txt | 9 + 1 file changed, 9 insertions(+) diff

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On 18 October 2017 at 23:48, Rafael J. Wysocki wrote: > On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote: >> >> On 10/18/2017 09:11 AM, Ulf Hansson wrote: > > [...] > >> >>> That's the point. We know pm_runtime_force_* works nicely for the >> >>> trivial

Re: [Update][PATCH v2 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

On Thu, Oct 19, 2017 at 01:17:31AM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The motivation for this change is to provide a way to work around > a problem with the direct-complete mechanism used for avoiding > system suspend/resume handling for