[PATCH 2/4] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

From: Len Brown The goal of this change is to give users a uniform and meaningful result when they read /sys/...cpufreq/scaling_cur_freq on modern x86 hardware, as compared to what they get today. Modern x86 processors include the hardware needed to accurately calculate

[PATCH 2/4] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

From: Len Brown The goal of this change is to give users a uniform and meaningful result when they read /sys/...cpufreq/scaling_cur_freq on modern x86 hardware, as compared to what they get today. Modern x86 processors include the hardware needed to accurately calculate frequency over an

Re: [PATCH v4 4/5] watchdog: provide watchdog_reconfigure() for arch watchdogs

On Fri, 16 Jun 2017 11:24:07 -0700 Andrew Morton wrote: > On Fri, 16 Jun 2017 16:57:14 +1000 Nicholas Piggin wrote: > > > After reconfiguring watchdog sysctls etc., architecture specific > > watchdogs may not get all their parameters updated. > >

Re: [PATCH v4 4/5] watchdog: provide watchdog_reconfigure() for arch watchdogs

On Fri, 16 Jun 2017 11:24:07 -0700 Andrew Morton wrote: > On Fri, 16 Jun 2017 16:57:14 +1000 Nicholas Piggin wrote: > > > After reconfiguring watchdog sysctls etc., architecture specific > > watchdogs may not get all their parameters updated. > > > > watchdog_reconfigure() can be implemented

[PATCH V3] staging: vt6655 - style fix

Fix checkpatch.pl warnings of the form "function definition argument 'foo' should also have an identifier name" in header files. Signed-off-by: Derek Robson V1 and V2 had vague subject line --- drivers/staging/vt6655/card.h| 30 ++---

[PATCH V3] staging: vt6655 - style fix

Fix checkpatch.pl warnings of the form "function definition argument 'foo' should also have an identifier name" in header files. Signed-off-by: Derek Robson V1 and V2 had vague subject line --- drivers/staging/vt6655/card.h| 30 ++--- drivers/staging/vt6655/channel.h | 4

[git pull] vfs fixes

A couple of fixes; a leak in mntns_install() caught by Andrei (this cycle regression) + d_invalidate() softlockup fix - that had been reported by a bunch of people lately, but the problem is pretty old. The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452: Linux

[git pull] vfs fixes

A couple of fixes; a leak in mntns_install() caught by Andrei (this cycle regression) + d_invalidate() softlockup fix - that had been reported by a bunch of people lately, but the problem is pretty old. The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452: Linux

[PATCH V2] staging: ccree: - style fix, spaces and tabs

Changed code indent to be tabs across whole driver Found using checkpatch Signed-off-by: Derek Robson V1 had vague subject. --- drivers/staging/ccree/ssi_cipher.c | 45 +- drivers/staging/ccree/ssi_driver.c | 6 ++---

[PATCH V2] staging: ccree: - style fix, spaces and tabs

Changed code indent to be tabs across whole driver Found using checkpatch Signed-off-by: Derek Robson V1 had vague subject. --- drivers/staging/ccree/ssi_cipher.c | 45 +- drivers/staging/ccree/ssi_driver.c | 6 ++--- drivers/staging/ccree/ssi_driver.h

Re: [PATCH v4 2/5] watchdog: introduce arch_touch_nmi_watchdog()

On Fri, 16 Jun 2017 11:21:17 -0700 Andrew Morton wrote: > On Fri, 16 Jun 2017 16:57:12 +1000 Nicholas Piggin wrote: > > > For architectures that define HAVE_NMI_WATCHDOG, instead of having > > them provide the complete touch_nmi_watchdog()

Re: [PATCH v4 2/5] watchdog: introduce arch_touch_nmi_watchdog()

On Fri, 16 Jun 2017 11:21:17 -0700 Andrew Morton wrote: > On Fri, 16 Jun 2017 16:57:12 +1000 Nicholas Piggin wrote: > > > For architectures that define HAVE_NMI_WATCHDOG, instead of having > > them provide the complete touch_nmi_watchdog() function, just have > > them provide

Re: [git pull] first batch of ufs fixes

On Fri, Jun 16, 2017 at 07:29:00AM -0700, Richard Narron wrote: > The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5. > They seem to work fine with the simple testing that I do. > > I tested all 3 BSDs, FreeBSD 11.0, OpenBSD 6.1 and NetBSD 7.1 using 2 > filesystems, 44bsd (ufs1)

Re: [git pull] first batch of ufs fixes

