Re: [PATCH 2/3] thermal: Add Mediatek thermal driver for mt2701.

Dear Keerthy, On Mon, 2016-07-11 at 16:56 +0800, dawei chien wrote: > Dear Keerthy, > > On Thu, 2016-07-07 at 17:24 +0530, Keerthy wrote: > > Hi Dawei Chien, > > > > > > On Thursday 07 July 2016 02:36 PM, Dawei Chien wrote: > > > This patch adds support for mt2701 chip to mtk_thermal.c, > > >

Re: [PATCH 2/3] thermal: Add Mediatek thermal driver for mt2701.

Dear Keerthy, On Mon, 2016-07-11 at 16:56 +0800, dawei chien wrote: > Dear Keerthy, > > On Thu, 2016-07-07 at 17:24 +0530, Keerthy wrote: > > Hi Dawei Chien, > > > > > > On Thursday 07 July 2016 02:36 PM, Dawei Chien wrote: > > > This patch adds support for mt2701 chip to mtk_thermal.c, > > >

Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

On Wed, 2016-08-03 at 13:46 +0800, James Liao wrote: > On Mon, 2016-07-11 at 16:24 +0800, James Liao wrote: > > Hi Mike, > > > > On Fri, 2016-07-08 at 16:32 -0700, Michael Turquette wrote: > > > Hi James, > > > > > > Quoting James Liao (2016-07-03 20:51:48) > > > > On Fri, 2016-07-01 at 18:21

Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

On Wed, 2016-08-03 at 13:46 +0800, James Liao wrote: > On Mon, 2016-07-11 at 16:24 +0800, James Liao wrote: > > Hi Mike, > > > > On Fri, 2016-07-08 at 16:32 -0700, Michael Turquette wrote: > > > Hi James, > > > > > > Quoting James Liao (2016-07-03 20:51:48) > > > > On Fri, 2016-07-01 at 18:21

Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()

On Fri, 5 Aug 2016 23:21:35 -0700 Tony Lindgren wrote: > * Andreas Kemnade [160805 08:35]: > > I repeat the subject line of the patch: > > [PATCH v2] musb: omap2430: do not assume balanced enable()/disable() > > It is *not* fix charging. > > > > So you

Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()

On Fri, 5 Aug 2016 23:21:35 -0700 Tony Lindgren wrote: > * Andreas Kemnade [160805 08:35]: > > I repeat the subject line of the patch: > > [PATCH v2] musb: omap2430: do not assume balanced enable()/disable() > > It is *not* fix charging. > > > > So you mean that the phy should magically know

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

On 08/08/2016 09:40 PM, Thomas Garnier wrote: > Default implementation expects 6 pages maximum are needed for low page > allocations. If KASLR memory randomization is enabled, the worse case > of e820 layout would require 12 pages (no large pages). It is due to the > PUD level randomization and

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

On 08/08/2016 09:40 PM, Thomas Garnier wrote: > Default implementation expects 6 pages maximum are needed for low page > allocations. If KASLR memory randomization is enabled, the worse case > of e820 layout would require 12 pages (no large pages). It is due to the > PUD level randomization and

[PATCH] cgroup: add tracepoints for basic operations

>From 471f89b317a21a78dacaee85957984b9f11e79e4 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Tue, 9 Aug 2016 01:11:13 -0400 Debugging what goes wrong with cgroup setup can get hairy. Add tracepoints for cgroup hierarchy mount, cgroup creation/destruction and task migration

[PATCH] cgroup: add tracepoints for basic operations

>From 471f89b317a21a78dacaee85957984b9f11e79e4 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Tue, 9 Aug 2016 01:11:13 -0400 Debugging what goes wrong with cgroup setup can get hairy. Add tracepoints for cgroup hierarchy mount, cgroup creation/destruction and task migration operations for

Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput

Hi Andrey, > Am 09.08.2016 um 01:49 schrieb Andrey Utkin : > > On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote: >> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff". >> I hope someone knows what it means. >> >> BR and thanks, >>

Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput

