Re: [PATCH 4/6] fpga: region: change fpga_region_register to have one param

On Thu, Mar 29, 2018 at 4:39 PM, Moritz Fischer wrote: > On Thu, Mar 29, 2018 at 03:42:51PM -0500, Alan Tull wrote: >> On Thu, Mar 29, 2018 at 12:06 PM, Greg KH wrote: >> >> Hi Greg, >> >> >> -int fpga_region_register(struct device *dev, struct

Re: [PATCH 4/6] fpga: region: change fpga_region_register to have one param

On Thu, Mar 29, 2018 at 4:39 PM, Moritz Fischer wrote: > On Thu, Mar 29, 2018 at 03:42:51PM -0500, Alan Tull wrote: >> On Thu, Mar 29, 2018 at 12:06 PM, Greg KH wrote: >> >> Hi Greg, >> >> >> -int fpga_region_register(struct device *dev, struct fpga_region *region) >> >> +int

Re: [PATCH 4.14 00/43] 4.14.32-stable review

On 29 March 2018 at 23:29, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.32 release. > There are 43 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: [PATCH 4.14 00/43] 4.14.32-stable review

On 29 March 2018 at 23:29, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.32 release. > There are 43 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > >

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On Thu, Mar 29, 2018 at 11:33:34PM -0700, Christoph Hellwig wrote: > On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote: > > dma_map_resource() is the right API (thought its current implementation > > is fill with x86 assumptions). So i would argue that arch can decide to > > implement

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On Thu, Mar 29, 2018 at 11:33:34PM -0700, Christoph Hellwig wrote: > On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote: > > dma_map_resource() is the right API (thought its current implementation > > is fill with x86 assumptions). So i would argue that arch can decide to > > implement

Re: [PATCH V7 00/13] drivers: Boot Constraint core

Hi Greg and Viresh, On 03/23/2018 05:04 PM, Greg Kroah-Hartman wrote: > On Thu, Mar 22, 2018 at 09:26:06AM +0800, Viresh Kumar wrote: >> On 23-02-18, 15:53, Viresh Kumar wrote: >>> Problem statement: >>> >>> Some devices are powered ON by the bootloader before the bootloader >>> handovers control

Re: [PATCH V7 00/13] drivers: Boot Constraint core

Hi Greg and Viresh, On 03/23/2018 05:04 PM, Greg Kroah-Hartman wrote: > On Thu, Mar 22, 2018 at 09:26:06AM +0800, Viresh Kumar wrote: >> On 23-02-18, 15:53, Viresh Kumar wrote: >>> Problem statement: >>> >>> Some devices are powered ON by the bootloader before the bootloader >>> handovers control

Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

* Merlijn Wajer [180330 13:09]: > On 30/03/18 12:37, Pavel Machek wrote: > > On Thu 2018-03-29 14:56:13, Tony Lindgren wrote: > >> * Pavel Machek [180329 18:41]: > >>> Thanks. I got call working including outgoing audio: in capture > >>> settings, right->mic 1,

Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

* Merlijn Wajer [180330 13:09]: > On 30/03/18 12:37, Pavel Machek wrote: > > On Thu 2018-03-29 14:56:13, Tony Lindgren wrote: > >> * Pavel Machek [180329 18:41]: > >>> Thanks. I got call working including outgoing audio: in capture > >>> settings, right->mic 1, Mic1 + Mic2 in alsamixer -> 100%.

Re: [PATCH 4.15 00/47] 4.15.15-stable review

On 03/29/2018 10:59 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.15.15 release. There are 47 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.15 00/47] 4.15.15-stable review

On 03/29/2018 10:59 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.15.15 release. There are 47 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.14 00/43] 4.14.32-stable review

On 03/29/2018 10:59 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.32 release. There are 43 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.14 00/43] 4.14.32-stable review

On 03/29/2018 10:59 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.32 release. There are 43 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.9 00/28] 4.9.92-stable review

On 03/29/2018 11:00 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.92 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.9 00/28] 4.9.92-stable review

On 03/29/2018 11:00 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.92 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [v3] hwmon, via-cputem: support new centaur CPUs

