Re: [PATCH] radix-tree: fix radix_tree_iter_retry() for tagged iterators.

On Fri, Jul 15, 2016 at 01:57:33PM -0700, Andrew Morton wrote: > On Fri, 15 Jul 2016 13:00:40 -0600 Ross Zwisler > wrote: > > > > > ... > > > > In looking at this more, I agree that your patch fixes this particular bug, > > but I think that ultimately we might want something more general. > >

[PATCH V10 2/9] vfio: platform: move reset call to a common function

The reset call sequence seems to replicate itself multiple times across the file. Grouping them together for maintenance reasons. Signed-off-by: Sinan Kaya Reviewed-by: Eric Auger Reviewed-by: Baptiste Reynal --- drivers/vfio/platform/vfio_platform_common.c | 30 +---

Re: [PATCH V2 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

On 07/11/2016 10:08 AM, Stephen Warren wrote: On 07/11/2016 08:14 AM, Rob Herring wrote: On Thu, Jul 07, 2016 at 12:35:02PM -0600, Stephen Warren wrote: On 07/07/2016 12:13 PM, Sivaram Nair wrote: On Tue, Jul 05, 2016 at 05:04:22PM +0800, Joseph Lo wrote: Add DT binding for the Hardware

[PATCH V10 1/9] vfio: platform: rename reset function

Renaming the reset function to of_reset as it is only used by the device tree based platforms. Signed-off-by: Sinan Kaya Reviewed-by: Eric Auger Reviewed-by: Baptiste Reynal --- drivers/vfio/platform/vfio_platform_common.c | 30 +--

[PATCH V10 7/9] vfio, platform: make reset driver a requirement by default

The code was allowing platform devices to be used without a supporting VFIO reset driver. The hardware can be left in some inconsistent state after a guest machine abort. The reset driver will put the hardware back to safe state and disable interrupts before returning the control back to the host

[PATCH V10 3/9] vfio: platform: determine reset capability

Creating a new function to determine if this driver supports reset function or not. This is an attempt to abstract device tree calls from the rest of the code. Signed-off-by: Sinan Kaya Reviewed-by: Eric Auger Reviewed-by: Baptiste Reynal --- drivers/vfio/platform/vfio_platform_common.c | 7

[PATCH V10 8/9] vfio: platform: check reset call return code during open

Open call is ignoring the return code from reset call and can potentially continue even though reset call failed. If reset_required module parameter is set, this patch is going to validate the return code and will abort open if reset fails. Signed-off-by: Sinan Kaya

Re: [PATCH v3 1/8] Input: synaptics-rmi4: Use of_get_child_by_name() instead of of_find_node_by_name()

On 07/18/2016 07:48 AM, Benjamin Tissoires wrote: On Jul 13 2016 or thereabouts, Andrew Duggan wrote: Calling of_find_node_by_name() assumes that the caller has incremented the refcount of the of_node being passed in. Currently, the caller is not incrementing the refcount of the of_node which

[PATCH V10 8/9] vfio: platform: check reset call return code during open

Open call is ignoring the return code from reset call and can potentially continue even though reset call failed. If reset_required module parameter is set, this patch is going to validate the return code and will abort open if reset fails. Signed-off-by: Sinan Kaya Reviewed-by: Baptiste Reynal

Re: [PATCH v3 1/8] Input: synaptics-rmi4: Use of_get_child_by_name() instead of of_find_node_by_name()

On 07/18/2016 07:48 AM, Benjamin Tissoires wrote: On Jul 13 2016 or thereabouts, Andrew Duggan wrote: Calling of_find_node_by_name() assumes that the caller has incremented the refcount of the of_node being passed in. Currently, the caller is not incrementing the refcount of the of_node which

[PATCH V10 5/9] vfio: platform: add extra debug info argument to call reset

Getting ready to bring out extra debug information to the caller so that more verbose information can be printed when an error is observed. Signed-off-by: Sinan Kaya Reviewed-by: Baptiste Reynal ---

[PATCH V10 4/9] vfio: platform: add support for ACPI probe

The code is using the compatible DT string to associate a reset driver with the actual device itself. The compatible string does not exist on ACPI based systems. HID is the unique identifier for a device driver instead. Signed-off-by: Sinan Kaya ---

[PATCH V10 5/9] vfio: platform: add extra debug info argument to call reset

Getting ready to bring out extra debug information to the caller so that more verbose information can be printed when an error is observed. Signed-off-by: Sinan Kaya Reviewed-by: Baptiste Reynal --- drivers/vfio/platform/vfio_platform_common.c | 9 + 1 file changed, 5 insertions(+), 4

[PATCH V10 4/9] vfio: platform: add support for ACPI probe

The code is using the compatible DT string to associate a reset driver with the actual device itself. The compatible string does not exist on ACPI based systems. HID is the unique identifier for a device driver instead. Signed-off-by: Sinan Kaya --- drivers/vfio/platform/vfio_platform_common.c

[PATCH V10 6/9] vfio: platform: call _RST method when using ACPI

The device tree code checks for the presence of a reset driver and calls the of_reset function pointer by looking up the reset driver as a module. ACPI defines _RST method to perform device level reset. After the _RST method is executed, the OS can resume using the device. _RST method is expected

Ongoing remoteproc discussions

During discussions with various people interested in moving their remoteproc-related out-of-tree patches towards mainline I have come across a set of topics common among various teams. The purpose of this email is to share some insight into these discussions and the current ideas for moving

[PATCH V10 6/9] vfio: platform: call _RST method when using ACPI

The device tree code checks for the presence of a reset driver and calls the of_reset function pointer by looking up the reset driver as a module. ACPI defines _RST method to perform device level reset. After the _RST method is executed, the OS can resume using the device. _RST method is expected

Ongoing remoteproc discussions

During discussions with various people interested in moving their remoteproc-related out-of-tree patches towards mainline I have come across a set of topics common among various teams. The purpose of this email is to share some insight into these discussions and the current ideas for moving

Re: [PATCH resend] virtio-net: Remove more stack DMA

On Mon, Jul 18, 2016 at 03:34:49PM -0700, Andy Lutomirski wrote: > VLAN and MQ control was doing DMA from the stack. Fix it. > > Cc: Michael S. Tsirkin > Cc: "net...@vger.kernel.org" > Signed-off-by: Andy Lutomirski Acked-by: Michael

Re: [PATCH resend] virtio-net: Remove more stack DMA

On Mon, Jul 18, 2016 at 03:34:49PM -0700, Andy Lutomirski wrote: > VLAN and MQ control was doing DMA from the stack. Fix it. > > Cc: Michael S. Tsirkin > Cc: "net...@vger.kernel.org" > Signed-off-by: Andy Lutomirski Acked-by: Michael S. Tsirkin > --- > > I tested VLAN addition and

Re: [PATCH v3 2/3] spi: of: allow instantiating slaves without a driver

On Tue, Jul 19, 2016 at 12:35:41AM +0200, Michal Suchanek wrote: > SPI slave devices are not created when looking up driver for the slave > fails. Create a device anyway so it can be used with spidev. > rc = of_modalias_node(nc, spi->modalias, >

Re: [PATCH v3 2/3] spi: of: allow instantiating slaves without a driver

On Tue, Jul 19, 2016 at 12:35:41AM +0200, Michal Suchanek wrote: > SPI slave devices are not created when looking up driver for the slave > fails. Create a device anyway so it can be used with spidev. > rc = of_modalias_node(nc, spi->modalias, >

Re: [PATCH v3 1/3] spi: spidev: create spidev device for all spi slaves.

On Tue, Jul 19, 2016 at 12:35:40AM +0200, Michal Suchanek wrote: > config SPI_SPIDEV > - tristate "User mode SPI device driver support" > + bool "User mode SPI device driver support" This is a step back, it would require spidev to be built in. > - spin_lock_irq(>spi_lock); > -

Re: [PATCH v3 1/3] spi: spidev: create spidev device for all spi slaves.

On Tue, Jul 19, 2016 at 12:35:40AM +0200, Michal Suchanek wrote: > config SPI_SPIDEV > - tristate "User mode SPI device driver support" > + bool "User mode SPI device driver support" This is a step back, it would require spidev to be built in. > - spin_lock_irq(>spi_lock); > -

Re: [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level

On Fri, Jul 15, 2016 at 05:15:41PM +, Topi Miettinen wrote: > There are clear semantics for the limits themselves, either they apply > per task or per user. It makes sense to gather values according to these > semantics. Then with systemd or other tools you can use the valuse to > set the

Re: [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level

On Fri, Jul 15, 2016 at 05:15:41PM +, Topi Miettinen wrote: > There are clear semantics for the limits themselves, either they apply > per task or per user. It makes sense to gather values according to these > semantics. Then with systemd or other tools you can use the valuse to > set the

Re: [PATCH 1/2] locking/percpu-rwsem: Optimize readers and reduce global impact

Hi, [auto build test ERROR on v4.7-rc7] [also build test ERROR on next-20160718] [cannot apply to tip/core/locking] [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/Peter-Zijlstra/locking-percpu

Re: [PATCH 1/2] locking/percpu-rwsem: Optimize readers and reduce global impact

Hi, [auto build test ERROR on v4.7-rc7] [also build test ERROR on next-20160718] [cannot apply to tip/core/locking] [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/Peter-Zijlstra/locking-percpu

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

Em Mon, Jul 18, 2016 at 02:14:09PM +0200, Jiri Olsa escreveu: > On Mon, Jul 18, 2016 at 01:46:02PM +0200, Jiri Pirko wrote: > > SNIP > > > >diff --git a/tools/perf/tests/is_printable_array.c > > >b/tools/perf/tests/is_printable_array.c > > >new file mode 100644 > > >index

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

Em Mon, Jul 18, 2016 at 02:14:09PM +0200, Jiri Olsa escreveu: > On Mon, Jul 18, 2016 at 01:46:02PM +0200, Jiri Pirko wrote: > > SNIP > > > >diff --git a/tools/perf/tests/is_printable_array.c > > >b/tools/perf/tests/is_printable_array.c > > >new file mode 100644 > > >index

Re: [RFCv2 3/4] perf: util: only open events on CPUs an evsel permits

Em Mon, Jul 18, 2016 at 04:32:59PM +0200, Jiri Olsa escreveu: > On Fri, Jul 15, 2016 at 11:08:12AM +0100, Mark Rutland wrote: > > In systems with heterogeneous CPU PMUs, it's possible for each evsel to > > cover a distinct set of CPUs, and hence the cpu_map associated with each > > evsel may have

Re: [RFCv2 3/4] perf: util: only open events on CPUs an evsel permits

Em Mon, Jul 18, 2016 at 04:32:59PM +0200, Jiri Olsa escreveu: > On Fri, Jul 15, 2016 at 11:08:12AM +0100, Mark Rutland wrote: > > In systems with heterogeneous CPU PMUs, it's possible for each evsel to > > cover a distinct set of CPUs, and hence the cpu_map associated with each > > evsel may have

Re: [PATCH 2/2] iio: stx104: Move the STX104 IIO driver to the ADC directory

On Mon, 18 Jul 2016, William Breathitt Gray wrote: > The Apex Embedded Systems STX104 is primarily an analog-to-digital > converter device. The STX104 IIO driver was initially placed in the DAC > directory because only the DAC portion of the STX104 was supported at > the time. Now that ADC

Re: [PATCH 2/2] iio: stx104: Move the STX104 IIO driver to the ADC directory

On Mon, 18 Jul 2016, William Breathitt Gray wrote: > The Apex Embedded Systems STX104 is primarily an analog-to-digital > converter device. The STX104 IIO driver was initially placed in the DAC > directory because only the DAC portion of the STX104 was supported at > the time. Now that ADC

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

On Mon, 2016-07-18 at 11:04 +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 <

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

On Mon, 2016-07-18 at 11:04 +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 - 1)) > > > > When

[PATCH v3 0/3] Spidev usability patchset update

Hello, this simplifies spidev to not pose as SPI driver but instead attach a character device on each SPI slave indiscriminately. This does not require spidev to be matched during driver binding and hence does not require it to be specified in devicetree. Any SPI slave device for which a driver

[PATCH v3 2/3] spi: of: allow instantiating slaves without a driver

SPI slave devices are not created when looking up driver for the slave fails. Create a device anyway so it can be used with spidev. Signed-off-by: Michal Suchanek --- drivers/spi/spi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/spi/spi.c

[PATCH v3 0/3] Spidev usability patchset update

Hello, this simplifies spidev to not pose as SPI driver but instead attach a character device on each SPI slave indiscriminately. This does not require spidev to be matched during driver binding and hence does not require it to be specified in devicetree. Any SPI slave device for which a driver

[PATCH v3 2/3] spi: of: allow instantiating slaves without a driver

SPI slave devices are not created when looking up driver for the slave fails. Create a device anyway so it can be used with spidev. Signed-off-by: Michal Suchanek --- drivers/spi/spi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c

[PATCH v3 3/3] spi: core: allow creating devices without spi-max-frequency

Since the previous patch allows creating SPI slaves without specifying what device the CS connects to make spi-max-frequency also optional. The spi-max-frequency is device-specific and the driver can set it anyway. Signed-off-by: Michal Suchanek --- drivers/spi/spi.c | 6

[PATCH v3 1/3] spi: spidev: create spidev device for all spi slaves.

This patch makes spidev into a bus addon rather than a separate driver. spidev character device is created for each spi slave. When a spi slave driver is bound the spidev IOCTLs return -EBUSY. This is similar to i2c bus which alows access to any address not claimed by a kernel driver and should

[PATCH v3 3/3] spi: core: allow creating devices without spi-max-frequency

Since the previous patch allows creating SPI slaves without specifying what device the CS connects to make spi-max-frequency also optional. The spi-max-frequency is device-specific and the driver can set it anyway. Signed-off-by: Michal Suchanek --- drivers/spi/spi.c | 6 +++--- 1 file

[PATCH v3 1/3] spi: spidev: create spidev device for all spi slaves.

This patch makes spidev into a bus addon rather than a separate driver. spidev character device is created for each spi slave. When a spi slave driver is bound the spidev IOCTLs return -EBUSY. This is similar to i2c bus which alows access to any address not claimed by a kernel driver and should

[PATCH resend] virtio-net: Remove more stack DMA

VLAN and MQ control was doing DMA from the stack. Fix it. Cc: Michael S. Tsirkin Cc: "net...@vger.kernel.org" Signed-off-by: Andy Lutomirski --- I tested VLAN addition and removal with CONFIG_VMAP_STACK=y, CONFIG_DEBUG_SG=y and it got

[PATCH resend] virtio-net: Remove more stack DMA

VLAN and MQ control was doing DMA from the stack. Fix it. Cc: Michael S. Tsirkin Cc: "net...@vger.kernel.org" Signed-off-by: Andy Lutomirski --- I tested VLAN addition and removal with CONFIG_VMAP_STACK=y, CONFIG_DEBUG_SG=y and it got rid of the warnings I saw. I haven't tested the MQ part

Re: BUG: INTx is assered unexpectly when unload AHCI driver with MSIx support.

Hello, Pang. On Fri, Jul 15, 2016 at 12:39:59PM +, Pang Raymond wrote: > Hi Tejun, > > > Yes! It only happens when the device is shutdown. > > I think you're right. It's more wiser to add clearing operation to driver > > clean up path. > > So we can add it to ahci_port_stop() > > >

Re: BUG: INTx is assered unexpectly when unload AHCI driver with MSIx support.

Hello, Pang. On Fri, Jul 15, 2016 at 12:39:59PM +, Pang Raymond wrote: > Hi Tejun, > > > Yes! It only happens when the device is shutdown. > > I think you're right. It's more wiser to add clearing operation to driver > > clean up path. > > So we can add it to ahci_port_stop() > > >

Re: [PATCH] um: Stop conflating task_struct::stack with thread_info

On Mon, Jul 18, 2016 at 3:22 PM, Andy Lutomirski wrote: > From: Linus Torvalds > > thread_info may move in the future, so use the accessors. > > [Andy Lutomirski wrote this changelog message and changed > "task_thread_info(child)->cpu" to

Re: [PATCH] um: Stop conflating task_struct::stack with thread_info

On Mon, Jul 18, 2016 at 3:22 PM, Andy Lutomirski wrote: > From: Linus Torvalds > > thread_info may move in the future, so use the accessors. > > [Andy Lutomirski wrote this changelog message and changed > "task_thread_info(child)->cpu" to "task_cpu(child)".] > > Message-Id: > > Signed-off-by:

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Hi Arnaldo, On Mon, 18 Jul 2016 17:36:34 -0300 Arnaldo Carvalho de Melo wrote: > > Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu: > > On Sun, Jul 17, 2016 at 10:18 PM, Stephen Rothwell > > wrote: > > > On Fri, 15 Jul 2016 12:43:26

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Hi Arnaldo, On Mon, 18 Jul 2016 17:36:34 -0300 Arnaldo Carvalho de Melo wrote: > > Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu: > > On Sun, Jul 17, 2016 at 10:18 PM, Stephen Rothwell > > wrote: > > > On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo > > >

[PATCH] um: Stop conflating task_struct::stack with thread_info

From: Linus Torvalds thread_info may move in the future, so use the accessors. [Andy Lutomirski wrote this changelog message and changed "task_thread_info(child)->cpu" to "task_cpu(child)".] Message-Id:

[PATCH] um: Stop conflating task_struct::stack with thread_info

From: Linus Torvalds thread_info may move in the future, so use the accessors. [Andy Lutomirski wrote this changelog message and changed "task_thread_info(child)->cpu" to "task_cpu(child)".] Message-Id: Signed-off-by: Andy Lutomirski --- arch/x86/um/ptrace_32.c | 8 1 file

Re: [PATCH 1/1] iio: vcnl4000: Add IR current adjust support

> Signed-off-by: Pratik Prajapati comments below; nice addition it seems this patch clashes with the recent changes to this driver in iio-testing; can you rebase on top please? I suggest to split out the transition to regmap in a separate patch > --- >

Re: [PATCH 1/1] iio: vcnl4000: Add IR current adjust support

> Signed-off-by: Pratik Prajapati comments below; nice addition it seems this patch clashes with the recent changes to this driver in iio-testing; can you rebase on top please? I suggest to split out the transition to regmap in a separate patch > --- > drivers/iio/light/vcnl4000.c | 119 >

Re: [PATCH v5 4/8] char: rpmb: provide a user space interface

On Mon, Jul 18, 2016 at 4:27 PM, Tomas Winkler wrote: > The user space API is achieved via two synchronous IOCTL. > Simplified one, RPMB_IOC_REQ_CMD, were read result cycles is performed > by the framework on behalf the user and second, RPMB_IOC_SEQ_CMD where > the whole

Re: [PATCH v5 4/8] char: rpmb: provide a user space interface

On Mon, Jul 18, 2016 at 4:27 PM, Tomas Winkler wrote: > The user space API is achieved via two synchronous IOCTL. > Simplified one, RPMB_IOC_REQ_CMD, were read result cycles is performed > by the framework on behalf the user and second, RPMB_IOC_SEQ_CMD where > the whole RPMB sequence including

[PATCH v2] pwm: Create device class for pwm channels

Pwm channels don't send uevents when exported, this change adds the channels to a pwm class and set their device type to pwm_channel so uevents are sent. To do this properly, the device names need to change to uniquely identify a channel. This change is from pwmN to pwmchipM:N Signed-off-by:

[PATCH v2] pwm: Create device class for pwm channels

Pwm channels don't send uevents when exported, this change adds the channels to a pwm class and set their device type to pwm_channel so uevents are sent. To do this properly, the device names need to change to uniquely identify a channel. This change is from pwmN to pwmchipM:N Signed-off-by:

Re: [patch] crypto: sha256-mb - cleanup a || vs | typo

On Mon, 2016-07-18 at 10:59 +0200, Pavel Machek wrote: > On Fri 2016-07-08 10:19:26, Linus Torvalds wrote: > > > > [ rare comment rant. I think I'll do this once, and then ignore the > > discussion ] > > > > On Fri, Jul 8, 2016 at 9:45 AM, Herbert Xu > > wrote: >

Re: [patch] crypto: sha256-mb - cleanup a || vs | typo

On Mon, 2016-07-18 at 10:59 +0200, Pavel Machek wrote: > On Fri 2016-07-08 10:19:26, Linus Torvalds wrote: > > > > [ rare comment rant. I think I'll do this once, and then ignore the > > discussion ] > > > > On Fri, Jul 8, 2016 at 9:45 AM, Herbert Xu > > wrote: > > > > > > > > > Nack.  As I

Re: [PATCH v13 00/12] support "task_isolation" mode

On Thu, Jul 14, 2016 at 2:22 PM, Chris Metcalf wrote: > On 7/14/2016 5:03 PM, Andy Lutomirski wrote: >> >> On Thu, Jul 14, 2016 at 1:48 PM, Chris Metcalf >> wrote: >>> >>> Here is a respin of the task-isolation patch set. This primarily >>> reflects

Re: [PATCH v13 00/12] support "task_isolation" mode

On Thu, Jul 14, 2016 at 2:22 PM, Chris Metcalf wrote: > On 7/14/2016 5:03 PM, Andy Lutomirski wrote: >> >> On Thu, Jul 14, 2016 at 1:48 PM, Chris Metcalf >> wrote: >>> >>> Here is a respin of the task-isolation patch set. This primarily >>> reflects feedback from Frederic and Peter Z. >> >> I

Re: [PATCH 2/2] net: ethernet: marvell: pxa168_eth: use phy_ethtool_{get|set}_link_ksettings

On 07/17/2016 02:30 PM, Philippe Reynes wrote: > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes > --- > - cmd.phy_address = pep->phy_addr; > -

Re: [PATCH 2/2] net: ethernet: marvell: pxa168_eth: use phy_ethtool_{get|set}_link_ksettings

On 07/17/2016 02:30 PM, Philippe Reynes wrote: > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes > --- > - cmd.phy_address = pep->phy_addr; > - cmd.speed =

[PATCH] of: fdt: mark unflattened tree as detached

The tree returned from of_fdt_unflatten_tree cannot be attached to the live tree because it is not marked as detached so mark it as such. The dt resolver checks the flag and refuses to process the tree otherwise. Signed-off-by: Michal Suchanek --- - rebase on top of 4.7rc

[PATCH] of: fdt: mark unflattened tree as detached

The tree returned from of_fdt_unflatten_tree cannot be attached to the live tree because it is not marked as detached so mark it as such. The dt resolver checks the flag and refuses to process the tree otherwise. Signed-off-by: Michal Suchanek --- - rebase on top of 4.7rc --- drivers/of/fdt.c

Re: [PATCH 1/2] net: ethernet: marvell: pxa168_eth: use phydev from struct net_device

Hi, On 18/07/16 12:14, Sergei Shtylyov wrote: Hello. On 7/18/2016 12:30 AM, Philippe Reynes wrote: The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver

Re: [PATCH 1/2] net: ethernet: marvell: pxa168_eth: use phydev from struct net_device

Hi, On 18/07/16 12:14, Sergei Shtylyov wrote: Hello. On 7/18/2016 12:30 AM, Philippe Reynes wrote: The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver

Re: [PATCH] timekeeping: Fix memory overwrite of sleep_time_bin array

On Monday, July 18, 2016 09:42:19 AM Chen Yu wrote: > It is reported the hibernation fails at 2nd attempt, which > hangs at hibernate() -> syscore_resume() -> i8237A_resume() > -> claim_dma_lock(), because the lock has already been taken. > However there is actually no other process would like to

Re: [PATCH] timekeeping: Fix memory overwrite of sleep_time_bin array

On Monday, July 18, 2016 09:42:19 AM Chen Yu wrote: > It is reported the hibernation fails at 2nd attempt, which > hangs at hibernate() -> syscore_resume() -> i8237A_resume() > -> claim_dma_lock(), because the lock has already been taken. > However there is actually no other process would like to

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

Hello, On Mon, Jul 18, 2016, at 21:43, Andi Kleen wrote: > > I wonder if this can be attacked from a different angle. What would be > > missing to add support for this in user space? The first possibility > > that came to my mind is to just multiplex those hints in the kernel. > > "just" is the

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

Hello, On Mon, Jul 18, 2016, at 21:43, Andi Kleen wrote: > > I wonder if this can be attacked from a different angle. What would be > > missing to add support for this in user space? The first possibility > > that came to my mind is to just multiplex those hints in the kernel. > > "just" is the

Re: [PATCH 1/2] of: overlay: add resolver error prints

On Sun, Jun 26, 2016 at 3:11 PM, Michal Suchanek wrote: > Applying overlay fails silently in case of an error. Add error prints. > Most notably the lack of symbols in the live tree is not reported. > > Signed-off-by: Michal Suchanek > --- >

Re: [PATCH 1/2] of: overlay: add resolver error prints

On Sun, Jun 26, 2016 at 3:11 PM, Michal Suchanek wrote: > Applying overlay fails silently in case of an error. Add error prints. > Most notably the lack of symbols in the live tree is not reported. > > Signed-off-by: Michal Suchanek > --- > drivers/of/resolver.c | 6 ++ > 1 file changed, 6

[PATCH] x86/vdso: Error out if the vDSO isn't a valid DSO

Some distros has been playing with toolchain changes that can affect the type of ELF objects built. Occasionally, this goes wrong and the vDSO ends up not being a DSO at all. This causes the kernel to end up broken in a surprisingly subtle way -- glibc apparently silently ignores a vDSO that

[PATCH] x86/vdso: Error out if the vDSO isn't a valid DSO

Some distros has been playing with toolchain changes that can affect the type of ELF objects built. Occasionally, this goes wrong and the vDSO ends up not being a DSO at all. This causes the kernel to end up broken in a surprisingly subtle way -- glibc apparently silently ignores a vDSO that

Re: [PATCH 2/2] of: fdt: mark unflattened tree as detached

On Sun, Jun 26, 2016 at 3:11 PM, Michal Suchanek wrote: > The tree returned from of_fdt_unflatten_tree cannot be attached to the > live tree because it is not marked as detached so mark it as such. The > dt resolver checks the flag and refuses to process the tree otherwise. >

Re: [PATCH 2/2] of: fdt: mark unflattened tree as detached

On Sun, Jun 26, 2016 at 3:11 PM, Michal Suchanek wrote: > The tree returned from of_fdt_unflatten_tree cannot be attached to the > live tree because it is not marked as detached so mark it as such. The > dt resolver checks the flag and refuses to process the tree otherwise. > > Signed-off-by:

Re: [PATCH 2/2] watchdog: ziirave_wdt: Add support to upload the firmware.

Few comments inline On 17/06/16 11:52, Enric Balletbo i Serra wrote: This patch adds and entry to the sysfs to start firmware upload process on the specified device with the requested firmware. The uploading of the firmware needs only to happen once per firmware upgrade, as the firmware is

Re: [PATCH 2/2] watchdog: ziirave_wdt: Add support to upload the firmware.

Few comments inline On 17/06/16 11:52, Enric Balletbo i Serra wrote: This patch adds and entry to the sysfs to start firmware upload process on the specified device with the requested firmware. The uploading of the firmware needs only to happen once per firmware upgrade, as the firmware is

Re: [PATCH] tools lib bpf: Use official ELF e_machine value

On Mon, Jul 18, 2016 at 06:01:08AM +, Wang Nan wrote: > New LLVM will issue newly assigned EM_BPF machine code. The new code > will be propogated to glibc and libelf. > > This patch introduces the new machine code to libbpf. > > Signed-off-by: Wang Nan > Cc: Alexei

Re: [PATCH] tools lib bpf: Use official ELF e_machine value

On Mon, Jul 18, 2016 at 06:01:08AM +, Wang Nan wrote: > New LLVM will issue newly assigned EM_BPF machine code. The new code > will be propogated to glibc and libelf. > > This patch introduces the new machine code to libbpf. > > Signed-off-by: Wang Nan > Cc: Alexei Starovoitov > Cc:

Re: [PATCH v2 2/3] hwmon: xgene: Add hwmon driver

Hi Guenter, On Sat, Jul 16, 2016 at 9:35 AM, Guenter Roeck wrote: > On 07/11/2016 05:30 PM, Hoan Tran wrote: >> >> This patch adds hardware temperature and power reading support for >> APM X-Gene SoC using the mailbox communication interface. >> >> Signed-off-by: Hoan Tran

Re: [PATCH v2 2/3] hwmon: xgene: Add hwmon driver

Hi Guenter, On Sat, Jul 16, 2016 at 9:35 AM, Guenter Roeck wrote: > On 07/11/2016 05:30 PM, Hoan Tran wrote: >> >> This patch adds hardware temperature and power reading support for >> APM X-Gene SoC using the mailbox communication interface. >> >> Signed-off-by: Hoan Tran >> --- >>

Re: [PATCH v2 net-next v2 12/12] net: dsa: mv88e6xxx: add support for DSA ageing time

> OK. I think caching per-port (and thus per-bridge) ageing time would do > the trick and keep DSA drivers simple. What about the following patch? Hi Vivien This looks good. I would suggest you do some testing with a printk, and force some topology changes, just to make sure it works how we

Re: [PATCH v2 net-next v2 12/12] net: dsa: mv88e6xxx: add support for DSA ageing time

> OK. I think caching per-port (and thus per-bridge) ageing time would do > the trick and keep DSA drivers simple. What about the following patch? Hi Vivien This looks good. I would suggest you do some testing with a printk, and force some topology changes, just to make sure it works how we

Re: [PATCH 03/10] of: irq: make of_msi_configure accessible from modules

On Mon, Jul 18, 2016 at 1:39 PM, Sinan Kaya wrote: > The of_msi_configure routine is only accessible by the built-in > kernel drivers. Export this function so that modules can use it > too. > > This function is useful for configuring MSI on child device tree > nodes on

Re: [PATCH v2] config: Add android config fragments

On Thu, Jun 23, 2016 at 1:57 PM, Rob Herring wrote: > Copy the config fragments from the AOSP common kernel android-4.4 > branch. It is becoming possible to run mainline kernels with Android, > but the kernel defconfigs don't work as-is and debugging missing config > options is a

Re: [PATCH 03/10] of: irq: make of_msi_configure accessible from modules

On Mon, Jul 18, 2016 at 1:39 PM, Sinan Kaya wrote: > The of_msi_configure routine is only accessible by the built-in > kernel drivers. Export this function so that modules can use it > too. > > This function is useful for configuring MSI on child device tree > nodes on hierarchical objects. > >

Re: [PATCH v2] config: Add android config fragments

On Thu, Jun 23, 2016 at 1:57 PM, Rob Herring wrote: > Copy the config fragments from the AOSP common kernel android-4.4 > branch. It is becoming possible to run mainline kernels with Android, > but the kernel defconfigs don't work as-is and debugging missing config > options is a pain. Adding the

Re: [PATCH V9 4/9] vfio: platform: add support for ACPI probe

On 7/18/2016 1:32 PM, Alex Williamson wrote: > The implementation looks pretty fixed, it seems like a lot would break > if that were changed, so the callers of the function would need to be > updated, including this one. The ternary below is already paranoid > enough to handle an API change, but

Re: [PATCH V9 4/9] vfio: platform: add support for ACPI probe

On 7/18/2016 1:32 PM, Alex Williamson wrote: > The implementation looks pretty fixed, it seems like a lot would break > if that were changed, so the callers of the function would need to be > updated, including this one. The ternary below is already paranoid > enough to handle an API change, but

[PATCH v8 08/10] Input: atmel_mxt_ts - add support for reference data

There are different datatypes available from a maXTouch chip. Add support to retrieve reference data as well. Signed-off-by: Nick Dyer --- drivers/input/touchscreen/atmel_mxt_ts.c | 57 ++ 1 file changed, 51 insertions(+), 6 deletions(-) diff

[PATCH v8 02/10] v4l2-core: Add support for touch devices

Some touch controllers send out touch data in a similar way to a greyscale frame grabber. Add new device type VFL_TYPE_TOUCH: - This uses a new device prefix v4l-touch for these devices, to stop generic capture software from treating them as webcams. Otherwise, touch is treated similarly to

[PATCH] v4l2-compliance: Changes to support touch sensors

Signed-off-by: Nick Dyer --- utils/v4l2-compliance/v4l2-compliance.cpp| 51 +- utils/v4l2-compliance/v4l2-compliance.h |1 + utils/v4l2-compliance/v4l2-test-input-output.cpp |4 +- 3 files changed, 53 insertions(+), 3

[PATCH v8 08/10] Input: atmel_mxt_ts - add support for reference data

There are different datatypes available from a maXTouch chip. Add support to retrieve reference data as well. Signed-off-by: Nick Dyer --- drivers/input/touchscreen/atmel_mxt_ts.c | 57 ++ 1 file changed, 51 insertions(+), 6 deletions(-) diff --git

[PATCH v8 02/10] v4l2-core: Add support for touch devices

Some touch controllers send out touch data in a similar way to a greyscale frame grabber. Add new device type VFL_TYPE_TOUCH: - This uses a new device prefix v4l-touch for these devices, to stop generic capture software from treating them as webcams. Otherwise, touch is treated similarly to

[PATCH] v4l2-compliance: Changes to support touch sensors

Signed-off-by: Nick Dyer --- utils/v4l2-compliance/v4l2-compliance.cpp| 51 +- utils/v4l2-compliance/v4l2-compliance.h |1 + utils/v4l2-compliance/v4l2-test-input-output.cpp |4 +- 3 files changed, 53 insertions(+), 3 deletions(-) diff --git

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