Hi Andrey, > Am 09.08.2016 um 01:49 schrieb Andrey Utkin : > > On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote: >> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff". >> I hope someone knows what it means. >> >> BR and thanks, >> Nikolaus >> >>

[git pull] drm fixes

Hi Linus, I thought I should dequeue this, some of these could have made -rc1 if I'd had less illness. This contains a bunch of amdgpu fixes, and some i915 regression fixes. It also contains some fixes for an older regression with some EDID changes and some 6bpc panels. Then there are the

[git pull] drm fixes

Hi Linus, I thought I should dequeue this, some of these could have made -rc1 if I'd had less illness. This contains a bunch of amdgpu fixes, and some i915 regression fixes. It also contains some fixes for an older regression with some EDID changes and some 6bpc panels. Then there are the

[PATCH 1/4] kernfs: add dummy implementation of kernfs_path_from_node()

The dummy version of kernfs_path_from_node() was missing. This currently doesn't break anything. Let's add it for consistency and to ease adding wrappers around it. Signed-off-by: Tejun Heo Cc: Greg Kroah-Hartman --- include/linux/kernfs.h | 5

[PATCH 4/4] cgroup: make cgroup_path() and friends behave in the style of strlcpy()

cgroup_path() and friends used to format the path from the end and thus the resulting path usually didn't start at the start of the passed in buffer. Also, when the buffer was too small, the partial result was truncated from the head rather than tail and there was no way to tell how long the full

[PATCH 1/4] kernfs: add dummy implementation of kernfs_path_from_node()

The dummy version of kernfs_path_from_node() was missing. This currently doesn't break anything. Let's add it for consistency and to ease adding wrappers around it. Signed-off-by: Tejun Heo Cc: Greg Kroah-Hartman --- include/linux/kernfs.h | 5 + 1 file changed, 5 insertions(+) diff

[PATCH 4/4] cgroup: make cgroup_path() and friends behave in the style of strlcpy()

cgroup_path() and friends used to format the path from the end and thus the resulting path usually didn't start at the start of the passed in buffer. Also, when the buffer was too small, the partial result was truncated from the head rather than tail and there was no way to tell how long the full

[PATCH 2/4] kernfs: make kernfs_path*() behave in the style of strlcpy()

kernfs_path*() functions always return the length of the full path but the path content is undefined if the length is larger than the provided buffer. This makes its behavior different from strlcpy() and requires error handling in all its users even when they don't care about truncation. In

[PATCH 3/4] kernfs: remove kernfs_path_len()

It doesn't have any in-kernel user and the same result can be obtained from kernfs_path(@kn, NULL, 0). Remove it. Signed-off-by: Tejun Heo Cc: Serge Hallyn Cc: Greg Kroah-Hartman --- fs/kernfs/dir.c| 23

[PATCHSET] kernfs, cgroup: make kernfs_path*() and cgroup_path*() behave in strlcpy() style

kernfs path formatting functions always return the length of full path but the content of the output buffer is undefined when the length is longer than the provided buffer. Most cgroup path formatting functions return the start of the output or NULL on errors including overflow. These

[PATCH 2/4] kernfs: make kernfs_path*() behave in the style of strlcpy()

kernfs_path*() functions always return the length of the full path but the path content is undefined if the length is larger than the provided buffer. This makes its behavior different from strlcpy() and requires error handling in all its users even when they don't care about truncation. In

[PATCH 3/4] kernfs: remove kernfs_path_len()

It doesn't have any in-kernel user and the same result can be obtained from kernfs_path(@kn, NULL, 0). Remove it. Signed-off-by: Tejun Heo Cc: Serge Hallyn Cc: Greg Kroah-Hartman --- fs/kernfs/dir.c| 23 --- include/linux/kernfs.h | 4 2 files changed, 27

[PATCHSET] kernfs, cgroup: make kernfs_path*() and cgroup_path*() behave in strlcpy() style

