[PATCH v2 0/7] of_graph: prepare for ALSA graph support

Hi Rob These are v2 of of_graph patch-set Now OF graph is mainly used by V4L2 SoC, and ALSA SoC is using different style for SoC <-> Codec binding. But, for example, HDMI case, V4L2 <-> ALSA need to collaborate, and then ALSA SoC needs to adjust to OF graph. OTOH, V4L2's "OF graph" position is

[PATCH v2 0/7] of_graph: prepare for ALSA graph support

Hi Rob These are v2 of of_graph patch-set Now OF graph is mainly used by V4L2 SoC, and ALSA SoC is using different style for SoC <-> Codec binding. But, for example, HDMI case, V4L2 <-> ALSA need to collaborate, and then ALSA SoC needs to adjust to OF graph. OTOH, V4L2's "OF graph" position is

[PATCH 2/2] net: ethernet: lpc_eth: use phy_ethtool_{get|set}_link_ksettings

There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/nxp/lpc_eth.c | 26 ++ 1 files changed, 2

[PATCH 2/2] net: ethernet: lpc_eth: use phy_ethtool_{get|set}_link_ksettings

There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/nxp/lpc_eth.c | 26 ++ 1 files changed, 2 insertions(+), 24 deletions(-)

Re: [PATCH v2] clk: Provide notifier stubs when !COMMON_CLK

On 06/28, Krzysztof Kozlowski wrote: > On Tue, Jun 28, 2016 at 10:26:53AM -0700, Stephen Boyd wrote: > > On 06/28, Krzysztof Kozlowski wrote: > > > The clk notifier symbols are hidden by COMMON_CLK. However on some > > > platforms HAVE_CLK might be set while COMMON_CLK not which leads to > > >

Re: [PATCH v2] clk: Provide notifier stubs when !COMMON_CLK

On 06/28, Krzysztof Kozlowski wrote: > On Tue, Jun 28, 2016 at 10:26:53AM -0700, Stephen Boyd wrote: > > On 06/28, Krzysztof Kozlowski wrote: > > > The clk notifier symbols are hidden by COMMON_CLK. However on some > > > platforms HAVE_CLK might be set while COMMON_CLK not which leads to > > >

Re: trace: use-after-free in hist_unreg_all

Hi Steve, On 06/28/2016 09:43 AM, Steven Rostedt wrote: > On Tue, 28 Jun 2016 14:58:50 +0200 > Dmitry Vyukov wrote: > >> Hello, >> >> While running tools/testing/selftests test suite with KASAN I hit the >> following use-after-free report: >> >> >> >>

Re: trace: use-after-free in hist_unreg_all

Hi Steve, On 06/28/2016 09:43 AM, Steven Rostedt wrote: > On Tue, 28 Jun 2016 14:58:50 +0200 > Dmitry Vyukov wrote: > >> Hello, >> >> While running tools/testing/selftests test suite with KASAN I hit the >> following use-after-free report: >> >> >> >>

Re: [kernel-hardening] Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 2016-06-28 at 18:07 -0400, valdis.kletni...@vt.edu wrote: > On Tue, 28 Jun 2016 14:49:15 -0700, Joe Perches said: > > > > > Another potentially useful plugin, especially for embedded systems, > > would be to compress any string literal marked with > > > >  

Re: [kernel-hardening] Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 2016-06-28 at 18:07 -0400, valdis.kletni...@vt.edu wrote: > On Tue, 28 Jun 2016 14:49:15 -0700, Joe Perches said: > > > > > Another potentially useful plugin, especially for embedded systems, > > would be to compress any string literal marked with > > > >  

Re: [PATCH] power: qcom_smbb: Make an extcon for usb cable detection

Hi, On Sat, Jun 25, 2016 at 10:54:37PM -0700, Stephen Boyd wrote: > On these PMICs the usb cable connection/disconnection is > indicated by the usb-valid interrupt being high or low > respectively. Let's make an extcon for that, so we can notify usb > drivers of the cable state. > > Cc: Bjorn

Re: [PATCH] power: qcom_smbb: Make an extcon for usb cable detection

Hi, On Sat, Jun 25, 2016 at 10:54:37PM -0700, Stephen Boyd wrote: > On these PMICs the usb cable connection/disconnection is > indicated by the usb-valid interrupt being high or low > respectively. Let's make an extcon for that, so we can notify usb > drivers of the cable state. > > Cc: Bjorn

Re: [PATCH V3] tracing: Make latency tracers fully support the set_graph_notrace

