Re: [PATCH 1/1] net: pegasus: simplify logical constraint

On 16-05-18 20:40:51, Heinrich Schuchardt wrote: > If !count is true, count < 4 is also true. Yep, you're right. However, gcc optimizes away the first condition. What you really got me to think about is whether 4 is the right number. I guess i shall refer to the HW documentation.

Re: [PATCH 1/1] net: pegasus: simplify logical constraint

On 16-05-18 20:40:51, Heinrich Schuchardt wrote: > If !count is true, count < 4 is also true. Yep, you're right. However, gcc optimizes away the first condition. What you really got me to think about is whether 4 is the right number. I guess i shall refer to the HW documentation.

[PATCH v5] iio: max5487: Add support for Maxim digital potentiometers

Add implementation for Maxim MAX5487, MAX5488, MAX5489 digital potentiometers. Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf Signed-off-by: Cristina Moraru CC: Daniel Baluta --- Changes since v4: Add

[PATCH v5] iio: max5487: Add support for Maxim digital potentiometers

Add implementation for Maxim MAX5487, MAX5488, MAX5489 digital potentiometers. Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf Signed-off-by: Cristina Moraru CC: Daniel Baluta --- Changes since v4: Add year for copyright Changes since v3: Fix size

[PATCH v2] xen: add steal_clock support on x86

The pv_time_ops structure contains a function pointer for the "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 uses its own mechanism to account for the "stolen" time a thread wasn't able to run due to hypervisor scheduling. Add support in Xen arch independent time handling

[PATCH v2] xen: add steal_clock support on x86

The pv_time_ops structure contains a function pointer for the "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 uses its own mechanism to account for the "stolen" time a thread wasn't able to run due to hypervisor scheduling. Add support in Xen arch independent time handling

[PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.

In ftrace.c inside the function alloc_retstack_tasklist()(which will be invoked when function_graph tracing is on) the tasklist_lock is being held as reader while iterating through list of threads. Here the lock being held as reader with irqs disabled. The tasklist_lock is never write_locked in

[PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.

In ftrace.c inside the function alloc_retstack_tasklist()(which will be invoked when function_graph tracing is on) the tasklist_lock is being held as reader while iterating through list of threads. Here the lock being held as reader with irqs disabled. The tasklist_lock is never write_locked in

[PATCH net V2] tuntap: correctly wake up process during uninit

We used to check dev->reg_state against NETREG_REGISTERED after each time we are woke up. But after commit 9e641bdcfa4e ("net-tun: restructure tun_do_read for better sleep/wakeup efficiency"), it uses skb_recv_datagram() which does not check dev->reg_state. This will result if we delete a tun/tap

[PATCH net V2] tuntap: correctly wake up process during uninit

We used to check dev->reg_state against NETREG_REGISTERED after each time we are woke up. But after commit 9e641bdcfa4e ("net-tun: restructure tun_do_read for better sleep/wakeup efficiency"), it uses skb_recv_datagram() which does not check dev->reg_state. This will result if we delete a tun/tap

Re: [PATCH net] tuntap: correctly wake up process during uninit

On 2016年05月18日 21:01, Eric Dumazet wrote: On Wed, 2016-05-18 at 18:58 +0800, Jason Wang wrote: We used to check dev->reg_state against NETREG_REGISTERED after each time we are woke up. But after commit 9e641bdcfa4e ("net-tun: restructure tun_do_read for better sleep/wakeup efficiency"), it

Re: [PATCH net] tuntap: correctly wake up process during uninit

On 2016年05月18日 21:01, Eric Dumazet wrote: On Wed, 2016-05-18 at 18:58 +0800, Jason Wang wrote: We used to check dev->reg_state against NETREG_REGISTERED after each time we are woke up. But after commit 9e641bdcfa4e ("net-tun: restructure tun_do_read for better sleep/wakeup efficiency"), it

Re: [PATCH] xen: add steal_clock support on x86

On 18/05/16 18:13, Boris Ostrovsky wrote: > On 05/18/2016 12:00 PM, Juergen Gross wrote: >> On 18/05/16 17:53, Boris Ostrovsky wrote: >>> On 05/18/2016 11:45 AM, David Vrabel wrote: On 18/05/16 16:42, Juergen Gross wrote: > On 18/05/16 17:25, Boris Ostrovsky wrote: >> On 05/18/2016

Re: [PATCH] xen: add steal_clock support on x86

On 18/05/16 18:13, Boris Ostrovsky wrote: > On 05/18/2016 12:00 PM, Juergen Gross wrote: >> On 18/05/16 17:53, Boris Ostrovsky wrote: >>> On 05/18/2016 11:45 AM, David Vrabel wrote: On 18/05/16 16:42, Juergen Gross wrote: > On 18/05/16 17:25, Boris Ostrovsky wrote: >> On 05/18/2016

Re: [PATCH perf/core v8 07/16] perf probe: Remove caches when --cache is given

On Thu, 19 May 2016 06:15:38 +0530 Hemant Kumar wrote: > Hi Masami, > > On 05/15/2016 08:50 AM, Masami Hiramatsu wrote: > > From: Masami Hiramatsu > > > > perf-probe --del removes caches when --cache is given. > > Note that the delete

Re: [PATCH perf/core v8 07/16] perf probe: Remove caches when --cache is given

On Thu, 19 May 2016 06:15:38 +0530 Hemant Kumar wrote: > Hi Masami, > > On 05/15/2016 08:50 AM, Masami Hiramatsu wrote: > > From: Masami Hiramatsu > > > > perf-probe --del removes caches when --cache is given. > > Note that the delete pattern is not same as normal events. > > > > If you cached

Re: [PATCH 1/1 RFC] net/phy: Add Lantiq PHY driver

Hi, On 18/05/2016 18:24, Florian Fainelli wrote: > CC'ing Andrew, John, > also CC'ing Matthias and Hauke. we have had a driver in OpenWrt/LEDE for several years that seems a little more complete than this one.

Re: [PATCH 1/1 RFC] net/phy: Add Lantiq PHY driver

Hi, On 18/05/2016 18:24, Florian Fainelli wrote: > CC'ing Andrew, John, > also CC'ing Matthias and Hauke. we have had a driver in OpenWrt/LEDE for several years that seems a little more complete than this one.

Re: [PATCH 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime

On 18-05-16, 18:30, Dave Gerlach wrote: > Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families, > have different OPPs available for the MPU depending on which specific > variant of the SoC is in use. This can be determined through use of the > revision and an eFuse register

Re: [PATCH 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime

On 18-05-16, 18:30, Dave Gerlach wrote: > Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families, > have different OPPs available for the MPU depending on which specific > variant of the SoC is in use. This can be determined through use of the > revision and an eFuse register

[PATCH V1 4/4] MIPS: Loongson1C: Add defconfig

Add defconfig file for Loongson1C Signed-off-by: Yang Ling --- arch/mips/configs/loongson1c_defconfig | 126 + 1 file changed, 126 insertions(+) create mode 100644 arch/mips/configs/loongson1c_defconfig diff --git

[PATCH V1 4/4] MIPS: Loongson1C: Add defconfig

Add defconfig file for Loongson1C Signed-off-by: Yang Ling --- arch/mips/configs/loongson1c_defconfig | 126 + 1 file changed, 126 insertions(+) create mode 100644 arch/mips/configs/loongson1c_defconfig diff --git a/arch/mips/configs/loongson1c_defconfig

[PATCH V1 3/4] MIPS: Loongson1C: Add board support

Adds basic platform devices for Loongson1C, including serial port and ethernet. Signed-off-by: Yang Ling --- arch/mips/Kconfig | 13 + arch/mips/include/asm/mach-loongson32/irq.h | 41 ++-

[PATCH V1 3/4] MIPS: Loongson1C: Add board support

Adds basic platform devices for Loongson1C, including serial port and ethernet. Signed-off-by: Yang Ling --- arch/mips/Kconfig | 13 + arch/mips/include/asm/mach-loongson32/irq.h | 41 ++- arch/mips/include/asm/mach-loongson32/loongson1.h |

Re: [PATCH 0/4] rcutorture: Several fixes to run selftest scripts on PPC

On Thu, May 19, 2016 at 11:42:20AM +0800, Boqun Feng wrote: > I spend some time to make tools/testing/selftest/rcutorture run on PPC, > here are some documention and fixes made while I was trying. > > The scripts are able to run and get results on PPC, however please > note there are some stalls

Re: [PATCH 0/4] rcutorture: Several fixes to run selftest scripts on PPC

On Thu, May 19, 2016 at 11:42:20AM +0800, Boqun Feng wrote: > I spend some time to make tools/testing/selftest/rcutorture run on PPC, > here are some documention and fixes made while I was trying. > > The scripts are able to run and get results on PPC, however please > note there are some stalls

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote: > The option "-soundhw pcspk" gives me a error on PPC as follow: > > qemu-system-ppc64: ISA bus not available for pcspk > > , which means this option doesn't work on ppc by default. So simply make > this an x86-specific option via

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote: > The option "-soundhw pcspk" gives me a error on PPC as follow: > > qemu-system-ppc64: ISA bus not available for pcspk > > , which means this option doesn't work on ppc by default. So simply make > this an x86-specific option via

[PATCH V1 2/4] MIPS: Add CPU support for Loongson1C

Loongson1C is a 32-bit SoC designed by Loongson Technology Co., Ltd, with many features similar to Loongson1B. Signed-off-by: Yang Ling --- arch/mips/include/asm/cpu-type.h | 3 ++- arch/mips/include/asm/cpu.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff

[PATCH] fbcon: use default if cursor blink interval is not valid

Two current [1] and three previous [2] systems locked during boot because the cursor flash timer was set using an ops->cur_blink_jiffies value of 0. Previous patches attempted to solve the problem by moving variable initialization earlier in the setup sequence [2]. Use the normal cursor blink

[PATCH V1 2/4] MIPS: Add CPU support for Loongson1C

Loongson1C is a 32-bit SoC designed by Loongson Technology Co., Ltd, with many features similar to Loongson1B. Signed-off-by: Yang Ling --- arch/mips/include/asm/cpu-type.h | 3 ++- arch/mips/include/asm/cpu.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH] fbcon: use default if cursor blink interval is not valid

Two current [1] and three previous [2] systems locked during boot because the cursor flash timer was set using an ops->cur_blink_jiffies value of 0. Previous patches attempted to solve the problem by moving variable initialization earlier in the setup sequence [2]. Use the normal cursor blink

investici

Jsem zastupujicí investicní zajem ze strany Dubaji, pro ktere hledáme vasi ucast. Odpoved na e-mailu nize v pripade zajmu. E-mail: pbrt...@gmail.com

investici

Jsem zastupujicí investicní zajem ze strany Dubaji, pro ktere hledáme vasi ucast. Odpoved na e-mailu nize v pripade zajmu. E-mail: pbrt...@gmail.com

[added to the 4.1 stable tree] workqueue: fix ghost PENDING flag while doing MQ IO

From: Roman Pen This patch has been added to the 4.1 stable tree. If you have any objections, please let us know. === [ Upstream commit 346c09f80459a3ad97df1816d6d606169a51001a ] The bug in a workqueue leads to a stalled IO request in MQ

[added to the 4.1 stable tree] workqueue: fix ghost PENDING flag while doing MQ IO

From: Roman Pen This patch has been added to the 4.1 stable tree. If you have any objections, please let us know. === [ Upstream commit 346c09f80459a3ad97df1816d6d606169a51001a ] The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list with the following backtrace:

[added to the 3.18 stable tree] workqueue: fix ghost PENDING flag while doing MQ IO

From: Roman Pen This patch has been added to the 3.18 stable tree. If you have any objections, please let us know. === [ Upstream commit 346c09f80459a3ad97df1816d6d606169a51001a ] The bug in a workqueue leads to a stalled IO request in MQ

[added to the 3.18 stable tree] workqueue: fix ghost PENDING flag while doing MQ IO

From: Roman Pen This patch has been added to the 3.18 stable tree. If you have any objections, please let us know. === [ Upstream commit 346c09f80459a3ad97df1816d6d606169a51001a ] The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list with the following backtrace:

Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

I'm travelling and very busy with the merge window. So sorry I won't be able to think about this for some time.

Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

I'm travelling and very busy with the merge window. So sorry I won't be able to think about this for some time.

Re: [GIT] Networking

From: Linus Torvalds Date: Wed, 18 May 2016 11:45:06 -0700 > David, do you happen to recall that merge conflict? I think you must > have removed that "skb_info" variable declaration and initialization > manually (due to the "unused variable" warning, which in turn

Re: [GIT] Networking

From: Linus Torvalds Date: Wed, 18 May 2016 11:45:06 -0700 > David, do you happen to recall that merge conflict? I think you must > have removed that "skb_info" variable declaration and initialization > manually (due to the "unused variable" warning, which in turn was due > to the incorrect

[GIT PULL] security subsystem updates for 4.7

Please pull these updates for the 4.7 kernel. Highlights: 1. A new LSM, "LoadPin", from Kees Cook is added, which allows forcing of modules and firmware to be loaded from a specific device (this is from ChromeOS, where the device as a whole is verified cryptographically via

[GIT PULL] security subsystem updates for 4.7

Please pull these updates for the 4.7 kernel. Highlights: 1. A new LSM, "LoadPin", from Kees Cook is added, which allows forcing of modules and firmware to be loaded from a specific device (this is from ChromeOS, where the device as a whole is verified cryptographically via

Re: [PATCH] mpt3sas: Do scsi_remove_host() before deleting SAS PHY objects

Hi Calvin, Here is the log w.r.t target drive 2:0:0:0 with your changes, mpt3sas version 12.100.00.00 unloading kobject: '2:0:0:0' (8800d50f1010): kobject_uevent_env kobject: '2:0:0:0' (8800d50f1010): fill_kobj_path: path =

Re: [PATCH] mpt3sas: Do scsi_remove_host() before deleting SAS PHY objects

Hi Calvin, Here is the log w.r.t target drive 2:0:0:0 with your changes, mpt3sas version 12.100.00.00 unloading kobject: '2:0:0:0' (8800d50f1010): kobject_uevent_env kobject: '2:0:0:0' (8800d50f1010): fill_kobj_path: path =

linux-next: build failure after merge of the security tree

Hi James, After merging the security tree, today's linux-next build (x86_64 allmodconfig) failed like this: fs/cifs/cifs_spnego.c: In function 'init_cifs_spnego': fs/cifs/cifs_spnego.c:206:12: error: too few arguments to function 'keyring_alloc' keyring = keyring_alloc(".cifs_spnego",

linux-next: build failure after merge of the security tree

Hi James, After merging the security tree, today's linux-next build (x86_64 allmodconfig) failed like this: fs/cifs/cifs_spnego.c: In function 'init_cifs_spnego': fs/cifs/cifs_spnego.c:206:12: error: too few arguments to function 'keyring_alloc' keyring = keyring_alloc(".cifs_spnego",

Re: Crash in -next due to 'drivers/of: Fix depth when unflattening devicetree'

On Wed, May 18, 2016 at 08:11:12PM -0700, Guenter Roeck wrote: > Hi, > > some of my ppc qemu tests crash with the following log message. > > VFS: Cannot open root device "hda" or unknown-block(0,0): error -6 > Please append a correct "root=" boot option; here are the available > partitions: >

Re: Crash in -next due to 'drivers/of: Fix depth when unflattening devicetree'

On Wed, May 18, 2016 at 08:11:12PM -0700, Guenter Roeck wrote: > Hi, > > some of my ppc qemu tests crash with the following log message. > > VFS: Cannot open root device "hda" or unknown-block(0,0): error -6 > Please append a correct "root=" boot option; here are the available > partitions: >

Re: [PATCH 3.14 00/17] 3.14.70-stable review

On Wed, May 18, 2016 at 08:48:16PM -0700, Kevin Hilman wrote: > kernelci.org bot writes: > > > stable-queue boot: 234 boots: 15 failed, 215 passed with 1 offline, 3 > > untried/unknown (v3.14.69-17-g9f0aa90f9624) > > Interpretation: all good. > > The OMAP failures were due

Re: [PATCH 3.14 00/17] 3.14.70-stable review

On Wed, May 18, 2016 at 08:48:16PM -0700, Kevin Hilman wrote: > kernelci.org bot writes: > > > stable-queue boot: 234 boots: 15 failed, 215 passed with 1 offline, 3 > > untried/unknown (v3.14.69-17-g9f0aa90f9624) > > Interpretation: all good. > > The OMAP failures were due to a bug in my lab.

[PATCH] mwifiex: fix racing condition when downloading firmware

The action 'check for winner' and 'download firmware' should be an atomic action. This is true for btmrvl driver but not mwmfiex, which cause firmware download to fail when the following senerio happens: 1) mwifiex check winner status: true 2) btmrvl check winner status: true, and start

[PATCH] mwifiex: fix racing condition when downloading firmware

The action 'check for winner' and 'download firmware' should be an atomic action. This is true for btmrvl driver but not mwmfiex, which cause firmware download to fail when the following senerio happens: 1) mwifiex check winner status: true 2) btmrvl check winner status: true, and start

[PATCH V1 1/4] clk: add Loongson1C clock support

This adds clock support to Loongson1C SoC. Signed-off-by: Yang Ling --- drivers/clk/clk-loongson1.c | 52 +++-- 1 file changed, 45 insertions(+), 7 deletions(-) diff --git a/drivers/clk/clk-loongson1.c b/drivers/clk/clk-loongson1.c

[PATCH V1 1/4] clk: add Loongson1C clock support

This adds clock support to Loongson1C SoC. Signed-off-by: Yang Ling --- drivers/clk/clk-loongson1.c | 52 +++-- 1 file changed, 45 insertions(+), 7 deletions(-) diff --git a/drivers/clk/clk-loongson1.c b/drivers/clk/clk-loongson1.c index ce2135c..cc9793a

[PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

The option "-soundhw pcspk" gives me a error on PPC as follow: qemu-system-ppc64: ISA bus not available for pcspk , which means this option doesn't work on ppc by default. So simply make this an x86-specific option via identify_qemu_args(). Signed-off-by: Boqun Feng ---

[PATCH 4/4] rcutorture: Don't specify the cpu type of QEMU on PPC

Do not restrict the cpu type to POWER7 for QEMU as we have POWER8 now. Signed-off-by: Boqun Feng --- tools/testing/selftests/rcutorture/bin/functions.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh

[PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

The option "-soundhw pcspk" gives me a error on PPC as follow: qemu-system-ppc64: ISA bus not available for pcspk , which means this option doesn't work on ppc by default. So simply make this an x86-specific option via identify_qemu_args(). Signed-off-by: Boqun Feng ---

[PATCH 4/4] rcutorture: Don't specify the cpu type of QEMU on PPC

Do not restrict the cpu type to POWER7 for QEMU as we have POWER8 now. Signed-off-by: Boqun Feng --- tools/testing/selftests/rcutorture/bin/functions.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh

[PATCH 2/4] rcutorture: Use vmlinux as the fallback kernel image

vmlinux is available for all the architectures, and suitable for running a KVM guest by QEMU, besides, we used to copy the vmlinux to $resdir anyway. Therefore it makes sense to use it as the fallback kernel image for rcutorture KVM tests. This patch makes identify_boot_image() return vmlinux if

[PATCH 2/4] rcutorture: Use vmlinux as the fallback kernel image

vmlinux is available for all the architectures, and suitable for running a KVM guest by QEMU, besides, we used to copy the vmlinux to $resdir anyway. Therefore it makes sense to use it as the fallback kernel image for rcutorture KVM tests. This patch makes identify_boot_image() return vmlinux if

[PATCH 1/4] rcutorture/doc: Add a new way to create initrd using dracut

Using dracut is another way to get an initramfs for kvm based rcu torture tests, which is more flexible than using the host's initramfs image, because modules and binaries may be added or removed via dracut command options. So add an example in the document, in case that there are some situations

[PATCH 1/4] rcutorture/doc: Add a new way to create initrd using dracut

Using dracut is another way to get an initramfs for kvm based rcu torture tests, which is more flexible than using the host's initramfs image, because modules and binaries may be added or removed via dracut command options. So add an example in the document, in case that there are some situations

[PATCH 0/4] rcutorture: Several fixes to run selftest scripts on PPC

I spend some time to make tools/testing/selftest/rcutorture run on PPC, here are some documention and fixes made while I was trying. The scripts are able to run and get results on PPC, however please note there are some stalls even build errors that could be found by the tests currently. As I'm

[PATCH 0/4] rcutorture: Several fixes to run selftest scripts on PPC

I spend some time to make tools/testing/selftest/rcutorture run on PPC, here are some documention and fixes made while I was trying. The scripts are able to run and get results on PPC, however please note there are some stalls even build errors that could be found by the tests currently. As I'm

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

On Wed, 2016-05-18 at 12:03 -0600, Tony S wrote: > On Wed, May 18, 2016 at 11:59 AM, Tony S > wrote: > > On Wed, May 18, 2016 at 11:20 AM, Boris Ostrovsky > > wrote: > > > Tony narrowed the problem down to update_curr() where vruntime is > > >

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

On Wed, 2016-05-18 at 12:03 -0600, Tony S wrote: > On Wed, May 18, 2016 at 11:59 AM, Tony S > wrote: > > On Wed, May 18, 2016 at 11:20 AM, Boris Ostrovsky > > wrote: > > > Tony narrowed the problem down to update_curr() where vruntime is > > > calculated, based on runqueue's clock_task value.

Re: [PATCH 1/2] Documentation: dt: add bindings for ti-cpufreq

On 18-05-16, 18:30, Dave Gerlach wrote: > Add the device tree bindings document for the TI CPUFreq/OPP driver > on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us > to provide an opp-supported-hw property for each OPP to define when > it is available. This driver is responsible

Re: [PATCH 1/2] Documentation: dt: add bindings for ti-cpufreq

On 18-05-16, 18:30, Dave Gerlach wrote: > Add the device tree bindings document for the TI CPUFreq/OPP driver > on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us > to provide an opp-supported-hw property for each OPP to define when > it is available. This driver is responsible

Crash in -next due to 'drivers/of: Fix depth when unflattening devicetree'

Hi, some of my ppc qemu tests crash with the following log message. VFS: Cannot open root device "hda" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; here are the available partitions: 01004096 ram0 (driver?) 01014096 ram1 (driver?) 0102

Crash in -next due to 'drivers/of: Fix depth when unflattening devicetree'

Hi, some of my ppc qemu tests crash with the following log message. VFS: Cannot open root device "hda" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; here are the available partitions: 01004096 ram0 (driver?) 01014096 ram1 (driver?) 0102

[PATCH v2] ION: Sys_heap: Add cached pool to spead up cached buffer alloc

Add ion cached pool in system heap. This patch add a cached pool in system heap. It has a great improvement of alloc for cached buffer. With memory pressue alloc test 800MB in userspace used iontest. The result avg is 577ms. Without patch it's avg is about 883ms. v1: Makes the cached buffer

[PATCH v2] ION: Sys_heap: Add cached pool to spead up cached buffer alloc

Add ion cached pool in system heap. This patch add a cached pool in system heap. It has a great improvement of alloc for cached buffer. With memory pressue alloc test 800MB in userspace used iontest. The result avg is 577ms. Without patch it's avg is about 883ms. v1: Makes the cached buffer

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> On Wed, May 18 2016, Felipe Balbi wrote: > > we've been through this before. This needs to be done at the gadget > > layer. Gadget driver can over-allocate ahead of time if > > gadget->quirk_ep_out_aligned_size is true, then we avoid memcpy() at > > the UDC driver level. > > Right, all right,

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> On Wed, May 18 2016, Felipe Balbi wrote: > > we've been through this before. This needs to be done at the gadget > > layer. Gadget driver can over-allocate ahead of time if > > gadget->quirk_ep_out_aligned_size is true, then we avoid memcpy() at > > the UDC driver level. > > Right, all right,

[PATCH] i2c_hid: enable i2c-hid devices to suspend/resume asynchronously

i2c-hid devices' suspend/resume are usually time-consuming process. For example, the touch controller(i2c-ATML1000:00) on ASUS T100 tablet takes about 160ms for suspending and 120ms for resuming. This patch enables i2c-hid devices to suspend/resume asynchronously. This will take advantage of

[PATCH] i2c_hid: enable i2c-hid devices to suspend/resume asynchronously

i2c-hid devices' suspend/resume are usually time-consuming process. For example, the touch controller(i2c-ATML1000:00) on ASUS T100 tablet takes about 160ms for suspending and 120ms for resuming. This patch enables i2c-hid devices to suspend/resume asynchronously. This will take advantage of

[PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility

we find that some apps will read cpuinfo when start up, they need the string as follows: "Processor : AArch64 Processor rev 0 (aarch64)" Then thay could load the corresponding libs. But now arm64 platform's cpuinfo don't has this now, so we need add this. Signed-off-by: Qing Xia

[PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility

we find that some apps will read cpuinfo when start up, they need the string as follows: "Processor : AArch64 Processor rev 0 (aarch64)" Then thay could load the corresponding libs. But now arm64 platform's cpuinfo don't has this now, so we need add this. Signed-off-by: Qing Xia ---

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> >> thanks Alan Stern and Michal. > >> Here just have a comment - the buffered data need be dropped when > the > >> epfile is closed, because it means the session is terminated. > > > > I blame that on sleep deprivation. Another issue is what to do when > > endpoint is disabled. Should the

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> >> thanks Alan Stern and Michal. > >> Here just have a comment - the buffered data need be dropped when > the > >> epfile is closed, because it means the session is terminated. > > > > I blame that on sleep deprivation. Another issue is what to do when > > endpoint is disabled. Should the

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

Hey James, yeah that's a lot better. I do still get some syslog messages, but i was trivially able to bind a shiftfs into a container and use it the way I'd want. [ 209.452274] [ cut here ] [ 209.452296] WARNING: CPU: 0 PID: 3072 at fs/ext4/inode.c:3977

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

Hey James, yeah that's a lot better. I do still get some syslog messages, but i was trivially able to bind a shiftfs into a container and use it the way I'd want. [ 209.452274] [ cut here ] [ 209.452296] WARNING: CPU: 0 PID: 3072 at fs/ext4/inode.c:3977

Re: [PATCH v3] iio: max5487: Add support for Maxim digital potentiometers

Slight nitpick below. On Tue, May 17, 2016 at 6:11 AM, Cristina Moraru wrote: > Add implementation for Maxim MAX5487, MAX5488, MAX5489 > digital potentiometers. > > Datasheet: > http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf > > Signed-off-by:

Re: [PATCH v3] iio: max5487: Add support for Maxim digital potentiometers

Slight nitpick below. On Tue, May 17, 2016 at 6:11 AM, Cristina Moraru wrote: > Add implementation for Maxim MAX5487, MAX5488, MAX5489 > digital potentiometers. > > Datasheet: > http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf > > Signed-off-by: Cristina Moraru > CC: Daniel

Re: Linux 3.14.70

diff --git a/Makefile b/Makefile index c6762fdfc967..bc3311a0893b 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ VERSION = 3 PATCHLEVEL = 14 -SUBLEVEL = 69 +SUBLEVEL = 70 EXTRAVERSION = NAME = Remembering Coco diff --git a/arch/arm/mach-omap2/sleep34xx.S

Re: Linux 4.4.11

diff --git a/Makefile b/Makefile index 5b5f462f834c..aad86274b61b 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ VERSION = 4 PATCHLEVEL = 4 -SUBLEVEL = 10 +SUBLEVEL = 11 EXTRAVERSION = NAME = Blurry Fish Butt diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi

Re: Linux 3.14.70

diff --git a/Makefile b/Makefile index c6762fdfc967..bc3311a0893b 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ VERSION = 3 PATCHLEVEL = 14 -SUBLEVEL = 69 +SUBLEVEL = 70 EXTRAVERSION = NAME = Remembering Coco diff --git a/arch/arm/mach-omap2/sleep34xx.S

Re: Linux 4.4.11

diff --git a/Makefile b/Makefile index 5b5f462f834c..aad86274b61b 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ VERSION = 4 PATCHLEVEL = 4 -SUBLEVEL = 10 +SUBLEVEL = 11 EXTRAVERSION = NAME = Blurry Fish Butt diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi

Linux 3.14.70

I'm announcing the release of the 3.14.70 kernel. All users of the 3.14 kernel series must upgrade. The updated 3.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.14.y and can be browsed at the normal kernel.org git web

Linux 4.4.11

I'm announcing the release of the 4.4.11 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser:

Linux 3.14.70

I'm announcing the release of the 3.14.70 kernel. All users of the 3.14 kernel series must upgrade. The updated 3.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.14.y and can be browsed at the normal kernel.org git web

Linux 4.4.11

I'm announcing the release of the 4.4.11 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser:

Linux 4.5.5

I'm announcing the release of the 4.5.5 kernel. All users of the 4.5 kernel series must upgrade. The updated 4.5.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.5.y and can be browsed at the normal kernel.org git web browser:

Linux 4.5.5

I'm announcing the release of the 4.5.5 kernel. All users of the 4.5 kernel series must upgrade. The updated 4.5.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.5.y and can be browsed at the normal kernel.org git web browser:

Re: [PATCH 4/6] cpufreq: conservative: Remove declaration of cs_dbs_gov

On 18-05-16, 23:03, Rafael J. Wysocki wrote: > On Wed, May 18, 2016 at 2:25 PM, Viresh Kumar wrote: > > The code doesn't use 'cs_dbs_gov' anymore before it is defined and the > > extra line for declaring it can be removed. > > This sort of conflicts with a patch I've

Re: [PATCH 4/6] cpufreq: conservative: Remove declaration of cs_dbs_gov

On 18-05-16, 23:03, Rafael J. Wysocki wrote: > On Wed, May 18, 2016 at 2:25 PM, Viresh Kumar wrote: > > The code doesn't use 'cs_dbs_gov' anymore before it is defined and the > > extra line for declaring it can be removed. > > This sort of conflicts with a patch I've just posted >

Re: [PATCH 5/6] cpufreq: Reuse gov_attr_* macros in schedutil governor

On 18-05-16, 23:01, Rafael J. Wysocki wrote: > On Wed, May 18, 2016 at 2:25 PM, Viresh Kumar wrote: > > These macros can be used by governors which don't use the common > > governor code present in cpufreq_governor.c and should be moved to the > > relevant header. > > > >

Re: [PATCH 5/6] cpufreq: Reuse gov_attr_* macros in schedutil governor

On 18-05-16, 23:01, Rafael J. Wysocki wrote: > On Wed, May 18, 2016 at 2:25 PM, Viresh Kumar wrote: > > These macros can be used by governors which don't use the common > > governor code present in cpufreq_governor.c and should be moved to the > > relevant header. > > > > Now that they are

  1   2   3   4   5   6   7   8   9   10   >