Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [Xen-devel] [linux-4.1 bisection] complet

i have the same issue without xen. for me network traffic causes oom within seconds to 3 minutes on embedded systems. but i dont know if this is the cause. i just can say that it was introduced with 3.18.37 Am 18.07.2016 um 18:18 schrieb Konrad Rzeszutek Wilk: On Mon, Jul 18, 2016 at

[PATCH v4 2/2] pinctrl: iproc: Add NSP and Stingray GPIO support

The iProc GPIO controller is shared among multiple iProc based SoCs. In the NSP integration, the drive strength pinctrl function is disabled. In the integration of Stingray, pinctrl is handled by another block and this GPIO controller is solely used as a GPIO controller, and therefore should not

Re: [PATCH 7/7] dts: hi6220: Add k3-dma and i2s/hdmi audio support

On Sat, Jul 16, 2016 at 4:48 AM, Mark Brown wrote: > On Fri, Jul 15, 2016 at 07:13:27PM -0700, John Stultz wrote: > >> Add entry for k3-dma driver and i2s/hdmi audio devices. > >> This enables HDMI audio output. > > These bindings appear to be undocumented. All new bindings

[PATCH v4 0/2] Additional iProc GPIO support

Add support to the iProc GPIO driver for the NSP and Stingray iProc based SoCs. The integration in NSP has drive strength pinconf feature disabled and the integration in Stingray has all pinconf related features disabled and handled by a different IP block GITHUB repo:

[PATCH v4 1/2] dt-bindings: Update iProc GPIO bindings

Update the iProc GPIO binding document to add new compatible strings "brcm,iproc-nsp-gpio" and "brcm,iproc-stingray-gpio" to support the iProc based GPIO controller used in the NSP and Stingray SoCs, respectively Signed-off-by: Ray Jui ---

[PATCH v4 0/2] Additional iProc GPIO support

Add support to the iProc GPIO driver for the NSP and Stingray iProc based SoCs. The integration in NSP has drive strength pinconf feature disabled and the integration in Stingray has all pinconf related features disabled and handled by a different IP block GITHUB repo:

[PATCH v4 1/2] dt-bindings: Update iProc GPIO bindings

Update the iProc GPIO binding document to add new compatible strings "brcm,iproc-nsp-gpio" and "brcm,iproc-stingray-gpio" to support the iProc based GPIO controller used in the NSP and Stingray SoCs, respectively Signed-off-by: Ray Jui --- .../devicetree/bindings/pinctrl/brcm,iproc-gpio.txt

Re: [PATCH 7/7] dts: hi6220: Add k3-dma and i2s/hdmi audio support

On Sat, Jul 16, 2016 at 4:48 AM, Mark Brown wrote: > On Fri, Jul 15, 2016 at 07:13:27PM -0700, John Stultz wrote: > >> Add entry for k3-dma driver and i2s/hdmi audio devices. > >> This enables HDMI audio output. > > These bindings appear to be undocumented. All new bindings require >

Re: [PATCH 2/3] f2fs: support copy_file_range

Hi, Please ignore copy/clone_file_range patches, which are wrong implementation. Sorry for the noise. Thanks, On Sat, Jul 16, 2016 at 11:24:26PM -0700, Jaegeuk Kim wrote: > This patch implements copy_file_range in f2fs. > > Signed-off-by: Jaegeuk Kim > --- >

Re: [PATCH 2/3] f2fs: support copy_file_range

Hi, Please ignore copy/clone_file_range patches, which are wrong implementation. Sorry for the noise. Thanks, On Sat, Jul 16, 2016 at 11:24:26PM -0700, Jaegeuk Kim wrote: > This patch implements copy_file_range in f2fs. > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/file.c | 98 >

Re: [PATCH] mtd: nand: fix bug writing 1 byte less than page size

