[PATCH] devfreq: fix double call put_device

From: Cai Zhiyong Date: Sat, 14 May 2016 14:13:30 +0800 Subject: [PATCH] devfreq: fix double call put_device 1295 */ 1296 void device_unregister(struct device *dev) 1297 { 1298 pr_debug("device: '%s': %s\n", dev_name(dev), __func__); 1299 device_del(dev);

[PATCH] devfreq: fix double call put_device

From: Cai Zhiyong Date: Sat, 14 May 2016 14:13:30 +0800 Subject: [PATCH] devfreq: fix double call put_device 1295 */ 1296 void device_unregister(struct device *dev) 1297 { 1298 pr_debug("device: '%s': %s\n", dev_name(dev), __func__); 1299 device_del(dev); 1300

Re: [PATCH] mm/kasan/kasan.h: Fix boolean checking issue for kasan_report_enabled()

Hello all: Shall I send patch v2 for it? (if really need, please let me know, and I shall try). Default, I shall continue to try to find and send another patches for mm in "include/linux/*.h". Thanks. On 5/3/16 00:38, Chen Gang wrote: > On 5/3/16 00:23, Chen Gang wrote: >> On 5/2/16 23:35,

Re: [PATCH] mm/kasan/kasan.h: Fix boolean checking issue for kasan_report_enabled()

Hello all: Shall I send patch v2 for it? (if really need, please let me know, and I shall try). Default, I shall continue to try to find and send another patches for mm in "include/linux/*.h". Thanks. On 5/3/16 00:38, Chen Gang wrote: > On 5/3/16 00:23, Chen Gang wrote: >> On 5/2/16 23:35,

Re: [PATCH 1/4] signals/sigaltstack: If SS_AUTODISARM, bypass on_sig_stack

On May 8, 2016 7:05 PM, "Stas Sergeev" wrote: > > 09.05.2016 04:32, Andy Lutomirski пишет: > >> On May 7, 2016 7:38 AM, "Stas Sergeev" wrote: >>> >>> 03.05.2016 20:31, Andy Lutomirski пишет: >>> If a signal stack is set up with SS_AUTODISARM, then the kernel

Re: [PATCH 1/4] signals/sigaltstack: If SS_AUTODISARM, bypass on_sig_stack

On May 8, 2016 7:05 PM, "Stas Sergeev" wrote: > > 09.05.2016 04:32, Andy Lutomirski пишет: > >> On May 7, 2016 7:38 AM, "Stas Sergeev" wrote: >>> >>> 03.05.2016 20:31, Andy Lutomirski пишет: >>> If a signal stack is set up with SS_AUTODISARM, then the kernel inherently avoids

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On May 1, 2016 at 9:51 AM, Lnus Torvalds wrote: > On Sun, May 1, 2016 at 2:43 AM, George Spelvin wrote: >> * If you feel ambitious, add a 32-bit CONFIG_ARCH_HAS_SLOW_MULTIPLIER >> exception path. > Let's make that a separate worry, and just fix hash_64() first. > > In

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On May 1, 2016 at 9:51 AM, Lnus Torvalds wrote: > On Sun, May 1, 2016 at 2:43 AM, George Spelvin wrote: >> * If you feel ambitious, add a 32-bit CONFIG_ARCH_HAS_SLOW_MULTIPLIER >> exception path. > Let's make that a separate worry, and just fix hash_64() first. > > In particular, that means

Re: [PATCH 2/2] clk: rockchip: fix incorrect parent for rk3399's {c,g}pll_aclk_perihp_src

Hi Doug, On 2016年05月14日 04:10, Doug Anderson wrote: Hi, On Fri, May 13, 2016 at 11:42 AM, Brian Norris wrote: From: Xing Zheng There was a typo, swapping 'c' <--> 'g'. Signed-off-by: Xing Zheng Signed-off-by:

Re: [PATCH 2/2] clk: rockchip: fix incorrect parent for rk3399's {c,g}pll_aclk_perihp_src

Hi Doug, On 2016年05月14日 04:10, Doug Anderson wrote: Hi, On Fri, May 13, 2016 at 11:42 AM, Brian Norris wrote: From: Xing Zheng There was a typo, swapping 'c' <--> 'g'. Signed-off-by: Xing Zheng Signed-off-by: Brian Norris --- drivers/clk/rockchip/clk-rk3399.c | 4 ++-- 1 file

[PATCH v4 1/2] cgroup: make cgroup.procs permissions userns-aware

Instead of comparing the thread's euid to GLOBAL_ROOT_UID, use capabilities to check the additional privileges required to migrate processes between cgroups. In addition, add further permissions to cgroup namespaces where: * Both tasks are in the same cgroup namespace; and * The current task has

[PATCH v4 1/2] cgroup: make cgroup.procs permissions userns-aware

Instead of comparing the thread's euid to GLOBAL_ROOT_UID, use capabilities to check the additional privileges required to migrate processes between cgroups. In addition, add further permissions to cgroup namespaces where: * Both tasks are in the same cgroup namespace; and * The current task has

[PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces

This is an updated (and rewritten) version of v3 of this patchset[1]. The main difference is that I changed how we the "allow management" is implemented. Rather than just chmod-ing the cgroup directory (which everyone agreed was quite an odd way of doing it), unshare(CLONE_NEWCGROUP) will create

[PATCH v4 2/2] cgroup: implement subtree creation on copy_cgroup_ns()

Allow unprivileged processes to control subtrees of their associated processes, a necessary feature if a rootless container wishes to take advantage of cgroups for its own processes. As cgroups are hierarchical, having the ability to set limits in a subtree does not preclude the ability to modify

[PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces

This is an updated (and rewritten) version of v3 of this patchset[1]. The main difference is that I changed how we the "allow management" is implemented. Rather than just chmod-ing the cgroup directory (which everyone agreed was quite an odd way of doing it), unshare(CLONE_NEWCGROUP) will create

[PATCH v4 2/2] cgroup: implement subtree creation on copy_cgroup_ns()

Allow unprivileged processes to control subtrees of their associated processes, a necessary feature if a rootless container wishes to take advantage of cgroups for its own processes. As cgroups are hierarchical, having the ability to set limits in a subtree does not preclude the ability to modify

Re: [PATCH v4] usb: dwc2: fix regression on big-endian PowerPC/ARM systems

On 5/13/2016 6:53 AM, Arnd Bergmann wrote: > A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq > MIPS system unfortunately broke big-endian operation on PowerPC > APM82181 as reported by Christian Lamparter, and likely other > systems. > > It actually introduced multiple issues:

Re: [RFC PATCH 2/2] Documentation: devictree: Add macb mdio bindings

HI Andrew, On Fri, May 13, 2016 at 11:13 PM, Andrew Lunn wrote: > Hi Harini > > Is this backward compatible? Will devices using the old binding still > work? It isn't right now. I will have to assign the bus read/write functions conditionally in order to do that - I'll see if I

Re: [PATCH v4] usb: dwc2: fix regression on big-endian PowerPC/ARM systems

On 5/13/2016 6:53 AM, Arnd Bergmann wrote: > A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq > MIPS system unfortunately broke big-endian operation on PowerPC > APM82181 as reported by Christian Lamparter, and likely other > systems. > > It actually introduced multiple issues:

Re: [RFC PATCH 2/2] Documentation: devictree: Add macb mdio bindings

HI Andrew, On Fri, May 13, 2016 at 11:13 PM, Andrew Lunn wrote: > Hi Harini > > Is this backward compatible? Will devices using the old binding still > work? It isn't right now. I will have to assign the bus read/write functions conditionally in order to do that - I'll see if I can make it

Re: [PATCH] zram: introduce per-device debug_stat sysfs node

On (05/14/16 08:08), Minchan Kim wrote: [..] > Fortunately, Andrew isn't pick up this patch yet so I want to replace > it to below suggested by Sergey which is better. [..] > > + atomic64_inc(>stats.writestall); looks good to me. thanks! -ss

Re: [PATCH] zram: introduce per-device debug_stat sysfs node

On (05/14/16 08:08), Minchan Kim wrote: [..] > Fortunately, Andrew isn't pick up this patch yet so I want to replace > it to below suggested by Sergey which is better. [..] > > + atomic64_inc(>stats.writestall); looks good to me. thanks! -ss

Re: [PATCH] zram: introduce per-device debug_stat sysfs node

Hello Minchan, On (05/14/16 08:05), Minchan Kim wrote: [..] > > recompress: > > compress > > handle = zs_malloc FAST PATH > > > > if (!handle) { > > release stream > > handle = zs_malloc SLOW PATH > > > > << my patch accounts SLOW PATH here >> > >

Re: [PATCH] zram: introduce per-device debug_stat sysfs node

Hello Minchan, On (05/14/16 08:05), Minchan Kim wrote: [..] > > recompress: > > compress > > handle = zs_malloc FAST PATH > > > > if (!handle) { > > release stream > > handle = zs_malloc SLOW PATH > > > > << my patch accounts SLOW PATH here >> > >

[PATCH 3/8] perf/x86/intel: Add Top Down events to Intel Core

From: Andi Kleen Add declarations for the events needed for TopDown to the Intel big core CPUs starting with Sandy Bridge. We need to report different values if HyperThreading is on or off. The only thing this patch does is to export some events in sysfs. TopDown level 1

[PATCH 3/8] perf/x86/intel: Add Top Down events to Intel Core

From: Andi Kleen Add declarations for the events needed for TopDown to the Intel big core CPUs starting with Sandy Bridge. We need to report different values if HyperThreading is on or off. The only thing this patch does is to export some events in sysfs. TopDown level 1 uses a set of

[PATCH 4/8] perf/x86/intel: Add Top Down events to Intel Atom

From: Andi Kleen Add topdown event declarations to Silvermont / Airmont. These cores do not support the full Top Down metrics, but an useful subset (FrontendBound, Retiring, Backend Bound/Bad Speculation). The perf stat tool automatically handles the missing events and

Add top down metrics to perf stat

Note to reviewers: includes both tools and kernel patches. The kernel patches are at the beginning. [v2: Address review feedback. Metrics are now always printed, but colored when crossing threshold. --topdown implies --metric-only. Various smaller fixes, see individual patches] [v3: Add

[PATCH 4/8] perf/x86/intel: Add Top Down events to Intel Atom

From: Andi Kleen Add topdown event declarations to Silvermont / Airmont. These cores do not support the full Top Down metrics, but an useful subset (FrontendBound, Retiring, Backend Bound/Bad Speculation). The perf stat tool automatically handles the missing events and combines the available

Add top down metrics to perf stat

Note to reviewers: includes both tools and kernel patches. The kernel patches are at the beginning. [v2: Address review feedback. Metrics are now always printed, but colored when crossing threshold. --topdown implies --metric-only. Various smaller fixes, see individual patches] [v3: Add

[PATCH 1/8] x86/topology: Add topology_max_smt_threads()

From: Andi Kleen For SMT specific workarounds it is useful to know if SMT is active on any online CPU in the system. This currently requires a loop over all online CPUs. Add a global variable that is updated with the maximum number of smt threads on any CPU on

[PATCH 7/8] perf stat: Basic support for TopDown in perf stat

From: Andi Kleen Add basic plumbing for TopDown in perf stat Add a new --topdown options to enable events. When --topdown is specified set up events for all topdown events supported by the kernel. Add topdown-* as a special case to the event parser, as is needed for all

[PATCH 6/8] perf stat: Avoid fractional digits for integer scales

From: Andi Kleen When the scaling factor is a full integer don't display fractional digits. This avoids unnecessary .00 output for topdown metrics with scale factors. v2: Remove redundant check. Signed-off-by: Andi Kleen ---

[PATCH 5/8] perf/x86/intel: Use new topology_max_smt_threads() in HT leak workaround

From: Andi Kleen Now that we have topology_max_smt_threads() use it to detect the HT workarounds for older CPUs. v2: Use topology_max_smt_threads() Signed-off-by: Andi Kleen --- arch/x86/events/intel/core.c | 6 ++ 1 file changed, 2

[PATCH 7/8] perf stat: Basic support for TopDown in perf stat

From: Andi Kleen Add basic plumbing for TopDown in perf stat Add a new --topdown options to enable events. When --topdown is specified set up events for all topdown events supported by the kernel. Add topdown-* as a special case to the event parser, as is needed for all events containing -.

[PATCH 6/8] perf stat: Avoid fractional digits for integer scales

From: Andi Kleen When the scaling factor is a full integer don't display fractional digits. This avoids unnecessary .00 output for topdown metrics with scale factors. v2: Remove redundant check. Signed-off-by: Andi Kleen --- tools/perf/builtin-stat.c | 7 --- 1 file changed, 4

[PATCH 5/8] perf/x86/intel: Use new topology_max_smt_threads() in HT leak workaround

From: Andi Kleen Now that we have topology_max_smt_threads() use it to detect the HT workarounds for older CPUs. v2: Use topology_max_smt_threads() Signed-off-by: Andi Kleen --- arch/x86/events/intel/core.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

[PATCH 1/8] x86/topology: Add topology_max_smt_threads()

From: Andi Kleen For SMT specific workarounds it is useful to know if SMT is active on any online CPU in the system. This currently requires a loop over all online CPUs. Add a global variable that is updated with the maximum number of smt threads on any CPU on online/offline, and use it for

[PATCH 2/8] perf/x86: Support sysfs files depending on SMT status

From: Andi Kleen Add a way to show different sysfs events attributes depending on HyperThreading is on or off. This is difficult to determine early at boot, so we just do it dynamically when the sysfs attribute is read. v2: Compute HT status only once in CPU online/offline

[PATCH 8/8] perf stat: Add computation of TopDown formulas

From: Andi Kleen Implement the TopDown formulas in perf stat. The topdown basic metrics reported by the kernel are collected, and the formulas are computed and output as normal metrics. See the kernel commit exporting the events for details on the used metrics. v2: Always

[PATCH 2/8] perf/x86: Support sysfs files depending on SMT status

From: Andi Kleen Add a way to show different sysfs events attributes depending on HyperThreading is on or off. This is difficult to determine early at boot, so we just do it dynamically when the sysfs attribute is read. v2: Compute HT status only once in CPU online/offline hooks. v3: Use

[PATCH 8/8] perf stat: Add computation of TopDown formulas

From: Andi Kleen Implement the TopDown formulas in perf stat. The topdown basic metrics reported by the kernel are collected, and the formulas are computed and output as normal metrics. See the kernel commit exporting the events for details on the used metrics. v2: Always print all metrics,

Re: [PATCH net] net: dsa: mv88e6xxx: remove bridge work

Hi David, Vivien Didelot writes: > Now that the bridge code defers the switchdev port state setting, there > is no need to defer the port STP state change within the mv88e6xxx code. > Thus get rid of the driver's bridge work code. > > This also fixes a race

Re: [PATCH net] net: dsa: mv88e6xxx: remove bridge work

Hi David, Vivien Didelot writes: > Now that the bridge code defers the switchdev port state setting, there > is no need to defer the port STP state change within the mv88e6xxx code. > Thus get rid of the driver's bridge work code. > > This also fixes a race condition where the DSA layer assumes

Re: [PATCH 3/5] thermal: x86_pkg_temp: Handle the FROZEN hot plug notifier actions.

On Fri, 2016-03-18 at 22:26 +0100, Richard Cochran wrote: > When performing a suspend operation, the kernel brings all of the > non-boot CPUs offline, calling the hot plug notifiers with the flag, > CPU_TASKS_FROZEN, set in the action code.  Similarly, during resume, > the CPUs are brought back

Re: [PATCH 3/5] thermal: x86_pkg_temp: Handle the FROZEN hot plug notifier actions.

On Fri, 2016-03-18 at 22:26 +0100, Richard Cochran wrote: > When performing a suspend operation, the kernel brings all of the > non-boot CPUs offline, calling the hot plug notifiers with the flag, > CPU_TASKS_FROZEN, set in the action code.  Similarly, during resume, > the CPUs are brought back

[PATCH net] net: dsa: mv88e6xxx: remove bridge work

Now that the bridge code defers the switchdev port state setting, there is no need to defer the port STP state change within the mv88e6xxx code. Thus get rid of the driver's bridge work code. This also fixes a race condition where the DSA layer assumes that the bridge code already set the

[PATCH net] net: dsa: mv88e6xxx: remove bridge work

Now that the bridge code defers the switchdev port state setting, there is no need to defer the port STP state change within the mv88e6xxx code. Thus get rid of the driver's bridge work code. This also fixes a race condition where the DSA layer assumes that the bridge code already set the

[PATCH] kconfig/merge_config.sh: add -C to choose make dir

This is useful for running the script from somewhere besides the root of the source tree. Signed-off-by: Martin Kelly --- scripts/kconfig/merge_config.sh | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/scripts/kconfig/merge_config.sh

[PATCH] kconfig/merge_config.sh: add -C to choose make dir

This is useful for running the script from somewhere besides the root of the source tree. Signed-off-by: Martin Kelly --- scripts/kconfig/merge_config.sh | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/scripts/kconfig/merge_config.sh

Re: [Patch v5 6/8] firmware: qcom: scm: Add support for ARM64 SoCs

On Thu 12 May 20:46 PDT 2016, Andy Gross wrote: > From: Kumar Gala > > Add an implementation of the SCM interface that works on ARM64 SoCs. This > is used by things like determine if we have HDCP support or not on the > system. > > Signed-off-by: Kumar Gala

Re: [Patch v5 6/8] firmware: qcom: scm: Add support for ARM64 SoCs

On Thu 12 May 20:46 PDT 2016, Andy Gross wrote: > From: Kumar Gala > > Add an implementation of the SCM interface that works on ARM64 SoCs. This > is used by things like determine if we have HDCP support or not on the > system. > > Signed-off-by: Kumar Gala > Signed-off-by: Andy Gross

Re: [Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

On Thu 12 May 20:46 PDT 2016, Andy Gross wrote: > This patch converts the Qualcomm SCM driver to use the streaming DMA APIs > for communication buffers. > > Signed-off-by: Andy Gross > --- > drivers/firmware/qcom_scm-32.c | 189 >

Re: [Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

On Thu 12 May 20:46 PDT 2016, Andy Gross wrote: > This patch converts the Qualcomm SCM driver to use the streaming DMA APIs > for communication buffers. > > Signed-off-by: Andy Gross > --- > drivers/firmware/qcom_scm-32.c | 189 > +++-- >

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Fri, May 13, 2016 at 11:56:12PM +0300, Sergei Shtylyov wrote: > On 05/13/2016 11:44 PM, Andrew Lunn wrote: > > >>>Another issue is that on some boards we have one reset line tied to > >>>multiple PHYs.How do we prevent multiple resets being taking place when > >>>each of > >>>the PHYs are

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Fri, May 13, 2016 at 11:56:12PM +0300, Sergei Shtylyov wrote: > On 05/13/2016 11:44 PM, Andrew Lunn wrote: > > >>>Another issue is that on some boards we have one reset line tied to > >>>multiple PHYs.How do we prevent multiple resets being taking place when > >>>each of > >>>the PHYs are

[RFC PATCH] perf session: fixing uninitialised cpumode

The following patch[1] adds a new "cpumode" to the perf_sample structure that gets initialised as events are read from the data event file. With the advent of HW tracers and more specifically the decoding of the traces they generate, function perf_session__deliver_synth_event() gets called

[RFC PATCH] perf session: fixing uninitialised cpumode

The following patch[1] adds a new "cpumode" to the perf_sample structure that gets initialised as events are read from the data event file. With the advent of HW tracers and more specifically the decoding of the traces they generate, function perf_session__deliver_synth_event() gets called

Re: [Patch v5 3/8] firmware: qcom: scm: Use atomic SCM for cold boot

On Thu 12 May 20:46 PDT 2016, Andy Gross wrote: > This patch changes the cold_set_boot_addr function to use atomic SCM > calls. cold_set_boot_addr required adding qcom_scm_call_atomic2 to > support the two arguments going to the smc call. Using atomic removes > the need for memory allocation

Re: [Patch v5 3/8] firmware: qcom: scm: Use atomic SCM for cold boot

On Thu 12 May 20:46 PDT 2016, Andy Gross wrote: > This patch changes the cold_set_boot_addr function to use atomic SCM > calls. cold_set_boot_addr required adding qcom_scm_call_atomic2 to > support the two arguments going to the smc call. Using atomic removes > the need for memory allocation

Re: [Patch v5 2/8] firmware: qcom: scm: Convert SCM to platform driver

On Thu 12 May 20:46 PDT 2016, Andy Gross wrote: > This patch converts the Qualcomm SCM firmware driver into a platform > driver. > > Signed-off-by: Andy Gross Acked-by: Bjorn Andersson Regards, Bjorn

Re: [Patch v5 2/8] firmware: qcom: scm: Convert SCM to platform driver

On Thu 12 May 20:46 PDT 2016, Andy Gross wrote: > This patch converts the Qualcomm SCM firmware driver into a platform > driver. > > Signed-off-by: Andy Gross Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH RESEND v5 6/6] crypto: AF_ALG - add support for key_id

Tadeusz - David updated the keys-asym-keyctl branch, and this patch set won't build any more. On Thu, 5 May 2016, Tadeusz Struk wrote: diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c index e00793d..f486b6d 100644 --- a/crypto/algif_akcipher.c +++ b/crypto/algif_akcipher.c

Re: [PATCH RESEND v5 6/6] crypto: AF_ALG - add support for key_id

Tadeusz - David updated the keys-asym-keyctl branch, and this patch set won't build any more. On Thu, 5 May 2016, Tadeusz Struk wrote: diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c index e00793d..f486b6d 100644 --- a/crypto/algif_akcipher.c +++ b/crypto/algif_akcipher.c

Re: [Patch v5 1/8] dt/bindings: firmware: Add Qualcomm SCM binding

On Thu 12 May 20:46 PDT 2016, Andy Gross wrote: > This patch adds the device tree support for the Qualcomm SCM firmware. > > Signed-off-by: Andy Gross Acked-by: Bjorn Andersson Regards, Bjorn

Re: [Patch v5 1/8] dt/bindings: firmware: Add Qualcomm SCM binding

On Thu 12 May 20:46 PDT 2016, Andy Gross wrote: > This patch adds the device tree support for the Qualcomm SCM firmware. > > Signed-off-by: Andy Gross Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH] zram: introduce per-device debug_stat sysfs node

On Fri, May 13, 2016 at 10:03:58PM +0900, Sergey Senozhatsky wrote: > debug_stat sysfs is read-only and represents various debugging > data that zram developers may need. This file is not meant to be > used by anyone else: its content is not documented and will change > any time w/o any notice.

Re: [PATCH] zram: introduce per-device debug_stat sysfs node

On Fri, May 13, 2016 at 10:03:58PM +0900, Sergey Senozhatsky wrote: > debug_stat sysfs is read-only and represents various debugging > data that zram developers may need. This file is not meant to be > used by anyone else: its content is not documented and will change > any time w/o any notice.

Re: [PATCH] zram: introduce per-device debug_stat sysfs node

Hello Sergey, On Fri, May 13, 2016 at 05:06:43PM +0900, Sergey Senozhatsky wrote: > On (05/13/16 16:20), Minchan Kim wrote: > > > > > @@ -737,12 +737,12 @@ static int zram_bvec_write(struct zram *zram, > > > > > struct bio_vec *bvec, u32 index, > > > > >

Re: [PATCH] zram: introduce per-device debug_stat sysfs node

Hello Sergey, On Fri, May 13, 2016 at 05:06:43PM +0900, Sergey Senozhatsky wrote: > On (05/13/16 16:20), Minchan Kim wrote: > > > > > @@ -737,12 +737,12 @@ static int zram_bvec_write(struct zram *zram, > > > > > struct bio_vec *bvec, u32 index, > > > > >

[PATCH 5/5] cpufreq: governor: Get rid of governor events

From: Rafael J. Wysocki The design of the cpufreq governor API is not very straightforward, as struct cpufreq_governor provides only one callback to be invoked from different code paths for different purposes. The purpose it is invoked for is determined by its second

[PATCH] megaraid: fix error code check of register_chrdev()

There is invalid error code check of register_chrdev() in megaraid_init(). register_chrdev() returns negative code in case of error, as a result current code can try to unregister_chrdev() with error code instead of major that may lead to unregistering somebody else's chardev. Found by Linux

[PATCH] megaraid: fix error code check of register_chrdev()

There is invalid error code check of register_chrdev() in megaraid_init(). register_chrdev() returns negative code in case of error, as a result current code can try to unregister_chrdev() with error code instead of major that may lead to unregistering somebody else's chardev. Found by Linux

[PATCH 5/5] cpufreq: governor: Get rid of governor events

From: Rafael J. Wysocki The design of the cpufreq governor API is not very straightforward, as struct cpufreq_governor provides only one callback to be invoked from different code paths for different purposes. The purpose it is invoked for is determined by its second "event" argument, causing

[PATCH 1/5] cpufreq: governor: CPUFREQ_GOV_LIMITS never fails

From: Rafael J. Wysocki None of the cpufreq governors currently in the tree will ever fail an invocation of the ->governor() callback with the event argument equal to CPUFREQ_GOV_LIMITS (unless invoked with incorrect arguments which doesn't matter anyway) and had it

[PATCH 3/5] cpufreq: governor: Simplify performance and powersave governors

From: Rafael J. Wysocki The performance and powersave cpufreq governors handle the CPUFREQ_GOV_START event in the same way as CPUFREQ_GOV_LIMITS. However, the cpufreq core always invokes cpufreq_governor() with the event argument equal to CPUFREQ_GOV_LIMITS right

[PATCH 4/5] cpufreq: Split cpufreq_governor() into simpler functions

From: Rafael J. Wysocki The cpufreq_governor() routine is used by the cpufreq core to invoke the current governor's ->governor() callback with appropriate arguments and do some housekeeping related to that. Unfortunately, the way it mixes different governor events in

[PATCH 1/5] cpufreq: governor: CPUFREQ_GOV_LIMITS never fails

From: Rafael J. Wysocki None of the cpufreq governors currently in the tree will ever fail an invocation of the ->governor() callback with the event argument equal to CPUFREQ_GOV_LIMITS (unless invoked with incorrect arguments which doesn't matter anyway) and had it ever failed, the result of it

[PATCH 3/5] cpufreq: governor: Simplify performance and powersave governors

From: Rafael J. Wysocki The performance and powersave cpufreq governors handle the CPUFREQ_GOV_START event in the same way as CPUFREQ_GOV_LIMITS. However, the cpufreq core always invokes cpufreq_governor() with the event argument equal to CPUFREQ_GOV_LIMITS right after invoking it with event

[PATCH 4/5] cpufreq: Split cpufreq_governor() into simpler functions

From: Rafael J. Wysocki The cpufreq_governor() routine is used by the cpufreq core to invoke the current governor's ->governor() callback with appropriate arguments and do some housekeeping related to that. Unfortunately, the way it mixes different governor events in one code path makes it

[PATCH 2/5] cpufreq: governor: Check transition latecy at init time only

From: Rafael J. Wysocki It is not necessary to check the governor's max_transition_latency attribute every time cpufreq_governor() runs, so check it only if the event argument is CPUFREQ_GOV_POLICY_INIT. Signed-off-by: Rafael J. Wysocki

Re: [PATCH 00/10]block-throttle: add low/high limit

On Fri, May 13, 2016 at 03:12:45PM -0400, Vivek Goyal wrote: > On Tue, May 10, 2016 at 05:16:30PM -0700, Shaohua Li wrote: > > Hi, > > > > This patch set adds low/high limit for blk-throttle cgroup. The interface is > > io.low and io.high. > > > > low limit implements best effort bandwidth/iops

[PATCH 2/5] cpufreq: governor: Check transition latecy at init time only

From: Rafael J. Wysocki It is not necessary to check the governor's max_transition_latency attribute every time cpufreq_governor() runs, so check it only if the event argument is CPUFREQ_GOV_POLICY_INIT. Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/cpufreq.c | 25

Re: [PATCH 00/10]block-throttle: add low/high limit

On Fri, May 13, 2016 at 03:12:45PM -0400, Vivek Goyal wrote: > On Tue, May 10, 2016 at 05:16:30PM -0700, Shaohua Li wrote: > > Hi, > > > > This patch set adds low/high limit for blk-throttle cgroup. The interface is > > io.low and io.high. > > > > low limit implements best effort bandwidth/iops

[PATCH 0/5] cpufreq: governor: Rework API to use callbacks instead of events

Hi, This series is on top of the current linux-next witn the following two patches applied: https://patchwork.kernel.org/patch/9080801/ https://patchwork.kernel.org/patch/9080791/ It cleans up a few things and then reworks the governor API to get rid of governor events and use callbacks

[PATCH 0/5] cpufreq: governor: Rework API to use callbacks instead of events

Hi, This series is on top of the current linux-next witn the following two patches applied: https://patchwork.kernel.org/patch/9080801/ https://patchwork.kernel.org/patch/9080791/ It cleans up a few things and then reworks the governor API to get rid of governor events and use callbacks

Re: [PATCH v4 3/3] ARM64: dts: rockchip: enable eMMC for rk3399 EVB

Hi, On Fri, May 13, 2016 at 3:12 PM, Brian Norris wrote: > Rockchip's rk3399 evaluation board has eMMC. Let's enable the > newly-added nodes. > > Signed-off-by: Brian Norris > --- > v4: > > * alphabetize references > > v3: > > * no change >

Re: [PATCH v4 3/3] ARM64: dts: rockchip: enable eMMC for rk3399 EVB

Hi, On Fri, May 13, 2016 at 3:12 PM, Brian Norris wrote: > Rockchip's rk3399 evaluation board has eMMC. Let's enable the > newly-added nodes. > > Signed-off-by: Brian Norris > --- > v4: > > * alphabetize references > > v3: > > * no change > > v2: > > * better commit description > >

Re: [PATCH v4 1/3] ARM64: dts: rockchip: make rk3399's grf a "simple-mfd"

Hi, On Fri, May 13, 2016 at 3:12 PM, Brian Norris wrote: > Per the examples in > Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt, we need the > grf node to be a simple-mfd in order to properly enumerate child devices > like our eMMC PHY. > > Signed-off-by:

Re: [PATCH v4 1/3] ARM64: dts: rockchip: make rk3399's grf a "simple-mfd"

Hi, On Fri, May 13, 2016 at 3:12 PM, Brian Norris wrote: > Per the examples in > Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt, we need the > grf node to be a simple-mfd in order to properly enumerate child devices > like our eMMC PHY. > > Signed-off-by: Brian Norris > --- > v4: >

Re: QRTR merge conflict resolution (was: Re: linux-next: build failure after merge of the net-next tree)

On 13 May 2016 at 17:19, Bjorn Andersson wrote: > On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote: > >> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote: > [..] >> > I assume we could have the QRTR go through Andy and arm-soc, with >> > David's approval and this

Re: QRTR merge conflict resolution (was: Re: linux-next: build failure after merge of the net-next tree)

On 13 May 2016 at 17:19, Bjorn Andersson wrote: > On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote: > >> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote: > [..] >> > I assume we could have the QRTR go through Andy and arm-soc, with >> > David's approval and this fix squashed in. But we're

Re: Additional compiler barrier required in sched_preempt_enable_no_resched?

On 5/13/2016 7:58 AM, Peter Zijlstra wrote: On Thu, May 12, 2016 at 11:39:47PM -0700, Vikram Mulukutla wrote: Hi, I came across a piece of engineering code that looked like: preempt_disable(); /* --cut, lots of code-- */ preempt_enable_no_resched(); put_user() preempt_disable(); (If you wish

Re: Additional compiler barrier required in sched_preempt_enable_no_resched?

On 5/13/2016 7:58 AM, Peter Zijlstra wrote: On Thu, May 12, 2016 at 11:39:47PM -0700, Vikram Mulukutla wrote: Hi, I came across a piece of engineering code that looked like: preempt_disable(); /* --cut, lots of code-- */ preempt_enable_no_resched(); put_user() preempt_disable(); (If you wish

Re: [PATCH v2 0/3] input: rmi4: Regulator supply support

On Thu 12 May 17:52 PDT 2016, Andrew Duggan wrote: > On 05/11/2016 08:05 PM, Bjorn Andersson wrote: > >On Wed 11 May 16:30 PDT 2016, Andrew Duggan wrote: > > > >>Hi Bjorn, > >> > >>On 05/10/2016 08:49 AM, Bjorn Andersson wrote: > >[..] > >>>So either we duplicate the regulator support in spi/i2c

Re: [PATCH v2 0/3] input: rmi4: Regulator supply support

On Thu 12 May 17:52 PDT 2016, Andrew Duggan wrote: > On 05/11/2016 08:05 PM, Bjorn Andersson wrote: > >On Wed 11 May 16:30 PDT 2016, Andrew Duggan wrote: > > > >>Hi Bjorn, > >> > >>On 05/10/2016 08:49 AM, Bjorn Andersson wrote: > >[..] > >>>So either we duplicate the regulator support in spi/i2c

Re: [PATCH 4/4] phy: rockchip-emmc: reindent the register definitions

Hi, On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote: > Some of the spacing was wrong (spaces instead of tabs), and due to > longer entries added later, the columns weren't aligned. Let's get > everything consistent. > > Signed-off-by: Brian Norris

Re: [PATCH 4/4] phy: rockchip-emmc: reindent the register definitions

Hi, On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote: > Some of the spacing was wrong (spaces instead of tabs), and due to > longer entries added later, the columns weren't aligned. Let's get > everything consistent. > > Signed-off-by: Brian Norris > --- > drivers/phy/phy-rockchip-emmc.c |

Re: [PATCH 3/4] phy: rockchip-emmc: configure default output tap delay

Hi, On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote: > The output tap delay controls helps maintain the hold requirements for > eMMC. The exact value is dependent on the SoC and other factors, though > it isn't really an exact science. But the default of 0 is not

Re: [PATCH 3/4] phy: rockchip-emmc: configure default output tap delay

Hi, On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote: > The output tap delay controls helps maintain the hold requirements for > eMMC. The exact value is dependent on the SoC and other factors, though > it isn't really an exact science. But the default of 0 is not very good, > as it doesn't

  1   2   3   4   5   6   7   8   9   10   >