On Fri, Mar 30, 2018 at 09:04:48AM +0800, davidwang wrote: > New centaur CPUs(Familiy == 7) also support this cpu temperature sensor. > > Change from v2 to v3: > *replace "goto" with "if...else.." according to suggestion from Guenter > > Change from v1 to v2: > *fixed the wrong if condition in

Re: [v3] hwmon, via-cputem: support new centaur CPUs

On Fri, Mar 30, 2018 at 09:04:48AM +0800, davidwang wrote: > New centaur CPUs(Familiy == 7) also support this cpu temperature sensor. > > Change from v2 to v3: > *replace "goto" with "if...else.." according to suggestion from Guenter > > Change from v1 to v2: > *fixed the wrong if condition in

[PATCH v2 2/2] trace: Mention trace_clock=global when warning about unstable clocks

Mention the alternative of adding trace_clock=global to the kernel command line when we detect that we've used an unstable clock across a suspend/resume cycle. Signed-off-by: Chris Wilson Cc: Steven Rostedt --- kernel/trace/ring_buffer.c | 3 ++-

[PATCH v2 2/2] trace: Mention trace_clock=global when warning about unstable clocks

Mention the alternative of adding trace_clock=global to the kernel command line when we detect that we've used an unstable clock across a suspend/resume cycle. Signed-off-by: Chris Wilson Cc: Steven Rostedt --- kernel/trace/ring_buffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

Across suspend, we may see a very large drift in timestamps if the sched clock is unstable, prompting the global trace's ringbuffer code to warn and suggest switching to the global clock. Preempt this request by detecting when the sched clock is unstable (determined during late_initcall) and

[PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

Across suspend, we may see a very large drift in timestamps if the sched clock is unstable, prompting the global trace's ringbuffer code to warn and suggest switching to the global clock. Preempt this request by detecting when the sched clock is unstable (determined during late_initcall) and

Re: [PATCH 4.4 00/20] 4.4.126-stable review

On 03/29/2018 11:00 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.126 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/20] 4.4.126-stable review

On 03/29/2018 11:00 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.126 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH v7 12/14] xfs: prepare xfs_break_layouts() to be called with XFS_MMAPLOCK_EXCL

On Wed, Mar 21, 2018 at 03:58:20PM -0700, Dan Williams wrote: > In preparation for adding coordination between extent unmap operations > and busy dax-pages, update xfs_break_layouts() to permit it to be called > with the mmap lock held. This lock scheme will be required for > coordinating the

Re: [PATCH v7 12/14] xfs: prepare xfs_break_layouts() to be called with XFS_MMAPLOCK_EXCL

On Wed, Mar 21, 2018 at 03:58:20PM -0700, Dan Williams wrote: > In preparation for adding coordination between extent unmap operations > and busy dax-pages, update xfs_break_layouts() to permit it to be called > with the mmap lock held. This lock scheme will be required for > coordinating the

Re: [PATCH] io: prevent compiler reordering on the default writeX() implementation

On Fri, Mar 30, 2018 at 10:29:58AM -0400, Sinan Kaya wrote: > The default implementation of mapping writeX() to __raw_writeX() is wrong. > writeX() has stronger ordering semantics. Compiler is allowed to reorder > __raw_writeX(). > > In the abscence of a write barrier or when using a strongly

Re: [PATCH] io: prevent compiler reordering on the default writeX() implementation

On Fri, Mar 30, 2018 at 10:29:58AM -0400, Sinan Kaya wrote: > The default implementation of mapping writeX() to __raw_writeX() is wrong. > writeX() has stronger ordering semantics. Compiler is allowed to reorder > __raw_writeX(). > > In the abscence of a write barrier or when using a strongly

Re: [PATCH 4.9 00/28] 4.9.92-stable review

On 30 March 2018 at 14:38, Greg Kroah-Hartman wrote: > On Fri, Mar 30, 2018 at 11:51:26AM +0530, Naresh Kamboju wrote: >> On 29 March 2018 at 23:30, Greg Kroah-Hartman >> wrote: >> > This is the start of the stable review cycle for the

Re: [PATCH 4.9 00/28] 4.9.92-stable review