+ Kamal, FYI On Mon, Jul 18, 2016 at 11:04:32AM +0200, Boris Brezillon wrote: > On Mon, 18 Jul 2016 10:39:18 +0200 > Hector Palacios wrote: > > > nand_do_write_ops() determines if it is writing a partial page with the > > formula: > > part_pagewr = (column ||

Re: [PATCH] mtd: nand: fix bug writing 1 byte less than page size

+ Kamal, FYI On Mon, Jul 18, 2016 at 11:04:32AM +0200, Boris Brezillon wrote: > On Mon, 18 Jul 2016 10:39:18 +0200 > Hector Palacios wrote: > > > nand_do_write_ops() determines if it is writing a partial page with the > > formula: > > part_pagewr = (column || writelen < (mtd->writesize -

Re: [RFC] locking/mutex: Fix starvation of sleeping waiters

On Mon, Jul 18, 2016 at 07:16:47PM +0300, Imre Deak wrote: > Currently a thread sleeping on a mutex wait queue can be delayed > indefinitely by other threads managing to steal the lock, that is > acquiring the lock out-of-order before the sleepers. I noticed this via > a testcase (see the

Re: [RFC] locking/mutex: Fix starvation of sleeping waiters

On Mon, Jul 18, 2016 at 07:16:47PM +0300, Imre Deak wrote: > Currently a thread sleeping on a mutex wait queue can be delayed > indefinitely by other threads managing to steal the lock, that is > acquiring the lock out-of-order before the sleepers. I noticed this via > a testcase (see the

Re: [RFCv2 4/4] perf: util: support sysfs supported_cpumask file

On Mon, Jul 18, 2016 at 05:38:16PM +0100, Suzuki K Poulose wrote: > On 15/07/16 11:08, Mark Rutland wrote: > >For system PMUs, the perf tools have long expected a cpumask file under > >sysfs, describing the single CPU which they support events being > >opened/handled on. Prior patches in this

Re: [RFCv2 4/4] perf: util: support sysfs supported_cpumask file

On Mon, Jul 18, 2016 at 05:38:16PM +0100, Suzuki K Poulose wrote: > On 15/07/16 11:08, Mark Rutland wrote: > >For system PMUs, the perf tools have long expected a cpumask file under > >sysfs, describing the single CPU which they support events being > >opened/handled on. Prior patches in this

Re: [PATCH v5] wlcore: spi: add wl18xx support

"Reizer, Eyal" writes: > Add support for using with both wl12xx and wl18xx. > > - all wilink family needs special init command for entering wspi mode. > extra clock cycles should be sent after the spi init command while the > cs pin is high. > - Use inverted chip select for

Re: [PATCH v5] wlcore: spi: add wl18xx support

"Reizer, Eyal" writes: > Add support for using with both wl12xx and wl18xx. > > - all wilink family needs special init command for entering wspi mode. > extra clock cycles should be sent after the spi init command while the > cs pin is high. > - Use inverted chip select for sending a dummy 4

Re: [PATCH] mtd: update description of MTD_BCM47XXSFLASH symbol

On Mon, Jul 18, 2016 at 12:07:03PM +0200, Rafał Miłecki wrote: > For years now we support writing to BCMA SoC serial flash, so don't > describe this driver as providing read-only support anymore. > > Signed-off-by: Rafał Miłecki Applied to l2-mtd.git

Re: [PATCH] mtd: update description of MTD_BCM47XXSFLASH symbol

On Mon, Jul 18, 2016 at 12:07:03PM +0200, Rafał Miłecki wrote: > For years now we support writing to BCMA SoC serial flash, so don't > describe this driver as providing read-only support anymore. > > Signed-off-by: Rafał Miłecki Applied to l2-mtd.git

Re: [PATCH 1/2] dmi-id: don't free dev structure after calling device_register

On Thu, 14 Jul 2016 16:01:22 +0800, Allen Hung wrote: > dmi_dev is freed in error exit code but, according to the document > of device_register, it should never directly free device structure > after calling this function, even if it returned an error! Use > put_device() instead. > >

Re: [PATCH 1/2] dmi-id: don't free dev structure after calling device_register

On Thu, 14 Jul 2016 16:01:22 +0800, Allen Hung wrote: > dmi_dev is freed in error exit code but, according to the document > of device_register, it should never directly free device structure > after calling this function, even if it returned an error! Use > put_device() instead. > >

[PATCH v2 0/2] led: is31fl32xx: minor improvements

Changes V2: * added tested David Rivshin (received off-list) * fixes: (received off-list) 2016-07-18 18:39:40: while developing the is31fl319x driver we found some minor issues relevant in the is31fl32xx driver. H. Nikolaus Schaller (2): led: is31fl32xx: fix typo in id

[PATCH v2 1/2] led: is31fl32xx: fix typo in id and match table names

Signed-off-by: H. Nikolaus Schaller Tested-by: David Rivshin Acked-by: David Rivshin --- drivers/leds/leds-is31fl32xx.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git

[PATCH v2 2/2] led: is31fl32xx: define complete i2c_device_id table

Otherwise the driver module will not be automatically probed. Fixes: 9d7cffaf99f5 ("leds: Add driver for the ISSI IS31FL32xx family of LED controllers") Fixes: e0442d7def8f ("leds: Add SN3218 and SN3216 support to the IS31FL32XX driver") Signed-off-by: H. Nikolaus Schaller

[PATCH v2 0/2] led: is31fl32xx: minor improvements

Changes V2: * added tested David Rivshin (received off-list) * fixes: (received off-list) 2016-07-18 18:39:40: while developing the is31fl319x driver we found some minor issues relevant in the is31fl32xx driver. H. Nikolaus Schaller (2): led: is31fl32xx: fix typo in id and match table names

[PATCH v2 1/2] led: is31fl32xx: fix typo in id and match table names

Signed-off-by: H. Nikolaus Schaller Tested-by: David Rivshin Acked-by: David Rivshin --- drivers/leds/leds-is31fl32xx.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/leds/leds-is31fl32xx.c b/drivers/leds/leds-is31fl32xx.c index c901d13..a53b71e

[PATCH v2 2/2] led: is31fl32xx: define complete i2c_device_id table

Otherwise the driver module will not be automatically probed. Fixes: 9d7cffaf99f5 ("leds: Add driver for the ISSI IS31FL32xx family of LED controllers") Fixes: e0442d7def8f ("leds: Add SN3218 and SN3216 support to the IS31FL32XX driver") Signed-off-by: H. Nikolaus Schaller Tested-by: David

Re: [RFC PATCH 00/30] Kernel NET policy

On Sun, Jul 17, 2016 at 11:55 PM, wrote: > From: Kan Liang > > It is a big challenge to get good network performance. First, the network > performance is not good with default system settings. Second, it is too > difficult to do automatic tuning for all

Re: [PATCH/RFC 2/6] spi: core: Add support for registering SPI slave controllers

On Wed, Jun 22, 2016 at 03:42:05PM +0200, Geert Uytterhoeven wrote: > Add support for registering SPI slave controllers using the existing SPI > master framework: > - SPI slave controllers must set the SPI_MASTER_IS_SLAVE flag in > spi_master.flags, > - The "cs-gpios" property is ignored,

Re: [RFC PATCH 00/30] Kernel NET policy

On Sun, Jul 17, 2016 at 11:55 PM, wrote: > From: Kan Liang > > It is a big challenge to get good network performance. First, the network > performance is not good with default system settings. Second, it is too > difficult to do automatic tuning for all possible workloads, since workloads >

Re: [PATCH/RFC 2/6] spi: core: Add support for registering SPI slave controllers

On Wed, Jun 22, 2016 at 03:42:05PM +0200, Geert Uytterhoeven wrote: > Add support for registering SPI slave controllers using the existing SPI > master framework: > - SPI slave controllers must set the SPI_MASTER_IS_SLAVE flag in > spi_master.flags, > - The "cs-gpios" property is ignored,

Re: drm/ttm: Delete an unnecessary check before the function call "ttm_tt_destroy"

> When resending pls describe what changed (and why). v3: A bit of reformatting with current software v2: Broken patch where I managed to delete a "t" too much in a source code line somehow. v1: See also a similar update suggestion https://lkml.org/lkml/2015/11/16/416 Would you like

Re: drm/ttm: Delete an unnecessary check before the function call "ttm_tt_destroy"

> When resending pls describe what changed (and why). v3: A bit of reformatting with current software v2: Broken patch where I managed to delete a "t" too much in a source code line somehow. v1: See also a similar update suggestion https://lkml.org/lkml/2015/11/16/416 Would you like

Re: [RFC PATCH 30/30] Documentation/networking: Document net policy

On 07/17/16 23:56, kan.li...@intel.com wrote: > From: Kan Liang > > Signed-off-by: Kan Liang > --- > Documentation/networking/netpolicy.txt | 158 > + > 1 file changed, 158 insertions(+) > create mode 100644

Re: [RFC PATCH 30/30] Documentation/networking: Document net policy

On 07/17/16 23:56, kan.li...@intel.com wrote: > From: Kan Liang > > Signed-off-by: Kan Liang > --- > Documentation/networking/netpolicy.txt | 158 > + > 1 file changed, 158 insertions(+) > create mode 100644 Documentation/networking/netpolicy.txt > > diff

Re: [PATCH v2 10/10] binfmt_flat: allow compressed flat binary format to work on MMU systems

On Mon, 18 Jul 2016, One Thousand Gnomes wrote: > On Mon, 18 Jul 2016 11:45:53 -0400 (EDT) > Nicolas Pitre wrote: > > > On Mon, 18 Jul 2016, One Thousand Gnomes wrote: > > > > > On Sun, 17 Jul 2016 23:31:56 -0400 > > > Nicolas Pitre wrote: >

Re: [PATCH v2 10/10] binfmt_flat: allow compressed flat binary format to work on MMU systems

On Mon, 18 Jul 2016, One Thousand Gnomes wrote: > On Mon, 18 Jul 2016 11:45:53 -0400 (EDT) > Nicolas Pitre wrote: > > > On Mon, 18 Jul 2016, One Thousand Gnomes wrote: > > > > > On Sun, 17 Jul 2016 23:31:56 -0400 > > > Nicolas Pitre wrote: > > > > > > > Let's take the simple and obvious

Re: [PATCH v2 10/10] binfmt_flat: allow compressed flat binary format to work on MMU systems

On Mon, 18 Jul 2016 11:45:53 -0400 (EDT) Nicolas Pitre wrote: > On Mon, 18 Jul 2016, One Thousand Gnomes wrote: > > > On Sun, 17 Jul 2016 23:31:56 -0400 > > Nicolas Pitre wrote: > > > > > Let's take the simple and obvious approach by

Re: [PATCH v2 10/10] binfmt_flat: allow compressed flat binary format to work on MMU systems

On Mon, 18 Jul 2016 11:45:53 -0400 (EDT) Nicolas Pitre wrote: > On Mon, 18 Jul 2016, One Thousand Gnomes wrote: > > > On Sun, 17 Jul 2016 23:31:56 -0400 > > Nicolas Pitre wrote: > > > > > Let's take the simple and obvious approach by decompressing the binary > > > into a kernel buffer and

Re: [PATCH v8 2/4] i2c-smbus: add SMBus Host Notify support

On Mon, 18 Jul 2016 17:59:02 +0200, Benjamin Tissoires wrote: > On Jul 18 2016 or thereabouts, Jean Delvare wrote: > > You provide stubs for SMBus Host Notify support if CONFIG_I2C_SMBUS is > > not selected. There are no such stubs for SMBus Alert support, for which > > I assumed drivers would

Re: [PATCH v8 2/4] i2c-smbus: add SMBus Host Notify support

On Mon, 18 Jul 2016 17:59:02 +0200, Benjamin Tissoires wrote: > On Jul 18 2016 or thereabouts, Jean Delvare wrote: > > You provide stubs for SMBus Host Notify support if CONFIG_I2C_SMBUS is > > not selected. There are no such stubs for SMBus Alert support, for which > > I assumed drivers would

Re: [RFCv2 4/4] perf: util: support sysfs supported_cpumask file

On 15/07/16 11:08, Mark Rutland wrote: For system PMUs, the perf tools have long expected a cpumask file under sysfs, describing the single CPU which they support events being opened/handled on. Prior patches in this series have reworked this support to support multiple CPUs in a mask, as is

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hey Marek, Marek Szyprowski wrote: > Dear Tobias > > > On 2016-07-18 13:00, Tobias Jakobi wrote: >> Marek Szyprowski wrote: >>> On 2016-07-15 15:21, Tobias Jakobi wrote: Tobias Jakobi wrote: > Hello Marek, > > I've tested the patchset on 4.7-rc7 and noticed that it breaks

[PATCH 2/2] led: is31fl32xx: define complete i2c_device_id table

Otherwise the driver module will not be automatically probed. Signed-off-by: H. Nikolaus Schaller --- drivers/leds/leds-is31fl32xx.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/leds/leds-is31fl32xx.c b/drivers/leds/leds-is31fl32xx.c

[PATCH V2 0/3] perf/core: Miscellaneous fix for address filtering

This is the second wave of a patchset that address miscellaneous bugs encountered while implementing address filtering on CoreSight. The set has been tested, and applies cleanly, on 4.7-rc7. Thanks, Mathieu Changes since V1: . Simplified filename handling in function

Re: [RFCv2 4/4] perf: util: support sysfs supported_cpumask file

On 15/07/16 11:08, Mark Rutland wrote: For system PMUs, the perf tools have long expected a cpumask file under sysfs, describing the single CPU which they support events being opened/handled on. Prior patches in this series have reworked this support to support multiple CPUs in a mask, as is

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hey Marek, Marek Szyprowski wrote: > Dear Tobias > > > On 2016-07-18 13:00, Tobias Jakobi wrote: >> Marek Szyprowski wrote: >>> On 2016-07-15 15:21, Tobias Jakobi wrote: Tobias Jakobi wrote: > Hello Marek, > > I've tested the patchset on 4.7-rc7 and noticed that it breaks

[PATCH 2/2] led: is31fl32xx: define complete i2c_device_id table

Otherwise the driver module will not be automatically probed. Signed-off-by: H. Nikolaus Schaller --- drivers/leds/leds-is31fl32xx.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/leds/leds-is31fl32xx.c b/drivers/leds/leds-is31fl32xx.c index

[PATCH V2 0/3] perf/core: Miscellaneous fix for address filtering

This is the second wave of a patchset that address miscellaneous bugs encountered while implementing address filtering on CoreSight. The set has been tested, and applies cleanly, on 4.7-rc7. Thanks, Mathieu Changes since V1: . Simplified filename handling in function

[PATCH V2 1/3] perf/core: Fixing filename for start/stop filters

Binary file names have to be supplied for both range and start/stop filters but the current code only process the filename if an address range filter is specified. This code adds processing of the filename for start/stop filters. Signed-off-by: Mathieu Poirier ---

[PATCH 0/2] led: is31fl32xx: minor improvements

while developing the is31fl319x driver we found some minor issues relevant in the is31fl32xx driver. H. Nikolaus Schaller (2): led: is31fl32xx: fix typo in id and match table names led: is31fl32xx: define complete i2c_device_id table drivers/leds/leds-is31fl32xx.c | 24

[PATCH V2 2/3] perf/core: Update filter only on executable mmap

Function perf_event_mmap() is called by the MM subsystem each time part of a binary is loaded in memory. There can be several mapping for a binary, many times unrelated to the code section. Each time a section of a binary is mapped address filters are updated, event when the map doesn't pertain

[PATCH 0/2] led: is31fl32xx: minor improvements

while developing the is31fl319x driver we found some minor issues relevant in the is31fl32xx driver. H. Nikolaus Schaller (2): led: is31fl32xx: fix typo in id and match table names led: is31fl32xx: define complete i2c_device_id table drivers/leds/leds-is31fl32xx.c | 24

[PATCH V2 2/3] perf/core: Update filter only on executable mmap

Function perf_event_mmap() is called by the MM subsystem each time part of a binary is loaded in memory. There can be several mapping for a binary, many times unrelated to the code section. Each time a section of a binary is mapped address filters are updated, event when the map doesn't pertain

[PATCH V2 1/3] perf/core: Fixing filename for start/stop filters

Binary file names have to be supplied for both range and start/stop filters but the current code only process the filename if an address range filter is specified. This code adds processing of the filename for start/stop filters. Signed-off-by: Mathieu Poirier --- kernel/events/core.c | 6

Re: [PATCH v1 1/1] x86/pci: Use MRFLD abbreviation for Merrifield

On Wed, Jul 13, 2016 at 09:24:35AM +0200, Ingo Molnar wrote: > > Bjorn, we already have a few incidental changes to > arch/x86/pci/intel_mid_pci.c > pending in the tip:x86/platform tree: > > e99a0745bdf8 x86/pci, x86/platform/intel_mid_pci: Remove duplicate power off > code > 5823d0893ec2

[PATCH V2 3/3] perf/core: Enabling mapping of the stop filters

At this time function perf_addr_filter_needs_mmap() will _not_ return true on a user space 'stop' filter. But stop filters needs exactly the same kind of mapping that range and start filters get. Signed-off-by: Mathieu Poirier --- kernel/events/core.c | 15

[PATCH 1/2] led: is31fl32xx: fix typo in id and match table names

Signed-off-by: H. Nikolaus Schaller --- drivers/leds/leds-is31fl32xx.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/leds/leds-is31fl32xx.c b/drivers/leds/leds-is31fl32xx.c index c901d13..a53b71e 100644 ---

Re: [PATCH v1 1/1] x86/pci: Use MRFLD abbreviation for Merrifield

On Wed, Jul 13, 2016 at 09:24:35AM +0200, Ingo Molnar wrote: > > Bjorn, we already have a few incidental changes to > arch/x86/pci/intel_mid_pci.c > pending in the tip:x86/platform tree: > > e99a0745bdf8 x86/pci, x86/platform/intel_mid_pci: Remove duplicate power off > code > 5823d0893ec2

[PATCH V2 3/3] perf/core: Enabling mapping of the stop filters

At this time function perf_addr_filter_needs_mmap() will _not_ return true on a user space 'stop' filter. But stop filters needs exactly the same kind of mapping that range and start filters get. Signed-off-by: Mathieu Poirier --- kernel/events/core.c | 15 +-- 1 file changed, 5

[PATCH 1/2] led: is31fl32xx: fix typo in id and match table names

Signed-off-by: H. Nikolaus Schaller --- drivers/leds/leds-is31fl32xx.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/leds/leds-is31fl32xx.c b/drivers/leds/leds-is31fl32xx.c index c901d13..a53b71e 100644 --- a/drivers/leds/leds-is31fl32xx.c +++

Re: [RFC PATCH 00/30] Kernel NET policy

On Mon, Jul 18, 2016 at 5:51 PM, Liang, Kan wrote: > > >> > >> > It is a big challenge to get good network performance. First, the >> > network performance is not good with default system settings. Second, >> > it is too difficult to do automatic tuning for all possible

Re: [RFC PATCH 00/30] Kernel NET policy

On Mon, Jul 18, 2016 at 5:51 PM, Liang, Kan wrote: > > >> > >> > It is a big challenge to get good network performance. First, the >> > network performance is not good with default system settings. Second, >> > it is too difficult to do automatic tuning for all possible workloads, >> > since

Re: [PATCH v3 1/2] dt-bindings: Update iProc GPIO bindings

Hi Rob, On 7/16/2016 2:20 PM, Rob Herring wrote: On Tue, Jul 12, 2016 at 10:39:17AM -0700, Ray Jui wrote: Update the iProc GPIO binding document to add new compatible strings "brcm,iproc-gpio-nsp" and "brcm,iproc-gpio-stingray" to support the iProc based GPIO controller used in the NSP and

Re: [PATCH v3 1/2] dt-bindings: Update iProc GPIO bindings

Hi Rob, On 7/16/2016 2:20 PM, Rob Herring wrote: On Tue, Jul 12, 2016 at 10:39:17AM -0700, Ray Jui wrote: Update the iProc GPIO binding document to add new compatible strings "brcm,iproc-gpio-nsp" and "brcm,iproc-gpio-stingray" to support the iProc based GPIO controller used in the NSP and

Re: [PATCH v8 2/4] i2c-smbus: add SMBus Host Notify support

On Jul 18 2016 or thereabouts, Jean Delvare wrote: > Hi Benjamin, Wolfram, > > Now that I have reviewed the i2c-i801 part of the implementation, I'm > wondering... > > On Thu, 9 Jun 2016 16:53:48 +0200, Benjamin Tissoires wrote: > > +/** > > + * i2c_setup_smbus_host_notify - Allocate a new

Re: [PATCH v8 2/4] i2c-smbus: add SMBus Host Notify support

On Jul 18 2016 or thereabouts, Jean Delvare wrote: > Hi Benjamin, Wolfram, > > Now that I have reviewed the i2c-i801 part of the implementation, I'm > wondering... > > On Thu, 9 Jun 2016 16:53:48 +0200, Benjamin Tissoires wrote: > > +/** > > + * i2c_setup_smbus_host_notify - Allocate a new

Re: [PATCH v2] virtio_blk: Fix a slient kernel panic

On Tue, 19 Jul 2016 00:18:32 +0800 Minfei Huang wrote: > On 07/18/16 at 05:21P, Cornelia Huck wrote: > > On Mon, 18 Jul 2016 22:01:29 +0800 > > Minfei Huang wrote: > > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > > index

Re: [PATCH v2] virtio_blk: Fix a slient kernel panic

On Tue, 19 Jul 2016 00:18:32 +0800 Minfei Huang wrote: > On 07/18/16 at 05:21P, Cornelia Huck wrote: > > On Mon, 18 Jul 2016 22:01:29 +0800 > > Minfei Huang wrote: > > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > > index 42758b5..d920512 100644 > > > ---

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [Xen-devel] [linux-4.1 bisection] complet

On Mon, Jul 18, 2016 at 03:48:03PM +, Odzioba, Lukasz wrote: > On Monday, July 18, 2016 5:31 PM, Konrad Rzeszutek Wilk wrote: > > We found that your patch in the automated Xen test-case ends up > > OOMing the box when trying to install guests. This worked prior > > to your patch. > > > > See

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [Xen-devel] [linux-4.1 bisection] complet

On Mon, Jul 18, 2016 at 03:48:03PM +, Odzioba, Lukasz wrote: > On Monday, July 18, 2016 5:31 PM, Konrad Rzeszutek Wilk wrote: > > We found that your patch in the automated Xen test-case ends up > > OOMing the box when trying to install guests. This worked prior > > to your patch. > > > > See

[PATCH v1 2/3] cgroup: allow for unprivileged subtree management

Use the new custom ->permission hook to allow unprivileged processes to mkdir new sub-cgroup directories of the root_cset of their current cgroup namespace. No process outside of the cgroup namespace (or in a sub-namespace) has this ability, and thus a process must have sufficient privileges to

Re: [PATCH v3] arm64: dts: rockchip: Add basic support for orion-r68

On 07/18/2016 03:13 AM, Shawn Lin wrote: 在 2016/7/15 18:09, Matthias Brugger 写道: This patch adds basic support for the Tronsmart orion r86 set-top-box. Signed-off-by: Matthias Brugger --- Changes since v2: - gpio-keys cleanpup - set sdmmc properties correctly It seems

[PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

If we're moving from a parent to a direct descendant, the only end result (on cgroupv2 hierarchies) is that the process experiences more restrictive resource limits. Thus, there's no reason to restrict processes from moving to direct descendants based on whether or not they have cgroup.procs write

Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

On 07/18/2016 01:44 AM, Joseph Lo wrote: Hi Rob, Thanks for your reviewing. On 07/12/2016 12:05 AM, Stephen Warren wrote: On 07/11/2016 08:22 AM, Rob Herring wrote: On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote: The BPMP is a specific processor in Tegra chip, which is designed

Re: [PATCH 3/3] perf tests: Add is_printable_array test

Sat, Jul 16, 2016 at 06:11:20PM CEST, jo...@kernel.org wrote: >Add automated test for is_printable_array function. > >Link: http://lkml.kernel.org/n/tip-if70lj3zhdc3csdqm5web...@git.kernel.org >Signed-off-by: Jiri Olsa >--- > tools/perf/tests/Build| 1 + >

Re: [PATCH 3/5] mm, pagevec: Release/reacquire lru_lock on pgdat change

On Fri, Jul 15, 2016 at 02:09:23PM +0100, Mel Gorman wrote: > With node-lru, the locking is based on the pgdat. Previously it was > required that a pagevec drain released one zone lru_lock and acquired > another zone lru_lock on every zone change. Now, it's only necessary if > the node changes.

Re: [PATCH v3] arm64: dts: rockchip: Add basic support for orion-r68

On 07/18/2016 03:13 AM, Shawn Lin wrote: 在 2016/7/15 18:09, Matthias Brugger 写道: This patch adds basic support for the Tronsmart orion r86 set-top-box. Signed-off-by: Matthias Brugger --- Changes since v2: - gpio-keys cleanpup - set sdmmc properties correctly It seems there are two

[PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

If we're moving from a parent to a direct descendant, the only end result (on cgroupv2 hierarchies) is that the process experiences more restrictive resource limits. Thus, there's no reason to restrict processes from moving to direct descendants based on whether or not they have cgroup.procs write

Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

On 07/18/2016 01:44 AM, Joseph Lo wrote: Hi Rob, Thanks for your reviewing. On 07/12/2016 12:05 AM, Stephen Warren wrote: On 07/11/2016 08:22 AM, Rob Herring wrote: On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote: The BPMP is a specific processor in Tegra chip, which is designed

Re: [PATCH 3/3] perf tests: Add is_printable_array test

Sat, Jul 16, 2016 at 06:11:20PM CEST, jo...@kernel.org wrote: >Add automated test for is_printable_array function. > >Link: http://lkml.kernel.org/n/tip-if70lj3zhdc3csdqm5web...@git.kernel.org >Signed-off-by: Jiri Olsa >--- > tools/perf/tests/Build| 1 + >

Re: [PATCH 3/5] mm, pagevec: Release/reacquire lru_lock on pgdat change

On Fri, Jul 15, 2016 at 02:09:23PM +0100, Mel Gorman wrote: > With node-lru, the locking is based on the pgdat. Previously it was > required that a pagevec drain released one zone lru_lock and acquired > another zone lru_lock on every zone change. Now, it's only necessary if > the node changes.

[PATCH v1 2/3] cgroup: allow for unprivileged subtree management

Use the new custom ->permission hook to allow unprivileged processes to mkdir new sub-cgroup directories of the root_cset of their current cgroup namespace. No process outside of the cgroup namespace (or in a sub-namespace) has this ability, and thus a process must have sufficient privileges to

Re: [RFC PATCH 23/30] i40e/ethtool: support RX_CLS_LOC_ANY

On Sun, Jul 17, 2016 at 11:56 PM, wrote: > From: Kan Liang > > The existing special location RX_CLS_LOC_ANY flag is designed for the > case which the caller does not know/care about the location. Now, this > flag is only handled in ethtool user space.

Re: [RFC PATCH 23/30] i40e/ethtool: support RX_CLS_LOC_ANY

On Sun, Jul 17, 2016 at 11:56 PM, wrote: > From: Kan Liang > > The existing special location RX_CLS_LOC_ANY flag is designed for the > case which the caller does not know/care about the location. Now, this > flag is only handled in ethtool user space. If the kernel directly calls > the

Re: [RFC PATCH 00/30] Kernel NET policy

Hi Kan, On 07/18/2016 08:55 AM, kan.li...@intel.com wrote: From: Kan Liang It is a big challenge to get good network performance. First, the network performance is not good with default system settings. Second, it is too difficult to do automatic tuning for all possible

[PATCH v1 0/3] cgroup: allow for unprivileged management

This is a rewrite of my old cgroup unprivileged subtree management[1] patchset. Rather than magically creating a new cgroup, I've instead modified kernfs so that we can have custom permission hooks. The following only applies to cgroupv2 trees, due to the fact that cgroupv1 doesn't explicitly

Re: [RFC PATCH 00/30] Kernel NET policy

Hi Kan, On 07/18/2016 08:55 AM, kan.li...@intel.com wrote: From: Kan Liang It is a big challenge to get good network performance. First, the network performance is not good with default system settings. Second, it is too difficult to do automatic tuning for all possible workloads, since

[PATCH v1 0/3] cgroup: allow for unprivileged management

This is a rewrite of my old cgroup unprivileged subtree management[1] patchset. Rather than magically creating a new cgroup, I've instead modified kernfs so that we can have custom permission hooks. The following only applies to cgroupv2 trees, due to the fact that cgroupv1 doesn't explicitly

[PATCH v1 1/3] kernfs: add support for custom per-sb permission hooks

This allows for users of kernfs to create custom (and possibly less restrictive) permission checks for kernfs_nodes. The default is unchanged. This patch is part of the cgroupns unprivileged subtree management patchset. Cc: d...@opencontainers.org Signed-off-by: Aleksa Sarai ---

Re: [PATCH v2] virtio_blk: Fix a slient kernel panic

On 07/18/16 at 05:21P, Cornelia Huck wrote: > On Mon, 18 Jul 2016 22:01:29 +0800 > Minfei Huang wrote: > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > index 42758b5..d920512 100644 > > --- a/drivers/block/virtio_blk.c > > +++

[PATCH v1 1/3] kernfs: add support for custom per-sb permission hooks

This allows for users of kernfs to create custom (and possibly less restrictive) permission checks for kernfs_nodes. The default is unchanged. This patch is part of the cgroupns unprivileged subtree management patchset. Cc: d...@opencontainers.org Signed-off-by: Aleksa Sarai ---

Re: [PATCH v2] virtio_blk: Fix a slient kernel panic

On 07/18/16 at 05:21P, Cornelia Huck wrote: > On Mon, 18 Jul 2016 22:01:29 +0800 > Minfei Huang wrote: > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > index 42758b5..d920512 100644 > > --- a/drivers/block/virtio_blk.c > > +++ b/drivers/block/virtio_blk.c > > @@ -381,9

[RFC] locking/mutex: Fix starvation of sleeping waiters

Currently a thread sleeping on a mutex wait queue can be delayed indefinitely by other threads managing to steal the lock, that is acquiring the lock out-of-order before the sleepers. I noticed this via a testcase (see the Reference: below) where one CPU was unlocking / relocking a mutex in a

Re: [RFC PATCH 00/30] Kernel NET policy

Liang, Kan wrote: > > What is missing in the kernel UAPI so userspace could do these settings on > > its > > own, without adding this policy stuff to the kernel? > > The main purpose of the proposal is to simplify the configuration. Too many > options will let them confuse.

Re: [PATCH 2/5] mm, vmscan: avoid passing in classzone_idx unnecessarily to compaction_ready -fix

On Fri, Jul 15, 2016 at 02:09:22PM +0100, Mel Gorman wrote: > As pointed out by Vlastimil, there is a redundant check in shrink_zones > since commit "mm, vmscan: avoid passing in classzone_idx unnecessarily to > compaction_ready". The zonelist iterator only returns zones that already > meet the

Re: [PATCH 1/5] mm, vmscan: make shrink_node decisions more node-centric -fix

On Fri, Jul 15, 2016 at 02:09:21PM +0100, Mel Gorman wrote: > The patch "mm, vmscan: make shrink_node decisions more node-centric" > checks whether compaction is suitable on empty nodes. This is expensive > rather than wrong but is worth fixing. > > This is a fix to the mmotm patch >

[RFC] locking/mutex: Fix starvation of sleeping waiters

Currently a thread sleeping on a mutex wait queue can be delayed indefinitely by other threads managing to steal the lock, that is acquiring the lock out-of-order before the sleepers. I noticed this via a testcase (see the Reference: below) where one CPU was unlocking / relocking a mutex in a

Re: [RFC PATCH 00/30] Kernel NET policy

Liang, Kan wrote: > > What is missing in the kernel UAPI so userspace could do these settings on > > its > > own, without adding this policy stuff to the kernel? > > The main purpose of the proposal is to simplify the configuration. Too many > options will let them confuse. > For normal users,

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