- Original Message - > From: "Steven Rostedt" > To: "Chunyu Hu" > Cc: "Namhyung Kim" , "LKML" > Sent: Wednesday, June 29, 2016 4:03:33 AM > Subject: Re: [PATCH V3] tracing: Make latency tracers

Re: [PATCH V3] tracing: Make latency tracers fully support the set_graph_notrace

- Original Message - > From: "Steven Rostedt" > To: "Chunyu Hu" > Cc: "Namhyung Kim" , "LKML" > Sent: Wednesday, June 29, 2016 4:03:33 AM > Subject: Re: [PATCH V3] tracing: Make latency tracers fully support the > set_graph_notrace > > On Tue, 28 Jun 2016 04:03:12 -0400 (EDT) >

Re: [RFC/PATCH v2] ftrace: Reduce size of function graph entries

On Tue, 28 Jun 2016 14:30:40 +0900 Namhyung Kim wrote: > Currently ftrace_graph_ent{,_entry} and ftrace_graph_ret{,_entry} struct > can have padding bytes at the end due to alignment in 64-bit data type. > As these data are recorded so frequently, those paddings waste >

Re: [RFC/PATCH v2] ftrace: Reduce size of function graph entries

On Tue, 28 Jun 2016 14:30:40 +0900 Namhyung Kim wrote: > Currently ftrace_graph_ent{,_entry} and ftrace_graph_ret{,_entry} struct > can have padding bytes at the end due to alignment in 64-bit data type. > As these data are recorded so frequently, those paddings waste > non-negligible space. As

[RFC][PATCH] tracing: Add trace_printk_ptr() to force non use of trace_bprintk()

trace_printk() is a very helpful tool for debugging the kernel. It adds lots of tricks to optimize itself to prevent any "heisenbugs". That is, having the addition of tracing cause the bug to change its timing and disappear. One of this tricks is to use trace_bprintk() when possible, which just

[RFC][PATCH] tracing: Add trace_printk_ptr() to force non use of trace_bprintk()

trace_printk() is a very helpful tool for debugging the kernel. It adds lots of tricks to optimize itself to prevent any "heisenbugs". That is, having the addition of tracing cause the bug to change its timing and disappear. One of this tricks is to use trace_bprintk() when possible, which just

Kernel v4.7-rc5 - performance degradation upto 40% after disabling and re-enabling a core

Hello, on NUMA enabled server equipped with 4 Intel E5-4610 v2 CPUs we observe following performance degradation: Runtime to run "lu.C.x" test from NAS Parallel Benchmarks after booting the kernel: real 1m57.834s user 113m51.520s Then we disable and re-enable one core: echo 0 >

Kernel v4.7-rc5 - performance degradation upto 40% after disabling and re-enabling a core

Hello, on NUMA enabled server equipped with 4 Intel E5-4610 v2 CPUs we observe following performance degradation: Runtime to run "lu.C.x" test from NAS Parallel Benchmarks after booting the kernel: real 1m57.834s user 113m51.520s Then we disable and re-enable one core: echo 0 >

Re: [PATCH v5 0/7] max8903: Add device tree support and misc fixes

