Re: [PATCH v3] clk: qcom: clk-smd-rpm: Fix the reported rate of branches

On 07/17, Georgi Djakov wrote: > As there is no way to actually query the hardware for the current clock > rate, now racalc_rate() just returns the last rate that was previously > set. But if the rate was not set yet, we return the bogus rate of 1000Hz. > > The branch clocks have the same rate as

Re: [PATCH v3] clk: qcom: clk-smd-rpm: Fix the reported rate of branches

On 07/17, Georgi Djakov wrote: > As there is no way to actually query the hardware for the current clock > rate, now racalc_rate() just returns the last rate that was previously > set. But if the rate was not set yet, we return the bogus rate of 1000Hz. > > The branch clocks have the same rate as

Re: [PATCH v2 2/2] staging: gs_fpgaboot: change char to u8

On Mon, 2017-07-17 at 20:47 -0400, Jacob von Chorus wrote: > The bitstream storage variables were changed from char to u8 arrays to > prevent issues such as negative lengths. This change makes the code > compatible with the "data" field in "struct firmware" which is of type > u8. > >

Re: [PATCH v2 2/2] staging: gs_fpgaboot: change char to u8

On Mon, 2017-07-17 at 20:47 -0400, Jacob von Chorus wrote: > The bitstream storage variables were changed from char to u8 arrays to > prevent issues such as negative lengths. This change makes the code > compatible with the "data" field in "struct firmware" which is of type > u8. > >

RE: [PATCH v2 12/22] fpga: intel: fme: add header sub feature support

> On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao wrote: > > Hi Hao, > > I'm making my way through this (very large) patchset. Some minor > comments below. > Hi Alan Thanks for your review. : ) > > From: Kang Luwei > > > > The header register set is always

RE: [PATCH v2 12/22] fpga: intel: fme: add header sub feature support

> On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao wrote: > > Hi Hao, > > I'm making my way through this (very large) patchset. Some minor > comments below. > Hi Alan Thanks for your review. : ) > > From: Kang Luwei > > > > The header register set is always present for FPGA Management Engine

Re: [PATCH v2] clk: mediatek: fixed static checker warning in clk_cpumux_get_parent call

On 07/17, sean.w...@mediatek.com wrote: > From: Sean Wang > > Fixed the signedness bug returning '(-22)' on the return type as u8 with > removing the sanity checker in clk_cpumux_get_parent() since > clk_cpumux_set_parent() always ensures validity in

Re: [PATCH v2] clk: mediatek: fixed static checker warning in clk_cpumux_get_parent call

On 07/17, sean.w...@mediatek.com wrote: > From: Sean Wang > > Fixed the signedness bug returning '(-22)' on the return type as u8 with > removing the sanity checker in clk_cpumux_get_parent() since > clk_cpumux_set_parent() always ensures validity in clk_cpumux_get_parent() > got called. > >

Re: [PATCH v5 1/2] clk: gate: expose clk_gate_ops::is_enabled

