Re: [PATCH] drm/fb-helper: pass physical dimensions to fbdev

On 08/02/2017 04:46 AM, Daniel Vetter wrote: On Tue, Aug 01, 2017 at 10:26:41AM -0500, David Lechner wrote: The fbdev subsystem has a place for physical dimensions (width and height in mm) that is readable by userspace. Since DRM also knows these dimensions, pass this information to the fbdev

Re: [PATCH] drm/fb-helper: pass physical dimensions to fbdev

On 08/02/2017 04:46 AM, Daniel Vetter wrote: On Tue, Aug 01, 2017 at 10:26:41AM -0500, David Lechner wrote: The fbdev subsystem has a place for physical dimensions (width and height in mm) that is readable by userspace. Since DRM also knows these dimensions, pass this information to the fbdev

[PATCH] serial: 8250_of: Add basic PM runtime support

Add basic PM Runtime support. Signed-off-by: Franklin S Cooper Jr --- drivers/tty/serial/8250/8250_of.c | 35 --- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/drivers/tty/serial/8250/8250_of.c

[PATCH] serial: 8250_of: Add basic PM runtime support

Add basic PM Runtime support. Signed-off-by: Franklin S Cooper Jr --- drivers/tty/serial/8250/8250_of.c | 35 --- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c index

Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers

On Wed, Aug 2, 2017 at 9:06 AM, Allen Hubbe wrote: > From: Logan Gunthorpe >> On 01/08/17 01:10 PM, Jon Mason wrote: >> > It would probaly be better if I remarked about the SPADs in the actual >> > patch about the SPADS :) >> > >> > The whole point of using the SPADs in the

Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers

On Wed, Aug 2, 2017 at 9:06 AM, Allen Hubbe wrote: > From: Logan Gunthorpe >> On 01/08/17 01:10 PM, Jon Mason wrote: >> > It would probaly be better if I remarked about the SPADs in the actual >> > patch about the SPADS :) >> > >> > The whole point of using the SPADs in the NTB driver was to

[PATCH] x86/efi: page align EFI ROM image ranges

The kernel's EFI stub locates and copies EFI ROM images into memory, which it allocates using the byte-granular EFI allocate_pool function. These memory ranges are then added to setup_data, and later to e820 (in e820__reserve_setup_data()). The e820 ranges are parsed to create nosave regions

[PATCH] x86/efi: page align EFI ROM image ranges

The kernel's EFI stub locates and copies EFI ROM images into memory, which it allocates using the byte-granular EFI allocate_pool function. These memory ranges are then added to setup_data, and later to e820 (in e820__reserve_setup_data()). The e820 ranges are parsed to create nosave regions

[PATCH] ecryptfs: convert to file_write_and_wait in ->fsync

From: Jeff Layton This change is mainly for documentation/completeness, as ecryptfs never calls mapping_set_error, and so will never return a previous writeback error. Signed-off-by: Jeff Layton --- fs/ecryptfs/file.c | 2 +- 1 file changed, 1

[PATCH] ecryptfs: convert to file_write_and_wait in ->fsync

From: Jeff Layton This change is mainly for documentation/completeness, as ecryptfs never calls mapping_set_error, and so will never return a previous writeback error. Signed-off-by: Jeff Layton --- fs/ecryptfs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] sched/deadline: make it configurable

On most small systems, the deadline scheduler class is a luxury that rarely gets used if at all. It is preferable to have the ability to configure it out to reduce the kernel size in that case. Before: $ size -t kernel/sched/built-in.o textdata bss dec hex filename [...]

[PATCH] sched/deadline: make it configurable

On most small systems, the deadline scheduler class is a luxury that rarely gets used if at all. It is preferable to have the ability to configure it out to reduce the kernel size in that case. Before: $ size -t kernel/sched/built-in.o textdata bss dec hex filename [...]

Re: [PATCH v2 2/4] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD

On 08/02/2017 08:03 AM, Noralf Trønnes wrote: Please use tinydrm_xrgb_to_gray8(). I considered this, but is seems excessive to loop through the entire fb twice just to make a 4x6 cursor blink. You should use this function to enable the regulator and init the controller. Don't look at

Re: [PATCH v2 2/4] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD

On 08/02/2017 08:03 AM, Noralf Trønnes wrote: Please use tinydrm_xrgb_to_gray8(). I considered this, but is seems excessive to loop through the entire fb twice just to make a 4x6 cursor blink. You should use this function to enable the regulator and init the controller. Don't look at

[PATCH V2 1/2] trace-cmd: use asprintf when possible

It makes the code clearer and less error prone. clearer: - less code - the code is now using the same format to create strings dynamically less error prone: - no magic number +2 +9 +5 to compute the size - no copy of the strings to compute the size and to concatenate The function `asprintf` is

[PATCH V2 1/2] trace-cmd: use asprintf when possible

It makes the code clearer and less error prone. clearer: - less code - the code is now using the same format to create strings dynamically less error prone: - no magic number +2 +9 +5 to compute the size - no copy of the strings to compute the size and to concatenate The function `asprintf` is

Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone

On Wed 02-08-17 17:55:22, Andrea Arcangeli wrote: > On Wed, Aug 02, 2017 at 03:34:41PM +0300, Mike Rapoport wrote: > > I surely can take care of CRIU, but I don't know if QEMU or certain > > database application that uses userfaultfd rely on this API, not mentioning > > there maybe other unknown

Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone

On Wed 02-08-17 17:55:22, Andrea Arcangeli wrote: > On Wed, Aug 02, 2017 at 03:34:41PM +0300, Mike Rapoport wrote: > > I surely can take care of CRIU, but I don't know if QEMU or certain > > database application that uses userfaultfd rely on this API, not mentioning > > there maybe other unknown

Re: [RFC][PATCH v3]: documentation,atomic: Add new documents

On Wed, Aug 02, 2017 at 10:45:32AM +0100, Will Deacon wrote: > Hi Paul, > > On Tue, Aug 01, 2017 at 09:14:12AM -0700, Paul E. McKenney wrote: > > On Tue, Aug 01, 2017 at 01:17:13PM +0100, Will Deacon wrote: > > > On Tue, Aug 01, 2017 at 01:47:44PM +0200, Peter Zijlstra wrote: > > > > On Tue, Aug

Re: [RFC][PATCH v3]: documentation,atomic: Add new documents

On Wed, Aug 02, 2017 at 10:45:32AM +0100, Will Deacon wrote: > Hi Paul, > > On Tue, Aug 01, 2017 at 09:14:12AM -0700, Paul E. McKenney wrote: > > On Tue, Aug 01, 2017 at 01:17:13PM +0100, Will Deacon wrote: > > > On Tue, Aug 01, 2017 at 01:47:44PM +0200, Peter Zijlstra wrote: > > > > On Tue, Aug

Re: [PATCH v4] acpi/iort: numa: Add numa node mapping for smmuv3 devices

On Tue, Jul 25, 2017 at 05:13:05PM +0200, Robert Richter wrote: > On 25.07.17 10:32:37, Ganapatrao Kulkarni wrote: > > ARM IORT specification(rev. C) has added provision to define proximity > > domain in SMMUv3 IORT table. Adding required code to parse Proximity > > domain and set numa_node of

Re: [PATCH v4] acpi/iort: numa: Add numa node mapping for smmuv3 devices

On Tue, Jul 25, 2017 at 05:13:05PM +0200, Robert Richter wrote: > On 25.07.17 10:32:37, Ganapatrao Kulkarni wrote: > > ARM IORT specification(rev. C) has added provision to define proximity > > domain in SMMUv3 IORT table. Adding required code to parse Proximity > > domain and set numa_node of

Re: [PATCH] misc: Kconfig: fix missing tristate prompt and add help for LIS3LV02D

Hi, > Am 02.08.2017 um 18:06 schrieb Arnd Bergmann : > > On Wed, Aug 2, 2017 at 5:57 PM, Greg Kroah-Hartman > wrote: >> On Wed, Aug 02, 2017 at 04:05:36PM +0200, H. Nikolaus Schaller wrote: >>> + help >>> + If you say yes here, you get

Re: [PATCH] misc: Kconfig: fix missing tristate prompt and add help for LIS3LV02D