Hi Sebastian, Sorry about the extra dtsi file, I accidentally included it in the v5 patch set (wasn't in <= v4). Thanks, Chris On 29/06/2016 4:16 AM, Sebastian Reichel wrote: Hi Chris, On Fri, Jun 24, 2016 at 12:26:05PM +1000, Chris Lapa wrote: This patch set adds device tree support for

Re: [PATCH v5 0/7] max8903: Add device tree support and misc fixes

Hi Sebastian, Sorry about the extra dtsi file, I accidentally included it in the v5 patch set (wasn't in <= v4). Thanks, Chris On 29/06/2016 4:16 AM, Sebastian Reichel wrote: Hi Chris, On Fri, Jun 24, 2016 at 12:26:05PM +1000, Chris Lapa wrote: This patch set adds device tree support for

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On 06/28, Andy Lutomirski wrote: > > On Tue, Jun 28, 2016 at 1:12 PM, Oleg Nesterov wrote: > > > > So please forget unless you see another reason for this change. > > > > But I might need to that anyway for procfs to read the the stack, > right? Do you see another way to handle

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On 06/28, Andy Lutomirski wrote: > > On Tue, Jun 28, 2016 at 1:12 PM, Oleg Nesterov wrote: > > > > So please forget unless you see another reason for this change. > > > > But I might need to that anyway for procfs to read the the stack, > right? Do you see another way to handle that case? Well,

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On 06/28, Linus Torvalds wrote: > > Then try_get_task_stack(tsk) becomes > > void *try_get_task_stack(struct task_struct *tsk) > { > void *stack = tsk->stack; > if (!atomic_inc_not_zero(>stackref)) >stack = NULL; > return stack; > }

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On 06/28, Linus Torvalds wrote: > > Then try_get_task_stack(tsk) becomes > > void *try_get_task_stack(struct task_struct *tsk) > { > void *stack = tsk->stack; > if (!atomic_inc_not_zero(>stackref)) >stack = NULL; > return stack; > }

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

2016-06-29 4:07 GMT+08:00 Paolo Bonzini : > > > On 28/06/2016 20:34, yunhong jiang wrote: >> Paolo, thanks for reply. >> >> Which race window you are talking about? Is it the >> kvm_lapic_switch_to_hv_timer()? If yes, hope we will not forgot it once the >> lapic timer is not

Re: [PATCH] KVM: vmx: fix underflow in TSC deadline calculation

2016-06-29 4:07 GMT+08:00 Paolo Bonzini : > > > On 28/06/2016 20:34, yunhong jiang wrote: >> Paolo, thanks for reply. >> >> Which race window you are talking about? Is it the >> kvm_lapic_switch_to_hv_timer()? If yes, hope we will not forgot it once the >> lapic timer is not pinned anymore in

Re: [Cluster-devel] [PATCH 2/2] GFS2: Add a gfs2-specific prune_icache_sb

On Tue, Jun 28, 2016 at 10:13:32AM +0100, Steven Whitehouse wrote: > Hi, > > On 28/06/16 03:08, Dave Chinner wrote: > >On Fri, Jun 24, 2016 at 02:50:11PM -0500, Bob Peterson wrote: > >>This patch adds a new prune_icache_sb function for the VFS slab > >>shrinker to call. Trying to directly free

Re: [Cluster-devel] [PATCH 2/2] GFS2: Add a gfs2-specific prune_icache_sb

On Tue, Jun 28, 2016 at 10:13:32AM +0100, Steven Whitehouse wrote: > Hi, > > On 28/06/16 03:08, Dave Chinner wrote: > >On Fri, Jun 24, 2016 at 02:50:11PM -0500, Bob Peterson wrote: > >>This patch adds a new prune_icache_sb function for the VFS slab > >>shrinker to call. Trying to directly free

[PATCH v2 1/2] ARM: PIE infrastructure

Add support for embedding position independent executables (PIE) in the kernel. Those PIEs can then be loaded into memory allocated using genalloc. For example, this allows running code from SRAM which is usually needed for suspend/resume or to change the DDR timings. That code is usually written

[PATCH v2 0/2] Embedding Position Independent Executables

Hi, This series introduces Position Independent Executables (PIEs) for the ARM architecture. The main goal is to avoid having to write low level code in assembly as this is currently the case for suspend/resume. Multiple platforms will benefit from this infrastructure: at91, rockchip, sunxi,

[PATCH v2 1/2] ARM: PIE infrastructure

Add support for embedding position independent executables (PIE) in the kernel. Those PIEs can then be loaded into memory allocated using genalloc. For example, this allows running code from SRAM which is usually needed for suspend/resume or to change the DDR timings. That code is usually written

[PATCH v2 0/2] Embedding Position Independent Executables

Hi, This series introduces Position Independent Executables (PIEs) for the ARM architecture. The main goal is to avoid having to write low level code in assembly as this is currently the case for suspend/resume. Multiple platforms will benefit from this infrastructure: at91, rockchip, sunxi,

[PATCH v2 2/2] ARM: at91: pm: switch to the PIE infrastructure

Using the PIE infrastructure allows to write the whole suspend/resume functions in C instead of assembly. The only remaining assembly instruction is wfi for armv5 It makes the code shorter and clearer. Signed-off-by: Alexandre Belloni ---

[PATCH v2 2/2] ARM: at91: pm: switch to the PIE infrastructure

Using the PIE infrastructure allows to write the whole suspend/resume functions in C instead of assembly. The only remaining assembly instruction is wfi for armv5 It makes the code shorter and clearer. Signed-off-by: Alexandre Belloni --- arch/arm/mach-at91/Kconfig | 1 +

Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute

On Tue, Jun 28 2016, "PaX Team" wrote: > On 28 Jun 2016 at 22:50, Rasmus Villemoes wrote: > >> > +extern const char *kstrdup_const(const char *s, gfp_t gfp) __nocapture(1); >> >> OK, so this one is pretty dangerous, and probably wrong. If one does >> >> foo->bar =

Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute

On Tue, Jun 28 2016, "PaX Team" wrote: > On 28 Jun 2016 at 22:50, Rasmus Villemoes wrote: > >> > +extern const char *kstrdup_const(const char *s, gfp_t gfp) __nocapture(1); >> >> OK, so this one is pretty dangerous, and probably wrong. If one does >> >> foo->bar =

Re: [PATCH 1/2] arm: dts: bcm5301x: Add syscon based reboot in DT

On Tue, Jun 28, 2016 at 6:13 PM, Scott Branden wrote: > > > On 16-06-28 03:10 PM, Jon Mason wrote: >> >> From: Jon Mason >> >> Add the ability to reboot via a reset of the processor. This is >> achieved via a write of 0x39 to the CRU Reset

Re: [PATCH 1/2] arm: dts: bcm5301x: Add syscon based reboot in DT

On Tue, Jun 28, 2016 at 6:13 PM, Scott Branden wrote: > > > On 16-06-28 03:10 PM, Jon Mason wrote: >> >> From: Jon Mason >> >> Add the ability to reboot via a reset of the processor. This is >> achieved via a write of 0x39 to the CRU Reset Register. Unfortunately, >> this only resets the core

Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer.

Am Donnerstag, 23 Juni 2016, 10:25:06 schrieb Dave Young: > On 06/22/16 at 08:30pm, Thiago Jung Bauermann wrote: > > Am Mittwoch, 22 Juni 2016, 18:20:47 schrieb Dave Young: > > > The patch looks good, but could the subject be more specific? > > > > > > For example just like the first sentence of

Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer.

Am Donnerstag, 23 Juni 2016, 10:25:06 schrieb Dave Young: > On 06/22/16 at 08:30pm, Thiago Jung Bauermann wrote: > > Am Mittwoch, 22 Juni 2016, 18:20:47 schrieb Dave Young: > > > The patch looks good, but could the subject be more specific? > > > > > > For example just like the first sentence of

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

Am Dienstag, 28 Juni 2016, 15:20:55 schrieb Dave Young: > On 06/27/16 at 04:21pm, Dave Young wrote: > > Please ignore previous reply, I mistakenly send a broken mail without > > subject, sorry about it. Resend the reply here. > > > > On 06/27/16 at 01:37pm, Thiago Jung Bauermann wrote: > > > Am

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

Am Dienstag, 28 Juni 2016, 15:20:55 schrieb Dave Young: > On 06/27/16 at 04:21pm, Dave Young wrote: > > Please ignore previous reply, I mistakenly send a broken mail without > > subject, sorry about it. Resend the reply here. > > > > On 06/27/16 at 01:37pm, Thiago Jung Bauermann wrote: > > > Am

[PATCH 1/2] arm: dts: bcm5301x: Add syscon based reboot in DT

From: Jon Mason Add the ability to reboot via a reset of the processor. This is achieved via a write of 0x39 to the CRU Reset Register. Unfortunately, this only resets the core and not the other IP blocks. So if possible, other methods should be used on the individual

[PATCH 1/2] arm: dts: bcm5301x: Add syscon based reboot in DT

From: Jon Mason Add the ability to reboot via a reset of the processor. This is achieved via a write of 0x39 to the CRU Reset Register. Unfortunately, this only resets the core and not the other IP blocks. So if possible, other methods should be used on the individual boards. Signed-off-by:

[PATCH 2/2] arm: dts: nsp: Add syscon based reboot in DT

From: Jon Mason Add the ability to reboot via a reset of the processor. This is achieved via a write of 0x2f9 to the CRU Reset Register. Unfortunately, this only resets the core and not the other IP blocks. So if possible, other methods should be used on the individual

[PATCH 2/2] arm: dts: nsp: Add syscon based reboot in DT

From: Jon Mason Add the ability to reboot via a reset of the processor. This is achieved via a write of 0x2f9 to the CRU Reset Register. Unfortunately, this only resets the core and not the other IP blocks. So if possible, other methods should be used on the individual boards. Signed-off-by:

Re: [PATCH 1/2] arm: dts: bcm5301x: Add syscon based reboot in DT

On 16-06-28 03:10 PM, Jon Mason wrote: From: Jon Mason Add the ability to reboot via a reset of the processor. This is achieved via a write of 0x39 to the CRU Reset Register. Unfortunately, this only resets the core and not the other IP blocks. So if possible, other

Re: [PATCH 1/2] arm: dts: bcm5301x: Add syscon based reboot in DT

On 16-06-28 03:10 PM, Jon Mason wrote: From: Jon Mason Add the ability to reboot via a reset of the processor. This is achieved via a write of 0x39 to the CRU Reset Register. Unfortunately, this only resets the core and not the other IP blocks. So if possible, other methods should be used

[PATCH 1/2] net: ethernet: lpc_eth: use phydev from struct net_device

The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by: Philippe Reynes ---

[PATCH v2] phy: rockchip-usb: should be a child device of the GRF

The usb-phy is fully enclosed in the general register files (GRF). Therefore as seen from the device-tree it shouldn't be a separate platform-device but instead a sub-device of the GRF - using the simply-mfd mechanism. As the usb-phy is part of the kernel for some releases now, we keep the old

[PATCH 1/2] net: ethernet: lpc_eth: use phydev from struct net_device

The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by: Philippe Reynes ---

[PATCH v2] phy: rockchip-usb: should be a child device of the GRF

The usb-phy is fully enclosed in the general register files (GRF). Therefore as seen from the device-tree it shouldn't be a separate platform-device but instead a sub-device of the GRF - using the simply-mfd mechanism. As the usb-phy is part of the kernel for some releases now, we keep the old

[PATCH 0/2] arm: dts: syscon based reboot in DT

Splitting off the bcm5301x reset device tree changes from the patch series (originally sent on http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/395155.html and resent on https://lkml.org/lkml/2016/5/11/953) and adding a Northstar Plus reset device tree change. I'd like to get

[PATCH 0/2] arm: dts: syscon based reboot in DT

Splitting off the bcm5301x reset device tree changes from the patch series (originally sent on http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/395155.html and resent on https://lkml.org/lkml/2016/5/11/953) and adding a Northstar Plus reset device tree change. I'd like to get

Re: [kernel-hardening] Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 28 Jun 2016 14:49:15 -0700, Joe Perches said: > Another potentially useful plugin, especially for embedded systems, > would be to compress any string literal marked with > >  __attribute__((format(printf, string-index,))) > > and decompress the compressed format on the stack in

Re: [kernel-hardening] Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 28 Jun 2016 14:49:15 -0700, Joe Perches said: > Another potentially useful plugin, especially for embedded systems, > would be to compress any string literal marked with > >  __attribute__((format(printf, string-index,))) > > and decompress the compressed format on the stack in

Re: [RFC/PATCH] lib/vsprintf: Add support to store cpumask

On Tue, 28 Jun 2016 23:50:27 +0200 Rasmus Villemoes wrote: > On Tue, Jun 28 2016, Steven Rostedt wrote: > > > But people don't usually run "make smatch" on debug kernels. > > trace_printk() currently is not allowed to be used in the kernel. When >

Re: [RFC/PATCH] lib/vsprintf: Add support to store cpumask

On Tue, 28 Jun 2016 23:50:27 +0200 Rasmus Villemoes wrote: > On Tue, Jun 28 2016, Steven Rostedt wrote: > > > But people don't usually run "make smatch" on debug kernels. > > trace_printk() currently is not allowed to be used in the kernel. When > > it is used, a big ugly banner is posted on

Re: [PATCH 20/21] phy: Add support for Qualcomm's USB HSIC phy

Quoting Neil Armstrong (2016-06-28 01:49:37) > On 06/26/2016 09:28 AM, Stephen Boyd wrote: > > + uphy->cal_sleep_clk = clk = devm_clk_get(>dev, "cal_sleep"); > > + if (IS_ERR(clk)) > > + return PTR_ERR(clk); > > Hi Stephen, > > In the bindings the cal_sleep is marked

Re: [RFC/PATCH] lib/vsprintf: Add support to store cpumask

On Tue, 28 Jun 2016 21:27:29 +0200 Rasmus Villemoes wrote: > > I probably should make a trace_printk() that doesn't default to the > > binary print, to handle things like this. > > > > trace_printk_ptr()? > > > > Or even just see if I can find a way that detects this

Re: [RFC/PATCH] lib/vsprintf: Add support to store cpumask

On Tue, 28 Jun 2016 21:27:29 +0200 Rasmus Villemoes wrote: > > I probably should make a trace_printk() that doesn't default to the > > binary print, to handle things like this. > > > > trace_printk_ptr()? > > > > Or even just see if I can find a way that detects this in the fmt > > string.

Re: [PATCH 20/21] phy: Add support for Qualcomm's USB HSIC phy

Quoting Neil Armstrong (2016-06-28 01:49:37) > On 06/26/2016 09:28 AM, Stephen Boyd wrote: > > + uphy->cal_sleep_clk = clk = devm_clk_get(>dev, "cal_sleep"); > > + if (IS_ERR(clk)) > > + return PTR_ERR(clk); > > Hi Stephen, > > In the bindings the cal_sleep is marked

Re: [PATCH] extcon: Add support for qcom SPMI PMIC USB id detection hardware

Quoting Roger Quadros (2016-06-28 02:13:57) > On 28/06/16 11:47, Stephen Boyd wrote: > > > > Sorry I must have confused you. There are two modules in the PMIC that > > are doing detection here. The charger module is detecting the VBUS event > > and this misc module is detecting the ID pin. I'm not

Re: [PATCH] extcon: Add support for qcom SPMI PMIC USB id detection hardware

Quoting Roger Quadros (2016-06-28 02:13:57) > On 28/06/16 11:47, Stephen Boyd wrote: > > > > Sorry I must have confused you. There are two modules in the PMIC that > > are doing detection here. The charger module is detecting the VBUS event > > and this misc module is detecting the ID pin. I'm not

[PATCH -v4 01/12] locking/atomic: Introduce inc/dec calls for FETCH-OP flavors

With the inclusion of atomic FETCH-OP variants, many places in the kernel can make use of atomic_fetch_$op() to avoid the callers that need to compute the value/state _before_ the operation. Peter laid out the machinery but we are still missing the simpler dec,inc calls (which future patches will

[PATCH -v4 01/12] locking/atomic: Introduce inc/dec calls for FETCH-OP flavors

With the inclusion of atomic FETCH-OP variants, many places in the kernel can make use of atomic_fetch_$op() to avoid the callers that need to compute the value/state _before_ the operation. Peter laid out the machinery but we are still missing the simpler dec,inc calls (which future patches will

Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 2016-06-28 at 13:34 +0200, Emese Revfy wrote: > I would like to introduce the initify gcc plugin. The kernel already has > a mechanism to free up code and data memory that is only used during kernel > or module initialization. > This plugin will teach the compiler to find more such code

Re: [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 2016-06-28 at 13:34 +0200, Emese Revfy wrote: > I would like to introduce the initify gcc plugin. The kernel already has > a mechanism to free up code and data memory that is only used during kernel > or module initialization. > This plugin will teach the compiler to find more such code

Re: [RFC/PATCH] lib/vsprintf: Add support to store cpumask

On Tue, Jun 28 2016, Steven Rostedt wrote: > But people don't usually run "make smatch" on debug kernels. > trace_printk() currently is not allowed to be used in the kernel. When > it is used, a big ugly banner is posted on boot up saying that the > kernel is in "debug mode"

Re: [RFC/PATCH] lib/vsprintf: Add support to store cpumask

On Tue, Jun 28 2016, Steven Rostedt wrote: > But people don't usually run "make smatch" on debug kernels. > trace_printk() currently is not allowed to be used in the kernel. When > it is used, a big ugly banner is posted on boot up saying that the > kernel is in "debug mode" and is "unstable"

Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute

On 28 Jun 2016 at 22:50, Rasmus Villemoes wrote: > > +extern const char *kstrdup_const(const char *s, gfp_t gfp) __nocapture(1); > > OK, so this one is pretty dangerous, and probably wrong. If one does > > foo->bar = kstrdup_const(a-macro-that-might-be-a-string-literal) > > in an .init

Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute

On 28 Jun 2016 at 22:50, Rasmus Villemoes wrote: > > +extern const char *kstrdup_const(const char *s, gfp_t gfp) __nocapture(1); > > OK, so this one is pretty dangerous, and probably wrong. If one does > > foo->bar = kstrdup_const(a-macro-that-might-be-a-string-literal) > > in an .init

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On Tue, Jun 28, 2016 at 2:35 PM, Linus Torvalds wrote: > On Tue, Jun 28, 2016 at 2:21 PM, Andy Lutomirski wrote: > >> If so, that seems considerably more complicated than just adding a reference >> count. > > Fair enough. Ahh, and if you put

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On Tue, Jun 28, 2016 at 2:35 PM, Linus Torvalds wrote: > On Tue, Jun 28, 2016 at 2:21 PM, Andy Lutomirski wrote: > >> If so, that seems considerably more complicated than just adding a reference >> count. > > Fair enough. Ahh, and if you put the reference count just in the task_struct (next to

Re: [PATCH 1/3] Documentation: dt: i2c: use correct STMicroelectronics vendor prefix

On Sun, Jun 26, 2016 at 02:34:04AM -0700, Stefan Agner wrote: > The documentation currently uses the non-standard vendor prefix stm > and st-micro for STMicroelectronics. The drivers do not specify the > vendor prefixes since the I2C Core strips them away from the DT Note that people are working

Re: [PATCH 1/3] Documentation: dt: i2c: use correct STMicroelectronics vendor prefix

On Sun, Jun 26, 2016 at 02:34:04AM -0700, Stefan Agner wrote: > The documentation currently uses the non-standard vendor prefix stm > and st-micro for STMicroelectronics. The drivers do not specify the > vendor prefixes since the I2C Core strips them away from the DT Note that people are working

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On Tue, Jun 28, 2016 at 2:21 PM, Andy Lutomirski wrote: > > Or are you > suggesting that we actually make a list somewhere of stacks that are > nominally unused but are still around for RCU's benefit and then > scavenge from that lest when we need a new stack? Yes. We'd

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On Tue, Jun 28, 2016 at 2:21 PM, Andy Lutomirski wrote: > > Or are you > suggesting that we actually make a list somewhere of stacks that are > nominally unused but are still around for RCU's benefit and then > scavenge from that lest when we need a new stack? Yes. We'd have to make our own

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On Tue, Jun 28, 2016 at 10:02:59PM +0200, Michal Suchanek wrote: > Of course I could add "my-shiny-new-board" compatible to the device > tree and spidev. Then when I build my-shiny-new-board2 and it happens > to also use userspace driver I will not bother to update the > compatible nor will

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On Tue, Jun 28, 2016 at 10:02:59PM +0200, Michal Suchanek wrote: > Of course I could add "my-shiny-new-board" compatible to the device > tree and spidev. Then when I build my-shiny-new-board2 and it happens > to also use userspace driver I will not bother to update the > compatible nor will

Re: [PATCH] m32r: fix build warning about putc

On Monday 27 June 2016 04:48 AM, kbuild test robot wrote: Hi, [auto build test WARNING on v4.7-rc5] [also build test WARNING on next-20160624] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] m32r: fix build warning about putc

On Monday 27 June 2016 04:48 AM, kbuild test robot wrote: Hi, [auto build test WARNING on v4.7-rc5] [also build test WARNING on next-20160624] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: Freeing alternatives sections after module init?

Jessica Yu writes: > Hi Rusty, Hi Jessica, > I noticed that the module loader keeps .altinstructions and > .altinstr_replacement (which are normally freed after kernel init) in > core memory after module init, so these sections are never freed for > modules. > > In fact, the

Re: Freeing alternatives sections after module init?

Jessica Yu writes: > Hi Rusty, Hi Jessica, > I noticed that the module loader keeps .altinstructions and > .altinstr_replacement (which are normally freed after kernel init) in > core memory after module init, so these sections are never freed for > modules. > > In fact, the module loader seems

[PATCH v3] ARM64: boot: dts: Add regulators for Tegra210 Smaug

Add regulators to the Tegra210 Smaug DTS file including support for the max77620 PMIC. Signed-off-by: Rhyland Klein --- v3: - Fixed up ramp delays - s/maxim,enable-sleep/maxim,device-state-on-disabled-event/ - remove GPIO 3 from pp3300 v2: - Updated reg properties to

[PATCH v3] ARM64: boot: dts: Add regulators for Tegra210 Smaug

Add regulators to the Tegra210 Smaug DTS file including support for the max77620 PMIC. Signed-off-by: Rhyland Klein --- v3: - Fixed up ramp delays - s/maxim,enable-sleep/maxim,device-state-on-disabled-event/ - remove GPIO 3 from pp3300 v2: - Updated reg properties to match current binding

Re: [PATCH v3] ARM: dts: sun7i: Add BCM53125 switch nodes to the lamobo-r1 board

On Mon, Jun 27, 2016 at 05:45:56PM -0700, Florian Fainelli wrote: > Now that we have a proper binding for Ethernet switches hanging off > different buses, and a driver for the BCM53125 switch, add its Device > Tree as a child MDIO node, at MDIO address 30 (Broadcom pseudo-PHY > address) and

Re: [PATCH v3] ARM: dts: sun7i: Add BCM53125 switch nodes to the lamobo-r1 board

On Mon, Jun 27, 2016 at 05:45:56PM -0700, Florian Fainelli wrote: > Now that we have a proper binding for Ethernet switches hanging off > different buses, and a driver for the BCM53125 switch, add its Device > Tree as a child MDIO node, at MDIO address 30 (Broadcom pseudo-PHY > address) and

Re: [PATCH v3 2/2] remoteproc: qcom: Introduce WCNSS peripheral image loader

On Tue 28 Jun 14:05 PDT 2016, Arnd Bergmann wrote: > On Tuesday, June 28, 2016 1:58:26 PM CEST Bjorn Andersson wrote: > > > > +config QCOM_WCNSS_PIL > > + tristate "Qualcomm WCNSS Peripheral Image Loader" > > + depends on OF && ARCH_QCOM > > + select QCOM_MDT_LOADER > > +

Re: [PATCH] sparc64: sparc64_defconfig: convert to use libata PATA drivers

On 28/06/16 00:18, Julian Calaby wrote: > Hi Alex, > > On Tue, Jun 28, 2016 at 2:38 AM, wrote: >> On 2016-06-27 08:23, Bartlomiej Zolnierkiewicz wrote: >> >>> If you have affected hardware please test. Thank you. >> >> >> For what it's worth, I've been using libata

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On Tue, Jun 28, 2016 at 2:14 PM, Linus Torvalds wrote: > On Tue, Jun 28, 2016 at 1:54 PM, Andy Lutomirski wrote: >> >> But I might need to that anyway for procfs to read the the stack, >> right? Do you see another way to handle that case? > >

Re: [PATCH v3 2/2] remoteproc: qcom: Introduce WCNSS peripheral image loader

On Tue 28 Jun 14:05 PDT 2016, Arnd Bergmann wrote: > On Tuesday, June 28, 2016 1:58:26 PM CEST Bjorn Andersson wrote: > > > > +config QCOM_WCNSS_PIL > > + tristate "Qualcomm WCNSS Peripheral Image Loader" > > + depends on OF && ARCH_QCOM > > + select QCOM_MDT_LOADER > > +

Re: [PATCH] sparc64: sparc64_defconfig: convert to use libata PATA drivers

On 28/06/16 00:18, Julian Calaby wrote: > Hi Alex, > > On Tue, Jun 28, 2016 at 2:38 AM, wrote: >> On 2016-06-27 08:23, Bartlomiej Zolnierkiewicz wrote: >> >>> If you have affected hardware please test. Thank you. >> >> >> For what it's worth, I've been using libata on sparc64 for roughly two

Re: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

On Tue, Jun 28, 2016 at 2:14 PM, Linus Torvalds wrote: > On Tue, Jun 28, 2016 at 1:54 PM, Andy Lutomirski wrote: >> >> But I might need to that anyway for procfs to read the the stack, >> right? Do you see another way to handle that case? > > I think the other way to handle the kernel stack

Re: [RFC/PATCH] lib/vsprintf: Add support to store cpumask

On Tue, Jun 28 2016, Jiri Olsa wrote: > When using trace_printk for cpumask I've got wrong results, > some bitmaps were completely different from what I expected. > > Currently you get wrong results when using trace_printk > on local cpumask, like: > > void test(void) > { >

Re: [RFC/PATCH] lib/vsprintf: Add support to store cpumask

On Tue, Jun 28 2016, Jiri Olsa wrote: > When using trace_printk for cpumask I've got wrong results, > some bitmaps were completely different from what I expected. > > Currently you get wrong results when using trace_printk > on local cpumask, like: > > void test(void) > { > struct

Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

Quoting Rob Herring (2016-06-28 13:55:18) > On Fri, Jun 24, 2016 at 01:12:52PM +0900, Jongsung Kim wrote: > > There is no way to set additional flags for a DT-initialized fixed- > > factor-clock, and it can be problematic i.e., when the clock rate > > needs to be changed. [1][2] > > > > This

Re: [PATCH v3 2/6] Documentation: dt: mtd: gpmi: document the clocks and clock-names in DT property

On Tue, Jun 28, 2016 at 3:55 PM, Rob Herring wrote: > On Fri, Jun 24, 2016 at 04:40:07PM -0500, Han Xu wrote: >> add the clocks and clock-names in DT property, gpmi-io clock is >> mandatory for all platforms, but some platforms, such as i.MX6Q may >> need more extra clocks for

<    1   2   3   4   5   6   7   8   9   10   >