On 07/17, Gabriel FERNANDEZ wrote: > Hi Stephen, > > > On 07/14/2017 08:52 PM, kbuild test robot wrote: > > Hi Gabriel, > > > > [auto build test ERROR on clk/clk-next] > > [also build test ERROR on v4.12 next-20170714] > > [if your patch is applied to the wrong git tree, please drop us a note to

Re: [PATCH v5 1/2] clk: gate: expose clk_gate_ops::is_enabled

On 07/17, Gabriel FERNANDEZ wrote: > Hi Stephen, > > > On 07/14/2017 08:52 PM, kbuild test robot wrote: > > Hi Gabriel, > > > > [auto build test ERROR on clk/clk-next] > > [also build test ERROR on v4.12 next-20170714] > > [if your patch is applied to the wrong git tree, please drop us a note to

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

NFIG_BPF=y # CONFIG_BPF_SYSCALL is not set I have used the net-next tree from next-20170717 for today. -- Cheers, Stephen Rothwell

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

NFIG_BPF=y # CONFIG_BPF_SYSCALL is not set I have used the net-next tree from next-20170717 for today. -- Cheers, Stephen Rothwell

[REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

After updating my tape backup server to 4.12 I found that mtx had issues controlling the tape library. Good behavior: [root@backup2 ~]# mtx -f /dev/sg7 next 0 Unloading drive 0 into Storage Element 4...done Loading media from Storage Element 5 into drive 0...done Bad behavior: [root@backup2

[REGRESSION] 28676d869bbb (scsi: sg: check for valid direction before starting the request) breaks mtx tape library control

After updating my tape backup server to 4.12 I found that mtx had issues controlling the tape library. Good behavior: [root@backup2 ~]# mtx -f /dev/sg7 next 0 Unloading drive 0 into Storage Element 4...done Loading media from Storage Element 5 into drive 0...done Bad behavior: [root@backup2

Re: [PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI

Rob, 在 2017年07月18日 04:07, Rob Herring 写道: On Mon, Jul 17, 2017 at 04:14:28PM +0800, Caesar Wang wrote: This patch adds the MALI's power-model to set the IPA model to be used for power management. What's IPA? India Pale Ale or Intermediate Physical Address? IPA is intelligent Power

Re: [PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI

Rob, 在 2017年07月18日 04:07, Rob Herring 写道: On Mon, Jul 17, 2017 at 04:14:28PM +0800, Caesar Wang wrote: This patch adds the MALI's power-model to set the IPA model to be used for power management. What's IPA? India Pale Ale or Intermediate Physical Address? IPA is intelligent Power

fs/btrfs/ctree.c:5149: warning: 'found_key' is used uninitialized in this function

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: cb8c65ccff7f77d0285f1b126c72d37b2572c865 commit: 6974f0c4555e285ab217cee58b6e874f776ff409 include/linux/string.h: add the option of fortified string.h functions date: 5 days ago config:

fs/btrfs/ctree.c:5149: warning: 'found_key' is used uninitialized in this function

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: cb8c65ccff7f77d0285f1b126c72d37b2572c865 commit: 6974f0c4555e285ab217cee58b6e874f776ff409 include/linux/string.h: add the option of fortified string.h functions date: 5 days ago config:

Re: A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

Hi, Julian At 07/14/2017 11:01 PM, Julian Wollrath wrote: Hi, I reproduced it by the following command line: ...noapic acpi_sci=level... the original dmesg is: [0.00] tsc: Fast TSC calibration using PIT the broken dmesg is: [0.001000] tsc: PIT calibration matches HPET. 1

Re: A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

Hi, Julian At 07/14/2017 11:01 PM, Julian Wollrath wrote: Hi, I reproduced it by the following command line: ...noapic acpi_sci=level... the original dmesg is: [0.00] tsc: Fast TSC calibration using PIT the broken dmesg is: [0.001000] tsc: PIT calibration matches HPET. 1

[PATCH v2 2/2] staging: gs_fpgaboot: change char to u8

The bitstream storage variables were changed from char to u8 arrays to prevent issues such as negative lengths. This change makes the code compatible with the "data" field in "struct firmware" which is of type u8. Signed-off-by: Jacob von Chorus ---

[PATCH v2 2/2] staging: gs_fpgaboot: change char to u8

The bitstream storage variables were changed from char to u8 arrays to prevent issues such as negative lengths. This change makes the code compatible with the "data" field in "struct firmware" which is of type u8. Signed-off-by: Jacob von Chorus --- drivers/staging/gs_fpgaboot/gs_fpgaboot.c |

Re: [PATCH] perf tools: Add ARM Statistical Profiling Extensions (SPE) support

On Fri, 30 Jun 2017 15:02:41 +0100 Mark Rutland wrote: > Hi Kim, Hi Mark, > On Wed, Jun 28, 2017 at 08:43:10PM -0500, Kim Phillips wrote: > > if (evlist) { > > evlist__for_each_entry(evlist, evsel) { > > if (cs_etm_pmu && > >

Re: [PATCH] perf tools: Add ARM Statistical Profiling Extensions (SPE) support

On Fri, 30 Jun 2017 15:02:41 +0100 Mark Rutland wrote: > Hi Kim, Hi Mark, > On Wed, Jun 28, 2017 at 08:43:10PM -0500, Kim Phillips wrote: > > if (evlist) { > > evlist__for_each_entry(evlist, evsel) { > > if (cs_etm_pmu && > >

[PATCH v2 1/2] staging: gs_fpgaboot: add buffer overflow checks

Four fields in struct fpgaimage are char arrays of length MAX_STR (256). The amount of data read into these buffers is controlled by a length field in the bitstream file read from userspace. If a corrupt or malicious firmware file was supplied, kernel data beyond these buffers can be overwritten

[PATCH v2 1/2] staging: gs_fpgaboot: add buffer overflow checks

Four fields in struct fpgaimage are char arrays of length MAX_STR (256). The amount of data read into these buffers is controlled by a length field in the bitstream file read from userspace. If a corrupt or malicious firmware file was supplied, kernel data beyond these buffers can be overwritten

[PATCH] pci: quirk: Apply APM ACS quirk to XGene devices

The APM X-Gene PCIe root port does not support ACS at this point. Since the root does not allow peer to peer transactions, mask out ACS capability flag bits. Signed-off-by: Feng Kan --- drivers/pci/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/quirks.c

[PATCH] pci: quirk: Apply APM ACS quirk to XGene devices

The APM X-Gene PCIe root port does not support ACS at this point. Since the root does not allow peer to peer transactions, mask out ACS capability flag bits. Signed-off-by: Feng Kan --- drivers/pci/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/quirks.c

Re: Help with trace-cmd/ftrace recording process ID information

On Mon, 17 Jul 2017 18:31:14 -0400 Will Hawkins wrote: > > It may be that it stopped and never started again, so you will only > > have a stale file. > > This appears to have been the problem! I did a reboot and everything > is back to normal. > > Is there a way to

Re: Help with trace-cmd/ftrace recording process ID information

On Mon, 17 Jul 2017 18:31:14 -0400 Will Hawkins wrote: > > It may be that it stopped and never started again, so you will only > > have a stale file. > > This appears to have been the problem! I did a reboot and everything > is back to normal. > > Is there a way to poke at the tracing

Re: [PATCH v5 2/5] tick: Add freeze timer events

On Sat, Jul 15, 2017 at 5:39 AM, Rafael J. Wysocki wrote: > On Thursday, July 13, 2017 03:58:53 PM dbasehore . wrote: >> On Thu, Jul 13, 2017 at 8:09 AM, Rafael J. Wysocki wrote: >> > On Thu, Jul 13, 2017 at 9:32 AM, Peter Zijlstra

Re: [PATCH v5 2/5] tick: Add freeze timer events

On Sat, Jul 15, 2017 at 5:39 AM, Rafael J. Wysocki wrote: > On Thursday, July 13, 2017 03:58:53 PM dbasehore . wrote: >> On Thu, Jul 13, 2017 at 8:09 AM, Rafael J. Wysocki wrote: >> > On Thu, Jul 13, 2017 at 9:32 AM, Peter Zijlstra >> > wrote: >> >> On Fri, Jul 07, 2017 at 05:03:00PM -0700,

Re: [PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback mechanism

On Mon, Jul 17, 2017 at 06:20:37PM +0200, Greg KH wrote: > On Mon, Jul 17, 2017 at 06:04:33PM +0200, Luis R. Rodriguez wrote: > > On Mon, Jul 17, 2017 at 04:00:07PM +0200, Greg KH wrote: > > > On Thu, Jun 29, 2017 at 01:51:51PM -0700, Luis R. Rodriguez wrote: > > > > Right now we send -EAGAIN to a

Re: [PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback mechanism

On Mon, Jul 17, 2017 at 06:20:37PM +0200, Greg KH wrote: > On Mon, Jul 17, 2017 at 06:04:33PM +0200, Luis R. Rodriguez wrote: > > On Mon, Jul 17, 2017 at 04:00:07PM +0200, Greg KH wrote: > > > On Thu, Jun 29, 2017 at 01:51:51PM -0700, Luis R. Rodriguez wrote: > > > > Right now we send -EAGAIN to a

RE: 4.12 nf_conntrack_expect crash

Hi Jiri, > From: Jiri Slaby [mailto:jsl...@suse.cz] > Subject: Re: 4.12 nf_conntrack_expect crash > > On 07/17/2017, 04:49 PM, Jiri Slaby wrote: > > Hi, > > > > on my system, I see a crash in del_timer invoked in nf_conntrack_expect. > > See the attached picture. > > > > I somehow suspect this

RE: 4.12 nf_conntrack_expect crash

Hi Jiri, > From: Jiri Slaby [mailto:jsl...@suse.cz] > Subject: Re: 4.12 nf_conntrack_expect crash > > On 07/17/2017, 04:49 PM, Jiri Slaby wrote: > > Hi, > > > > on my system, I see a crash in del_timer invoked in nf_conntrack_expect. > > See the attached picture. > > > > I somehow suspect this

Re: [PATCH] staging: gs_fpgaboot: add buffer overflow checks

On Mon, Jul 17, 2017 at 10:53:25PM +0300, Dan Carpenter wrote: > > + if (len + 1 > n) { > > It's more idiomatic to say "if (len >= n)". Plus that's a good habbit My reasoning behind using "((len + 1) > n)" is that len represents the length of the string without null-termination. "buf" is

Re: [PATCH] staging: gs_fpgaboot: add buffer overflow checks

On Mon, Jul 17, 2017 at 10:53:25PM +0300, Dan Carpenter wrote: > > + if (len + 1 > n) { > > It's more idiomatic to say "if (len >= n)". Plus that's a good habbit My reasoning behind using "((len + 1) > n)" is that len represents the length of the string without null-termination. "buf" is

[PATCH v4] PM / suspend: Export pm_suspend_target_state

Have the core suspend/resume framework store the system-wide suspend state (suspend_state_t) we are about to enter, and expose it to drivers via pm_suspend_target_state in order to retrieve that. The state is assigned in suspend_devices_and_enter(). This is useful for platform specific drivers

[PATCH v4] PM / suspend: Export pm_suspend_target_state

Have the core suspend/resume framework store the system-wide suspend state (suspend_state_t) we are about to enter, and expose it to drivers via pm_suspend_target_state in order to retrieve that. The state is assigned in suspend_devices_and_enter(). This is useful for platform specific drivers

linux-next: manual merge of the btrfs-kdave tree with Linus' tree

Hi David, Today's linux-next merge of the btrfs-kdave tree got a conflict in: fs/btrfs/extent_io.c between commit: e6959b9350c6 ("btrfs: add support for passing in write hints for buffered writes") from Linus' tree and commit: 41a3f2a7c062 ("btrfs: merge REQ_OP and REQ_ flags to one

linux-next: manual merge of the btrfs-kdave tree with Linus' tree

Hi David, Today's linux-next merge of the btrfs-kdave tree got a conflict in: fs/btrfs/extent_io.c between commit: e6959b9350c6 ("btrfs: add support for passing in write hints for buffered writes") from Linus' tree and commit: 41a3f2a7c062 ("btrfs: merge REQ_OP and REQ_ flags to one

Re: What differences and relations between SVM, HSA, HMM and Unified Memory?

Hi Jérôme and Jean-Philippe , Get it, thanks for all of your detail explain. Thanks Yisheng Xie On 2017/7/17 22:27, Jerome Glisse wrote: > On Mon, Jul 17, 2017 at 07:57:23PM +0800, Yisheng Xie wrote: >> Hi Jean-Philippe， >> >> On 2017/6/12 19:37, Jean-Philippe Brucker wrote: >>> Hello, >>> >>>

Re: What differences and relations between SVM, HSA, HMM and Unified Memory?

Hi Jérôme and Jean-Philippe , Get it, thanks for all of your detail explain. Thanks Yisheng Xie On 2017/7/17 22:27, Jerome Glisse wrote: > On Mon, Jul 17, 2017 at 07:57:23PM +0800, Yisheng Xie wrote: >> Hi Jean-Philippe， >> >> On 2017/6/12 19:37, Jean-Philippe Brucker wrote: >>> Hello, >>> >>>

Re: [PATCH] kthread: Fix race condition between kthread_parkme() and kthread_unpark()

Hi, Has anyone been able to take a look at this? Thanks, Junaid On Tuesday, May 30, 2017 03:40:02 PM Andrew Morton wrote: > (cc tglx & tj) > > On Tue, 30 May 2017 15:37:23 -0700 Junaid Shahid wrote: > > > (Resending) > > > > On Friday, April 28, 2017 07:32:36 PM Junaid

Re: [PATCH] kthread: Fix race condition between kthread_parkme() and kthread_unpark()

Hi, Has anyone been able to take a look at this? Thanks, Junaid On Tuesday, May 30, 2017 03:40:02 PM Andrew Morton wrote: > (cc tglx & tj) > > On Tue, 30 May 2017 15:37:23 -0700 Junaid Shahid wrote: > > > (Resending) > > > > On Friday, April 28, 2017 07:32:36 PM Junaid Shahid wrote: > > >

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 11, 2017 at 8:32 AM, Kyle Huey wrote: > On Tue, Jul 11, 2017 at 2:03 AM, Ingo Molnar wrote: >> >> * Kyle Huey wrote: >> >>> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan >>> wrote: >>> > On Tue, Jul

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 11, 2017 at 8:32 AM, Kyle Huey wrote: > On Tue, Jul 11, 2017 at 2:03 AM, Ingo Molnar wrote: >> >> * Kyle Huey wrote: >> >>> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan >>> wrote: >>> > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: >>> >> Should any of those be moved

Re: [PATCH V6 0/7] crypto: AES CBC multibuffer implementation

Hi Herbert, Do you want any other changes to be made to this patchset? Thanks, Megha On Tue, 2017-06-27 at 17:26 -0700, Megha Dey wrote: > In this patch series, we introduce AES CBC encryption that is parallelized on > x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8 data >

Re: [PATCH V6 0/7] crypto: AES CBC multibuffer implementation

Hi Herbert, Do you want any other changes to be made to this patchset? Thanks, Megha On Tue, 2017-06-27 at 17:26 -0700, Megha Dey wrote: > In this patch series, we introduce AES CBC encryption that is parallelized on > x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8 data >

Re: [PATCH v2 3/3] DT: leds: Add Qualcomm Light Pulse Generator binding

On Mon 17 Jul 14:08 PDT 2017, Jacek Anaszewski wrote: > On 07/17/2017 06:44 AM, Bjorn Andersson wrote: > > On Sun 16 Jul 11:49 PDT 2017, Jacek Anaszewski wrote: > >> On 07/15/2017 12:45 AM, Bjorn Andersson wrote: > >>> diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt > >>>

Re: [PATCH v2 3/3] DT: leds: Add Qualcomm Light Pulse Generator binding

On Mon 17 Jul 14:08 PDT 2017, Jacek Anaszewski wrote: > On 07/17/2017 06:44 AM, Bjorn Andersson wrote: > > On Sun 16 Jul 11:49 PDT 2017, Jacek Anaszewski wrote: > >> On 07/15/2017 12:45 AM, Bjorn Andersson wrote: > >>> diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt > >>>

Re: [RFC PATCH 1/3] mm:hugetlb: Define system call hugetlb size encodings in single file

On Mon, Jul 17, 2017 at 03:27:59PM -0700, Mike Kravetz wrote: > +#define HUGETLB_FLAG_ENCODE_512KB(19 << MAP_HUGE_SHIFT > +#define HUGETLB_FLAG_ENCODE_1MB (20 << MAP_HUGE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_2MB (21 << MAP_HUGE_SHIFT) > +#define

Re: [RFC PATCH 1/3] mm:hugetlb: Define system call hugetlb size encodings in single file

On Mon, Jul 17, 2017 at 03:27:59PM -0700, Mike Kravetz wrote: > +#define HUGETLB_FLAG_ENCODE_512KB(19 << MAP_HUGE_SHIFT > +#define HUGETLB_FLAG_ENCODE_1MB (20 << MAP_HUGE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_2MB (21 << MAP_HUGE_SHIFT) > +#define

Re: [PATCH v5 4/4] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 07/17/17 at 04:13pm, Kees Cook wrote: > > +#ifdef CONFIG_EFI > > +/* > > + * Returns true if mirror region found (and must have been processed > > + * for slots adding) > > + */ > > +static bool process_efi_entries(unsigned long minimum, > > + unsigned long

Re: [PATCH v5 4/4] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 07/17/17 at 04:13pm, Kees Cook wrote: > > +#ifdef CONFIG_EFI > > +/* > > + * Returns true if mirror region found (and must have been processed > > + * for slots adding) > > + */ > > +static bool process_efi_entries(unsigned long minimum, > > + unsigned long

Re: [PATCH v2 1/3] leds: core: Introduce generic pattern interface

On Mon 17 Jul 14:08 PDT 2017, Jacek Anaszewski wrote: > On 07/16/2017 11:14 PM, Bjorn Andersson wrote: > > On Sun 16 Jul 11:49 PDT 2017, Jacek Anaszewski wrote: > >> On 07/06/2017 05:18 AM, Pavel Machek wrote: [..] > >> I've been working on addition of RGB LED support to the LED core for > >>

Re: [PATCH v2 1/3] leds: core: Introduce generic pattern interface

On Mon 17 Jul 14:08 PDT 2017, Jacek Anaszewski wrote: > On 07/16/2017 11:14 PM, Bjorn Andersson wrote: > > On Sun 16 Jul 11:49 PDT 2017, Jacek Anaszewski wrote: > >> On 07/06/2017 05:18 AM, Pavel Machek wrote: [..] > >> I've been working on addition of RGB LED support to the LED core for > >>

Re: [PATCH 10/10] percpu: add optimizations on allocation path for the bitmap allocator

On Sat, Jul 15, 2017 at 10:23:15PM -0400, Dennis Zhou wrote: > From: "Dennis Zhou (Facebook)" > > This patch adds two optimizations to the allocation path. The first is > to not consider a chunk if the requested allocation cannot fit in the > chunk's contig_hint. The

Re: [PATCH v3] PM / suspend: Export pm_suspend_target_state

On Monday, July 17, 2017 03:10:59 PM Florian Fainelli wrote: > Have the core suspend/resume framework store the system-wide suspend > state (suspend_state_t) we are about to enter, and expose it to drivers > via pm_suspend_target_state in order to retrieve that. The state is > assigned in

Re: [PATCH 10/10] percpu: add optimizations on allocation path for the bitmap allocator

On Sat, Jul 15, 2017 at 10:23:15PM -0400, Dennis Zhou wrote: > From: "Dennis Zhou (Facebook)" > > This patch adds two optimizations to the allocation path. The first is > to not consider a chunk if the requested allocation cannot fit in the > chunk's contig_hint. The benefit is that this avoids

Re: [PATCH v3] PM / suspend: Export pm_suspend_target_state

On Monday, July 17, 2017 03:10:59 PM Florian Fainelli wrote: > Have the core suspend/resume framework store the system-wide suspend > state (suspend_state_t) we are about to enter, and expose it to drivers > via pm_suspend_target_state in order to retrieve that. The state is > assigned in

Re: [PATCH 09/10] percpu: replace area map allocator with bitmap allocator

On Sat, Jul 15, 2017 at 10:23:14PM -0400, Dennis Zhou wrote: ... > While it does add to the allocation latency, the allocation scenario > here is optimal for the area map allocator. The second problem of > additional scanning can result in the area map allocator completing in > 52 minutes. The

Re: [PATCH 09/10] percpu: replace area map allocator with bitmap allocator

On Sat, Jul 15, 2017 at 10:23:14PM -0400, Dennis Zhou wrote: ... > While it does add to the allocation latency, the allocation scenario > here is optimal for the area map allocator. The second problem of > additional scanning can result in the area map allocator completing in > 52 minutes. The

Re: [PATCH] HID: Add quirk for Lenovo Yoga 910 with ITE Chips

On Mon, 2017-07-17 at 13:19 -0700, Srinivas Pandruvada wrote: > On Sat, 2017-07-15 at 22:05 +0200, Patrick wrote: > > On Sat, Jul 15, 2017 at 07:58:10PM +0200, Bastien Nocera wrote: > > > > > > On Sat, 2017-07-15 at 19:52 +0200, Patrick Pedersen wrote: > > > > > > > > On Sat, Jul 15, 2017 at

Re: [PATCH] HID: Add quirk for Lenovo Yoga 910 with ITE Chips

On Mon, 2017-07-17 at 13:19 -0700, Srinivas Pandruvada wrote: > On Sat, 2017-07-15 at 22:05 +0200, Patrick wrote: > > On Sat, Jul 15, 2017 at 07:58:10PM +0200, Bastien Nocera wrote: > > > > > > On Sat, 2017-07-15 at 19:52 +0200, Patrick Pedersen wrote: > > > > > > > > On Sat, Jul 15, 2017 at

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Tue, Jul 11, 2017 at 9:27 AM, Daniel Vetter wrote: > On Tue, Jul 11, 2017 at 5:44 PM, John Stultz wrote: >> On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote: >>> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Tue, Jul 11, 2017 at 9:27 AM, Daniel Vetter wrote: > On Tue, Jul 11, 2017 at 5:44 PM, John Stultz wrote: >> On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote: >>> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote: >> > be even better if you could calculate whether the mode is valid,

Fedora 26 / Kernel 4.11.10 - System becomes unresponsive when swapping

Hi all, Firstly, please CC me directly in replies due to not being subscribed. After a fix to glibc that fixed Unity 3D based games (Fedora ref: https:// bugzilla.redhat.com/show_bug.cgi?id=1440287), I have noticed that when I play Cities: Skylines that the system becomes unresponsive when

Fedora 26 / Kernel 4.11.10 - System becomes unresponsive when swapping

Hi all, Firstly, please CC me directly in replies due to not being subscribed. After a fix to glibc that fixed Unity 3D based games (Fedora ref: https:// bugzilla.redhat.com/show_bug.cgi?id=1440287), I have noticed that when I play Cities: Skylines that the system becomes unresponsive when

Re: [PATCH v5 4/4] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On Thu, Jul 13, 2017 at 7:19 AM, Baoquan He wrote: > Kernel text may be located in non-mirror regions (movable zone) when both > address range mirroring feature and KASLR are enabled. > > The address range mirroring feature arranges such mirror region into > normal zone and other

Re: [PATCH v5 4/4] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On Thu, Jul 13, 2017 at 7:19 AM, Baoquan He wrote: > Kernel text may be located in non-mirror regions (movable zone) when both > address range mirroring feature and KASLR are enabled. > > The address range mirroring feature arranges such mirror region into > normal zone and other region into

Re: [PATCH 2/6] f2fs: make max inline size changeable

Hi Chao, On 07/16, Chao Yu wrote: > From: Chao Yu > > This patch tries to make below macros calculating max inline size, > inline dentry field size considerring reserving size-changeable > space: > - MAX_INLINE_DATA > - NR_INLINE_DENTRY > - INLINE_DENTRY_BITMAP_SIZE > -

Re: [PATCH 2/6] f2fs: make max inline size changeable

Hi Chao, On 07/16, Chao Yu wrote: > From: Chao Yu > > This patch tries to make below macros calculating max inline size, > inline dentry field size considerring reserving size-changeable > space: > - MAX_INLINE_DATA > - NR_INLINE_DENTRY > - INLINE_DENTRY_BITMAP_SIZE > - INLINE_RESERVED_SIZE >

[PATCH linux v5 3/3] drivers: w1: add hwmon temp support for w1_therm

This change adds hwmon temp support for w1_therm. Signed-off-by: Jaghathiswari Rankappagounder Natarajan Acked-by: Evgeniy Polyakov Acked-by: Guenter Roeck --- v2 - make changes to support hwmon_device_register_with_info mentioned by

[PATCH linux v5 3/3] drivers: w1: add hwmon temp support for w1_therm

This change adds hwmon temp support for w1_therm. Signed-off-by: Jaghathiswari Rankappagounder Natarajan Acked-by: Evgeniy Polyakov Acked-by: Guenter Roeck --- v2 - make changes to support hwmon_device_register_with_info mentioned by Guenter. v3 - used IS_REACHABLE() - rearranged the code to

[PATCH linux v5 2/3] drivers: w1: refactor w1_slave_show to make the temp reading functionality separate

Inside the w1_slave_show function refactor the code to read the temp into a separate function. Signed-off-by: Jaghathiswari Rankappagounder Natarajan Acked-by: Guenter Roeck Acked-by: Evgeniy Polyakov --- v2 - made changes to support

[PATCH linux v5 2/3] drivers: w1: refactor w1_slave_show to make the temp reading functionality separate

Inside the w1_slave_show function refactor the code to read the temp into a separate function. Signed-off-by: Jaghathiswari Rankappagounder Natarajan Acked-by: Guenter Roeck Acked-by: Evgeniy Polyakov --- v2 - made changes to support hwmon_device_register_with_info mentioned by Guenter. v3 -

[PATCH linux v5 1/3] drivers: w1: add hwmon support structures

This patch has changes to w1.h/w1.c/w1_family.h generic files to add (optional) hwmon support structures. Signed-off-by: Jaghathiswari Rankappagounder Natarajan Acked-by: Evgeniy Polyakov Acked-by: Guenter Roeck --- v2 - made changes to

[PATCH linux v5 1/3] drivers: w1: add hwmon support structures

This patch has changes to w1.h/w1.c/w1_family.h generic files to add (optional) hwmon support structures. Signed-off-by: Jaghathiswari Rankappagounder Natarajan Acked-by: Evgeniy Polyakov Acked-by: Guenter Roeck --- v2 - made changes to support hwmon_device_register_with_info mentioned by

[PATCH linux v5 0/3] Export 1-wire thermal sensors as hwmon device

Hi Greg, Please pull in this patchset into the tree. Thanks! Summary of what this patchset does: Our board has 4 DS18B20 1-wire temperature sensors. Each 1-wire bus and the sensor under it is already configured against the Linux 1-wire driver (called w1). They have a sysfs file(e.g.

[PATCH linux v5 0/3] Export 1-wire thermal sensors as hwmon device

Hi Greg, Please pull in this patchset into the tree. Thanks! Summary of what this patchset does: Our board has 4 DS18B20 1-wire temperature sensors. Each 1-wire bus and the sensor under it is already configured against the Linux 1-wire driver (called w1). They have a sysfs file(e.g.

Re: [PATCH] nvme: Acknowledge completion queue on each iteration

On 2017-07-17 18:56, Keith Busch wrote: On Mon, Jul 17, 2017 at 06:46:11PM -0400, Sinan Kaya wrote: Hi Keith, On 7/17/2017 6:45 PM, Keith Busch wrote: > On Mon, Jul 17, 2017 at 06:36:23PM -0400, Sinan Kaya wrote: >> Code is moving the completion queue doorbell after processing all completed >>

Re: [PATCH] nvme: Acknowledge completion queue on each iteration

On 2017-07-17 18:56, Keith Busch wrote: On Mon, Jul 17, 2017 at 06:46:11PM -0400, Sinan Kaya wrote: Hi Keith, On 7/17/2017 6:45 PM, Keith Busch wrote: > On Mon, Jul 17, 2017 at 06:36:23PM -0400, Sinan Kaya wrote: >> Code is moving the completion queue doorbell after processing all completed >>

Re: [PATCH v4 1/2] wire: export w1_touch_bit

Am 17.07.2017 um 16:47 schrieb Greg Kroah-Hartman: > > This is in no format that I can apply, sorry. > > Jan, can you resend it in a correct format? > I sent part 1/2 again with the line breaks fixed (I hope.) Part 2/2 was okay? Kind regards Jan

Re: [PATCH v4 1/2] wire: export w1_touch_bit

Am 17.07.2017 um 16:47 schrieb Greg Kroah-Hartman: > > This is in no format that I can apply, sorry. > > Jan, can you resend it in a correct format? > I sent part 1/2 again with the line breaks fixed (I hope.) Part 2/2 was okay? Kind regards Jan

[PATCH v4 1/2] wire: export w1_touch_bit (RESEND: line breaks fixed, I hope.)

Changes in v4 against v3 in this subpatch: - adapted to linux-4.12.0 No changes in v3 against v2,v1 in this subpatch. The w1_ds28e17 driver from the next part of this patch needs to emit single-bit read timeslots to the DS28E17. The w1 subsystem already has this function but it is not exported

[PATCH v4 1/2] wire: export w1_touch_bit (RESEND: line breaks fixed, I hope.)

Changes in v4 against v3 in this subpatch: - adapted to linux-4.12.0 No changes in v3 against v2,v1 in this subpatch. The w1_ds28e17 driver from the next part of this patch needs to emit single-bit read timeslots to the DS28E17. The w1 subsystem already has this function but it is not exported

Re: [PATCH] exec: Check stack space more strictly

On Mon, Jul 17, 2017 at 3:22 PM, Andy Lutomirski wrote: > We can currently blow past the stack rlimit and cause odd behavior > if there are accounting bugs, rounding issues, or races. It's not > clear that the odd behavior is actually a problem, but it's nicer to > fail the exec

Re: [PATCH] exec: Check stack space more strictly

On Mon, Jul 17, 2017 at 3:22 PM, Andy Lutomirski wrote: > We can currently blow past the stack rlimit and cause odd behavior > if there are accounting bugs, rounding issues, or races. It's not > clear that the odd behavior is actually a problem, but it's nicer to > fail the exec instead of

Re: [PATCH] nvme: Acknowledge completion queue on each iteration

On Mon, Jul 17, 2017 at 06:46:11PM -0400, Sinan Kaya wrote: > Hi Keith, > > On 7/17/2017 6:45 PM, Keith Busch wrote: > > On Mon, Jul 17, 2017 at 06:36:23PM -0400, Sinan Kaya wrote: > >> Code is moving the completion queue doorbell after processing all completed > >> events and sending callbacks

Re: [PATCH] nvme: Acknowledge completion queue on each iteration

On Mon, Jul 17, 2017 at 06:46:11PM -0400, Sinan Kaya wrote: > Hi Keith, > > On 7/17/2017 6:45 PM, Keith Busch wrote: > > On Mon, Jul 17, 2017 at 06:36:23PM -0400, Sinan Kaya wrote: > >> Code is moving the completion queue doorbell after processing all completed > >> events and sending callbacks

Re: [PATCH] nvme: Acknowledge completion queue on each iteration

Hi Keith, On 7/17/2017 6:45 PM, Keith Busch wrote: > On Mon, Jul 17, 2017 at 06:36:23PM -0400, Sinan Kaya wrote: >> Code is moving the completion queue doorbell after processing all completed >> events and sending callbacks to the block layer on each iteration. >> >> This is causing a performance

Re: [PATCH] nvme: Acknowledge completion queue on each iteration

Hi Keith, On 7/17/2017 6:45 PM, Keith Busch wrote: > On Mon, Jul 17, 2017 at 06:36:23PM -0400, Sinan Kaya wrote: >> Code is moving the completion queue doorbell after processing all completed >> events and sending callbacks to the block layer on each iteration. >> >> This is causing a performance

Re: [PATCH] nvme: Acknowledge completion queue on each iteration

On Mon, Jul 17, 2017 at 06:36:23PM -0400, Sinan Kaya wrote: > Code is moving the completion queue doorbell after processing all completed > events and sending callbacks to the block layer on each iteration. > > This is causing a performance drop when a lot of jobs are queued towards > the HW.

Re: [PATCH] nvme: Acknowledge completion queue on each iteration

On Mon, Jul 17, 2017 at 06:36:23PM -0400, Sinan Kaya wrote: > Code is moving the completion queue doorbell after processing all completed > events and sending callbacks to the block layer on each iteration. > > This is causing a performance drop when a lot of jobs are queued towards > the HW.

Re: [f2fs-dev] [PATCH v2] f2fs: avoid cpu lockup

On 07/17, Chao Yu wrote: > On 2017/7/16 9:04, Jaegeuk Kim wrote: > > Before retrying to flush data or dentry pages, we need to release cpu in > > order > > to prevent watchdog. > > > > Signed-off-by: Jaegeuk Kim > > Reviewed-by: Chao Yu > > > --- > >

Re: [f2fs-dev] [PATCH v2] f2fs: avoid cpu lockup

On 07/17, Chao Yu wrote: > On 2017/7/16 9:04, Jaegeuk Kim wrote: > > Before retrying to flush data or dentry pages, we need to release cpu in > > order > > to prevent watchdog. > > > > Signed-off-by: Jaegeuk Kim > > Reviewed-by: Chao Yu > > > --- > > Change log from v1: > > - timeout more

[PATCH] nvme: Acknowledge completion queue on each iteration

Code is moving the completion queue doorbell after processing all completed events and sending callbacks to the block layer on each iteration. This is causing a performance drop when a lot of jobs are queued towards the HW. Move the completion queue doorbell on each loop instead and allow new

[PATCH] nvme: Acknowledge completion queue on each iteration

Code is moving the completion queue doorbell after processing all completed events and sending callbacks to the block layer on each iteration. This is causing a performance drop when a lot of jobs are queued towards the HW. Move the completion queue doorbell on each loop instead and allow new

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