kernfs path formatting functions always return the length of full path but the content of the output buffer is undefined when the length is longer than the provided buffer. Most cgroup path formatting functions return the start of the output or NULL on errors including overflow. These

Re: [PATCH 0/7] ima: carry the measurement list across kexec

On 04/08/16 22:24, Mimi Zohar wrote: > The TPM PCRs are only reset on a hard reboot. In order to validate a > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list > of the running kernel must be saved and then restored on the subsequent > boot. > > The existing securityfs

Re: [PATCH 0/7] ima: carry the measurement list across kexec

On 04/08/16 22:24, Mimi Zohar wrote: > The TPM PCRs are only reset on a hard reboot. In order to validate a > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list > of the running kernel must be saved and then restored on the subsequent > boot. > > The existing securityfs

Re: [PATCH 02/10] docs: sphinxify coccinelle.txt and add it to dev-tools

Acked-by: Julia Lawall On Mon, 8 Aug 2016, Jonathan Corbet wrote: > No textual changes have been made, but the formatting has obviously been > tweaked. > > Cc: Michal Marek > Cc: Gilles Muller > Cc: Nicolas Palix

Re: [PATCH 02/10] docs: sphinxify coccinelle.txt and add it to dev-tools

Acked-by: Julia Lawall On Mon, 8 Aug 2016, Jonathan Corbet wrote: > No textual changes have been made, but the formatting has obviously been > tweaked. > > Cc: Michal Marek > Cc: Gilles Muller > Cc: Nicolas Palix > Cc: Julia Lawall > Signed-off-by: Jonathan Corbet > --- >

Re: perf: WARNING: kernel/events/core.c:4893 perf_mmap_close

Vince Weaver writes: > Hello > > running the perf_fuzzer on Haswell, this is a new warning I don't think > I've seen before. > > It works out to be this code here: > > /* this has to be the last one */ > rb_free_aux(rb); >

Re: perf: WARNING: kernel/events/core.c:4893 perf_mmap_close

Vince Weaver writes: > Hello > > running the perf_fuzzer on Haswell, this is a new warning I don't think > I've seen before. > > It works out to be this code here: > > /* this has to be the last one */ > rb_free_aux(rb); >

Re: [PATCH 4.6 00/96] 4.6.6-stable review

On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.6.6 release. There are 96 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.6 00/96] 4.6.6-stable review

On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.6.6 release. There are 96 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH v2 3/4] perf/core: introduce PMU_EV_CAP_READ_ACTIVE_PKG

