Re: 3.10.9: Oops at elf_core_dump()

On Thu, Aug 29, 2013 at 03:05:50PM -0700, Greg KH wrote: > On Thu, Aug 29, 2013 at 11:46:18PM +0200, Martin MOKREJŠ wrote: > > Hi, > > I just got this stacktrace. Not sure whom to send it, poking throu > > MAINTAINERS > > file and looking for ELF gave me nothing. ;-) > > > > [105670.434336] BUG

Re: [gcv v3 06/35] scheduler: Replace __get_cpu_var uses

* Christoph Lameter wrote: > On Thu, 29 Aug 2013, Steven Rostedt wrote: > > > On Thu, Aug 29, 2013 at 04:57:43PM +, Christoph Lameter wrote: > > > > > > We could add a this_cpu variant that would be used in the cases we do > > > not want preemption checks? There should not be too many b

Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO

Hi George, On 08/30/2013 03:15 PM, George Cherian wrote: > Hi Chanwoo, > > On 8/30/2013 5:41 AM, Chanwoo Choi wrote: >> Hi George, >> >> On 08/29/2013 10:45 PM, George Cherian wrote: >>> Hi Chanwoo, >>> >>> >>> On 8/29/2013 5:42 PM, Chanwoo Choi wrote: >>> [big snip ] >> I tested various deve

Re: [Query] CPUFreq: Does these machines have separate clock domains for CPUs?

Hi Viresh, On Thu, Aug 29, 2013 at 7:15 PM, Viresh Kumar wrote: > Hi, > > I have been doing some CPUFreq cleanup work and > wanted to know if the below mentioned machines have separate > clock domains for their CPUs or all share the same domain? > > So, that we can use some generic routines for t

Re: [PATCH v2] h8300/kernel/setup.c: add "linux/initrd.h" to pass compiling