Hi, > Am 02.08.2017 um 18:06 schrieb Arnd Bergmann : > > On Wed, Aug 2, 2017 at 5:57 PM, Greg Kroah-Hartman > wrote: >> On Wed, Aug 02, 2017 at 04:05:36PM +0200, H. Nikolaus Schaller wrote: >>> + help >>> + If you say yes here, you get support for the STM >>> + LIS3LV02D sensor.

[PATCH v10 1/9] x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set

Code is arch/x86/hyperv/ is only needed when CONFIG_HYPERV is set, the 'basic' support and detection lives in arch/x86/kernel/cpu/mshyperv.c which is included when CONFIG_HYPERVISOR_GUEST is set. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko

[PATCH v10 1/9] x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set

Code is arch/x86/hyperv/ is only needed when CONFIG_HYPERV is set, the 'basic' support and detection lives in arch/x86/kernel/cpu/mshyperv.c which is included when CONFIG_HYPERVISOR_GUEST is set. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger ---

[PATCH -next] iommu/of: Check for valid fwspec after of_pci_iommu_init

The successful return from of_pci_iommu_init doesn't ensure valid fwspec if it's IOMMU is disabled. Accessing dev->iommu_fwspec->ops without checking dev->iommu_fwspec could result in NULL pointer dereference. Unable to handle kernel NULL pointer dereference at virtual address task:

[PATCH -next] iommu/of: Check for valid fwspec after of_pci_iommu_init

The successful return from of_pci_iommu_init doesn't ensure valid fwspec if it's IOMMU is disabled. Accessing dev->iommu_fwspec->ops without checking dev->iommu_fwspec could result in NULL pointer dereference. Unable to handle kernel NULL pointer dereference at virtual address task:

[PATCH v10 9/9] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others(). Tracing is done the same way we do xen_mmu_flush_tlb_others(). Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger

[PATCH v10 9/9] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others(). Tracing is done the same way we do xen_mmu_flush_tlb_others(). Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger Reviewed-by: Steven Rostedt (VMware) --- MAINTAINERS

[PATCH v10 7/9] x86/hyper-v: use hypercall for remote TLB flush

Hyper-V host can suggest us to use hypercall for doing remote TLB flush, this is supposed to work faster than IPIs. Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls we need to put the input somewhere in memory and we don't really want to have memory allocation on each

[PATCH v10 6/9] hyper-v: globalize vp_index

To support implementing remote TLB flushing on Hyper-V with a hypercall we need to make vp_index available outside of vmbus module. Rename and globalize. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 02/08/2017 16:38, Denis Plotnikov wrote: > V4: > * removed "is stable" function with vague definition of stability > there is the only function which does time with cycle stamp getting > * some variables renamed > * some patches split into smaller once > * atomic64_t usage is

[PATCH v10 7/9] x86/hyper-v: use hypercall for remote TLB flush

Hyper-V host can suggest us to use hypercall for doing remote TLB flush, this is supposed to work faster than IPIs. Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls we need to put the input somewhere in memory and we don't really want to have memory allocation on each

[PATCH v10 6/9] hyper-v: globalize vp_index

To support implementing remote TLB flushing on Hyper-V with a hypercall we need to make vp_index available outside of vmbus module. Rename and globalize. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger --- arch/x86/hyperv/hv_init.c | 34

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 02/08/2017 16:38, Denis Plotnikov wrote: > V4: > * removed "is stable" function with vague definition of stability > there is the only function which does time with cycle stamp getting > * some variables renamed > * some patches split into smaller once > * atomic64_t usage is

[PATCH v10 5/9] x86/hyper-v: implement rep hypercalls

Rep hypercalls are normal hypercalls which perform multiple actions at once. Hyper-V guarantees to return exectution to the caller in not more than 50us and the caller needs to use hypercall continuation. Touch NMI watchdog between hypercall invocations. This is going to be used for

[PATCH v10 5/9] x86/hyper-v: implement rep hypercalls

Rep hypercalls are normal hypercalls which perform multiple actions at once. Hyper-V guarantees to return exectution to the caller in not more than 50us and the caller needs to use hypercall continuation. Touch NMI watchdog between hypercall invocations. This is going to be used for

[PATCH v10 8/9] x86/hyper-v: support extended CPU ranges for TLB flush hypercalls