Hi Nilay, Sounds good, I will post an updated version. Thanks, David On Mon, Aug 8, 2016 at 9:12 AM, Nilay Vaish wrote: > On 7 August 2016 at 15:10, David Carrillo-Cisneros wrote: >> Hi Nilay, >> static int perf_event_read(struct perf_event

Re: [PATCH v2 3/4] perf/core: introduce PMU_EV_CAP_READ_ACTIVE_PKG

Hi Nilay, Sounds good, I will post an updated version. Thanks, David On Mon, Aug 8, 2016 at 9:12 AM, Nilay Vaish wrote: > On 7 August 2016 at 15:10, David Carrillo-Cisneros wrote: >> Hi Nilay, >> static int perf_event_read(struct perf_event *event, bool group) { - int

[PATCH 1/1] usb: misc: usbtest: add fix for driver hang

In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling into usb_sg_cancel(). usb_sg_cancel() will do nothing and return directly if req->status has been set to a non-zero value. This will cause driver hang as soon as transfer time out is triggered. In my test case, below system log

[PATCH 1/1] usb: misc: usbtest: add fix for driver hang

In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling into usb_sg_cancel(). usb_sg_cancel() will do nothing and return directly if req->status has been set to a non-zero value. This will cause driver hang as soon as transfer time out is triggered. In my test case, below system log

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

On Tue, Aug 09, 2016 at 04:31:19AM +, york sun wrote: > Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are > handled by EDAC. And how is mpc85_xxx EDAC handling them? mpc85xx_mc_check() only reports them. And now to get to my original question: is it *enough* to report

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

On Tue, Aug 09, 2016 at 04:31:19AM +, york sun wrote: > Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are > handled by EDAC. And how is mpc85_xxx EDAC handling them? mpc85xx_mc_check() only reports them. And now to get to my original question: is it *enough* to report

HELLO

Hello, I hope this Message finds you well. To start with my name is George Oloni. I am seeking for your cooperation to invest in your Country. Please kindly respond to this message as to enable me to gives you More Details about my investment proposal. Warm Regards Mr. George Oloni

HELLO

Hello, I hope this Message finds you well. To start with my name is George Oloni. I am seeking for your cooperation to invest in your Country. Please kindly respond to this message as to enable me to gives you More Details about my investment proposal. Warm Regards Mr. George Oloni

Re: [PATCH v6 RESEND 4/7] perf config: Use combined {fore,back}ground colors value instead of each two color

Hi, Arnaldo :) On 08/09/2016 03:58 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Aug 02, 2016 at 06:20:46PM +0900, Taeung Song escreveu: To easily set default config values into actual variables for 'colors' config, it would be better that actual variables for each 'colors' config also have only

Re: [PATCH v6 RESEND 4/7] perf config: Use combined {fore,back}ground colors value instead of each two color

Hi, Arnaldo :) On 08/09/2016 03:58 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Aug 02, 2016 at 06:20:46PM +0900, Taeung Song escreveu: To easily set default config values into actual variables for 'colors' config, it would be better that actual variables for each 'colors' config also have only

Клиентские базы Email: bawupecoda-3...@yopmail.com Skype: prodawez389 Запросите подробности сейчас Если интересно Благодарим за быстрый ответ!

Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса! В базе будут все контактные данные необходимые для массовой продажи Ваших товаров и услуг. По Вашему запросу пришлем пример и подробную информацию. Если интересно запросите подробности сейчас Email:

Клиентские базы Email: bawupecoda-3...@yopmail.com Skype: prodawez389 Запросите подробности сейчас Если интересно Благодарим за быстрый ответ!

Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса! В базе будут все контактные данные необходимые для массовой продажи Ваших товаров и услуг. По Вашему запросу пришлем пример и подробную информацию. Если интересно запросите подробности сейчас Email:

Re: Filesystem slow write performance

I wasn't able to repro this with mainline. Sorry for the noise. On 8/6/2016 1:49 PM, Babu Moger wrote: Hi, Seeing some terrible write performance with ext3/4 writes. Reads are fine. I have a created loop device and mounted as ext3(tried ext4 also). Here is iostat output. await time is

Re: Filesystem slow write performance

I wasn't able to repro this with mainline. Sorry for the noise. On 8/6/2016 1:49 PM, Babu Moger wrote: Hi, Seeing some terrible write performance with ext3/4 writes. Reads are fine. I have a created loop device and mounted as ext3(tried ext4 also). Here is iostat output. await time is

Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons

On Mon, Aug 8, 2016 at 2:31 AM, Jon Hunter wrote: > > On 06/08/16 00:45, John Stultz wrote: >> On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter wrote: >>> Hi John, >>> >>> On 30/07/16 05:39, John Stultz wrote: Hey Jon, So after rebasing my nexus7

Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons

On Mon, Aug 8, 2016 at 2:31 AM, Jon Hunter wrote: > > On 06/08/16 00:45, John Stultz wrote: >> On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter wrote: >>> Hi John, >>> >>> On 30/07/16 05:39, John Stultz wrote: Hey Jon, So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I

Re: [PATCH 4.4 00/68] 4.4.17-stable review

On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.17 release. There are 68 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/68] 4.4.17-stable review

On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.17 release. There are 68 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 3.14 00/21] 3.14.75-stable review

On 08/08/2016 12:09 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.75 release. There are 21 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 3.14 00/21] 3.14.75-stable review