On 30 March 2018 at 14:38, Greg Kroah-Hartman wrote: > On Fri, Mar 30, 2018 at 11:51:26AM +0530, Naresh Kamboju wrote: >> On 29 March 2018 at 23:30, Greg Kroah-Hartman >> wrote: >> > This is the start of the stable review cycle for the 4.9.92 release. >> > There are 28 patches in this series,

Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support

On Fri, Mar 30, 2018 at 04:16:34PM +0200, Alexandre Belloni wrote: > On 30/03/2018 at 15:54:22 +0200, Andrew Lunn wrote: > > > > All of this sounds like it should be moved into the br_join/leave, this > > > > does not appear to be the right place to do that. > > > > > > > > > > No, I've triple

Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support

On Fri, Mar 30, 2018 at 04:16:34PM +0200, Alexandre Belloni wrote: > On 30/03/2018 at 15:54:22 +0200, Andrew Lunn wrote: > > > > All of this sounds like it should be moved into the br_join/leave, this > > > > does not appear to be the right place to do that. > > > > > > > > > > No, I've triple

Re: [PATCH] io: prevent compiler reordering on the default writeX() implementation

On 3/30/2018 10:29 AM, Sinan Kaya wrote: > In the abscence of a write barrier or when using a strongly ordered > architecture, writeX() should at least have a compiler barrier in > it to prevent commpiler from clobbering the execution order. Same is true for readX(). I'll wait for review feedback

Re: [PATCH] io: prevent compiler reordering on the default writeX() implementation

On 3/30/2018 10:29 AM, Sinan Kaya wrote: > In the abscence of a write barrier or when using a strongly ordered > architecture, writeX() should at least have a compiler barrier in > it to prevent commpiler from clobbering the execution order. Same is true for readX(). I'll wait for review feedback

Re: [PATCH v4 0/2] of_net: Implement of_get_nvmem_mac_address helper

From: Mike Looijmans Date: Thu, 29 Mar 2018 07:29:47 +0200 > Posted this as a small set now, with an (optional) second patch that shows > how the changes work and what I've used to test the code on a Topic Miami > board. > I've taken the liberty to add appropriate

Re: [PATCH v4 0/2] of_net: Implement of_get_nvmem_mac_address helper

From: Mike Looijmans Date: Thu, 29 Mar 2018 07:29:47 +0200 > Posted this as a small set now, with an (optional) second patch that shows > how the changes work and what I've used to test the code on a Topic Miami > board. > I've taken the liberty to add appropriate "Acked" and "Review" tags. >

Re: [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

On Fri, 30 Mar 2018 15:07:53 +0100 Chris Wilson wrote: > Sure, I was mainly floating the idea of trying to pick sensible > defaults. Unstable clocks are quite rare nowadays, the ones we have in > the lab are a pair of Core2 Duo. I still have a box too ;-) I'm not so

Re: [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

On Fri, 30 Mar 2018 15:07:53 +0100 Chris Wilson wrote: > Sure, I was mainly floating the idea of trying to pick sensible > defaults. Unstable clocks are quite rare nowadays, the ones we have in > the lab are a pair of Core2 Duo. I still have a box too ;-) I'm not so against having

[PATCH] mtd: nand: davinci: don't acquire and enable clock