On 08/30/2013 12:53 PM, Guenter Roeck wrote: > On 08/29/2013 08:59 PM, Chen Gang wrote: >> The related error (allmodconfig for h8300): >> >>arch/h8300/kernel/setup.c: In function 'setup_arch': >>arch/h8300/kernel/setup.c:103:3: error: 'initrd_start' undeclared >> (first use in this function

omap: panda rcu stall on 3.10.1

> This also went to: linaro-ker...@lists.linaro.org Hi, current linaro kernel on 13.07 (3.10.1.0-1-linaro-omap) shows stack below. System is generally quite unstable. Light usage (postfix+dovecot...) Full dmesg here: https://dl.dropboxusercontent.com/u/21820416/rcu.stall.panda Rgds, Chris

Re: [PATCH] ARC: remove console_verbose() from setup_arch()

On 08/29/2013 12:08 AM, Mischa Jonker wrote: > It prevents kernel parameters such as 'loglevel' from doing their job. > > Signed-off-by: Mischa Jonker > Applied for 3.12 Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@

Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO

Hi Chanwoo, On 8/30/2013 5:41 AM, Chanwoo Choi wrote: Hi George, On 08/29/2013 10:45 PM, George Cherian wrote: Hi Chanwoo, On 8/29/2013 5:42 PM, Chanwoo Choi wrote: [big snip ] I tested various development board based on Samsung Exynos series SoC. Although some gpio of Exynos series SoC set

Re: [PATCH] x86: e820: fix memmap kernel boot parameter

On Fri, Aug 30, 2013 at 2:14 PM, Dan Aloni wrote: > On Fri, Aug 30, 2013 at 01:47:53PM +0800, Bob Liu wrote: >>[..] >> Machine2: bootcmdline in grub.cfg "memmap=0x77ff$0x88000", the >> result of >> "cat /proc/cmdline" changed to "memmap=0x77ffx88000". >> >> I didn't find the root

Re: linux-next: manual merge of the sound tree with the drm tree

At Fri, 30 Aug 2013 13:03:55 +1000, Stephen Rothwell wrote: > > Hi Takashi, > > Today's linux-next merge of the sound tree got a conflict in > sound/pci/hda/hda_intel.c between commit 246efa4a072f ("snd/hda: add > runtime suspend/resume on optimus support (v4)") from the drm tree and > commit 7d4

Re: [PATCH] x86: e820: fix memmap kernel boot parameter

On Fri, Aug 30, 2013 at 01:47:53PM +0800, Bob Liu wrote: >[..] > Machine2: bootcmdline in grub.cfg "memmap=0x77ff$0x88000", the result > of > "cat /proc/cmdline" changed to "memmap=0x77ffx88000". > > I didn't find the root cause, I think maybe grub reserved "$0" as something > spe

Re: linux-next: manual merge of the driver-core tree with the pm tree

On Fri, Aug 30, 2013 at 03:26:40PM +1000, Stephen Rothwell wrote: > Hi Greg, > > Today's linux-next merge of the driver-core tree got a conflict in > drivers/base/core.c between commit 5e33bc4165f3 ("driver core / ACPI: > Avoid device hot remove locking issues") from the tree and commit > 86df268

Re: [PATCH v4 3/5] clk: dt: binding for basic multiplexer clock

* Tero Kristo [130829 00:06]: > On 08/29/2013 04:14 AM, Mike Turquette wrote: > > > >The mux-clock binding covers a quite a few platforms that have similar > >mux-clock programming requirements. If the DT binding is verbose enough > >then the basic mux clock driver is sufficient to initialize all

Re: [PATCH v2] h8300/kernel/setup.c: add "linux/initrd.h" to pass compiling

On 08/30/2013 12:32 PM, Guenter Roeck wrote: > On 08/29/2013 08:59 PM, Chen Gang wrote: >> The related error (allmodconfig for h8300): >> >>arch/h8300/kernel/setup.c: In function 'setup_arch': >>arch/h8300/kernel/setup.c:103:3: error: 'initrd_start' undeclared >> (first use in this function

[PATCH] x86: e820: fix memmap kernel boot parameter

Kernel boot parameter memmap=nn[KMG]$ss[KMG] is used to mark specific memory as reserved. Region of memory to be used is from ss to ss+nn. But I found the action of this parameter is not as expected. I tried on two machines. Machine1: bootcmdline in grub.cfg "memmap=800M$0x60bfdfff", but the resul

Re: [PATCH v2] h8300/kernel/setup.c: add "linux/initrd.h" to pass compiling

On 08/29/2013 08:59 PM, Chen Gang wrote: The related error (allmodconfig for h8300): arch/h8300/kernel/setup.c: In function 'setup_arch': arch/h8300/kernel/setup.c:103:3: error: 'initrd_start' undeclared (first use in this function) initrd_start = memory_start; ^ arch/h8300

Re: [PATCH 1/2] extcon: extcon-dra7xx: Add extcon driver for USB ID detection

On 08/29/2013 05:20 PM, Chanwoo Choi wrote: Hi Guenter, I am currently working on adding device tree support to the extcon-gpio driver. Wonder if it would make sense to just use that driver. As far as I can see the only missing part is support for multiple cables and cable naming through devic

Re: [PATCH v2] h8300/kernel/setup.c: add "linux/initrd.h" to pass compiling

On 08/29/2013 08:59 PM, Chen Gang wrote: The related error (allmodconfig for h8300): arch/h8300/kernel/setup.c: In function 'setup_arch': arch/h8300/kernel/setup.c:103:3: error: 'initrd_start' undeclared (first use in this function) initrd_start = memory_start; ^ arch/h8300

linux-next: manual merge of the driver-core tree with the pm tree

Hi Greg, Today's linux-next merge of the driver-core tree got a conflict in drivers/base/core.c between commit 5e33bc4165f3 ("driver core / ACPI: Avoid device hot remove locking issues") from the tree and commit 86df26870569 ("drivers:base:core: Moved sym export macros to respective functions") f

[PATCH] gpio: null pointer dereference in error handling in gpiolib.c

Avoid calling desc_to_gpio() if desc->chip is NULL, as this will cause a kernel panic. In the code above the calls, there is a test for !chip, which comes to the 'fail' label if true. In this case, the code panics, since desc_to_gpio() uses desc->chip to look up the gpio number. An RFC patch th

Re: [PATCH] Make sure to wake reaper

"Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebied...@xmission.com): >> Serge Hallyn writes: >> >> > Since commit af4b8a83add95ef40716401395b44a1b579965f4 it's been >> > possible to get into a situation where a pidns reaper is >> > , reparented to host pid 1, but never reaped. How to

[PATCH] drivers: uio: Kconfig: add MMU dependancy for UIO

The User space I/O drivers are useful, only when user space meaningful (MMU must be enabled). So need let it depend on MMU, or can not pass compiling, the related error (allmodconfig for H8300): CC [M] drivers/uio/uio.o drivers/uio/uio.c: In function 'uio_mmap_physical': drivers/uio/uio.

[PATCH V2 2/6] vhost_net: use vhost_add_used_and_signal_n() in vhost_zerocopy_signal_used()

We tend to batch the used adding and signaling in vhost_zerocopy_callback() which may result more than 100 used buffers to be updated in vhost_zerocopy_signal_used() in some cases. So wwitch to use vhost_add_used_and_signal_n() to avoid multiple calls to vhost_add_used_and_signal(). Which means muc

[PATCH V2 4/6] vhost_net: determine whether or not to use zerocopy at one time

Currently, even if the packet length is smaller than VHOST_GOODCOPY_LEN, if upend_idx != done_idx we still set zcopy_used to true and rollback this choice later. This could be avoided by determine zerocopy once by checking all conditions at one time before. Signed-off-by: Jason Wang --- drivers/

[PATCH V2 3/6] vhost: switch to use vhost_add_used_n()

Let vhost_add_used() to use vhost_add_used_n() to reduce the code duplication. Signed-off-by: Jason Wang --- drivers/vhost/vhost.c | 54 ++-- 1 files changed, 12 insertions(+), 42 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost

[PATCH V2 5/6] vhost_net: poll vhost queue after marking DMA is done

We used to poll vhost queue before making DMA is done, this is racy if vhost thread were waked up before marking DMA is done which can result the signal to be missed. Fix this by always poll the vhost thread before DMA is done. Signed-off-by: Jason Wang --- drivers/vhost/net.c |9 +

Re: [PATCH] USB2NET : SR9700 : One Chip USB 1.1 USB2NET SR9700 Device Driver Support

On Fri, 2013-08-30 at 01:06 +0200, Francois Romieu wrote: just trivia: > diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c [] > @@ -288,19 +291,19 @@ static void sr9700_set_multicast(struct net_device *net) [] > +static int sr9700_set_mac_address(struct net_device *netdev, void *p)

[PATCH V2 0/6] vhost code cleanup and minor enhancement

Hi all: This series tries to unify and simplify vhost codes especially for zerocopy. With this series, 5% - 10% improvement for per cpu throughput were seen during netperf guest sending test. Plase review. Changes from V1: - Fix the zerocopy enabling check by changing the check of upend_idx != d

[PATCH V2 1/6] vhost_net: make vhost_zerocopy_signal_used() returns void

None of its caller use its return value, so let it return void. Signed-off-by: Jason Wang --- drivers/vhost/net.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 969a859..280ee66 100644 --- a/drivers/vhost/net.c +++ b/d

[PATCH V2 6/6] vhost_net: correctly limit the max pending buffers

As Michael point out, We used to limit the max pending DMAs to get better cache utilization. But it was not done correctly since it was one done when there's no new buffers submitted from guest. Guest can easily exceeds the limitation by keeping sending packets. So this patch moves the check into

[PATCH 4/4] ASoC: rsnd: use regmap instead of original register mapping method

Current Linux kernel is supporting regmap/regmap_field, and, it is good match for Renesas Sound Gen1/Gen2 register mapping. This patch uses regmap instead of original method for register access Signed-off-by: Kuninori Morimoto --- sound/soc/sh/rcar/core.c | 45 - sound/soc/sh/rcar/gen.

[PATCH 3/4] ASoC: rsnd: gen: rsnd_gen_ops cares .probe and .remove

Current rsnd_gen_ops didn't care about .probe and .remove functions, but it was not good sense. This patch tidyup it Signed-off-by: Kuninori Morimoto --- sound/soc/sh/rcar/gen.c | 41 - 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/soun

[PATCH 2/4] regmap: Add regmap_fields APIs

Current Linux kernel is supporting regmap_field method and it is very useful feature. It needs one regmap_filed for one register access. OTOH, there is multi port device which has many same registers in the market. The difference for each port register access is only its address offset. Current A

[PATCH 1/4] regmap: add regmap_field_update_bits()

Current regmap_field is supporting read/write functions. This patch adds new update_bits function for it. Signed-off-by: Kuninori Morimoto --- drivers/base/regmap/regmap.c | 20 include/linux/regmap.h |2 ++ 2 files changed, 22 insertions(+) diff --git a/drivers

[PATCH 0/4] add regmap_filelds and use it on Renesas Sound driver

Hi Mark These patches add new regmap_filelds API on kernel. ~ and use it on Renesas sound driver instead of original method. It can care about multi port register offset via regmap. 0x + 0x40-- port 0 -- regX regY

[PATCH 2/6] extcon-gpio: If the gpio driver/chip supports debounce, use it

Signed-off-by: Guenter Roeck --- drivers/extcon/extcon-gpio.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c index 77d35a7..973600e 100644 --- a/drivers/extcon/extcon-gpio.c +++ b/drivers/extcon/extcon-gpio.c @@ -111,6 +111,

[PATCH] h8300: include: asm: Kbuild: add default "serial.h"

Normally, an architecture need support serial, so include the default one, or can not pass compiling: The related error (allmodconfig for h8300): In file included from drivers/staging/speakup/speakup_acntpc.c:33:0: drivers/staging/speakup/serialio.h:7:24: fatal error: asm/serial.h: No such f

[PATCH 3/6] extcon-gpio: Add support for active-low presence detect pins

Signed-off-by: Guenter Roeck --- drivers/extcon/extcon-gpio.c |4 +++- include/linux/extcon/extcon-gpio.h |1 + 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c index 973600e..d4e3c89 100644 --- a/drivers/extco

[RFC PATCH 4/6] extcon-gpio: Add devicetree support

Signed-off-by: Guenter Roeck --- drivers/extcon/extcon-gpio.c | 59 -- 1 file changed, 57 insertions(+), 2 deletions(-) diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c index d4e3c89..16951fe 100644 --- a/drivers/extcon/extcon-gpi

[RFC PATCH 6/6] extcon-gpio: Describe possible properties to support multi-type cables

This is purely a possible description and an RFC; there is no code (yet). Signed-off-by: Guenter Roeck --- .../devicetree/bindings/extcon/extcon-gpio | 26 1 file changed, 26 insertions(+) diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio b/Docume

[RFC PATCH 5/6] extcon-gpio: Describe devicetree bindings

Signed-off-by: Guenter Roeck --- .../devicetree/bindings/extcon/extcon-gpio | 23 1 file changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio b/Document

Re: [Query] CPUFreq: Does these machines have separate clock domains for CPUs?

Cris are also UP 29 aug 2013 kl. 12:16 skrev "Viresh Kumar" : > Hi, > > I have been doing some CPUFreq cleanup work and > wanted to know if the below mentioned machines have separate > clock domains for their CPUs or all share the same domain? > > So, that we can use some generic routines for t

[PATCH 1/6] extcon-gpio: Do not unnecessarily initialize variables

Signed-off-by: Guenter Roeck --- drivers/extcon/extcon-gpio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c index 02bec32..77d35a7 100644 --- a/drivers/extcon/extcon-gpio.c +++ b/drivers/extcon/extcon-gpio.c @@ -

[PATCH 0/6] extcon-gpio: Add devicetree support

The first three patches of this series are either cleanup or add functionality unrelated to devicetree support and should hopefully be acceptable as-is or with minor modifications. Patch 1 of this series is a tiny cleanup patch. Patch 2 adds support for hardware debounce. If the gpio chip supports

Re: [PATCH] Kconfig.debug: Add FRAME_POINTER anti-dependency for ARC

On 08/29/2013 08:48 PM, Dave Hansen wrote: > > I assume you're sending this my way since getmaintainer.pl has me tagged > I moved a bunch of code in there. :) Indeed :-) > The Kconfig.debug stuff has no real maintainer. It would probably be OK > if you just stick this in your architecture's next

[PATCH V2 2/6] powerpc, perf: Enable conditional branch filter for POWER8

Enables conditional branch filter support for POWER8 utilizing MMCRA register based filter and also invalidates a BHRB branch filter combination involving conditional branches. Signed-off-by: Anshuman Khandual --- arch/powerpc/perf/power8-pmu.c | 10 ++ 1 file changed, 10 insertions(+)

[PATCH V2 3/6] perf, tool: Conditional branch filter 'cond' added to perf record

Adding perf record support for new branch stack filter criteria PERF_SAMPLE_BRANCH_COND. Signed-off-by: Anshuman Khandual --- tools/perf/builtin-record.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c index ecca62e..802d11d 100644 --

[PATCH V2 4/6] x86, perf: Add conditional branch filtering support

This patch adds conditional branch filtering support, enabling it for PERF_SAMPLE_BRANCH_COND in perf branch stack sampling framework by utilizing an available software filter X86_BR_JCC. Signed-off-by: Anshuman Khandual Reviewed-by: Stephane Eranian --- arch/x86/kernel/cpu/perf_event_intel_lbr

[PATCH V2 6/6] powerpc, perf: Enable SW filtering in branch stack sampling framework

This patch enables SW based post processing of BHRB captured branches to be able to meet more user defined branch filtration criteria in perf branch stack sampling framework. This changes increase the number of filters and their valid combinations on powerpc64 platform with BHRB support. Summary of

[PATCH V2 1/6] perf: New conditional branch filter criteria in branch stack sampling

POWER8 PMU based BHRB supports filtering for conditional branches. This patch introduces new branch filter PERF_SAMPLE_BRANCH_COND which will extend the existing perf ABI. Other architectures can provide this functionality with either HW filtering support (if present) or with SW filtering of instru

[PATCH V2 5/6] perf, documentation: Description for conditional branch filter

Adding documentation support for conditional branch filter. Signed-off-by: Anshuman Khandual Reviewed-by: Stephane Eranian --- tools/perf/Documentation/perf-record.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Do

[PATCH V2 0/6] perf: New conditional branch filter

This patchset is the re-spin of the original branch stack sampling patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset also enables SW based branch filtering support for PPC64 platforms which have branch stack sampling support. With this new enablement, the branch fi

[PATCH 2/2] w1: ds1wm: use dev_get_platdata()

Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. This is a cosmetic change to make the code simpler and enhance the readability. Signed-off-by: Jingoo Han --- drivers/w1/masters/ds1wm.c | 12 ++-- 1 file changed, 6 insertions(+

[PATCH 1/2] w1: w1-gpio: use dev_get_platdata()

Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. This is a cosmetic change to make the code simpler and enhance the readability. Signed-off-by: Jingoo Han --- drivers/w1/masters/w1-gpio.c | 10 +- 1 file changed, 5 insertions(+

Re: [PATCH net-next] drivers:net: Convert dma_alloc_coherent(...__GFP_ZERO) to dma_zalloc_coherent

On Thu, 2013-08-29 at 22:09 -0400, David Miller wrote: > Applied, thanks a lot Joe. Too bad I didn't know there was a dma_zalloc_coherent the first time... cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org

[PATCH 3/3] drivers: uio_pruss: use dev_get_platdata()

Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. This is a cosmetic change to make the code simpler and enhance the readability. Signed-off-by: Jingoo Han --- drivers/uio/uio_pruss.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(

[PATCH 2/3] drivers: uio_pdrv_genirq: use dev_get_platdata()

Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. This is a cosmetic change to make the code simpler and enhance the readability. Signed-off-by: Jingoo Han --- drivers/uio/uio_pdrv_genirq.c |2 +- 1 file changed, 1 insertion(+), 1 del

[PATCH 1/3] drivers: uio_dmem_genirq: use dev_get_platdata()

Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. This is a cosmetic change to make the code simpler and enhance the readability. Signed-off-by: Jingoo Han --- drivers/uio/uio_dmem_genirq.c |2 +- 1 file changed, 1 insertion(+), 1 del

[PATCH] drivers: parport: Kconfig: exclude h8300 for PARPORT_PC

h8300 does not support PARPORT_PC. The related error (with allmodconfig for h8300): CC [M] drivers/parport/parport_pc.o drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such file or directory Signed-off-by: Chen Gang --- drivers/parport/Kconfig |2 +- 1 files cha

Re: [PATCH] f2fs: optimize gc for better performance

Hi Jaegeuk, On 08/29/2013 07:56 PM, Jaegeuk Kim wrote: Hi, 2013-08-29 (목), 08:48 +0800, Jin Xu: From: Jin Xu This patch improves the foreground gc efficiency by optimizing the victim selection policy. With this optimization, the random re-write performance could increase up to 20%. [...]

Re: [PATCH 5/5] mm/cgroup: use N_MEMORY instead of N_HIGH_MEMORY

On 2013/8/30 11:44, Jianguo Wu wrote: > Since commit 8219fc48a(mm: node_states: introduce N_MEMORY), > we introduced N_MEMORY, now N_MEMORY stands for the nodes that has any memory, > and N_HIGH_MEMORY stands for the nodes that has normal or high memory. > > The code here need to handle with the

[PATCH v2] h8300/kernel/setup.c: add "linux/initrd.h" to pass compiling

The related error (allmodconfig for h8300): arch/h8300/kernel/setup.c: In function 'setup_arch': arch/h8300/kernel/setup.c:103:3: error: 'initrd_start' undeclared (first use in this function) initrd_start = memory_start; ^ arch/h8300/kernel/setup.c:103:3: note: each undeclared ide

Re: [PATCH 1/1] [media] uvcvideo: quirk PROBE_DEF for Dell SP2008WFP monitor.

On Fri, Aug 30, 2013 at 02:41:17AM +0200, Laurent Pinchart wrote: > Hi Joseph, > > Thank you for the patch. > > On Thursday 29 August 2013 11:17:41 Joseph Salisbury wrote: > > BugLink: http://bugs.launchpad.net/bugs/1217957 > > > > Add quirk for Dell SP2008WFP monitor: 05a9:2641 > > > > Signed-

perf_swevent_add warn_on.

WARNING: CPU: 2 PID: 7498 at kernel/events/core.c:5485 perf_swevent_add+0x18d/0x1a0() Modules linked in: snd_seq_dummy 8021q garp stp fuse tun rfcomm hidp nfnetlink ipt_ULOG nfc caif_socket caif af_802154 phonet af_rxrpc bnep bluetooth can_bcm rfkill can_raw can llc2 pppoe pppox ppp_generic slhc

RE: [PATCH v6 2/3] mmc: dw_mmc: Honor requests to set the clock to 0 (turn off clock)

On Fri, August 30, 2013, Doug Anderson wrote: > Seungwon, > > On Thu, Aug 29, 2013 at 12:04 AM, Seungwon Jeon wrote: > >> I'd really still rather honor the MMC subsystem's request. It > >> shouldn't _hurt_ to turn the clock off when the subsystem requests it, > > Even though turning off by clock

Re: [PATCH] h8300/kernel/setup.c: add "linux/initrd.h" to pass compiling

On 08/26/2013 06:31 PM, Chen Gang wrote: > Need add "linux/initrd.h" to pass compiling. > > The related error (allmodconfig for h8300): > > arch/h8300/kernel/setup.c: In function 'setup_arch': > arch/h8300/kernel/setup.c:103:3: error: 'initrd_start' undeclared (first > use in this function)

Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

On Thu, Aug 29, 2013 at 8:12 PM, Waiman Long wrote: > On 08/29/2013 07:42 PM, Linus Torvalds wrote: >> >> Waiman? Mind looking at this and testing? Linus > > Sure, I will try out the patch tomorrow morning and see how it works out for > my test case. Ok, thanks, please use this slightly updated p

[PATCH 5/5] mm/cgroup: use N_MEMORY instead of N_HIGH_MEMORY

Since commit 8219fc48a(mm: node_states: introduce N_MEMORY), we introduced N_MEMORY, now N_MEMORY stands for the nodes that has any memory, and N_HIGH_MEMORY stands for the nodes that has normal or high memory. The code here need to handle with the nodes which have memory, we should use N_MEMORY i

[PATCH 4/5] mm/ia64: use N_MEMORY instead of N_HIGH_MEMORY

Since commit 8219fc48a(mm: node_states: introduce N_MEMORY), we introduced N_MEMORY, now N_MEMORY stands for the nodes that has any memory, and N_HIGH_MEMORY stands for the nodes that has normal or high memory. The code here need to handle with the nodes which have memory, we should use N_MEMORY i

Re: + mm-sparse-introduce-alloc_usemap_and_memmap-fix-2.patch added to -mm tree

On Thu, Aug 29, 2013 at 4:35 PM, Wanpeng Li wrote: > On Thu, Aug 29, 2013 at 01:44:18PM -0700, Yinghai Lu wrote: >>> mm/sparse.c | 41 +++-- >>> 1 file changed, 15 insertions(+), 26 deletions(-) >>> >>> diff -puN mm/sparse.c~mm-sparse-introduce-alloc_usemap_

[PATCH 3/5] mm/vmemmap: use N_MEMORY instead of N_HIGH_MEMORY

Since commit 8219fc48a(mm: node_states: introduce N_MEMORY), we introduced N_MEMORY, now N_MEMORY stands for the nodes that has any memory, and N_HIGH_MEMORY stands for the nodes that has normal or high memory. The code here need to handle with the nodes which have memory, we should use N_MEMORY i

[PATCH 2/5] mm/sparse: use N_MEMORY instead of N_HIGH_MEMORY

Since commit 8219fc48a(mm: node_states: introduce N_MEMORY), we introduced N_MEMORY, now N_MEMORY stands for the nodes that has any memory, and N_HIGH_MEMORY stands for the nodes that has normal or high memory. The code here need to handle with the nodes which have memory, we should use N_MEMORY i

[PATCH 1/5] mm/vmalloc: use N_MEMORY instead of N_HIGH_MEMORY

Since commit 8219fc48a(mm: node_states: introduce N_MEMORY), we introduced N_MEMORY, now N_MEMORY stands for the nodes that has any memory, and N_HIGH_MEMORY stands for the nodes that has normal or high memory. The code here need to handle with the nodes which have memory, we should use N_MEMORY i

BUG: soft lockup - CPU#25 stuck for 23s! [memcg_process_s:5859]

Hello All, I hit the following errors when running memcg_stress_test.sh comes from LTP test suite on v3.11-rc7+: snip - [ 2163.674483] BUG: soft lockup - CPU#25 stuck for 23s! [memcg_process_s:5859] [ 2163.674489] Modules linked in: xt_CHECKSU

Re: [PATCH] hwmon: (htu21) Add Measurement Specialties HTU21D support

On 08/29/2013 04:51 AM, Markezana, William wrote: From: William Markezana hwmon: (htu21) Add Measurement Specialties HTU21D support Signed-off-by: William Markezana --- Applied [ with minor formatting changes ] to -next. Thanks, Guenter diff --git a/Documentation/hwmon/htu21 b/Documentati

Re: Memory synchronization vs. interrupt handlers

On 08/29/2013 04:51 PM, Paul E. McKenney wrote: > On Wed, Aug 28, 2013 at 01:28:08PM -0700, H. Peter Anvin wrote: >> On 08/28/2013 12:16 PM, Alan Stern wrote: >>> Russell, Peter, and Ingo: >>> >>> Can you folks enlighten us regarding this issue for some common >>> architectures? >> >> On x86, IRET

[PATCH RESEND 3/4] usb: phy-tegra-usb: use platform_{get,set}_drvdata()

Use the wrapper functions for getting and setting the driver data using platform_device instead of using dev_{get,set}_drvdata() with &of->dev, so we can directly pass a struct platform_device. Signed-off-by: Libo Chen --- drivers/usb/phy/phy-tegra-usb.c |2 +- 1 files changed, 1 insertions

[PATCH RESEND 2/4] usb: r8a66597-hcd: use platform_{get,set}_drvdata()

Use the wrapper functions for getting and setting the driver data using platform_device instead of using dev_{get,set}_drvdata() with &of->dev, so we can directly pass a struct platform_device. Signed-off-by: Libo Chen --- drivers/usb/host/r8a66597-hcd.c |4 ++-- 1 files changed, 2 insertio

Re: [PATCH 6/6] vhost_net: remove the max pending check

On 08/25/2013 07:53 PM, Michael S. Tsirkin wrote: > On Fri, Aug 23, 2013 at 04:55:49PM +0800, Jason Wang wrote: >> On 08/20/2013 10:48 AM, Jason Wang wrote: >>> On 08/16/2013 06:02 PM, Michael S. Tsirkin wrote: > On Fri, Aug 16, 2013 at 01:16:30PM +0800, Jason Wang wrote: >>> We used to lim

Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

On 08/29/2013 01:03 PM, Alexander Fyodorov wrote: 29.08.2013, 19:25, "Waiman Long": What I have been thinking is to set a flag in an architecture specific header file to tell if the architecture need a memory barrier. The generic code will then either do a smp_mb() or barrier() depending on the

Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

On 08/29/2013 07:42 PM, Linus Torvalds wrote: Waiman? Mind looking at this and testing? Linus Sure, I will try out the patch tomorrow morning and see how it works out for my test case. Regards, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

linux-next: manual merge of the sound tree with the drm tree

Hi Takashi, Today's linux-next merge of the sound tree got a conflict in sound/pci/hda/hda_intel.c between commit 246efa4a072f ("snd/hda: add runtime suspend/resume on optimus support (v4)") from the drm tree and commit 7d4f606c50ff ("ALSA: hda - WAKEEN feature enabling for runtime pm") from the s

Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

On Thu, 2013-08-29 at 19:35 -0700, Linus Torvalds wrote: > That said, on power, you have that "ACCESS_ONCE()" implicit in the > *type*, not in the code, so an "arch_spinlock_t" is fundamentally > volatile in itself. It's one of the reasons I despise "volatile": > things like volatility are _not_ at

Re: [PATCH v2 0/4] Unify CPU hotplug lock interface

(2013/08/30 9:22), Toshi Kani wrote: > lock_device_hotplug() was recently introduced to serialize CPU & Memory > online/offline and hotplug operations, along with sysfs online interface > restructure (commit 4f3549d7). With this new locking scheme, > cpu_hotplug_driver_lock() is redundant and is n

Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

On Thu, 2013-08-29 at 19:31 -0700, Linus Torvalds wrote: > Also, on x86, there are no advantages to cmpxchg over a spinlock - > they are both exactly one equally serializing instruction. If > anything, cmpxchg is worse due to having a cache read before the > write, and a few cycles slower anyway.

Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

On Thu, Aug 29, 2013 at 7:30 PM, Benjamin Herrenschmidt wrote: > > Or we can keep both completely separate like Linus does on x86. I did it that way mainly to minimize the patch. I agree with you that it probably makes sense to layer them the other way around from what Michael's patch did, iow i

Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

On Fri, 2013-08-30 at 12:06 +1000, Michael Neuling wrote: > powerpc patch below. I'm using arch_spin_is_locked() to implement > arch_spin_value_unlocked(). > > +static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock) > +{ > + return !arch_spin_is_locked(&lock); > +} > + A

Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

On Thu, Aug 29, 2013 at 7:06 PM, Michael Neuling wrote: > > Running on a POWER7 here with 32 threads (8 cores x 4 threads) I'm > getting some good improvements: That's *much* better than I get. But I literally just have a single socket with two cores (and HT, so four threads) in my test machine,

Re: [PATCH net-next] drivers:net: Convert dma_alloc_coherent(...__GFP_ZERO) to dma_zalloc_coherent

From: Joe Perches Date: Mon, 26 Aug 2013 22:45:23 -0700 > __GFP_ZERO is an uncommon flag and perhaps is better > not used. static inline dma_zalloc_coherent exists > so convert the uses of dma_alloc_coherent with __GFP_ZERO > to the more common kernel style with zalloc. > > Remove memset from t

[PATCH 4/4] mm/arch: use NUMA_NODE

Use more appropriate NUMA_NO_NODE instead of -1 in some archs' module_alloc() Signed-off-by: Jianguo Wu --- arch/arm/kernel/module.c|2 +- arch/arm64/kernel/module.c |2 +- arch/mips/kernel/module.c |2 +- arch/parisc/kernel/module.c |2 +- arch/s390/kernel/module.c |

Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

> Anyway, I'm attaching my completely mindless test program. It has > hacky things like "unsigned long count[MAXTHREADS][32]" which are > purely to just spread out the counts so that they aren't in the same > cacheline etc. > > Also note that the performance numbers it spits out depend a lot on >

Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site

On Mon, Aug 26, 2013 at 10:39:32AM +0800, Lai Jiangshan wrote: > On 08/26/2013 01:43 AM, Paul E. McKenney wrote: > > On Sun, Aug 25, 2013 at 11:19:37PM +0800, Lai Jiangshan wrote: > >> Hi, Steven > >> > >> Any comments about this patch? > > > > For whatever it is worth, it ran without incident for

Re: [PATCH] mmc/dw_mmc: Add support for ARC

Hi, On Thu, Aug 29 2013, Seungwon Jeon wrote: > On Thu, August 29, 2013, Mischa Jonker wrote: >> Adapt Kconfig to include ARC in supported architectures >> >> Signed-off-by: Mischa Jonker > Acked-by: Seungwon Jeon Thanks, pushed to mmc-next for 3.12. - Chris. -- Chris Ball

Re: [PATCH] Avoid useless inodes and dentries reclamation

On Thu, Aug 29, 2013 at 11:36:10AM -0700, Dave Hansen wrote: > The new shrinker infrastructure in mmotm looks like it will make this > problem worse. > > old code: > shrink_slab() > for_each_shrinker { > do_shrinker_shrink(); // one per batch > prune_super

Re: [PATCH] include/asm-generic/gpio.h: remove the call for __gpio_get_value() and __gpio_set_value() when GPIOLIB disabled

On 08/29/2013 08:08 PM, Linus Walleij wrote: > On Mon, Aug 26, 2013 at 12:08 PM, Chen Gang wrote: > >> When GPIOLIB disabled, __gpio_get_value() and __gpio_set_value() will >> not implement, so need remove them, or compiling fails. >> >> e.g. (allmodconfig for h8300) >> >> CC arch/h8300/

Re: RFC: Bug in error handling in gpiolib.c

On Fri, Aug 30, 2013 at 2:45 AM, Linus Walleij wrote: > On Tue, Aug 27, 2013 at 9:17 PM, Tim Bird wrote: > >> Hi all, >> >> There appears to be a bug in the error handling in >> drivers/gpi/gpiolib.c In certain error cases >> desc_to_gpio() is called to get the gpio number >> for an error messag

Re: [PATCH v4 5/5] clk: dt: binding for basic gate clock

On 22 August 2013 13:53, Mike Turquette wrote: > Device Tree binding for the basic clock gate, plus the setup function to > register the clock. Based on the existing fixed-clock binding. > > A different approach to this was proposed in 2012[1] and a similar > binding was proposed more recently[2]

Re: [PATCH] Avoid useless inodes and dentries reclamation

On Thu, Aug 29, 2013 at 11:07:56AM -0700, Tim Chen wrote: > > > > Signed-off-by: Tim Chen > > > --- > > > fs/super.c | 8 > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/fs/super.c b/fs/super.c > > > index 68307c0..70fa26c 100644 > > > --- a/fs/super.c > > > +++ b/fs/sup

[PATCH 3/4] x86/srat: use NUMA_NO_NODE

setup_node() return NUMA_NO_NODE or valid node id(>=0), So use more appropriate "if (node == NUMA_NO_NODE)" instead of "if (node < 0)" Signed-off-by: Jianguo Wu --- arch/x86/mm/srat.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/s

[GIT PULL] ARM: SoC fixes for 3.11

Hi Linus, The following changes since commit 30ca2226bea6f0db519dc53381b893cd66cb5b66: ARM: tegra: always enable USB VBUS regulators (2013-08-21 21:36:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus for y

  1   2   3   4   5   6   7   8   >