On 08/08/2016 12:09 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.75 release. There are 21 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

On August 8, 2016 9:01:42 PM PDT, Borislav Petkov wrote: >On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote: >> Default implementation expects 6 pages maximum are needed for low >page >> allocations. If KASLR memory randomization is enabled, the worse case >> of e820

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

On August 8, 2016 9:01:42 PM PDT, Borislav Petkov wrote: >On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote: >> Default implementation expects 6 pages maximum are needed for low >page >> allocations. If KASLR memory randomization is enabled, the worse case >> of e820 layout would

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote: > Default implementation expects 6 pages maximum are needed for low page > allocations. If KASLR memory randomization is enabled, the worse case > of e820 layout would require 12 pages (no large pages). It is due to the > PUD level

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote: > Default implementation expects 6 pages maximum are needed for low page > allocations. If KASLR memory randomization is enabled, the worse case > of e820 layout would require 12 pages (no large pages). It is due to the > PUD level

Re: [PATCH 1/5] sched,time: Count actually elapsed irq & softirq time

Hi Rik, 2016-07-13 22:50 GMT+08:00 Frederic Weisbecker : > From: Rik van Riel > > Currently, if there was any irq or softirq time during 'ticks' > jiffies, the entire period will be accounted as irq or softirq > time. > > This is inaccurate if only a subset of

Re: [PATCH 1/5] sched,time: Count actually elapsed irq & softirq time

Hi Rik, 2016-07-13 22:50 GMT+08:00 Frederic Weisbecker : > From: Rik van Riel > > Currently, if there was any irq or softirq time during 'ticks' > jiffies, the entire period will be accounted as irq or softirq > time. > > This is inaccurate if only a subset of the time was actually spent >

linux-next: Tree for Aug 9

Hi all, Changes since 20160808: Linus' tree lost the build failure (this was actually an rdma tree problem). The sound-asoc tree lost its build failure. Non-merge commits (relative to Linus' tree): 978 965 files changed, 27099 insertions(+), 7759 deletions

linux-next: Tree for Aug 9

Hi all, Changes since 20160808: Linus' tree lost the build failure (this was actually an rdma tree problem). The sound-asoc tree lost its build failure. Non-merge commits (relative to Linus' tree): 978 965 files changed, 27099 insertions(+), 7759 deletions

Re: [PATCH] drm/cirrus: Fix NULL pointer dereference when registering the fbdev

Boris Brezillon writes: > cirrus_modeset_init() is initializing/registering the emulated fbdev > and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where > !funcs->best_encoder is valid"), DRM internals can access/test some of > the fields in

Re: [PATCH] drm/cirrus: Fix NULL pointer dereference when registering the fbdev

Boris Brezillon writes: > cirrus_modeset_init() is initializing/registering the emulated fbdev > and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where > !funcs->best_encoder is valid"), DRM internals can access/test some of > the fields in mode_config->funcs as part of the

Re: [PATCH v4 0/5] vfs: Use dlock list for SB's s_inodes list

On 07/27/2016 11:12 AM, Christoph Lameter wrote: On Mon, 25 Jul 2016, Tejun Heo wrote: I don't get it. What's the harm of using percpu memory here? Other percpu data structures have remote access too. They're to a lower degree but I don't see a clear demarcation line and making addtions

Re: [PATCH v4 0/5] vfs: Use dlock list for SB's s_inodes list

On 07/27/2016 11:12 AM, Christoph Lameter wrote: On Mon, 25 Jul 2016, Tejun Heo wrote: I don't get it. What's the harm of using percpu memory here? Other percpu data structures have remote access too. They're to a lower degree but I don't see a clear demarcation line and making addtions