NAND itself is an asynchronous interface, it does not have any clock input. DaVinci NAND driver acquires clock for AEMIF (asynchronous external memory interface) which is an on-chip IP to which NAND is connected. The same clock is also enabled in AEMIF driver (either present drivers/memory or

[PATCH] mtd: nand: davinci: don't acquire and enable clock

NAND itself is an asynchronous interface, it does not have any clock input. DaVinci NAND driver acquires clock for AEMIF (asynchronous external memory interface) which is an on-chip IP to which NAND is connected. The same clock is also enabled in AEMIF driver (either present drivers/memory or

Re: [PATCHv3] gpio: Remove VLA from gpiolib

On Wed, Mar 28, 2018 at 9:18 PM, Laura Abbott wrote: > The new challenge is to remove VLAs from the kernel > (see https://lkml.org/lkml/2018/3/7/621) to eventually > turn on -Wvla. > > Using a kmalloc array is the easy way to fix this but kmalloc is still > more expensive than

Re: [v2] ftrace: drop a VLA in module_exists()

On Fri, 30 Mar 2018 10:53:08 +0200 Salvatore Mesoraca wrote: Couple of things. First, "PATCH" was dropped from the subject. If my inbox was busy today, I probably would have missed this email. > Avoid a VLA[1] by using a real constant expression instead of a variable. >

Re: [PATCHv3] gpio: Remove VLA from gpiolib

On Wed, Mar 28, 2018 at 9:18 PM, Laura Abbott wrote: > The new challenge is to remove VLAs from the kernel > (see https://lkml.org/lkml/2018/3/7/621) to eventually > turn on -Wvla. > > Using a kmalloc array is the easy way to fix this but kmalloc is still > more expensive than stack allocation.

Re: [v2] ftrace: drop a VLA in module_exists()

On Fri, 30 Mar 2018 10:53:08 +0200 Salvatore Mesoraca wrote: Couple of things. First, "PATCH" was dropped from the subject. If my inbox was busy today, I probably would have missed this email. > Avoid a VLA[1] by using a real constant expression instead of a variable. > The compiler should be

[PATCH] io: prevent compiler reordering on the default writeX() implementation

The default implementation of mapping writeX() to __raw_writeX() is wrong. writeX() has stronger ordering semantics. Compiler is allowed to reorder __raw_writeX(). In the abscence of a write barrier or when using a strongly ordered architecture, writeX() should at least have a compiler barrier in

[PATCH] io: prevent compiler reordering on the default writeX() implementation

The default implementation of mapping writeX() to __raw_writeX() is wrong. writeX() has stronger ordering semantics. Compiler is allowed to reorder __raw_writeX(). In the abscence of a write barrier or when using a strongly ordered architecture, writeX() should at least have a compiler barrier in

Re: [RFC PATCH v2 0/4] Eliminate zone->lock contention for will-it-scale/page_fault1 and parallel free

On 03/29/2018 09:42 PM, Aaron Lu wrote: On Thu, Mar 29, 2018 at 03:19:46PM -0400, Daniel Jordan wrote: On 03/20/2018 04:54 AM, Aaron Lu wrote: This series is meant to improve zone->lock scalability for order 0 pages. With will-it-scale/page_fault1 workload, on a 2 sockets Intel Skylake

Re: [RFC PATCH v2 0/4] Eliminate zone->lock contention for will-it-scale/page_fault1 and parallel free

On 03/29/2018 09:42 PM, Aaron Lu wrote: On Thu, Mar 29, 2018 at 03:19:46PM -0400, Daniel Jordan wrote: On 03/20/2018 04:54 AM, Aaron Lu wrote: This series is meant to improve zone->lock scalability for order 0 pages. With will-it-scale/page_fault1 workload, on a 2 sockets Intel Skylake

Re: [PATCH v1] kernel/trace:check the val against the available mem

[ Adding memory management folks to discuss the issue ] On Thu, 29 Mar 2018 18:41:44 +0800 Zhaoyang Huang wrote: > It is reported that some user app would like to echo a huge > number to "/sys/kernel/debug/tracing/buffer_size_kb" regardless > of the available memory,

Re: [PATCH v1] kernel/trace:check the val against the available mem

[ Adding memory management folks to discuss the issue ] On Thu, 29 Mar 2018 18:41:44 +0800 Zhaoyang Huang wrote: > It is reported that some user app would like to echo a huge > number to "/sys/kernel/debug/tracing/buffer_size_kb" regardless > of the available memory, which will cause the

Re: [PATCH 0/2] rhashtable_walk fixes

From: NeilBrown Date: Thu, 29 Mar 2018 12:19:09 +1100 > These two patches apply on top of my previous "rhashtable: reset iter > when rhashtable_walk_start sees new table" patch. > > The first fixes a bug that I found in rhltable_insert(). > > The second is an alternate to my

Re: [PATCH 0/2] rhashtable_walk fixes

From: NeilBrown Date: Thu, 29 Mar 2018 12:19:09 +1100 > These two patches apply on top of my previous "rhashtable: reset iter > when rhashtable_walk_start sees new table" patch. > > The first fixes a bug that I found in rhltable_insert(). > > The second is an alternate to my "rhashtable: allow

Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support

On 30/03/2018 at 15:54:22 +0200, Andrew Lunn wrote: > > > All of this sounds like it should be moved into the br_join/leave, this > > > does not appear to be the right place to do that. > > > > > > > No, I've triple checked because this is a comment that both Andrew and > > you had. Once a port

Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support

On 30/03/2018 at 15:54:22 +0200, Andrew Lunn wrote: > > > All of this sounds like it should be moved into the br_join/leave, this > > > does not appear to be the right place to do that. > > > > > > > No, I've triple checked because this is a comment that both Andrew and > > you had. Once a port

Re: [PATCH] fix typo in command value in drivers/net/phy/mdio-bitbang.

On Fri, Mar 30, 2018 at 02:03:38PM +0200, Frans Meulenbroeks wrote: > mdio-bitbang mentioned 10 for both read and write. > However mdio read opcode is 10 and write opcode is 01 > Fixed comment. > > Signed-off-by: Frans Meulenbroeks Hi Frans The correct place to

Re: [PATCH] fix typo in command value in drivers/net/phy/mdio-bitbang.

On Fri, Mar 30, 2018 at 02:03:38PM +0200, Frans Meulenbroeks wrote: > mdio-bitbang mentioned 10 for both read and write. > However mdio read opcode is 10 and write opcode is 01 > Fixed comment. > > Signed-off-by: Frans Meulenbroeks Hi Frans The correct place to send this patch is and David

Re: [PATCH] atm: iphase: fix spelling mistake: "Receiverd" -> "Received"

From: Colin King Date: Thu, 29 Mar 2018 00:18:53 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in message text > > Signed-off-by: Colin Ian King Applied, thanks Colin.

Re: [PATCH] atm: iphase: fix spelling mistake: "Receiverd" -> "Received"

From: Colin King Date: Thu, 29 Mar 2018 00:18:53 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in message text > > Signed-off-by: Colin Ian King Applied, thanks Colin.

Re: [PATCH net-next v2 0/2] phylink: API changes

From: Florian Fainelli Date: Wed, 28 Mar 2018 15:44:14 -0700 > This patch series contains two API changes to PHYLINK which will later be used > by DSA to migrate to PHYLINK. Because these are API changes that impact other > outstanding work (e.g: MVPP2) I would rather get

Re: [PATCH net-next v2 0/2] phylink: API changes

From: Florian Fainelli Date: Wed, 28 Mar 2018 15:44:14 -0700 > This patch series contains two API changes to PHYLINK which will later be used > by DSA to migrate to PHYLINK. Because these are API changes that impact other > outstanding work (e.g: MVPP2) I would rather get them included sooner to

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Fri, 30 Mar 2018 11:32:22 +0800 Zhaoyang Huang wrote: > Steve, thanks for your quick feedback. The original purpose is to > avoid such kind > of OOM as kernel can not define the behavior of the application. I > think it is no need > to do the alloc->free process if we

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Fri, 30 Mar 2018 11:32:22 +0800 Zhaoyang Huang wrote: > Steve, thanks for your quick feedback. The original purpose is to > avoid such kind > of OOM as kernel can not define the behavior of the application. I > think it is no need > to do the alloc->free process if we have known the number of

Re: [PATCH net-next] MAINTAINERS: update vmxnet3 driver maintainer

From: Ronak Doshi Date: Wed, 28 Mar 2018 15:38:19 -0700 > Shrikrishna Khare would no longer maintain the vmxnet3 driver. Taking > over the role of vmxnet3 maintainer. > > Signed-off-by: Ronak Doshi > Signed-off-by: Shrikrishna Khare

Re: [PATCH net-next] MAINTAINERS: update vmxnet3 driver maintainer

From: Ronak Doshi Date: Wed, 28 Mar 2018 15:38:19 -0700 > Shrikrishna Khare would no longer maintain the vmxnet3 driver. Taking > over the role of vmxnet3 maintainer. > > Signed-off-by: Ronak Doshi > Signed-off-by: Shrikrishna Khare Applied, thank you.

Re: [PATCH v2] MAINTAINERS: update entry for ARM/berlin

On Fri, Mar 30, 2018 at 11:02:11AM +0800, Jisheng Zhang wrote: > Synaptics has acquired the Multimedia Solutions Business of Marvell[1]. > So change the berlin entry name and move it to its alphabetical > location. We move to ARM/Synaptics instead of ARM/Marvell. > > This patch also updates my

Re: [PATCH v2] MAINTAINERS: update entry for ARM/berlin

On Fri, Mar 30, 2018 at 11:02:11AM +0800, Jisheng Zhang wrote: > Synaptics has acquired the Multimedia Solutions Business of Marvell[1]. > So change the berlin entry name and move it to its alphabetical > location. We move to ARM/Synaptics instead of ARM/Marvell. > > This patch also updates my

[PATCH 3/3] iio:dac:ad5686: Add AD5671R/75R/94/94R/95R/96/96R support

The AD5694/AD5694R/AD5695R/AD5696/AD5696R are a family of 4 channel DAC s with 12-bit, 14-bit and 16-bit precision respectively. The devices have either no built-in reference, or built-in 2.5V reference. The AD5671R/AD5675R are similar, except that they have 8 instead of 4 channels. These

[PATCH 3/3] iio:dac:ad5686: Add AD5671R/75R/94/94R/95R/96/96R support

The AD5694/AD5694R/AD5695R/AD5696/AD5696R are a family of 4 channel DAC s with 12-bit, 14-bit and 16-bit precision respectively. The devices have either no built-in reference, or built-in 2.5V reference. The AD5671R/AD5675R are similar, except that they have 8 instead of 4 channels. These

[PATCH 1/3] iio:dac:ad5686: Style fixes no functional changes

This patch fixes some indentation issues and does not modify the functionality of the driver. Signed-off-by: Stefan Popa --- drivers/iio/dac/ad5686.c | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/drivers/iio/dac/ad5686.c

[PATCH 1/3] iio:dac:ad5686: Style fixes no functional changes

This patch fixes some indentation issues and does not modify the functionality of the driver. Signed-off-by: Stefan Popa --- drivers/iio/dac/ad5686.c | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/drivers/iio/dac/ad5686.c

[PATCH 2/3] iio:dac:ad5686: Add AD5672R/AD5676/AD5676R/AD5684R/AD5685R/AD5686R support

The AD5684R/AD5685R/AD5686R are a family of 4 channel DACs with 12-bit, 14-bit and 16-bit precision respectively. The devices come either with a built-in reference or no built-in reference. The AD5672R/AD5676/AD5676R are similar, except that they have 8 channels instead of 4. Datasheets:

[PATCH 2/3] iio:dac:ad5686: Add AD5672R/AD5676/AD5676R/AD5684R/AD5685R/AD5686R support

The AD5684R/AD5685R/AD5686R are a family of 4 channel DACs with 12-bit, 14-bit and 16-bit precision respectively. The devices come either with a built-in reference or no built-in reference. The AD5672R/AD5676/AD5676R are similar, except that they have 8 channels instead of 4. Datasheets:

Re: [PATCH] tipc: avoid possible string overflow

From: Arnd Bergmann Date: Wed, 28 Mar 2018 16:02:04 +0200 > gcc points out that the combined length of the fixed-length inputs to > l->name is larger than the destination buffer size: > > net/tipc/link.c: In function 'tipc_link_create': > net/tipc/link.c:465:26: error: '%s'

Re: [PATCH] tipc: avoid possible string overflow

From: Arnd Bergmann Date: Wed, 28 Mar 2018 16:02:04 +0200 > gcc points out that the combined length of the fixed-length inputs to > l->name is larger than the destination buffer size: > > net/tipc/link.c: In function 'tipc_link_create': > net/tipc/link.c:465:26: error: '%s' directive writing up

Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support

> > All of this sounds like it should be moved into the br_join/leave, this > > does not appear to be the right place to do that. > > > > No, I've triple checked because this is a comment that both Andrew and > you had. Once a port is added to the PGID MASK, it will start forwarding > frames so

Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support

> > All of this sounds like it should be moved into the br_join/leave, this > > does not appear to be the right place to do that. > > > > No, I've triple checked because this is a comment that both Andrew and > you had. Once a port is added to the PGID MASK, it will start forwarding > frames so

[GIT PULL] Ceph fix for 4.16-rc8

Hi Linus, The following changes since commit 3eb2ce825ea1ad89d20f7a3b5780df850e4be274: Linux 4.16-rc7 (2018-03-25 12:44:30 -1000) are available in the git repository at: https://github.com/ceph/ceph-client.git tags/ceph-for-4.16-rc8 for you to fetch changes up to

[GIT PULL] Ceph fix for 4.16-rc8

Hi Linus, The following changes since commit 3eb2ce825ea1ad89d20f7a3b5780df850e4be274: Linux 4.16-rc7 (2018-03-25 12:44:30 -1000) are available in the git repository at: https://github.com/ceph/ceph-client.git tags/ceph-for-4.16-rc8 for you to fetch changes up to

Re: [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

On Thu, 29 Mar 2018 23:25:57 +0100 Chris Wilson wrote: > Across suspend, we may see a very large drift in timestamps if the sched > clock is unstable, prompting the global trace's ringbuffer code to warn > and suggest switching to the global clock. Preempt this request

Re: [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

On Thu, 29 Mar 2018 23:25:57 +0100 Chris Wilson wrote: > Across suspend, we may see a very large drift in timestamps if the sched > clock is unstable, prompting the global trace's ringbuffer code to warn > and suggest switching to the global clock. Preempt this request by > detecting when the

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Fri, Mar 30, 2018 at 09:55:08AM +0200, Pavel Machek wrote: > Hi! > > > Current implementation doesn't randomize address returned by mmap. > > All the entropy ends with choosing mmap_base_addr at the process > > creation. After that mmap build very predictable layout of address > > space. It

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Fri, Mar 30, 2018 at 09:55:08AM +0200, Pavel Machek wrote: > Hi! > > > Current implementation doesn't randomize address returned by mmap. > > All the entropy ends with choosing mmap_base_addr at the process > > creation. After that mmap build very predictable layout of address > > space. It

[PATCH] drm/tilcdc: Defer probe if there are no connectors

During probe there may not be any connectors yet if e.g. the panel failed or hasn't been probed yet. I hitting this in practice the panels probing was being delayed due to using a gpio backlight. Fix this by returning -EPROBE_DEFER so the probing will be retried. Signed-off-by: Sjoerd Simons

[PATCH] drm/tilcdc: Defer probe if there are no connectors

During probe there may not be any connectors yet if e.g. the panel failed or hasn't been probed yet. I hitting this in practice the panels probing was being delayed due to using a gpio backlight. Fix this by returning -EPROBE_DEFER so the probing will be retried. Signed-off-by: Sjoerd Simons

Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

On 30/03/18 12:37, Pavel Machek wrote: > On Thu 2018-03-29 14:56:13, Tony Lindgren wrote: >> * Pavel Machek [180329 18:41]: >>> Thanks. I got call working including outgoing audio: in capture >>> settings, right->mic 1, Mic1 + Mic2 in alsamixer -> 100%. But I had >>> the other phone

Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

On 30/03/18 12:37, Pavel Machek wrote: > On Thu 2018-03-29 14:56:13, Tony Lindgren wrote: >> * Pavel Machek [180329 18:41]: >>> Thanks. I got call working including outgoing audio: in capture >>> settings, right->mic 1, Mic1 + Mic2 in alsamixer -> 100%. But I had >>> the other phone muted, so I

Re: [PATCH v2 00/10] Add support for SAMA5D2 touchscreen

On Tue, 27 Mar 2018 15:32:33 +0300 Eugen Hristev wrote: > Hello, > > This patch series is a rework of my previous series named: > [PATCH 00/14] iio: triggers: add consumer support > > In few words, this is the implementation of splitting the functionality > of the

Re: [PATCH v2 00/10] Add support for SAMA5D2 touchscreen

On Tue, 27 Mar 2018 15:32:33 +0300 Eugen Hristev wrote: > Hello, > > This patch series is a rework of my previous series named: > [PATCH 00/14] iio: triggers: add consumer support > > In few words, this is the implementation of splitting the functionality > of the IP block ADC device in

[PATCHv6 2/2] mfd: motorola-cpcap: Add audio-codec support

From: Sebastian Reichel Add support for the audio-codec node by converting from devm_of_platform_populate() to devm_mfd_add_devices(). Tested-by: Pavel Machek Acked-by: Tony Lindgren Signed-off-by: Sebastian Reichel

[PATCHv6 1/2] dt-bindings: mfd: motorola-cpcap: document audio-codec

This adds the DT binding for the audio-codec sub-module found inside the Motorola CPCAP PMIC. Acked-by: Mark Brown Acked-by: Tony Lindgren Reviewed-by: Rob Herring Acked-for-MFD-by: Lee Jones Signed-off-by: Sebastian

[PATCHv6 2/2] mfd: motorola-cpcap: Add audio-codec support

From: Sebastian Reichel Add support for the audio-codec node by converting from devm_of_platform_populate() to devm_mfd_add_devices(). Tested-by: Pavel Machek Acked-by: Tony Lindgren Signed-off-by: Sebastian Reichel --- drivers/mfd/motorola-cpcap.c | 51

[PATCHv6 1/2] dt-bindings: mfd: motorola-cpcap: document audio-codec

This adds the DT binding for the audio-codec sub-module found inside the Motorola CPCAP PMIC. Acked-by: Mark Brown Acked-by: Tony Lindgren Reviewed-by: Rob Herring Acked-for-MFD-by: Lee Jones Signed-off-by: Sebastian Reichel --- .../devicetree/bindings/mfd/motorola-cpcap.txt | 42

[PATCHv6 0/2] Motorola Droid 4 Audio Support

Hi, This adds audio support to Motorola Droid 4. I dropped all patches, that have been applied and collected all Reviewed-by & Acked-by for the remaining ones. Also I changed the binding to use relative paths. -- Sebastian Sebastian Reichel (2): dt-bindings: mfd: motorola-cpcap: document

Re: [PATCH v2 07/10] input: touchscreen: touch_adc: add generic resistive ADC touchscreen

On Tue, 27 Mar 2018 15:32:40 +0300 Eugen Hristev wrote: > This adds a generic resistive touchscreen (GRTS) driver, which is based > on an IIO device (an ADC). It must be connected to the channels of an ADC > to receive touch data. Then it will feed the data into the

[PATCHv6 0/2] Motorola Droid 4 Audio Support

Hi, This adds audio support to Motorola Droid 4. I dropped all patches, that have been applied and collected all Reviewed-by & Acked-by for the remaining ones. Also I changed the binding to use relative paths. -- Sebastian Sebastian Reichel (2): dt-bindings: mfd: motorola-cpcap: document

Re: [PATCH v2 07/10] input: touchscreen: touch_adc: add generic resistive ADC touchscreen

On Tue, 27 Mar 2018 15:32:40 +0300 Eugen Hristev wrote: > This adds a generic resistive touchscreen (GRTS) driver, which is based > on an IIO device (an ADC). It must be connected to the channels of an ADC > to receive touch data. Then it will feed the data into the input subsystem > where it

[PATCH v2 4/6] spi: sun6i: use completion provided by SPI core

As long as the completion is already provided by the SPI core then there is no need to waste extra-memory on this. Also a waiting function was added to avoid code duplication. Changes in v2: 1) Fixed issue with passing an invalid argument into devm_request_irq() function. Signed-off-by: Sergey

[PATCH v2 1/6] spi: sun6i: coding style/readability improvements

Minor changes to fulfill the coding style and improve the readability of the code. Changes in v2: 1) Fixed issue with misplacing a piece of code that requires access to the transfer structure into sun6i_spi_prepare_message() function where the transfer structure is not available. Signed-off-by:

[PATCH v2 4/6] spi: sun6i: use completion provided by SPI core

As long as the completion is already provided by the SPI core then there is no need to waste extra-memory on this. Also a waiting function was added to avoid code duplication. Changes in v2: 1) Fixed issue with passing an invalid argument into devm_request_irq() function. Signed-off-by: Sergey

[PATCH v2 1/6] spi: sun6i: coding style/readability improvements

Minor changes to fulfill the coding style and improve the readability of the code. Changes in v2: 1) Fixed issue with misplacing a piece of code that requires access to the transfer structure into sun6i_spi_prepare_message() function where the transfer structure is not available. Signed-off-by:

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