Hyper-V hosts may support more than 64 vCPUs, we need to use HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX/LIST_EX hypercalls in this case. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger

[PATCH v10 8/9] x86/hyper-v: support extended CPU ranges for TLB flush hypercalls

Hyper-V hosts may support more than 64 vCPUs, we need to use HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX/LIST_EX hypercalls in this case. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger --- arch/x86/hyperv/mmu.c | 133

[PATCH v10 3/9] x86/hyper-v: fast hypercall implementation

Hyper-V supports 'fast' hypercalls when all parameters are passed through registers. Implement an inline version of a simpliest of these calls: hypercall with one 8-byte input and no output. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko

[PATCH v10 4/9] hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT

We need to pass only 8 bytes of input for HvSignalEvent which makes it a perfect fit for fast hypercall. hv_input_signal_event_buffer is not needed any more and hv_input_signal_event is converted to union for convenience. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy

[PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

Changes since v9: - Rebase to 4.13-rc3. - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no functional dependencies on this patch so the series can go through a different tree (and it actually belongs to x86 if I got Ingo's comment right). - Add in missing void return

[PATCH v10 3/9] x86/hyper-v: fast hypercall implementation

Hyper-V supports 'fast' hypercalls when all parameters are passed through registers. Implement an inline version of a simpliest of these calls: hypercall with one 8-byte input and no output. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by: Stephen Hemminger ---

[PATCH v10 4/9] hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT

We need to pass only 8 bytes of input for HvSignalEvent which makes it a perfect fit for fast hypercall. hv_input_signal_event_buffer is not needed any more and hv_input_signal_event is converted to union for convenience. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Andy Shevchenko Reviewed-by:

[PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

Changes since v9: - Rebase to 4.13-rc3. - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no functional dependencies on this patch so the series can go through a different tree (and it actually belongs to x86 if I got Ingo's comment right). - Add in missing void return

[PATCH v10 2/9] x86/hyper-v: make hv_do_hypercall() inline

We have only three call sites for hv_do_hypercall() and we're going to change HVCALL_SIGNAL_EVENT to doing fast hypercall so we can inline this function for optimization. Hyper-V top level functional specification states that r9-r11 registers and flags may be clobbered by the hypervisor during

[PATCH v10 2/9] x86/hyper-v: make hv_do_hypercall() inline

We have only three call sites for hv_do_hypercall() and we're going to change HVCALL_SIGNAL_EVENT to doing fast hypercall so we can inline this function for optimization. Hyper-V top level functional specification states that r9-r11 registers and flags may be clobbered by the hypervisor during

[PATCH 2/2] s390/cio: add const to bin_attribute structures

Add const to bin_attribute structures as they are only passed to the functions device_{remove/create}_bin_file. The corresponding arguments are of type const, so declare the structures to be const. Cross compiled for s390 architecture. Signed-off-by: Bhumika Goyal ---

[PATCH 0/2] s390: add const to bin_attribute structures

Declare bin_attribute structures as const. Bhumika Goyal (2): s390/sclp: add const to bin_attribute structure s390/cio: add const to bin_attribute structures drivers/s390/char/sclp_config.c | 2 +- drivers/s390/cio/chp.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)

[PATCH 2/2] s390/cio: add const to bin_attribute structures

Add const to bin_attribute structures as they are only passed to the functions device_{remove/create}_bin_file. The corresponding arguments are of type const, so declare the structures to be const. Cross compiled for s390 architecture. Signed-off-by: Bhumika Goyal --- drivers/s390/cio/chp.c |

[PATCH 0/2] s390: add const to bin_attribute structures

Declare bin_attribute structures as const. Bhumika Goyal (2): s390/sclp: add const to bin_attribute structure s390/cio: add const to bin_attribute structures drivers/s390/char/sclp_config.c | 2 +- drivers/s390/cio/chp.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)

Re: [PATCH tip/sched/core] swait: Remove the lockless swait_active() check in swake_up*()

On Sun, Jul 30, 2017 at 09:47:35PM +0800, Boqun Feng wrote: > Steven Rostedt reported a potential race in RCU core because of > swake_up(): > > CPU0CPU1 > > __call_rcu_core() { > >

Re: [PATCH tip/sched/core] swait: Remove the lockless swait_active() check in swake_up*()

On Sun, Jul 30, 2017 at 09:47:35PM +0800, Boqun Feng wrote: > Steven Rostedt reported a potential race in RCU core because of > swake_up(): > > CPU0CPU1 > > __call_rcu_core() { > >

[PATCH 1/2] s390/sclp: add const to bin_attribute structure

Declare bin_attribute structure as const as it is only passed as an argument to the function sysfs_create_bin_file. This argument is of type const, so declare the structure as const. Cross compiled for s390 architecture. Signed-off-by: Bhumika Goyal ---

[PATCH 1/2] s390/sclp: add const to bin_attribute structure

Declare bin_attribute structure as const as it is only passed as an argument to the function sysfs_create_bin_file. This argument is of type const, so declare the structure as const. Cross compiled for s390 architecture. Signed-off-by: Bhumika Goyal --- drivers/s390/char/sclp_config.c | 2 +-

Re: [PATCH] misc: Kconfig: fix missing tristate prompt and add help for LIS3LV02D

On Wed, Aug 2, 2017 at 5:57 PM, Greg Kroah-Hartman wrote: > On Wed, Aug 02, 2017 at 04:05:36PM +0200, H. Nikolaus Schaller wrote: >> + help >> + If you say yes here, you get support for the STM >> + LIS3LV02D sensor. > > No name for what the module is

Re: [PATCH] misc: Kconfig: fix missing tristate prompt and add help for LIS3LV02D

On Wed, Aug 2, 2017 at 5:57 PM, Greg Kroah-Hartman wrote: > On Wed, Aug 02, 2017 at 04:05:36PM +0200, H. Nikolaus Schaller wrote: >> + help >> + If you say yes here, you get support for the STM >> + LIS3LV02D sensor. > > No name for what the module is called? Not sure if that's

Re: [PATCH 0/3] FPGA Manager support for FPP via FT232H FT245-FIFO

On Wed, Aug 02, 2017 at 05:30:36PM +0200, Eric Schwarz wrote: > Hello Alan, > > many thanks for your response. > Well, I am following the whole discussion from the very start and for my > taste it is too superficial - don't know whether this is the right wording. > Please get me right. We need

Re: [PATCH 0/3] FPGA Manager support for FPP via FT232H FT245-FIFO

On Wed, Aug 02, 2017 at 05:30:36PM +0200, Eric Schwarz wrote: > Hello Alan, > > many thanks for your response. > Well, I am following the whole discussion from the very start and for my > taste it is too superficial - don't know whether this is the right wording. > Please get me right. We need

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

On 08/02/2017 03:05 AM, Noralf Trønnes wrote: Den 02.08.2017 00.26, skrev David Lechner: On 08/01/2017 01:08 PM, Noralf Trønnes wrote: (cc: Daniel Vetter) Den 01.08.2017 18.51, skrev David Lechner: On 07/30/2017 12:14 PM, Noralf Trønnes wrote: Den 29.07.2017 21.40, skrev David Lechner:

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

On 08/02/2017 03:05 AM, Noralf Trønnes wrote: Den 02.08.2017 00.26, skrev David Lechner: On 08/01/2017 01:08 PM, Noralf Trønnes wrote: (cc: Daniel Vetter) Den 01.08.2017 18.51, skrev David Lechner: On 07/30/2017 12:14 PM, Noralf Trønnes wrote: Den 29.07.2017 21.40, skrev David Lechner:

Re: [PATCH 2/2] sched: Implement interface for cgroup unified hierarchy

On Wed, Aug 02, 2017 at 08:41:35AM -0700, Tejun Heo wrote: > > Not entirely sure I follow, we currently only update the current cgroup > > and its immediate parents, no? Or are you looking to only account into > > the current cgroup and propagate into the parents on reading? > > Yeah, shifting

Re: [PATCH 2/2] sched: Implement interface for cgroup unified hierarchy

On Wed, Aug 02, 2017 at 08:41:35AM -0700, Tejun Heo wrote: > > Not entirely sure I follow, we currently only update the current cgroup > > and its immediate parents, no? Or are you looking to only account into > > the current cgroup and propagate into the parents on reading? > > Yeah, shifting

Re: [Patch V2] crypto: x86/sha1 : Fix reads beyond the number of blocks passed

On 08/02/2017 03:39 AM, Jan Stancek wrote: > On 08/02/2017 02:38 AM, Megha Dey wrote: >> It was reported that the sha1 AVX2 function(sha1_transform_avx2) is >> reading ahead beyond its intended data, and causing a crash if the next >> block is beyond page boundary: >>

Re: [Patch V2] crypto: x86/sha1 : Fix reads beyond the number of blocks passed

On 08/02/2017 03:39 AM, Jan Stancek wrote: > On 08/02/2017 02:38 AM, Megha Dey wrote: >> It was reported that the sha1 AVX2 function(sha1_transform_avx2) is >> reading ahead beyond its intended data, and causing a crash if the next >> block is beyond page boundary: >>

[PATCH V6 net-next 2/8] net: hns3: Add support of the HNAE3 framework

This patch adds the support of the HNAE3 (Hisilicon Network Acceleration Engine 3) framework support to the HNS3 driver. Framework facilitates clients like ENET(HNS3 Ethernet Driver), RoCE and user-space Ethernet drivers (like ODP etc.) to register with HNAE3 devices and their associated

[PATCH V6 net-next 2/8] net: hns3: Add support of the HNAE3 framework

This patch adds the support of the HNAE3 (Hisilicon Network Acceleration Engine 3) framework support to the HNS3 driver. Framework facilitates clients like ENET(HNS3 Ethernet Driver), RoCE and user-space Ethernet drivers (like ODP etc.) to register with HNAE3 devices and their associated

Re: [PATCH v2] dm: allow device-mapper to operate without dax support

Hi Dan, [auto build test ERROR on dm/for-next] [also build test ERROR on v4.13-rc3 next-20170802] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dan-Williams/dm-allow-device-mapper-to-operate

Re: [PATCH v2] dm: allow device-mapper to operate without dax support

Hi Dan, [auto build test ERROR on dm/for-next] [also build test ERROR on v4.13-rc3 next-20170802] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dan-Williams/dm-allow-device-mapper-to-operate

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

On Fri, Jul 28, 2017 at 10:06:20PM +0300, Dmitry Safonov wrote: > 2017-07-28 19:48 GMT+03:00 Will Deacon : > > On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: > >> vDSO VMA address is saved in mm_context for the purpose of using > >> restorer from vDSO page to

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

On Fri, Jul 28, 2017 at 10:06:20PM +0300, Dmitry Safonov wrote: > 2017-07-28 19:48 GMT+03:00 Will Deacon : > > On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: > >> vDSO VMA address is saved in mm_context for the purpose of using > >> restorer from vDSO page to return to userspace

Re: [PATCH 1/2] Add sysfs based cpuinfo structure

On Wed, Aug 02, 2017 at 05:14:11PM +0200, Felix Schnizlein wrote: > Create a new sysfs attribute group called 'info' for each > online cpu. The cleaned up cpuinfo shows up in a sysfs > subdirectory here: /sys/devices/system/cpu/cpu#/info. > > Define preprocessor macros (CPUINFO_DEFINE_* and

Re: [PATCH 1/2] Add sysfs based cpuinfo structure

On Wed, Aug 02, 2017 at 05:14:11PM +0200, Felix Schnizlein wrote: > Create a new sysfs attribute group called 'info' for each > online cpu. The cleaned up cpuinfo shows up in a sysfs > subdirectory here: /sys/devices/system/cpu/cpu#/info. > > Define preprocessor macros (CPUINFO_DEFINE_* and

[PATCH] KVM: svm: support single stepping over emulated instructions

Use kvm_skip_emulated_instruction so that debug exceptions are properly injected. This fixes debug.flat on AMD machines. Signed-off-by: Paolo Bonzini --- arch/x86/kvm/svm.c | 50 +- arch/x86/kvm/x86.c | 1 + 2 files changed,

[PATCH V6 net-next 3/8] net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support

This patch adds the support of IMP (Integrated Management Processor) command interface to the HNS3 driver. Each PF/VF has support of CQP(Command Queue Pair) ring interface. Each CQP consis of send queue CSQ and receive queue CRQ. There are various commands a PF/VF may support, like for Flow Table

[PATCH] KVM: svm: support single stepping over emulated instructions

Use kvm_skip_emulated_instruction so that debug exceptions are properly injected. This fixes debug.flat on AMD machines. Signed-off-by: Paolo Bonzini --- arch/x86/kvm/svm.c | 50 +- arch/x86/kvm/x86.c | 1 + 2 files changed, 22 insertions(+), 29

[PATCH V6 net-next 3/8] net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support

This patch adds the support of IMP (Integrated Management Processor) command interface to the HNS3 driver. Each PF/VF has support of CQP(Command Queue Pair) ring interface. Each CQP consis of send queue CSQ and receive queue CRQ. There are various commands a PF/VF may support, like for Flow Table

remap_pfn_range() + outer_flush_range()

Hi, I'm implementing a 2D graphics driver for an ARM A9 multicore SoC. As part of this, I'm using remap_pfn_range() to map memory to user space. During testing I realized that remap_pfn_range() flushes the L1 cache, but doesn't flush the L2 cache. As a result, I can get L2 cache hits even if I

remap_pfn_range() + outer_flush_range()

Hi, I'm implementing a 2D graphics driver for an ARM A9 multicore SoC. As part of this, I'm using remap_pfn_range() to map memory to user space. During testing I realized that remap_pfn_range() flushes the L1 cache, but doesn't flush the L2 cache. As a result, I can get L2 cache hits even if I

[PATCH V6 net-next 4/8] net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support

This patch adds the support of Hisilicon Network Subsystem Accceleration Engine and common operations to access it. This layer provides access to the hardware configuration, hardware statistics. This layer is also responsible for triggering the initialization of the PHY layer through the below

[PATCH V6 net-next 4/8] net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support

This patch adds the support of Hisilicon Network Subsystem Accceleration Engine and common operations to access it. This layer provides access to the hardware configuration, hardware statistics. This layer is also responsible for triggering the initialization of the PHY layer through the below

[PATCH V6 net-next 1/8] net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC

This patch adds the support of Hisilicon Network Subsystem 3 Ethernet driver to hip08 family of SoCs. This driver includes basic Rx/Tx functionality. It also includes the client registration code with the HNAE3(Hisilicon Network Acceleration Engine 3) framework. This work provides the initial

[PATCH V6 net-next 1/8] net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC

This patch adds the support of Hisilicon Network Subsystem 3 Ethernet driver to hip08 family of SoCs. This driver includes basic Rx/Tx functionality. It also includes the client registration code with the HNAE3(Hisilicon Network Acceleration Engine 3) framework. This work provides the initial

Re: [PATCH] misc: Kconfig: fix missing tristate prompt and add help for LIS3LV02D

Hi, > Am 02.08.2017 um 17:57 schrieb Greg Kroah-Hartman > : > > On Wed, Aug 02, 2017 at 04:05:36PM +0200, H. Nikolaus Schaller wrote: >> fix missing tristate prompt and add help for LIS3LV02D >> >> Signed-off-by: H. Nikolaus Schaller >> --- >>

Re: [PATCH] misc: Kconfig: fix missing tristate prompt and add help for LIS3LV02D

Hi, > Am 02.08.2017 um 17:57 schrieb Greg Kroah-Hartman > : > > On Wed, Aug 02, 2017 at 04:05:36PM +0200, H. Nikolaus Schaller wrote: >> fix missing tristate prompt and add help for LIS3LV02D >> >> Signed-off-by: H. Nikolaus Schaller >> --- >> drivers/misc/Kconfig | 5 - >> 1 file changed,

[PATCH V6 net-next 5/8] net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver

THis patch adds the support of the Scheduling and Shaping functionalities during the transmit leg. This also adds the support of Pause at MAC level. (Pause at per-priority level shall be added later along with the DCB feature). Hardware as such consists of two types of cofiguration of 6 level

[PATCH V6 net-next 5/8] net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver

THis patch adds the support of the Scheduling and Shaping functionalities during the transmit leg. This also adds the support of Pause at MAC level. (Pause at per-priority level shall be added later along with the DCB feature). Hardware as such consists of two types of cofiguration of 6 level

[PATCH V6 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

This patch adds the support of the Ethtool interface to the HNS3 Ethernet driver. Various commands to read the statistics, configure the offloading, loopback selftest etc. are supported. Signed-off-by: Daode Huang Signed-off-by: lipeng

[PATCH V6 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

This patch adds the support of the Ethtool interface to the HNS3 Ethernet driver. Various commands to read the statistics, configure the offloading, loopback selftest etc. are supported. Signed-off-by: Daode Huang Signed-off-by: lipeng Signed-off-by: Salil Mehta Signed-off-by: Yisen Zhuang

[PATCH V6 net-next 8/8] net: hns3: Add HNS3 driver to kernel build framework & MAINTAINERS

This patch updates the MAINTAINERS file with HNS3 Ethernet driver maintainers names and other details. This also introduces the new Makefiles required to build the HNS3 Ethernet driver and updates the existing Kconfig file in the hisilicon folder. Signed-off-by: Salil Mehta

[PATCH V6 net-next 8/8] net: hns3: Add HNS3 driver to kernel build framework & MAINTAINERS

This patch updates the MAINTAINERS file with HNS3 Ethernet driver maintainers names and other details. This also introduces the new Makefiles required to build the HNS3 Ethernet driver and updates the existing Kconfig file in the hisilicon folder. Signed-off-by: Salil Mehta --- MAINTAINERS

[PATCH V6 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

This patch adds the support of MDIO bus interface for HNS3 driver. Code provides various interfaces to start and stop the PHY layer and to read and write the MDIO bus or PHY. Signed-off-by: Daode Huang Signed-off-by: lipeng Signed-off-by: Salil

[PATCH V6 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

This patch adds the support of MDIO bus interface for HNS3 driver. Code provides various interfaces to start and stop the PHY layer and to read and write the MDIO bus or PHY. Signed-off-by: Daode Huang Signed-off-by: lipeng Signed-off-by: Salil Mehta Signed-off-by: Yisen Zhuang --- Patch V6:

[PATCH V6 net-next 0/8] Hisilicon Network Subsystem 3 Ethernet Driver

This patch-set contains the support of the HNS3 (Hisilicon Network Subsystem 3) Ethernet driver for hip08 family of SoCs and future upcoming SoCs. Hisilicon's new hip08 SoCs have integrated ethernet based on PCI Express and hence there was a need of new driver over the previous HNS driver which

[PATCH V6 net-next 0/8] Hisilicon Network Subsystem 3 Ethernet Driver

This patch-set contains the support of the HNS3 (Hisilicon Network Subsystem 3) Ethernet driver for hip08 family of SoCs and future upcoming SoCs. Hisilicon's new hip08 SoCs have integrated ethernet based on PCI Express and hence there was a need of new driver over the previous HNS driver which

Re: [PATCH] misc: Kconfig: fix missing tristate prompt and add help for LIS3LV02D

On Wed, Aug 02, 2017 at 04:05:36PM +0200, H. Nikolaus Schaller wrote: > fix missing tristate prompt and add help for LIS3LV02D > > Signed-off-by: H. Nikolaus Schaller > --- > drivers/misc/Kconfig | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH] misc: Kconfig: fix missing tristate prompt and add help for LIS3LV02D

On Wed, Aug 02, 2017 at 04:05:36PM +0200, H. Nikolaus Schaller wrote: > fix missing tristate prompt and add help for LIS3LV02D > > Signed-off-by: H. Nikolaus Schaller > --- > drivers/misc/Kconfig | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/misc/Kconfig

[PATCH] KVM: avoid using rcu_dereference_protected

During teardown, accesses to memslots and buses are using rcu_dereference_protected with an always-true condition because these accesses are done outside the usual mutexes. This is because the last reference is gone and there cannot be any concurrent modifications, but rcu_dereference_protected

[PATCH] KVM: avoid using rcu_dereference_protected

During teardown, accesses to memslots and buses are using rcu_dereference_protected with an always-true condition because these accesses are done outside the usual mutexes. This is because the last reference is gone and there cannot be any concurrent modifications, but rcu_dereference_protected

<    5   6   7   8   9   10   11   12   13   14   >