[PATCH 6/6] statfs: add ST_SLAVE

This lets userspace query whether a mountpoint was made MS_SLAVE. Signed-off-by: Christian Brauner --- fs/statfs.c| 10 +- include/linux/statfs.h | 1 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/statfs.c b/fs/statfs.c

[PATCH 2/6] statfs: use << to align with fs header

Consistenly use << to define ST_* constants. This also aligns them with their MS_* counterparts in fs.h Signed-off-by: Christian Brauner --- include/linux/statfs.h | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git

[PATCH 6/6] statfs: add ST_SLAVE

This lets userspace query whether a mountpoint was made MS_SLAVE. Signed-off-by: Christian Brauner --- fs/statfs.c| 10 +- include/linux/statfs.h | 1 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/statfs.c b/fs/statfs.c index 26cda2586d7e..86e957d16a68

[PATCH 2/6] statfs: use << to align with fs header

Consistenly use << to define ST_* constants. This also aligns them with their MS_* counterparts in fs.h Signed-off-by: Christian Brauner --- include/linux/statfs.h | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/include/linux/statfs.h

[PATCH 5/6] statfs: add ST_PRIVATE

This lets userspace query whether a mountpoint was made MS_PRIVATE. Signed-off-by: Christian Brauner --- fs/statfs.c| 2 ++ include/linux/statfs.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/statfs.c b/fs/statfs.c index

[PATCH 5/6] statfs: add ST_PRIVATE

This lets userspace query whether a mountpoint was made MS_PRIVATE. Signed-off-by: Christian Brauner --- fs/statfs.c| 2 ++ include/linux/statfs.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/statfs.c b/fs/statfs.c index 2fc6f9c3793c..26cda2586d7e 100644 ---

[PATCH 4/6] statfs: add ST_SHARED

This lets userspace query whether a mountpoint was made MS_SHARED. Signed-off-by: Christian Brauner --- fs/statfs.c| 2 ++ include/linux/statfs.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/statfs.c b/fs/statfs.c index

[PATCH 4/6] statfs: add ST_SHARED

This lets userspace query whether a mountpoint was made MS_SHARED. Signed-off-by: Christian Brauner --- fs/statfs.c| 2 ++ include/linux/statfs.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/statfs.c b/fs/statfs.c index 61b3063d3921..2fc6f9c3793c 100644 --- a/fs/statfs.c

[PATCH 0/3] Driver for AT91 USART in SPI mode

Hello, I wrote this driver for USART IP that is found in AT91 and SAMA5 SoCs. The IP has an internal chip select, but is not used because is deasserted and asserted after every byte sent over the wires. Gpio chip selects are used instead of internal one. The driver works with actual USART nodes

[PATCH 0/3] Driver for AT91 USART in SPI mode

Hello, I wrote this driver for USART IP that is found in AT91 and SAMA5 SoCs. The IP has an internal chip select, but is not used because is deasserted and asserted after every byte sent over the wires. Gpio chip selects are used instead of internal one. The driver works with actual USART nodes

[PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode

These are bindings for at91-usart IP in spi spi mode. There is no support for internal chip select. Only kind of chip selects available are gpio chip selects. Signed-off-by: Radu Pirea --- .../bindings/spi/microchip,at91-usart-spi.txt | 24 +++ 1 file

[PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode

These are bindings for at91-usart IP in spi spi mode. There is no support for internal chip select. Only kind of chip selects available are gpio chip selects. Signed-off-by: Radu Pirea --- .../bindings/spi/microchip,at91-usart-spi.txt | 24 +++ 1 file changed, 24 insertions(+)

[PATCH 1/3] MAINTAINERS: add usart spi driver

Add entry for at91 usart spi driver. Signed-off-by: Radu Pirea --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8e2a2fddbd19..8f80d0e30573 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9192,6 +9192,13 @@ S:

[PATCH 3/3] spi: at91-usart: add driver for at91-usart as spi

This is the driver for at91-usart in spi mode. The USART IP can be configured to work in many modes and one of them is SPI. The driver was tested on sama5d3-xplained and sama5d4-xplained boards with enc28j60 ethernet controller as slave. Signed-off-by: Radu Pirea ---

[PATCH 1/3] MAINTAINERS: add usart spi driver

Add entry for at91 usart spi driver. Signed-off-by: Radu Pirea --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8e2a2fddbd19..8f80d0e30573 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9192,6 +9192,13 @@ S: Supported F:

[PATCH 3/3] spi: at91-usart: add driver for at91-usart as spi

This is the driver for at91-usart in spi mode. The USART IP can be configured to work in many modes and one of them is SPI. The driver was tested on sama5d3-xplained and sama5d4-xplained boards with enc28j60 ethernet controller as slave. Signed-off-by: Radu Pirea --- drivers/spi/Kconfig

Re: [PATCH v3 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics

On Thu, Apr 12, 2018 at 10:15:41PM +0800, Kai-Heng Feng wrote: > at 6:59 PM, Pali Rohár wrote: > > > On Thursday 12 April 2018 12:50:02 Takashi Iwai wrote: > > > > +#if IS_ENABLED(CONFIG_DELL_LAPTOP) > > > > +static bool check_dell_switchable_gfx(struct pci_dev *pdev) > > >

Re: [PATCH v3 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics

On Thu, Apr 12, 2018 at 10:15:41PM +0800, Kai-Heng Feng wrote: > at 6:59 PM, Pali Rohár wrote: > > > On Thursday 12 April 2018 12:50:02 Takashi Iwai wrote: > > > > +#if IS_ENABLED(CONFIG_DELL_LAPTOP) > > > > +static bool check_dell_switchable_gfx(struct pci_dev *pdev) > > > > +{ > > > > +

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

On Wed, Apr 11, 2018 at 09:32:16AM +0200, Simon Horman wrote: > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote: > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 > > ("gpio: correct docs

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

On Wed, Apr 11, 2018 at 09:32:16AM +0200, Simon Horman wrote: > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote: > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 > > ("gpio: correct docs

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

On Fri, Apr 13, 2018 at 6:04 PM, Michal Hocko wrote: > On Fri 13-04-18 17:04:09, Jann Horn wrote: >> On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko wrote: >> > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote: >> > [...] >> >> So, you mean remove this entire

RE: [RFC 02/10] PCI: cadence: Update cdns_pcie_ep_raise_irq function signature

On Tue, Apr 10 at 18.15, Gustavo Pimentel wrote: > From: Gustavo Pimentel [mailto:gustavo.pimen...@synopsys.com] > Changes the cdns_pcie_ep_raise_irq function signature, namely the > interrupt_num variable type from u8 to u16 to accommodate the MSI-X > maximum interrupts of 2048. > >

RE: [RFC 02/10] PCI: cadence: Update cdns_pcie_ep_raise_irq function signature

On Tue, Apr 10 at 18.15, Gustavo Pimentel wrote: > From: Gustavo Pimentel [mailto:gustavo.pimen...@synopsys.com] > Changes the cdns_pcie_ep_raise_irq function signature, namely the > interrupt_num variable type from u8 to u16 to accommodate the MSI-X > maximum interrupts of 2048. > >

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

On Fri, Apr 13, 2018 at 6:04 PM, Michal Hocko wrote: > On Fri 13-04-18 17:04:09, Jann Horn wrote: >> On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko wrote: >> > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote: >> > [...] >> >> So, you mean remove this entire paragraph: >> >> >> >>

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

On 13/04/2018 18:02, Jim Mattson wrote: > On Fri, Apr 13, 2018 at 4:23 AM, Paolo Bonzini wrote: >> From: KarimAllah Ahmed >> >> Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always >> captures the TSC_OFFSET of the running guest

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

On 13/04/2018 18:02, Jim Mattson wrote: > On Fri, Apr 13, 2018 at 4:23 AM, Paolo Bonzini wrote: >> From: KarimAllah Ahmed >> >> Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always >> captures the TSC_OFFSET of the running guest whether it is the L1 or L2 >> guest. >> >>

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

On Fri 13-04-18 17:04:09, Jann Horn wrote: > On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko wrote: > > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote: > > [...] > >> So, you mean remove this entire paragraph: > >> > >> For cases in which the specified memory

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

On Fri 13-04-18 17:04:09, Jann Horn wrote: > On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko wrote: > > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote: > > [...] > >> So, you mean remove this entire paragraph: > >> > >> For cases in which the specified memory region has not been > >>

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

On Fri, Apr 13, 2018 at 4:23 AM, Paolo Bonzini wrote: > From: KarimAllah Ahmed > > Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always > captures the TSC_OFFSET of the running guest whether it is the L1 or L2 > guest. > > Cc: Jim

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

On Fri, Apr 13, 2018 at 4:23 AM, Paolo Bonzini wrote: > From: KarimAllah Ahmed > > Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always > captures the TSC_OFFSET of the running guest whether it is the L1 or L2 > guest. > > Cc: Jim Mattson > Cc: Paolo Bonzini > Cc: Radim

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

Hi Daniel, On Fri, Apr 13, 2018 at 05:44:09PM +0200, Daniel Vetter wrote: On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote: Hi Daniel, On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote: > On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote: > > On Tue, Mar 27,

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

Hi Daniel, On Fri, Apr 13, 2018 at 05:44:09PM +0200, Daniel Vetter wrote: On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote: Hi Daniel, On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote: > On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote: > > On Tue, Mar 27,

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

On Fri, Apr 13, 2018 at 5:13 AM, Jean Delvare wrote: > Hi Wolfram, Sam, > > On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote: >> On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote: >> > Currently, Documentation/i2c/dev-interface describes the use of i2c_smbus_* >>

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

On Fri, Apr 13, 2018 at 5:13 AM, Jean Delvare wrote: > Hi Wolfram, Sam, > > On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote: >> On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote: >> > Currently, Documentation/i2c/dev-interface describes the use of i2c_smbus_* >> > helper routines

Re: [PATCH RFC 7/8] mm: allow to control onlining/offlining of memory by a driver

On Fri 13-04-18 15:33:28, David Hildenbrand wrote: > Some devices (esp. paravirtualized) might want to control > - when to online/offline a memory block > - how to online memory (MOVABLE/NORMAL) > - in which granularity to online/offline memory > > So let's add a new flag "driver_managed" and

Re: [PATCH RFC 7/8] mm: allow to control onlining/offlining of memory by a driver

On Fri 13-04-18 15:33:28, David Hildenbrand wrote: > Some devices (esp. paravirtualized) might want to control > - when to online/offline a memory block > - how to online memory (MOVABLE/NORMAL) > - in which granularity to online/offline memory > > So let's add a new flag "driver_managed" and

Re: [PATCH ipmi/kcs_bmc v1] ipmi: add an NPCM7xx KCS BMC driver

On 03/22/2018 07:50 AM, Haiyue Wang wrote: This driver exposes the Keyboard Controller Style (KCS) interface on Novoton NPCM7xx SoCs as a character device. Such SOCs are commonly used as a BaseBoard Management Controller (BMC) on a server board, and KCS interface is commonly used to perform the

Re: [RFC PATCH 24/35] Revert "ovl: fix relatime for directories"

On Thu, Apr 12, 2018 at 05:08:15PM +0200, Miklos Szeredi wrote: > This reverts commit cd91304e7190b4c4802f8e413ab2214b233e0260. > > Overlayfs no longer relies on the vfs correct atime handling. > > Signed-off-by: Miklos Szeredi > --- > fs/inode.c | 21

Re: [RFC PATCH 24/35] Revert "ovl: fix relatime for directories"

On Thu, Apr 12, 2018 at 05:08:15PM +0200, Miklos Szeredi wrote: > This reverts commit cd91304e7190b4c4802f8e413ab2214b233e0260. > > Overlayfs no longer relies on the vfs correct atime handling. > > Signed-off-by: Miklos Szeredi > --- > fs/inode.c | 21 - >

Re: [PATCH ipmi/kcs_bmc v1] ipmi: add an NPCM7xx KCS BMC driver

On 03/22/2018 07:50 AM, Haiyue Wang wrote: This driver exposes the Keyboard Controller Style (KCS) interface on Novoton NPCM7xx SoCs as a character device. Such SOCs are commonly used as a BaseBoard Management Controller (BMC) on a server board, and KCS interface is commonly used to perform the

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Fri, Apr 13, 2018 at 2:43 PM, Dan Streetman wrote: > On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov wrote: >> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala >> wrote: >>> On 20.02.2018 18:26, Neil Horman wrote: On

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Fri, Apr 13, 2018 at 2:43 PM, Dan Streetman wrote: > On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov wrote: >> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala >> wrote: >>> On 20.02.2018 18:26, Neil Horman wrote: On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote: >

[PATCH v7 5/5] crypto: add flag for unstable encoding

The data-format of zBeWalgo, and some other algorithms is unstable. To identify such unstable algorithms this patch adds a new flag to the crypto-api. Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> --- crypto/zbewalgo.c | 2 +- include/linux/crypto.h | 6 ++ 2 files

[PATCH v7 5/5] crypto: add flag for unstable encoding

The data-format of zBeWalgo, and some other algorithms is unstable. To identify such unstable algorithms this patch adds a new flag to the crypto-api. Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> --- crypto/zbewalgo.c | 2 +- include/linux/crypto.h | 6 ++ 2 files

[PATCH v7 2/5] crypto: add zBeWalgo to crypto-api

This patch adds zBeWalgo to the crypto api so that zBeWalgo can be used by zram. Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> --- crypto/Kconfig | 12 crypto/Makefile| 1 + crypto/testmgr.c | 10 +++ crypto/testmgr.h |

[PATCH v7 2/5] crypto: add zBeWalgo to crypto-api

This patch adds zBeWalgo to the crypto api so that zBeWalgo can be used by zram. Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> --- crypto/Kconfig | 12 crypto/Makefile| 1 + crypto/testmgr.c | 10 +++ crypto/testmgr.h |

[PATCH v7 4/5] crypto: configurable compression level

Most compression algorithms published by the crypto api are supporting multiple different compression levels. The crypto api currently just calls these algorithms with their default compression level. This patch enables the caller to specify the compression level. Signed-off-by: Benjamin Warnke

[PATCH v7 4/5] crypto: configurable compression level

Most compression algorithms published by the crypto api are supporting multiple different compression levels. The crypto api currently just calls these algorithms with their default compression level. This patch enables the caller to specify the compression level. Signed-off-by: Benjamin Warnke

[PATCH v7 3/5] crypto: add unsafe decompression to api

Up to Version 3 of this patch the decompressor of zbewalgo did not verify that there is no overflow in the output buffer. Now zbewalgo includes a safe decompressor which does check for buffer overflows and heap-error. ZBewalgo and other Algorithms like lz4 include an unsafe decompressor version,

[PATCH v7 3/5] crypto: add unsafe decompression to api

Up to Version 3 of this patch the decompressor of zbewalgo did not verify that there is no overflow in the output buffer. Now zbewalgo includes a safe decompressor which does check for buffer overflows and heap-error. ZBewalgo and other Algorithms like lz4 include an unsafe decompressor version,

[PATCH v7 1/5] add compression algorithm zBeWalgo

zBeWalgo is a completely new algorithm - Currently it is not published somewhere else right now, googleing it would not show up any results. The following section describes how the algorithm works. zBeWalgo itself is a container compression algorithm, which can execute multiple different

[PATCH v7 1/5] add compression algorithm zBeWalgo

zBeWalgo is a completely new algorithm - Currently it is not published somewhere else right now, googleing it would not show up any results. The following section describes how the algorithm works. zBeWalgo itself is a container compression algorithm, which can execute multiple different

[PATCH v7 0/5] add compression algorithm zBeWalgo

This patch series adds a new compression algorithm to the kernel and to the crypto api. Changes since v6: - Fixed git apply error due to other recently applied patches Changes since v5: - Fixed compile-error due to variable definitions inside #ifdef CONFIG_ZRAM_WRITEBACK Changes since v4: -

[PATCH v7 0/5] add compression algorithm zBeWalgo

This patch series adds a new compression algorithm to the kernel and to the crypto api. Changes since v6: - Fixed git apply error due to other recently applied patches Changes since v5: - Fixed compile-error due to variable definitions inside #ifdef CONFIG_ZRAM_WRITEBACK Changes since v4: -

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote: > Hi Daniel, > > On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote: > > On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote: > > > On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote: > > > > On Tue, Mar

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote: > Hi Daniel, > > On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote: > > On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote: > > > On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote: > > > > On Tue, Mar

RE: [PATCH v3 2/2] MIPS: io: add a barrier after register read in readX()

From: James Hogan > Sent: 12 April 2018 22:52 > On Tue, Apr 03, 2018 at 08:55:04AM -0400, Sinan Kaya wrote: > > While a barrier is present in writeX() function before the register write, > > a similar barrier is missing in the readX() function after the register > > read. This could allow memory

RE: [PATCH v3 2/2] MIPS: io: add a barrier after register read in readX()

From: James Hogan > Sent: 12 April 2018 22:52 > On Tue, Apr 03, 2018 at 08:55:04AM -0400, Sinan Kaya wrote: > > While a barrier is present in writeX() function before the register write, > > a similar barrier is missing in the readX() function after the register > > read. This could allow memory

[GIT PULL] arch/sh updates for 4.17

Hi Linus, Please pull these changes for arch/sh. Some of them have been pending (and in linux-next) for a long time and address longstanding issues. Rich The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda: Linux 4.16 (2018-04-01 14:20:27 -0700) are available in

[GIT PULL] arch/sh updates for 4.17

Hi Linus, Please pull these changes for arch/sh. Some of them have been pending (and in linux-next) for a long time and address longstanding issues. Rich The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda: Linux 4.16 (2018-04-01 14:20:27 -0700) are available in

Re: [PATCH v5 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

On Tue, Apr 10 2018 at 22:39 -0600, Stephen Boyd wrote: Quoting Lina Iyer (2018-04-05 09:18:25) Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for

Re: [PATCH v5 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

On Tue, Apr 10 2018 at 22:39 -0600, Stephen Boyd wrote: Quoting Lina Iyer (2018-04-05 09:18:25) Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for

Re: [RfC PATCH] Add udmabuf misc device

On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote: > On 04/10/2018 08:26 PM, Dongwon Kim wrote: > > On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote: > > > On 04/06/2018 09:57 PM, Dongwon Kim wrote: > > > > On Fri, Apr 06, 2018 at 03:36:03PM +0300,

Re: [RfC PATCH] Add udmabuf misc device

On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote: > On 04/10/2018 08:26 PM, Dongwon Kim wrote: > > On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote: > > > On 04/06/2018 09:57 PM, Dongwon Kim wrote: > > > > On Fri, Apr 06, 2018 at 03:36:03PM +0300,

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

On 13/04/2018 14:40, Raslan, KarimAllah wrote: >> >> static void update_ia32_tsc_adjust_msr(struct kvm_vcpu *vcpu, s64 offset) >> { >> -u64 curr_offset = vcpu->arch.tsc_offset; >> +u64 curr_offset = kvm_x86_ops->read_l1_tsc_offset(vcpu); > I might be missing something but is this

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

On 13/04/2018 14:40, Raslan, KarimAllah wrote: >> >> static void update_ia32_tsc_adjust_msr(struct kvm_vcpu *vcpu, s64 offset) >> { >> -u64 curr_offset = vcpu->arch.tsc_offset; >> +u64 curr_offset = kvm_x86_ops->read_l1_tsc_offset(vcpu); > I might be missing something but is this

RE: [PATCH v5 05/14] PCI: Add pcie_print_link_status() to log link speed and whether it's limited

> -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Friday, April 13, 2018 7:07 AM > To: Jakub Kicinski > Cc: Tal Gilboa ; Tariq Toukan ; > Keller, Jacob E ; Ariel Elior >

RE: [PATCH v5 05/14] PCI: Add pcie_print_link_status() to log link speed and whether it's limited

> -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Friday, April 13, 2018 7:07 AM > To: Jakub Kicinski > Cc: Tal Gilboa ; Tariq Toukan ; > Keller, Jacob E ; Ariel Elior > ; > Ganesh Goudar ; Kirsher, Jeffrey T > ; everest-linux...@cavium.com; intel-wired- >

Re: [PATCHv2 1/3] dt-bindings: misc: achc: Make ezport distinguishable

On Mon, Apr 9, 2018 at 4:13 PM, Sebastian Reichel wrote: > Hi, > > On Mon, Apr 09, 2018 at 01:57:27PM -0500, Rob Herring wrote: >> On Tue, Mar 27, 2018 at 03:52:57PM +0200, Sebastian Reichel wrote: >> > This updates the GE ACHC binding, so that different

Re: [PATCHv2 1/3] dt-bindings: misc: achc: Make ezport distinguishable

On Mon, Apr 9, 2018 at 4:13 PM, Sebastian Reichel wrote: > Hi, > > On Mon, Apr 09, 2018 at 01:57:27PM -0500, Rob Herring wrote: >> On Tue, Mar 27, 2018 at 03:52:57PM +0200, Sebastian Reichel wrote: >> > This updates the GE ACHC binding, so that different compatible >> > strings are used for the

Re: [PATCH] kasan: add no_sanitize attribute for clang builds

On 04/12/2018 08:29 PM, Andrey Konovalov wrote: > KASAN uses the __no_sanitize_address macro to disable instrumentation > of particular functions. Right now it's defined only for GCC build, > which causes false positives when clang is used. > > This patch adds a definition for clang. > > Note,

Re: [PATCH] kasan: add no_sanitize attribute for clang builds

On 04/12/2018 08:29 PM, Andrey Konovalov wrote: > KASAN uses the __no_sanitize_address macro to disable instrumentation > of particular functions. Right now it's defined only for GCC build, > which causes false positives when clang is used. > > This patch adds a definition for clang. > > Note,

[PATCH v2] drm/arm/malidp: Ensure that the crtcs are shutdown before removing any encoder/connector

One needs to ensure that the crtcs are shutdown so that the drm_crtc_state->connector_mask reflects that no connectors are currently active. Further, it reduces the reference count for each connector. This ensures that the connectors and encoders can be cleanly removed either when _unbind is

[PATCH v2] drm/arm/malidp: Ensure that the crtcs are shutdown before removing any encoder/connector

One needs to ensure that the crtcs are shutdown so that the drm_crtc_state->connector_mask reflects that no connectors are currently active. Further, it reduces the reference count for each connector. This ensures that the connectors and encoders can be cleanly removed either when _unbind is

Re: KASAN: slab-out-of-bounds Write in perf_callchain_user

On Thu, Apr 12, 2018 at 03:02:01AM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on bpf-next commit > 17dec0a949153d9ac00760ba2f5b78cb583e995f (Wed Apr 4 02:15:32 2018 +) > Merge branch 'userns-linus' of >

Re: KASAN: slab-out-of-bounds Write in perf_callchain_user

On Thu, Apr 12, 2018 at 03:02:01AM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on bpf-next commit > 17dec0a949153d9ac00760ba2f5b78cb583e995f (Wed Apr 4 02:15:32 2018 +) > Merge branch 'userns-linus' of >

[PATCH] lockdown: fix coordination of kernel module signature verification

If both IMA-appraisal and sig_enforce are enabled, then both signatures are currently required. If the IMA-appraisal signature verification fails, it could rely on the appended signature verification; but with the lockdown patch set, the appended signature verification assumes that if

[PATCH] lockdown: fix coordination of kernel module signature verification

If both IMA-appraisal and sig_enforce are enabled, then both signatures are currently required. If the IMA-appraisal signature verification fails, it could rely on the appended signature verification; but with the lockdown patch set, the appended signature verification assumes that if

Re: [PATCH net] virtio-net: add missing virtqueue kick when flushing packets

From: Jason Wang Date: Fri, 13 Apr 2018 14:58:25 +0800 > We tends to batch submitting packets during XDP_TX. This requires to > kick virtqueue after a batch, we tried to do it through > xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So > explicitly kick the

Re: [PATCH net] virtio-net: add missing virtqueue kick when flushing packets

From: Jason Wang Date: Fri, 13 Apr 2018 14:58:25 +0800 > We tends to batch submitting packets during XDP_TX. This requires to > kick virtqueue after a batch, we tried to do it through > xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So > explicitly kick the virtqueue in this

Re: [RFC v2] virtio: support packed ring

On Sun, Apr 01, 2018 at 10:12:16PM +0800, Tiwei Bie wrote: > +static inline bool more_used(const struct vring_virtqueue *vq) > +{ > + return vq->packed ? more_used_packed(vq) : more_used_split(vq); > +} > + > +void *virtqueue_get_buf_ctx_split(struct virtqueue *_vq, unsigned int *len, > +

Re: [RFC v2] virtio: support packed ring

On Sun, Apr 01, 2018 at 10:12:16PM +0800, Tiwei Bie wrote: > +static inline bool more_used(const struct vring_virtqueue *vq) > +{ > + return vq->packed ? more_used_packed(vq) : more_used_split(vq); > +} > + > +void *virtqueue_get_buf_ctx_split(struct virtqueue *_vq, unsigned int *len, > +

Re: [PATCH v3 4/4] DTS: Bindings: pca953x: add example how to use interrupt-controller and gpio-controller

On Tue, Apr 10, 2018 at 11:07 AM, H. Nikolaus Schaller wrote: > It is not completely obvious that these are required and > how to use them. So we provide a tested example. > > Signed-off-by: H. Nikolaus Schaller > --- >

Re: [PATCH v3 4/4] DTS: Bindings: pca953x: add example how to use interrupt-controller and gpio-controller

On Tue, Apr 10, 2018 at 11:07 AM, H. Nikolaus Schaller wrote: > It is not completely obvious that these are required and > how to use them. So we provide a tested example. > > Signed-off-by: H. Nikolaus Schaller > --- > .../devicetree/bindings/gpio/gpio-pca953x.txt | 33 >

Re: [PATCH] soc: ti: knav_qmss: Use percpu instead atomic for stats counter

On 4/11/18 3:28 PM, santosh.shilim...@oracle.com wrote: On 4/11/18 12:16 PM, Vasyl Gomonovych wrote: Hwqueue has collect statistics in heavy use queue_pop/queu_push functions for cache efficiency and make push/pop faster use percpu variables. For performance reasons, driver should keep

Re: [PATCH] soc: ti: knav_qmss: Use percpu instead atomic for stats counter

On 4/11/18 3:28 PM, santosh.shilim...@oracle.com wrote: On 4/11/18 12:16 PM, Vasyl Gomonovych wrote: Hwqueue has collect statistics in heavy use queue_pop/queu_push functions for cache efficiency and make push/pop faster use percpu variables. For performance reasons, driver should keep

[PATCH 1/3] USB: musb: dsps: drop duplicate phy initialisation

Since commit 39cee200c23e ("usb: musb: core: call init and shutdown for the usb phy") the musb USB phy is initialised by musb_core, but the original initialisation in the dsps-glue init callback was left in place resulting in two calls to phy init during probe (and similarly, two shutdowns on

[PATCH 1/3] USB: musb: dsps: drop duplicate phy initialisation

Since commit 39cee200c23e ("usb: musb: core: call init and shutdown for the usb phy") the musb USB phy is initialised by musb_core, but the original initialisation in the dsps-glue init callback was left in place resulting in two calls to phy init during probe (and similarly, two shutdowns on

[PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

I've been carrying a patch out-of-tree since my work on improving the USB device-tree support which is needed to be able to describe USB topologies for musb based controllers. This patch, which associates the platform controller device with the glue device device-tree node, did not play well with

[PATCH 3/3] USB: musb: dsps: propagate device-tree node

To be able to use DSPS-based controllers with device-tree descriptions of the USB topology, we need to associate the glue device's device-tree node with the child controller device. Note that this can also be used to eventually let USB core manage generic phys. Also note that the other glue

[PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

I've been carrying a patch out-of-tree since my work on improving the USB device-tree support which is needed to be able to describe USB topologies for musb based controllers. This patch, which associates the platform controller device with the glue device device-tree node, did not play well with

[PATCH 3/3] USB: musb: dsps: propagate device-tree node

To be able to use DSPS-based controllers with device-tree descriptions of the USB topology, we need to associate the glue device's device-tree node with the child controller device. Note that this can also be used to eventually let USB core manage generic phys. Also note that the other glue

[PATCH 2/3] USB: musb: host: prevent core phy initialisation

Set the new HCD flag which prevents USB core from trying to manage our phys. This is needed to be able to associate the controller platform device with the glue device device-tree node on the BBB which uses legacy USB phys. Otherwise, the generic phy lookup in usb_phy_roothub_init() and thus HCD

[PATCH 2/3] USB: musb: host: prevent core phy initialisation

Set the new HCD flag which prevents USB core from trying to manage our phys. This is needed to be able to associate the controller platform device with the glue device device-tree node on the BBB which uses legacy USB phys. Otherwise, the generic phy lookup in usb_phy_roothub_init() and thus HCD

Re: [PATCH v6 01/11] dt-bindings: firmware: Add bindings for ZynqMP firmware

On Tue, Apr 10, 2018 at 12:38:37PM -0700, Jolly Shah wrote: > From: Rajan Vaja > > Add documentation to describe Xilinx ZynqMP firmware driver > bindings. Firmware driver provides an interface to firmware > APIs. Interface APIs can be used by any driver to communicate > to

[PATCH] drm/vmwgfx: Fix scatterlist unmapping

dma_unmap_sg() should be called with the same number of entries originally passed to dma_map_sg(), not the number it returned, which may be fewer. Admittedly this driver probably never runs on non-coherent architectures where getting that wrong could lead to data loss, but it's always good to be

Re: [PATCH v6 01/11] dt-bindings: firmware: Add bindings for ZynqMP firmware

On Tue, Apr 10, 2018 at 12:38:37PM -0700, Jolly Shah wrote: > From: Rajan Vaja > > Add documentation to describe Xilinx ZynqMP firmware driver > bindings. Firmware driver provides an interface to firmware > APIs. Interface APIs can be used by any driver to communicate > to PMUFW (Platform

[PATCH] drm/vmwgfx: Fix scatterlist unmapping

dma_unmap_sg() should be called with the same number of entries originally passed to dma_map_sg(), not the number it returned, which may be fewer. Admittedly this driver probably never runs on non-coherent architectures where getting that wrong could lead to data loss, but it's always good to be

[PATCH] cifs: smb2ops: Fix NULL check in smb2_query_symlink

The current code null checks variable err_buf, which is always null when it is checked, hence utf16_path is free'd and the function returns -ENOENT everytime it is called, making it impossible for the execution path to reach the following code: err_buf = err_iov.iov_base; Fix this by null

[PATCH] cifs: smb2ops: Fix NULL check in smb2_query_symlink

The current code null checks variable err_buf, which is always null when it is checked, hence utf16_path is free'd and the function returns -ENOENT everytime it is called, making it impossible for the execution path to reach the following code: err_buf = err_iov.iov_base; Fix this by null

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