On Fri, Jun 16, 2017 at 07:29:00AM -0700, Richard Narron wrote: > The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5. > They seem to work fine with the simple testing that I do. > > I tested all 3 BSDs, FreeBSD 11.0, OpenBSD 6.1 and NetBSD 7.1 using 2 > filesystems, 44bsd (ufs1)

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

> On a second thought, in order to compute the frequency, user space > needs to know the scaling and the max_pstate_physical value too, which > may not be straightforward to obtain (on some Atoms, for example). unless you run turbostat:-) > So why don't we leave the tracepoint as is for now?

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

> On a second thought, in order to compute the frequency, user space > needs to know the scaling and the max_pstate_physical value too, which > may not be straightforward to obtain (on some Atoms, for example). unless you run turbostat:-) > So why don't we leave the tracepoint as is for now?

Re: [PATCH 30/31] ext4: eliminate xattr entry e_hash recalculation for removes

On Thu, Jun 15, 2017 at 2:10 AM, Jan Kara wrote: > I agree with moving ext4_xattr_rehash_entry() out of ext4_xattr_rehash(). > However how about just keeping ext4_xattr_rehash() in > ext4_xattr_block_set() (so that you don't have to pass aditional argument > to

Re: [PATCH 30/31] ext4: eliminate xattr entry e_hash recalculation for removes

On Thu, Jun 15, 2017 at 2:10 AM, Jan Kara wrote: > I agree with moving ext4_xattr_rehash_entry() out of ext4_xattr_rehash(). > However how about just keeping ext4_xattr_rehash() in > ext4_xattr_block_set() (so that you don't have to pass aditional argument > to ext4_xattr_set_entry()) and calling

Re: [PATCH 28/28] quota: add extra inode count to dquot transfer functions

On Thu, Jun 15, 2017 at 12:57 AM, Jan Kara wrote: > Hum, rather handle this similarly to how we handle delalloc reserved space. > Add a callback to dq_ops to get "inode usage" of an inode and then use it > in dquot_transfer(), dquot_free_inode(), dquot_alloc_inode(). I tried that

Re: [PATCH 28/28] quota: add extra inode count to dquot transfer functions

On Thu, Jun 15, 2017 at 12:57 AM, Jan Kara wrote: > Hum, rather handle this similarly to how we handle delalloc reserved space. > Add a callback to dq_ops to get "inode usage" of an inode and then use it > in dquot_transfer(), dquot_free_inode(), dquot_alloc_inode(). I tried that approach by

Re: [PATCH 2/5] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

On Fri, Jun 16, 2017 at 8:30 PM, Rafael J. Wysocki wrote: > On Wednesday, June 07, 2017 07:39:13 PM Len Brown wrote: >> From: Len Brown >> >> The goal of this change is to give users a uniform and meaningful >> result when they read

Re: [PATCH 2/5] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

On Fri, Jun 16, 2017 at 8:30 PM, Rafael J. Wysocki wrote: > On Wednesday, June 07, 2017 07:39:13 PM Len Brown wrote: >> From: Len Brown >> >> The goal of this change is to give users a uniform and meaningful >> result when they read /sys/...cpufreq/scaling_cur_freq >> on modern x86 hardware, as

Re: [PATCH v2 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf

2017-06-16 23:38 GMT+08:00 Radim Krčmář : > 2017-06-16 22:24+0800, Wanpeng Li: >> 2017-06-16 21:37 GMT+08:00 Radim Krčmář : >> > 2017-06-14 19:26-0700, Wanpeng Li: >> >> From: Wanpeng Li >> >> >> >> Add an async_page_fault field to

Re: [PATCH v2 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf

2017-06-16 23:38 GMT+08:00 Radim Krčmář : > 2017-06-16 22:24+0800, Wanpeng Li: >> 2017-06-16 21:37 GMT+08:00 Radim Krčmář : >> > 2017-06-14 19:26-0700, Wanpeng Li: >> >> From: Wanpeng Li >> >> >> >> Add an async_page_fault field to vcpu->arch.exception to identify an async >> >> page fault, and

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Sat, Jun 17, 2017 at 3:21 AM, Rafael J. Wysocki wrote: > On Friday, June 16, 2017 09:10:39 PM Len Brown wrote: >> >> >> - get_avg_frequency(cpu), >> >> >> + aperfmperf_khz_on_cpu(cpu->cpu), >> >> >> >> Note that I deleted the line above in an updated

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Sat, Jun 17, 2017 at 3:21 AM, Rafael J. Wysocki wrote: > On Friday, June 16, 2017 09:10:39 PM Len Brown wrote: >> >> >> - get_avg_frequency(cpu), >> >> >> + aperfmperf_khz_on_cpu(cpu->cpu), >> >> >> >> Note that I deleted the line above in an updated version of this

Re: [PATCH 4/5] intel_pstate: skip scheduler hook when in "performance" mode.

sorry, that was a premature send... >>> > What about update_turbo_pstate()? >>> > >>> > In theory MSR_IA32_MISC_ENABLE_TURBO_DISABLE can be set at any time, so >>> > wouldn't that become problematic after this change? >>> >>> yes, the sysfs "no_turbo" attribute can be modified at any time,

Re: [PATCH 4/5] intel_pstate: skip scheduler hook when in "performance" mode.

sorry, that was a premature send... >>> > What about update_turbo_pstate()? >>> > >>> > In theory MSR_IA32_MISC_ENABLE_TURBO_DISABLE can be set at any time, so >>> > wouldn't that become problematic after this change? >>> >>> yes, the sysfs "no_turbo" attribute can be modified at any time,

Re: [PATCH v7 21/26] x86: Add emulation code for UMIP instructions

On Thu, 2017-06-08 at 20:38 +0200, Borislav Petkov wrote: > On Fri, May 05, 2017 at 11:17:19AM -0700, Ricardo Neri wrote: > > The feature User-Mode Instruction Prevention present in recent Intel > > processor prevents a group of instructions from being executed with > > CPL > 0. Otherwise, a

Re: [PATCH v7 21/26] x86: Add emulation code for UMIP instructions

On Thu, 2017-06-08 at 20:38 +0200, Borislav Petkov wrote: > On Fri, May 05, 2017 at 11:17:19AM -0700, Ricardo Neri wrote: > > The feature User-Mode Instruction Prevention present in recent Intel > > processor prevents a group of instructions from being executed with > > CPL > 0. Otherwise, a

Re: [PATCH 4/5] intel_pstate: skip scheduler hook when in "performance" mode.

On Fri, Jun 16, 2017 at 9:06 PM, Rafael J. Wysocki wrote: > On Friday, June 16, 2017 08:52:53 PM Len Brown wrote: >> On Fri, Jun 16, 2017 at 8:04 PM, Rafael J. Wysocki >> wrote: >> > On Wednesday, June 07, 2017 07:39:15 PM Len Brown wrote: >> >> From: Len

Re: [PATCH 4/5] intel_pstate: skip scheduler hook when in "performance" mode.

On Fri, Jun 16, 2017 at 9:06 PM, Rafael J. Wysocki wrote: > On Friday, June 16, 2017 08:52:53 PM Len Brown wrote: >> On Fri, Jun 16, 2017 at 8:04 PM, Rafael J. Wysocki >> wrote: >> > On Wednesday, June 07, 2017 07:39:15 PM Len Brown wrote: >> >> From: Len Brown >> >> >> >> When the governor is

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Friday, June 16, 2017 09:10:39 PM Len Brown wrote: > >> >> - get_avg_frequency(cpu), > >> >> + aperfmperf_khz_on_cpu(cpu->cpu), > >> > >> Note that I deleted the line above in an updated version of this patch > >> that I'm ready to send out. > >> > >> There were a couple

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Friday, June 16, 2017 09:10:39 PM Len Brown wrote: > >> >> - get_avg_frequency(cpu), > >> >> + aperfmperf_khz_on_cpu(cpu->cpu), > >> > >> Note that I deleted the line above in an updated version of this patch > >> that I'm ready to send out. > >> > >> There were a couple

Re: [PATCH 5/5] intel_pstate: delete scheduler hook in HWP mode

On Fri, Jun 16, 2017 at 8:09 PM, Rafael J. Wysocki wrote: > On Wednesday, June 07, 2017 07:39:16 PM Len Brown wrote: >> From: Len Brown >> >> The cpufreqa/scaling_cur_freq sysfs attribute is now provided by >> the x86 cpufreq core on all modern x86

Re: [PATCH 5/5] intel_pstate: delete scheduler hook in HWP mode

On Fri, Jun 16, 2017 at 8:09 PM, Rafael J. Wysocki wrote: > On Wednesday, June 07, 2017 07:39:16 PM Len Brown wrote: >> From: Len Brown >> >> The cpufreqa/scaling_cur_freq sysfs attribute is now provided by >> the x86 cpufreq core on all modern x86 systems, including >> all systems supported by

[RFC PATCH 0/2] daxfile: enable byte-addressable updates to pmem

Quoting PATCH 2/2: To date, the full promise of byte-addressable access to persistent memory has only been half realized via the filesystem-dax interface. The current filesystem-dax mechanism allows an application to consume (read) data from persistent storage at byte-size

[RFC PATCH 1/2] mm: introduce bmap_walk()

Refactor the core of generic_swapfile_activate() into bmap_walk() so that it can be used by a new daxfile_activate() helper (to be added). There should be no functional differences as a result of this change, although it does add the capability to perform the bmap with a given page-size. This is

[RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

To date, the full promise of byte-addressable access to persistent memory has only been half realized via the filesystem-dax interface. The current filesystem-dax mechanism allows an application to consume (read) data from persistent storage at byte-size granularity, bypassing the full page reads

[RFC PATCH 0/2] daxfile: enable byte-addressable updates to pmem

Quoting PATCH 2/2: To date, the full promise of byte-addressable access to persistent memory has only been half realized via the filesystem-dax interface. The current filesystem-dax mechanism allows an application to consume (read) data from persistent storage at byte-size

[RFC PATCH 1/2] mm: introduce bmap_walk()

Refactor the core of generic_swapfile_activate() into bmap_walk() so that it can be used by a new daxfile_activate() helper (to be added). There should be no functional differences as a result of this change, although it does add the capability to perform the bmap with a given page-size. This is

[RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

To date, the full promise of byte-addressable access to persistent memory has only been half realized via the filesystem-dax interface. The current filesystem-dax mechanism allows an application to consume (read) data from persistent storage at byte-size granularity, bypassing the full page reads

Re: [PATCH 4/5] intel_pstate: skip scheduler hook when in "performance" mode.

On Friday, June 16, 2017 08:52:53 PM Len Brown wrote: > On Fri, Jun 16, 2017 at 8:04 PM, Rafael J. Wysocki wrote: > > On Wednesday, June 07, 2017 07:39:15 PM Len Brown wrote: > >> From: Len Brown > >> > >> When the governor is set to "performance",

Re: [PATCH 4/5] intel_pstate: skip scheduler hook when in "performance" mode.

On Friday, June 16, 2017 08:52:53 PM Len Brown wrote: > On Fri, Jun 16, 2017 at 8:04 PM, Rafael J. Wysocki wrote: > > On Wednesday, June 07, 2017 07:39:15 PM Len Brown wrote: > >> From: Len Brown > >> > >> When the governor is set to "performance", intel_pstate does not > >> need the scheduler

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

>> >> - get_avg_frequency(cpu), >> >> + aperfmperf_khz_on_cpu(cpu->cpu), >> >> Note that I deleted the line above in an updated version of this patch >> that I'm ready to send out. >> >> There were a couple of problems with it. >> The first is that it was ugly that tracing

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

>> >> - get_avg_frequency(cpu), >> >> + aperfmperf_khz_on_cpu(cpu->cpu), >> >> Note that I deleted the line above in an updated version of this patch >> that I'm ready to send out. >> >> There were a couple of problems with it. >> The first is that it was ugly that tracing

Re: [PATCH 4/5] intel_pstate: skip scheduler hook when in "performance" mode.

On Fri, Jun 16, 2017 at 8:04 PM, Rafael J. Wysocki wrote: > On Wednesday, June 07, 2017 07:39:15 PM Len Brown wrote: >> From: Len Brown >> >> When the governor is set to "performance", intel_pstate does not >> need the scheduler hook for doing any

Re: [PATCH 4/5] intel_pstate: skip scheduler hook when in "performance" mode.

On Fri, Jun 16, 2017 at 8:04 PM, Rafael J. Wysocki wrote: > On Wednesday, June 07, 2017 07:39:15 PM Len Brown wrote: >> From: Len Brown >> >> When the governor is set to "performance", intel_pstate does not >> need the scheduler hook for doing any calculations. Under these >> conditions, its

RE: [PATCH v2] libnvdimm, pmem: Add sysfs notifications to badblocks

> On Fri, Jun 16, 2017 at 5:35 PM, Kani, Toshimitsu wrote: > >> On Mon, Jun 12, 2017 at 3:25 PM, Toshi Kani wrote: > >> > Sysfs "badblocks" information may be updated during run-time that: > >> > - MCE, SCI, and sysfs "scrub" may add new bad blocks > >> >

RE: [PATCH v2] libnvdimm, pmem: Add sysfs notifications to badblocks

> On Fri, Jun 16, 2017 at 5:35 PM, Kani, Toshimitsu wrote: > >> On Mon, Jun 12, 2017 at 3:25 PM, Toshi Kani wrote: > >> > Sysfs "badblocks" information may be updated during run-time that: > >> > - MCE, SCI, and sysfs "scrub" may add new bad blocks > >> > - Writes and ioctl() may clear bad

Re: [PATCH v2] libnvdimm, pmem: Add sysfs notifications to badblocks

On Fri, Jun 16, 2017 at 5:35 PM, Kani, Toshimitsu wrote: >> On Mon, Jun 12, 2017 at 3:25 PM, Toshi Kani wrote: >> > Sysfs "badblocks" information may be updated during run-time that: >> > - MCE, SCI, and sysfs "scrub" may add new bad blocks >> > - Writes

Re: [PATCH v2] libnvdimm, pmem: Add sysfs notifications to badblocks

On Fri, Jun 16, 2017 at 5:35 PM, Kani, Toshimitsu wrote: >> On Mon, Jun 12, 2017 at 3:25 PM, Toshi Kani wrote: >> > Sysfs "badblocks" information may be updated during run-time that: >> > - MCE, SCI, and sysfs "scrub" may add new bad blocks >> > - Writes and ioctl() may clear bad blocks >> >

RE: [PATCH v2 2/2] acpi/nfit: Issue Start ARS to retrieve existing records

> On Fri, Jun 16, 2017 at 5:01 PM, Kani, Toshimitsu wrote: > >> > --- a/drivers/acpi/nfit/core.c > >> > +++ b/drivers/acpi/nfit/core.c > >> > @@ -1031,7 +1031,7 @@ static ssize_t scrub_store(struct device *dev, > >> > if (nd_desc) { > >> > struct

RE: [PATCH v2 2/2] acpi/nfit: Issue Start ARS to retrieve existing records

> On Fri, Jun 16, 2017 at 5:01 PM, Kani, Toshimitsu wrote: > >> > --- a/drivers/acpi/nfit/core.c > >> > +++ b/drivers/acpi/nfit/core.c > >> > @@ -1031,7 +1031,7 @@ static ssize_t scrub_store(struct device *dev, > >> > if (nd_desc) { > >> > struct acpi_nfit_desc *acpi_desc

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Friday, June 16, 2017 08:35:19 PM Len Brown wrote: > On Fri, Jun 16, 2017 at 7:53 PM, Rafael J. Wysocki wrote: > > On Wednesday, June 07, 2017 07:39:14 PM Len Brown wrote: > >> From: Len Brown > >> > >> The x86 cpufreq core now uses

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Friday, June 16, 2017 08:35:19 PM Len Brown wrote: > On Fri, Jun 16, 2017 at 7:53 PM, Rafael J. Wysocki wrote: > > On Wednesday, June 07, 2017 07:39:14 PM Len Brown wrote: > >> From: Len Brown > >> > >> The x86 cpufreq core now uses aperfmperf_khz_on_cpu() > >> to supply

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

Hi Lee, On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: > It seems like what you are doing is basically "good", i.e. if there is > not enough random data, don't use it. But what happens in that case? The > authentication fails? How does the user know to wait and try again?

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

Hi Lee, On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: > It seems like what you are doing is basically "good", i.e. if there is > not enough random data, don't use it. But what happens in that case? The > authentication fails? How does the user know to wait and try again? The process just

Re: [PATCH] random: silence compiler warnings and fix race

On Fri, Jun 16, 2017 at 4:35 PM, Sebastian Andrzej Siewior wrote: > I wouldn't just push the lock one up as is but move that write part to > crng_init to remain within the locked section. Like that: We can't quite do that, because invalidate_batched_entropy() needs to be

Re: [PATCH] random: silence compiler warnings and fix race

On Fri, Jun 16, 2017 at 4:35 PM, Sebastian Andrzej Siewior wrote: > I wouldn't just push the lock one up as is but move that write part to > crng_init to remain within the locked section. Like that: We can't quite do that, because invalidate_batched_entropy() needs to be called _before_

Re: [PATCH 2/5] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

On Wednesday, June 07, 2017 07:39:13 PM Len Brown wrote: > From: Len Brown > > The goal of this change is to give users a uniform and meaningful > result when they read /sys/...cpufreq/scaling_cur_freq > on modern x86 hardware, as compared to what they get today. > > Modern

Re: [PATCH 2/5] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

On Wednesday, June 07, 2017 07:39:13 PM Len Brown wrote: > From: Len Brown > > The goal of this change is to give users a uniform and meaningful > result when they read /sys/...cpufreq/scaling_cur_freq > on modern x86 hardware, as compared to what they get today. > > Modern x86 processors

Re: [PATCH v5 0/2] add MSI support for PCIe port services and DPC IRQ support

On Tue, May 23, 2017 at 03:23:57PM +0100, Gabriele Paoloni wrote: > From: gabriele paoloni > > This patchset: > 1) adds support for MSI interrupt vectors to be used for Roor Port services > 2) adds support for DPC Root Port service interrupt > > The patchset has

Re: [PATCH v5 0/2] add MSI support for PCIe port services and DPC IRQ support

On Tue, May 23, 2017 at 03:23:57PM +0100, Gabriele Paoloni wrote: > From: gabriele paoloni > > This patchset: > 1) adds support for MSI interrupt vectors to be used for Roor Port services > 2) adds support for DPC Root Port service interrupt > > The patchset has been tested on Hisilicon Hip08

RE: [PATCH v2] libnvdimm, pmem: Add sysfs notifications to badblocks

> On Mon, Jun 12, 2017 at 3:25 PM, Toshi Kani wrote: > > Sysfs "badblocks" information may be updated during run-time that: > > - MCE, SCI, and sysfs "scrub" may add new bad blocks > > - Writes and ioctl() may clear bad blocks > > > > Add support to send sysfs notifications

RE: [PATCH v2] libnvdimm, pmem: Add sysfs notifications to badblocks

> On Mon, Jun 12, 2017 at 3:25 PM, Toshi Kani wrote: > > Sysfs "badblocks" information may be updated during run-time that: > > - MCE, SCI, and sysfs "scrub" may add new bad blocks > > - Writes and ioctl() may clear bad blocks > > > > Add support to send sysfs notifications to sysfs "badblocks"

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Fri, Jun 16, 2017 at 7:53 PM, Rafael J. Wysocki wrote: > On Wednesday, June 07, 2017 07:39:14 PM Len Brown wrote: >> From: Len Brown >> >> The x86 cpufreq core now uses aperfmperf_khz_on_cpu() >> to supply /sys/.../cpufreq/scaling_cur_freq >> on all

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Fri, Jun 16, 2017 at 7:53 PM, Rafael J. Wysocki wrote: > On Wednesday, June 07, 2017 07:39:14 PM Len Brown wrote: >> From: Len Brown >> >> The x86 cpufreq core now uses aperfmperf_khz_on_cpu() >> to supply /sys/.../cpufreq/scaling_cur_freq >> on all x86 systems supporting APERF/MPERF. >> >>

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Wednesday, June 07, 2017 07:39:14 PM Len Brown wrote: > From: Len Brown > > The x86 cpufreq core now uses aperfmperf_khz_on_cpu() > to supply /sys/.../cpufreq/scaling_cur_freq > on all x86 systems supporting APERF/MPERF. > > That includes 100% of systems supported by

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Wednesday, June 07, 2017 07:39:14 PM Len Brown wrote: > From: Len Brown > > The x86 cpufreq core now uses aperfmperf_khz_on_cpu() > to supply /sys/.../cpufreq/scaling_cur_freq > on all x86 systems supporting APERF/MPERF. > > That includes 100% of systems supported by intel_pstate, > and so

Re: [PATCH 5/5] intel_pstate: delete scheduler hook in HWP mode

On Wednesday, June 07, 2017 07:39:16 PM Len Brown wrote: > From: Len Brown > > The cpufreqa/scaling_cur_freq sysfs attribute is now provided by > the x86 cpufreq core on all modern x86 systems, including > all systems supported by the intel_pstate driver. Not sure what you

Re: [PATCH 5/5] intel_pstate: delete scheduler hook in HWP mode

On Wednesday, June 07, 2017 07:39:16 PM Len Brown wrote: > From: Len Brown > > The cpufreqa/scaling_cur_freq sysfs attribute is now provided by > the x86 cpufreq core on all modern x86 systems, including > all systems supported by the intel_pstate driver. Not sure what you mean by "x86 cpufreq

Re: [PATCH 4/5] intel_pstate: skip scheduler hook when in "performance" mode.

On Wednesday, June 07, 2017 07:39:15 PM Len Brown wrote: > From: Len Brown > > When the governor is set to "performance", intel_pstate does not > need the scheduler hook for doing any calculations. Under these > conditions, its only purpose is to continue to maintain >

Re: [PATCH 4/5] intel_pstate: skip scheduler hook when in "performance" mode.

On Wednesday, June 07, 2017 07:39:15 PM Len Brown wrote: > From: Len Brown > > When the governor is set to "performance", intel_pstate does not > need the scheduler hook for doing any calculations. Under these > conditions, its only purpose is to continue to maintain > cpufreq/scaling_cur_freq.

Re: [PATCH v2 2/2] acpi/nfit: Issue Start ARS to retrieve existing records

On Fri, Jun 16, 2017 at 5:01 PM, Kani, Toshimitsu wrote: >> > --- a/drivers/acpi/nfit/core.c >> > +++ b/drivers/acpi/nfit/core.c >> > @@ -1031,7 +1031,7 @@ static ssize_t scrub_store(struct device *dev, >> > if (nd_desc) { >> > struct acpi_nfit_desc

Re: [PATCH v2 2/2] acpi/nfit: Issue Start ARS to retrieve existing records

On Fri, Jun 16, 2017 at 5:01 PM, Kani, Toshimitsu wrote: >> > --- a/drivers/acpi/nfit/core.c >> > +++ b/drivers/acpi/nfit/core.c >> > @@ -1031,7 +1031,7 @@ static ssize_t scrub_store(struct device *dev, >> > if (nd_desc) { >> > struct acpi_nfit_desc *acpi_desc =

[PATCH v3 3/4] arm64: Provide a fncpy implementation

Utilize the asm-generic/fncpy.h implementation for ARM64 to allow the use of drivers/misc/sram*.c on these platforms as well. Signed-off-by: Florian Fainelli --- arch/arm64/include/asm/Kbuild | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/Kbuild

[PATCH v3 3/4] arm64: Provide a fncpy implementation

Utilize the asm-generic/fncpy.h implementation for ARM64 to allow the use of drivers/misc/sram*.c on these platforms as well. Signed-off-by: Florian Fainelli --- arch/arm64/include/asm/Kbuild | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/Kbuild

[PATCH v3 4/4] misc: sram: Allow ARM64 to select SRAM_EXEC

Now that ARM64 also has a fncpy() implementation, allow selection SRAM_EXEC for ARM64 as well. Signed-off-by: Florian Fainelli --- drivers/misc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index

[PATCH v3 2/4] asm-generic: Provide a fncpy() implementation

Define a generic fncpy() implementation largely based on the ARM version that requires an 8 bytes alignment for the destination address where to copy this function as well as the function's own address. Signed-off-by: Florian Fainelli --- include/asm-generic/fncpy.h | 93

[PATCH v3 0/4] Generalize fncpy availability

Hi all, This patch series makes ARM's fncpy() implementation more generic (dropping the Thumb-specifics) and available in an asm-generic header file. Tested on a Broadcom ARM64 STB platform with code that is written to SRAM. Changes in v3 (thanks Doug!): - correct include guard names in

[PATCH v3 1/4] ARM: fncpy: Rename include guards

In preparation for allowing a generic fncpy() implementation to live under include/asm-generic/fncpy.h, rename the current include guards to be __ASM_ARM_FNCPY_H, this also makes the header file more consistent with other headers in the same directory. Signed-off-by: Florian Fainelli

[PATCH v3 4/4] misc: sram: Allow ARM64 to select SRAM_EXEC

Now that ARM64 also has a fncpy() implementation, allow selection SRAM_EXEC for ARM64 as well. Signed-off-by: Florian Fainelli --- drivers/misc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index

[PATCH v3 2/4] asm-generic: Provide a fncpy() implementation

Define a generic fncpy() implementation largely based on the ARM version that requires an 8 bytes alignment for the destination address where to copy this function as well as the function's own address. Signed-off-by: Florian Fainelli --- include/asm-generic/fncpy.h | 93

[PATCH v3 0/4] Generalize fncpy availability

Hi all, This patch series makes ARM's fncpy() implementation more generic (dropping the Thumb-specifics) and available in an asm-generic header file. Tested on a Broadcom ARM64 STB platform with code that is written to SRAM. Changes in v3 (thanks Doug!): - correct include guard names in

[PATCH v3 1/4] ARM: fncpy: Rename include guards

In preparation for allowing a generic fncpy() implementation to live under include/asm-generic/fncpy.h, rename the current include guards to be __ASM_ARM_FNCPY_H, this also makes the header file more consistent with other headers in the same directory. Signed-off-by: Florian Fainelli ---

RE: [PATCH v2 2/2] acpi/nfit: Issue Start ARS to retrieve existing records

> > --- a/drivers/acpi/nfit/core.c > > +++ b/drivers/acpi/nfit/core.c > > @@ -1031,7 +1031,7 @@ static ssize_t scrub_store(struct device *dev, > > if (nd_desc) { > > struct acpi_nfit_desc *acpi_desc = to_acpi_desc(nd_desc); > > > > - rc =

RE: [PATCH v2 2/2] acpi/nfit: Issue Start ARS to retrieve existing records

> > --- a/drivers/acpi/nfit/core.c > > +++ b/drivers/acpi/nfit/core.c > > @@ -1031,7 +1031,7 @@ static ssize_t scrub_store(struct device *dev, > > if (nd_desc) { > > struct acpi_nfit_desc *acpi_desc = to_acpi_desc(nd_desc); > > > > - rc =

Re: [PATCH 1/2] loop: use filp_close() rather than fput()

On Fri, Jun 16, 2017 at 03:02:09PM +1000, NeilBrown wrote: > When a loop device is being shutdown the backing file is > closed with fput(). This is different from how close(2) > closes files - it uses filp_close(). > > The difference is important for filesystems which provide a ->flush > file

Re: [PATCH 1/2] loop: use filp_close() rather than fput()

On Fri, Jun 16, 2017 at 03:02:09PM +1000, NeilBrown wrote: > When a loop device is being shutdown the backing file is > closed with fput(). This is different from how close(2) > closes files - it uses filp_close(). > > The difference is important for filesystems which provide a ->flush > file

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Wednesday, June 07, 2017 07:39:14 PM Len Brown wrote: > From: Len Brown > > The x86 cpufreq core now uses aperfmperf_khz_on_cpu() > to supply /sys/.../cpufreq/scaling_cur_freq > on all x86 systems supporting APERF/MPERF. > > That includes 100% of systems supported by

Re: [PATCH 3/5] intel_pstate: remove intel_pstate.get()

On Wednesday, June 07, 2017 07:39:14 PM Len Brown wrote: > From: Len Brown > > The x86 cpufreq core now uses aperfmperf_khz_on_cpu() > to supply /sys/.../cpufreq/scaling_cur_freq > on all x86 systems supporting APERF/MPERF. > > That includes 100% of systems supported by intel_pstate, > and so

Re: LTS testing with latest kselftests - some failures

On Fri, Jun 16, 2017 at 06:46:51PM +0200, Luis R. Rodriguez wrote: Kees, please review 47e0bbb7fa98 below. Brian, please review be4a1326d12c below. On Thu, Jun 15, 2017 at 11:26:53PM +0530, Sumit Semwal wrote: Hello Greg, Shuah, While testing 4.4.y and 4.9.y LTS kernels with latest kselftest,

Re: LTS testing with latest kselftests - some failures

On Fri, Jun 16, 2017 at 06:46:51PM +0200, Luis R. Rodriguez wrote: Kees, please review 47e0bbb7fa98 below. Brian, please review be4a1326d12c below. On Thu, Jun 15, 2017 at 11:26:53PM +0530, Sumit Semwal wrote: Hello Greg, Shuah, While testing 4.4.y and 4.9.y LTS kernels with latest kselftest,

[PATCH 3/3] block: order /proc/devices by major number

Presently, the order of the block devices listed in /proc/devices is not entirely sequential. If a block device has a major number greater than BLKDEV_MAJOR_HASH_SIZE (255), it will be ordered as if its major were module 255. For example, 511 appears after 1. This patch cleans that up and prints

[PATCH 3/3] block: order /proc/devices by major number

Presently, the order of the block devices listed in /proc/devices is not entirely sequential. If a block device has a major number greater than BLKDEV_MAJOR_HASH_SIZE (255), it will be ordered as if its major were module 255. For example, 511 appears after 1. This patch cleans that up and prints

Re: [PATCH 1/2] platform/x86: silead_dmi: Add touchscreen info for PoV mobii wintab p800w

On Fri, Jun 16, 2017 at 03:22:45PM +0200, Hans de Goede wrote: > Hi, > > On 16-06-17 14:44, Andy Shevchenko wrote: > > On Thu, Jun 15, 2017 at 7:53 PM, Darren Hart wrote: > > > On Thu, Jun 15, 2017 at 08:48:31AM +0200, Hans de Goede wrote: > > > > > > + /*

Re: [PATCH 1/2] platform/x86: silead_dmi: Add touchscreen info for PoV mobii wintab p800w

On Fri, Jun 16, 2017 at 03:22:45PM +0200, Hans de Goede wrote: > Hi, > > On 16-06-17 14:44, Andy Shevchenko wrote: > > On Thu, Jun 15, 2017 at 7:53 PM, Darren Hart wrote: > > > On Thu, Jun 15, 2017 at 08:48:31AM +0200, Hans de Goede wrote: > > > > > > + /* Point of View mobii wintab

[PATCHv3 1/3] firmware_class: move NO_CACHE from private to driver_data_req_params

From: Yi Li This adds DRIVER_DATA_REQ_NO_CACHE flag with .req flag under struct driver_data_req_params. When this flag is set, the driver_data driver will not cache the firmware during PM cycle, which is expensive. It will be used by streaming case and other drivers which

[PATCHv3 1/3] firmware_class: move NO_CACHE from private to driver_data_req_params

From: Yi Li This adds DRIVER_DATA_REQ_NO_CACHE flag with .req flag under struct driver_data_req_params. When this flag is set, the driver_data driver will not cache the firmware during PM cycle, which is expensive. It will be used by streaming case and other drivers which implement their own

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