Re: [PATCH V5 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

On Tuesday, Aug 9, 2016 4:23 AM, Bjorn Helgaas wrote: > On Sun, Jun 26, 2016 at 11:44:57AM +0800, Rui Wang wrote: > > v5: Remove #ifdef CONFIG_X86 from setup-bus.c, making it neutral to > archs. > > v4: Add comments explaining when to call acpi_ioapic_add(). > > v3: Previous versions break mips.

Re: [PATCH V5 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

On Tuesday, Aug 9, 2016 4:23 AM, Bjorn Helgaas wrote: > On Sun, Jun 26, 2016 at 11:44:57AM +0800, Rui Wang wrote: > > v5: Remove #ifdef CONFIG_X86 from setup-bus.c, making it neutral to > archs. > > v4: Add comments explaining when to call acpi_ioapic_add(). > > v3: Previous versions break mips.

[PATCH] nvme/quirk: Add a delay before checking device ready for memblaze device

Add a delay before checking device ready for memblaze device Signed-off-by: Wenbo Wang --- drivers/nvme/host/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index c82282f..ab90e5f 100644 ---

[PATCH] nvme/quirk: Add a delay before checking device ready for memblaze device

Add a delay before checking device ready for memblaze device Signed-off-by: Wenbo Wang --- drivers/nvme/host/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index c82282f..ab90e5f 100644 --- a/drivers/nvme/host/pci.c +++

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

On Mon, Aug 08, 2016 at 03:39:44PM +, york sun wrote: > RFXE is cleared by default. So for most SoCs, this is not even a concern > at all. But for e500v1, when RIO or PCI are used, this bit is set > specifically to catch an error by machine check (see commit 4e0e3435). > This is not the

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

On Mon, Aug 08, 2016 at 03:39:44PM +, york sun wrote: > RFXE is cleared by default. So for most SoCs, this is not even a concern > at all. But for e500v1, when RIO or PCI are used, this bit is set > specifically to catch an error by machine check (see commit 4e0e3435). > This is not the

[RESEND PATCH] usb: hub: change CLEAR_FEATURE to SET_FEATURE

From: Yonglong Wu According to USB30 specification, the Function Remote Wakeup field can be modified by the SetFeature() requests. SetFeature() is recommended to use. Signed-off-by: Yonglong Wu --- drivers/usb/core/hub.c |2 +- 1 file

[RESEND PATCH] usb: hub: change CLEAR_FEATURE to SET_FEATURE

From: Yonglong Wu According to USB30 specification, the Function Remote Wakeup field can be modified by the SetFeature() requests. SetFeature() is recommended to use. Signed-off-by: Yonglong Wu --- drivers/usb/core/hub.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] usb: hub: change CLEAR_FEATURE to SET_FEATURE

From: Yonglong Wu According to USB30 specification, the Function Remote Wakeup field can be modified by the SetFeature() requests. SetFeature() is recommended to use. Change-Id: Ie744b95f12d7d21d9519e77ed706c8cc33fa Signed-off-by: Yonglong Wu

Re: [PATCH 1/3] ASoC: sst-haswell-pcm: don't use snd_soc_pcm_set_drvdata()

Hi Mark > > snd_soc_pcm_set_drvdata() will set driver data to rtd->dev, > > but driver data of rtd->dev is already used as "rtd" on > > soc_post_component_init(). > > This doesn't apply against current code, please check and resend. Thanks. It seems current your branch already has same patch.

[PATCH] usb: hub: change CLEAR_FEATURE to SET_FEATURE

From: Yonglong Wu According to USB30 specification, the Function Remote Wakeup field can be modified by the SetFeature() requests. SetFeature() is recommended to use. Change-Id: Ie744b95f12d7d21d9519e77ed706c8cc33fa Signed-off-by: Yonglong Wu --- drivers/usb/core/hub.c |2 +- 1 file

Re: [PATCH 1/3] ASoC: sst-haswell-pcm: don't use snd_soc_pcm_set_drvdata()

Hi Mark > > snd_soc_pcm_set_drvdata() will set driver data to rtd->dev, > > but driver data of rtd->dev is already used as "rtd" on > > soc_post_component_init(). > > This doesn't apply against current code, please check and resend. Thanks. It seems current your branch already has same patch.

[PATCH] cpuset: make sure new tasks conform to the current config of the cpuset

A new task inherits cpus_allowed and mems_allowed masks from its parent, but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems before this new task is inserted into the cgroup's task list, the new task won't be updated accordingly. Signed-off-by: Zefan Li

[PATCH] cpuset: make sure new tasks conform to the current config of the cpuset

A new task inherits cpus_allowed and mems_allowed masks from its parent, but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems before this new task is inserted into the cgroup's task list, the new task won't be updated accordingly. Signed-off-by: Zefan Li ---

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On 2016/08/08 09:26, Andreas Werner wrote: [...] > > > + > > > + if (cf->can_dlc > 0) > > > + data[0] = be32_to_cpup((__be32 *)(cf->data)); > > > + if (cf->can_dlc > 3) > > > + data[1] = be32_to_cpup((__be32 *)(cf->data + 4)); > > > + > > > + writel(id, _buf->can_id); > > > +

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On 2016/08/08 09:26, Andreas Werner wrote: [...] > > > + > > > + if (cf->can_dlc > 0) > > > + data[0] = be32_to_cpup((__be32 *)(cf->data)); > > > + if (cf->can_dlc > 3) > > > + data[1] = be32_to_cpup((__be32 *)(cf->data + 4)); > > > + > > > + writel(id, _buf->can_id); > > > +

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

On 08/08, valdis.kletni...@vt.edu wrote: >On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said: >> On 08/08, valdis.kletni...@vt.edu wrote: >> > In other words - how did this patch get into a tree that 0day listens to? >> >> 0Day has a service to automatically capture every patchset sent to LKML >

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

On 08/08, valdis.kletni...@vt.edu wrote: >On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said: >> On 08/08, valdis.kletni...@vt.edu wrote: >> > In other words - how did this patch get into a tree that 0day listens to? >> >> 0Day has a service to automatically capture every patchset sent to LKML >

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

On 08/09, Al Viro wrote: >On Tue, Aug 09, 2016 at 09:17:58AM +0800, Ye Xiaolong wrote: >> On 08/08, valdis.kletni...@vt.edu wrote: >> >On Sun, 07 Aug 2016 22:02:42 +0800, kernel test robot said: >> > >> >> FYI, we noticed the following commit: >> >> >> >> https://github.com/0day-ci/linux >> >>

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

On 08/09, Al Viro wrote: >On Tue, Aug 09, 2016 at 09:17:58AM +0800, Ye Xiaolong wrote: >> On 08/08, valdis.kletni...@vt.edu wrote: >> >On Sun, 07 Aug 2016 22:02:42 +0800, kernel test robot said: >> > >> >> FYI, we noticed the following commit: >> >> >> >> https://github.com/0day-ci/linux >> >>

[PATCH] seq/proc: Modify seq_put_decimal_[u]ll to take a const char *, not char

Allow some seq_puts removals by taking a string instead of a single char. Signed-off-by: Joe Perches --- On top of Alexey's patch, this would also save a couple percent CPU fs/proc/array.c | 178 ++- fs/proc/stat.c

[PATCH] seq/proc: Modify seq_put_decimal_[u]ll to take a const char *, not char

Allow some seq_puts removals by taking a string instead of a single char. Signed-off-by: Joe Perches --- On top of Alexey's patch, this would also save a couple percent CPU fs/proc/array.c | 178 ++- fs/proc/stat.c | 49

Re: [Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

On 8 August 2016 at 19:40, Daniel Vetter wrote: > On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote: >> Hello there, >> >> Recent versions of gcc say this: >> >> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ >> requires 37 bits to represent, but

Re: [Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

On 8 August 2016 at 19:40, Daniel Vetter wrote: > On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote: >> Hello there, >> >> Recent versions of gcc say this: >> >> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ >> requires 37 bits to represent, but ‘int’ only has 32

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast > (de)inflating > & fast live migration > > On 08/07/2016 11:35 PM, Liang Li wrote: > > Dave Hansen suggested a new scheme to encode the data structure, > > because of additional complexity, it's not implemented in v3. > >

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast > (de)inflating > & fast live migration > > On 08/07/2016 11:35 PM, Liang Li wrote: > > Dave Hansen suggested a new scheme to encode the data structure, > > because of additional complexity, it's not implemented in v3. > >

[PATCH v3] perf probe: Support signedness casting

Perf-probe detects a variable's type and use the detected type to add new probe. Then, kprobes prints its variable in hexadecimal format if the variable is unsigned and prints in decimal if it is signed. We sometimes want to see unsigned variable in decimal format (i.e. sector_t or size_t). In

[PATCH v3] perf probe: Support signedness casting

Perf-probe detects a variable's type and use the detected type to add new probe. Then, kprobes prints its variable in hexadecimal format if the variable is unsigned and prints in decimal if it is signed. We sometimes want to see unsigned variable in decimal format (i.e. sector_t or size_t). In

Re: 4.7.0-rc7 ext4 error in dx_probe

On Tue, Aug 09, 2016 at 12:13:01AM +0300, Török Edwin wrote: > On 2016-08-08 19:55, Darrick J. Wong wrote: > > On Mon, Aug 08, 2016 at 12:08:18PM -0400, Theodore Ts'o wrote: > >> On Sun, Aug 07, 2016 at 11:28:10PM -0700, Darrick J. Wong wrote: > >>> > >>> I have one lingering concern -- is it a

Re: 4.7.0-rc7 ext4 error in dx_probe

On Tue, Aug 09, 2016 at 12:13:01AM +0300, Török Edwin wrote: > On 2016-08-08 19:55, Darrick J. Wong wrote: > > On Mon, Aug 08, 2016 at 12:08:18PM -0400, Theodore Ts'o wrote: > >> On Sun, Aug 07, 2016 at 11:28:10PM -0700, Darrick J. Wong wrote: > >>> > >>> I have one lingering concern -- is it a

Re: [PATCH v2] drm/bridge: analogix_dp: Ensure the panel is properly prepared/unprepared

+ Archit On 08/09/2016 02:53 AM, Sean Paul wrote: Instead of just preparing the panel on bind, actually prepare/unprepare during modeset/disable. The panel must be prepared in order to read hpd status and edid, so we need to keep state around the prepares in order to ensure we don't

Re: [PATCH v2] drm/bridge: analogix_dp: Ensure the panel is properly prepared/unprepared

+ Archit On 08/09/2016 02:53 AM, Sean Paul wrote: Instead of just preparing the panel on bind, actually prepare/unprepare during modeset/disable. The panel must be prepared in order to read hpd status and edid, so we need to keep state around the prepares in order to ensure we don't

Build and qemu test results for v4.8-rc1

Build results: total: 148 pass: 142 fail: 6 Failed builds: h8300:allnoconfig h8300:edosk2674_defconfig h8300:h8300h-sim_defconfig h8300:h8s-sim_defconfig unicore32:defconfig unicore32:allnoconfig Qemu test results: total: 107 pass:

Build and qemu test results for v4.8-rc1

Build results: total: 148 pass: 142 fail: 6 Failed builds: h8300:allnoconfig h8300:edosk2674_defconfig h8300:h8300h-sim_defconfig h8300:h8s-sim_defconfig unicore32:defconfig unicore32:allnoconfig Qemu test results: total: 107 pass:

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said: > On 08/08, valdis.kletni...@vt.edu wrote: > > In other words - how did this patch get into a tree that 0day listens to? > > 0Day has a service to automatically capture every patchset sent to LKML Something's wrong then. Nick has proven to be

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said: > On 08/08, valdis.kletni...@vt.edu wrote: > > In other words - how did this patch get into a tree that 0day listens to? > > 0Day has a service to automatically capture every patchset sent to LKML Something's wrong then. Nick has proven to be

  1   2   3   4   5   6   7   8   9   10   >