Applied "regulator: axp20x: Fix axp22x ldo_io voltage ranges" to the regulator tree

The patch regulator: axp20x: Fix axp22x ldo_io voltage ranges has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: core: Add early supply resolution for regulators" to the regulator tree

The patch regulator: core: Add early supply resolution for regulators has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "ASoC: dmaengine_pcm: Add support for packed transfers" to the asoc tree

The patch ASoC: dmaengine_pcm: Add support for packed transfers has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "regulator: axp20x: Fix axp22x ldo_io voltage ranges" to the regulator tree

The patch regulator: axp20x: Fix axp22x ldo_io voltage ranges has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: axp20x: Fix axp22x ldo_io voltage ranges" to the regulator tree

The patch regulator: axp20x: Fix axp22x ldo_io voltage ranges has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: core: Add early supply resolution for regulators" to the regulator tree

The patch regulator: core: Add early supply resolution for regulators has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "regulator: rk808: Add rk808_reg_ops_ranges for LDO3" to the regulator tree

The patch regulator: rk808: Add rk808_reg_ops_ranges for LDO3 has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: atmel_ssc_dai: read DSP mode A data on rising edges of bclk" to the asoc tree

The patch ASoC: atmel_ssc_dai: read DSP mode A data on rising edges of bclk has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: rk808: Add rk808_reg_ops_ranges for LDO3" to the regulator tree

The patch regulator: rk808: Add rk808_reg_ops_ranges for LDO3 has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: atmel_ssc_dai: read DSP mode A data on rising edges of bclk" to the asoc tree

The patch ASoC: atmel_ssc_dai: read DSP mode A data on rising edges of bclk has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCH] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

On 04/26/2016 02:39 PM, Rafael J. Wysocki wrote: > On Wednesday, April 13, 2016 08:48:14 AM Betty Dall wrote: >> The ACPI _HRV object on the device is used to supply Linux with >> the device's hardware revision. This is an optional object. Add >> sysfs support for the _HRV object if it exists on

[for-next][PATCH 0/5] tracing: More updates for 4.7

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: 4afe6495e5cb3c352d95f07512cbb227e607e2ce Dan Carpenter (1): tracing: checking for NULL instead of IS_ERR() Steven Rostedt (Red Hat) (1): tracing: Do not inherit event-fork option for

Re: [PATCH] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

On 04/26/2016 02:39 PM, Rafael J. Wysocki wrote: > On Wednesday, April 13, 2016 08:48:14 AM Betty Dall wrote: >> The ACPI _HRV object on the device is used to supply Linux with >> the device's hardware revision. This is an optional object. Add >> sysfs support for the _HRV object if it exists on

[for-next][PATCH 0/5] tracing: More updates for 4.7

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: 4afe6495e5cb3c352d95f07512cbb227e607e2ce Dan Carpenter (1): tracing: checking for NULL instead of IS_ERR() Steven Rostedt (Red Hat) (1): tracing: Do not inherit event-fork option for

[PATCH 03/12] staging/android: move sync_file functions comments to sync.c

From: Gustavo Padovan To keep comments in line with drivers/dma-buf/ move all sync_file comments to sync.c. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 26 +-

[PATCH 12/12] Documentation: add Sync File doc

From: Gustavo Padovan Add sync_file documentation on dma-buf-sync_file.txt --- Documentation/dma-buf-sync_file.txt | 65 + 1 file changed, 65 insertions(+) create mode 100644 Documentation/dma-buf-sync_file.txt diff --git

[PATCH 10/12] dma-buf/sync_file: de-stage sync_file

From: Gustavo Padovan sync_file is useful to connect one or more fences to the file. The file is used by userspace to track fences between drivers that share DMA bufs. Signed-off-by: Gustavo Padovan --- drivers/Kconfig

[PATCH 04/12] staging/android: make sync_file_merge() static

From: Gustavo Padovan There is no plan in the near future to use this function outside of this file so keep it as static. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 4 ++--

[GIT PULL] workqueue fixes for v4.6-rc5

Hello, Linus. So, it turns out we had a silly bug in the most fundamental part of workqueue for a very long time. AFAICS, this dates back to pre-git era and has quite likely been there from the time workqueue was first introduced. A work item uses its PENDING bit to synchronize multiple

[PATCH 03/12] staging/android: move sync_file functions comments to sync.c

From: Gustavo Padovan To keep comments in line with drivers/dma-buf/ move all sync_file comments to sync.c. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 26 +- drivers/staging/android/sync.h | 31 --- 2 files changed,

[PATCH 12/12] Documentation: add Sync File doc

From: Gustavo Padovan Add sync_file documentation on dma-buf-sync_file.txt --- Documentation/dma-buf-sync_file.txt | 65 + 1 file changed, 65 insertions(+) create mode 100644 Documentation/dma-buf-sync_file.txt diff --git

[PATCH 10/12] dma-buf/sync_file: de-stage sync_file

From: Gustavo Padovan sync_file is useful to connect one or more fences to the file. The file is used by userspace to track fences between drivers that share DMA bufs. Signed-off-by: Gustavo Padovan --- drivers/Kconfig | 2 ++ drivers/dma-buf/Kconfig

[PATCH 04/12] staging/android: make sync_file_merge() static

From: Gustavo Padovan There is no plan in the near future to use this function outside of this file so keep it as static. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 4 ++-- drivers/staging/android/sync.h | 2 -- 2 files changed, 2 insertions(+), 4 deletions(-) diff

[GIT PULL] workqueue fixes for v4.6-rc5

Hello, Linus. So, it turns out we had a silly bug in the most fundamental part of workqueue for a very long time. AFAICS, this dates back to pre-git era and has quite likely been there from the time workqueue was first introduced. A work item uses its PENDING bit to synchronize multiple

[PATCH 08/12] staging/android: style fix: alignment to match the open parenthesis

From: Gustavo Padovan Fix checks reported by checkpatch.pl. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync_file.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH 11/12] Documentation: include sync_file into DocBook

From: Gustavo Padovan Add entry in device-drivers.tmpl for sync_file documentation. Signed-off-by: Gustavo Padovan --- Documentation/DocBook/device-drivers.tmpl | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 07/12] staging/android: improve documentation for sync_file

From: Gustavo Padovan num_fences was missing a colon mark and sync_file_create() now have better description. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync_file.c | 3 ++- drivers/staging/android/sync_file.h |

[PATCH 08/12] staging/android: style fix: alignment to match the open parenthesis

From: Gustavo Padovan Fix checks reported by checkpatch.pl. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync_file.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/android/sync_file.c b/drivers/staging/android/sync_file.c index

[PATCH 11/12] Documentation: include sync_file into DocBook

From: Gustavo Padovan Add entry in device-drivers.tmpl for sync_file documentation. Signed-off-by: Gustavo Padovan --- Documentation/DocBook/device-drivers.tmpl | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/DocBook/device-drivers.tmpl

[PATCH 07/12] staging/android: improve documentation for sync_file

From: Gustavo Padovan num_fences was missing a colon mark and sync_file_create() now have better description. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync_file.c | 3 ++- drivers/staging/android/sync_file.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff

[PATCH 05/12] staging/android: make sync_file_fdget() static

From: Gustavo Padovan There is no plan in the near future to use this function outside of this file so keep it as static. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 3 +-- drivers/staging/android/sync.h

[PATCH 05/12] staging/android: make sync_file_fdget() static

From: Gustavo Padovan There is no plan in the near future to use this function outside of this file so keep it as static. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 3 +-- drivers/staging/android/sync.h | 1 - 2 files changed, 1 insertion(+), 3 deletions(-) diff

[PATCH 06/12] staging/android: prepare sync_file for de-staging

From: Gustavo Padovan Move its functions and structs to their own file. Also moves function's docs to the .c file. Signed-off-by: Gustavo Padovan --- drivers/staging/android/Makefile | 2 +-

[PATCH 06/12] staging/android: prepare sync_file for de-staging

From: Gustavo Padovan Move its functions and structs to their own file. Also moves function's docs to the .c file. Signed-off-by: Gustavo Padovan --- drivers/staging/android/Makefile | 2 +- drivers/staging/android/sync.c | 373 ---

[for-next][PATCH 4/5] tracing: Handle tracing_map_alloc_elts() error path correctly

From: Tom Zanussi If tracing_map_elt_alloc() fails, it will return ERR_PTR() instead of NULL, so change the check to IS_ERROR(). We also need to set the failed entry in the map->elts array to NULL instead of ERR_PTR() so tracing_map_free_elts() doesn't try freeing

[for-next][PATCH 5/5] tracing: Dont use the address of the buffer array name in copy_from_user

From: Wang Xiaoqiang With the following code snippet: ... char buf[64]; ... if (copy_from_user(, ubuf, cnt)) ... Even though the value of "" equals "buf", but there is no need to get the address of the "buf" again. Use "buf" instead of "". Link:

[for-next][PATCH 1/5] tracing: Do not inherit event-fork option for instances

From: "Steven Rostedt (Red Hat)" As the event-fork option requires doing work when enabled and disabled, it can not be passed down to created instances. The instance must clear this flag when it is created, and must clear it when its removed. As more options may be created

[for-next][PATCH 4/5] tracing: Handle tracing_map_alloc_elts() error path correctly

From: Tom Zanussi If tracing_map_elt_alloc() fails, it will return ERR_PTR() instead of NULL, so change the check to IS_ERROR(). We also need to set the failed entry in the map->elts array to NULL instead of ERR_PTR() so tracing_map_free_elts() doesn't try freeing an ERR_PTR().

[for-next][PATCH 5/5] tracing: Dont use the address of the buffer array name in copy_from_user

From: Wang Xiaoqiang With the following code snippet: ... char buf[64]; ... if (copy_from_user(, ubuf, cnt)) ... Even though the value of "" equals "buf", but there is no need to get the address of the "buf" again. Use "buf" instead of "". Link:

[for-next][PATCH 1/5] tracing: Do not inherit event-fork option for instances

From: "Steven Rostedt (Red Hat)" As the event-fork option requires doing work when enabled and disabled, it can not be passed down to created instances. The instance must clear this flag when it is created, and must clear it when its removed. As more options may be created with this need, a

[for-next][PATCH 2/5] tracing: checking for NULL instead of IS_ERR()

From: Dan Carpenter tracing_map_elt_alloc() returns ERR_PTRs on error, never NULL. Fixes: 08d43a5fa063 ('tracing: Add lock-free tracing_map') Link: http://lkml.kernel.org/r/20160423102347.GA11136@mwanda Acked-by: Tom Zanussi

[for-next][PATCH 3/5] tracing: Add check for NULL event field when creating hist field

From: Tom Zanussi Smatch flagged create_hist_field() as possibly being able to dereference a NULL pointer, although the current code exits in all cases where the event field could be NULL, so it's not actually a problem. Still, to prevent future changes to the code

[for-next][PATCH 3/5] tracing: Add check for NULL event field when creating hist field

From: Tom Zanussi Smatch flagged create_hist_field() as possibly being able to dereference a NULL pointer, although the current code exits in all cases where the event field could be NULL, so it's not actually a problem. Still, to prevent future changes to the code from overlooking new cases,

[for-next][PATCH 2/5] tracing: checking for NULL instead of IS_ERR()

From: Dan Carpenter tracing_map_elt_alloc() returns ERR_PTRs on error, never NULL. Fixes: 08d43a5fa063 ('tracing: Add lock-free tracing_map') Link: http://lkml.kernel.org/r/20160423102347.GA11136@mwanda Acked-by: Tom Zanussi Signed-off-by: Dan Carpenter Signed-off-by: Steven Rostedt ---

Re: [PATCH 1/2] regulator: core: Allow use of "status = disabled" in regulator dts nodes

On Wed, Apr 27, 2016 at 05:54:48PM +0200, Hans de Goede wrote: > On 27-04-16 17:52, Hans de Goede wrote: > >On 27-04-16 17:50, Maxime Ripard wrote: > >>On Wed, Apr 27, 2016 at 04:01:08PM +0100, Mark Brown wrote: > >>>To repeat you really shouldn't have *any* DT nodes for regulators that >

[PATCH 01/12] staging/android: remove redundant comments on sync_merge_data

From: Gustavo Padovan struct sync_merge_data already have documentation on top of the struct definition. No need to duplicate it. Signed-off-by: Gustavo Padovan Reviewed-by: Maarten Lankhorst

Re: [PATCH 1/2] regulator: core: Allow use of "status = disabled" in regulator dts nodes

On Wed, Apr 27, 2016 at 05:54:48PM +0200, Hans de Goede wrote: > On 27-04-16 17:52, Hans de Goede wrote: > >On 27-04-16 17:50, Maxime Ripard wrote: > >>On Wed, Apr 27, 2016 at 04:01:08PM +0100, Mark Brown wrote: > >>>To repeat you really shouldn't have *any* DT nodes for regulators that >

[PATCH 01/12] staging/android: remove redundant comments on sync_merge_data

From: Gustavo Padovan struct sync_merge_data already have documentation on top of the struct definition. No need to duplicate it. Signed-off-by: Gustavo Padovan Reviewed-by: Maarten Lankhorst --- drivers/staging/android/uapi/sync.h | 10 +- 1 file changed, 5 insertions(+), 5

Re: [PATCH v2 3/3] regulator: axp20x: Fix axp22x ldo_io registration error on cold boot

On Wed, Apr 27, 2016 at 06:04:53PM +0200, Hans de Goede wrote: > On 27-04-16 17:48, Mark Brown wrote: > >Well, I guess someone can just measure what happens? > What happens will likely depend on the pmic input voltage, > which can be either 5V from a charger / usb or can be approx > 3.8V from a

Re: [PATCH v2 3/3] regulator: axp20x: Fix axp22x ldo_io registration error on cold boot

On Wed, Apr 27, 2016 at 06:04:53PM +0200, Hans de Goede wrote: > On 27-04-16 17:48, Mark Brown wrote: > >Well, I guess someone can just measure what happens? > What happens will likely depend on the pmic input voltage, > which can be either 5V from a charger / usb or can be approx > 3.8V from a

[PATCH 09/12] dma-buf/sync_file: de-stage sync_file headers

From: Gustavo Padovan Move sync_file headers file to include/ dir. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.h | 4 ++-- drivers/staging/android/sync_debug.c

[PATCH 09/12] dma-buf/sync_file: de-stage sync_file headers

From: Gustavo Padovan Move sync_file headers file to include/ dir. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.h | 4 ++-- drivers/staging/android/sync_debug.c | 2 +- drivers/staging/android/sync_file.c

Re: [PATCH] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

On 04/26/2016 02:33 PM, Rafael J. Wysocki wrote: > On Wednesday, April 13, 2016 08:48:14 AM Betty Dall wrote: >> The ACPI _HRV object on the device is used to supply Linux with >> the device's hardware revision. This is an optional object. Add >> sysfs support for the _HRV object if it exists on

Re: [PATCH] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

On 04/26/2016 02:33 PM, Rafael J. Wysocki wrote: > On Wednesday, April 13, 2016 08:48:14 AM Betty Dall wrote: >> The ACPI _HRV object on the device is used to supply Linux with >> the device's hardware revision. This is an optional object. Add >> sysfs support for the _HRV object if it exists on

Re: [tpmdd-devel] [PATCH v11 0/4] Multi-instance vTPM proxy driver

On 04/27/2016 08:56 AM, Jarkko Sakkinen wrote: On Tue, Apr 26, 2016 at 07:30:26AM -0400, Stefan Berger wrote: On 04/26/2016 05:28 AM, Jarkko Sakkinen wrote: On Fri, Apr 22, 2016 at 07:54:27PM +0300, Jarkko Sakkinen wrote: On Mon, Apr 18, 2016 at 01:26:12PM -0400, Stefan Berger wrote: The

Re: [tpmdd-devel] [PATCH v11 0/4] Multi-instance vTPM proxy driver

On 04/27/2016 08:56 AM, Jarkko Sakkinen wrote: On Tue, Apr 26, 2016 at 07:30:26AM -0400, Stefan Berger wrote: On 04/26/2016 05:28 AM, Jarkko Sakkinen wrote: On Fri, Apr 22, 2016 at 07:54:27PM +0300, Jarkko Sakkinen wrote: On Mon, Apr 18, 2016 at 01:26:12PM -0400, Stefan Berger wrote: The

[PATCH 02/12] staging/android: drop sync_file_install() and sync_file_put()

From: Gustavo Padovan These two functions are just wrappers for one line functions, they call fd_install() and fput() respectively, so just get rid of them and use fd_install() and fput() directly for more simplicity. Signed-off-by: Gustavo Padovan

[PATCH 00/12] De-stage Sync File Framework

From: Gustavo Padovan Hi, This patchset sits on top of Sync ABI Rework v13: https://www.spinics.net/lists/dri-devel/msg105667.html The first eight clean up and prepare sync_file for de-staging. The last four patches do the de-staging, moving files to

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On 4/27/16 10:09 AM, Frederic Weisbecker wrote: I first thought that this should be a tunable per event instead of a global sysctl Yeah, I'll work on that too. There is no rush though. The sysfs limit will probably be enough for most users. Unless someone requested it? I have. I spent

[PATCH 02/12] staging/android: drop sync_file_install() and sync_file_put()

From: Gustavo Padovan These two functions are just wrappers for one line functions, they call fd_install() and fput() respectively, so just get rid of them and use fd_install() and fput() directly for more simplicity. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c |

[PATCH 00/12] De-stage Sync File Framework

From: Gustavo Padovan Hi, This patchset sits on top of Sync ABI Rework v13: https://www.spinics.net/lists/dri-devel/msg105667.html The first eight clean up and prepare sync_file for de-staging. The last four patches do the de-staging, moving files to drivers/dma-buf/ and include/linux/ plus

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On 4/27/16 10:09 AM, Frederic Weisbecker wrote: I first thought that this should be a tunable per event instead of a global sysctl Yeah, I'll work on that too. There is no rush though. The sysfs limit will probably be enough for most users. Unless someone requested it? I have. I spent

Re: [PATCH v1] ARM: clocksource: make ARM_GLOBAL_TIMER selectable

* Grygorii Strashko [160427 06:32]: > Hi Russell, > > On 04/27/2016 01:41 PM, Russell King - ARM Linux wrote: > > On Tue, Apr 26, 2016 at 10:35:08PM +0300, Grygorii Strashko wrote: > >> On 04/26/2016 07:02 PM, Liviu Dudau wrote: > >>> Well, SoC-B has the GT *and* the DT

Re: [PATCH v1] ARM: clocksource: make ARM_GLOBAL_TIMER selectable

* Grygorii Strashko [160427 06:32]: > Hi Russell, > > On 04/27/2016 01:41 PM, Russell King - ARM Linux wrote: > > On Tue, Apr 26, 2016 at 10:35:08PM +0300, Grygorii Strashko wrote: > >> On 04/26/2016 07:02 PM, Liviu Dudau wrote: > >>> Well, SoC-B has the GT *and* the DT node, so what is the

Re: [PATCH] ASoC: atmel_ssc_dai: note buggy I2S support when the codec masters LRCLK

On Wed, Apr 27, 2016 at 11:06:33AM +0200, Peter Rosin wrote: > While the start condition is correct for the left channel word in the I2S > case, it is not correct that the right channel word follows immediately > after the left channel word. The start of the right channel word should > be

Re: [PATCH] ASoC: atmel_ssc_dai: note buggy I2S support when the codec masters LRCLK

On Wed, Apr 27, 2016 at 11:06:33AM +0200, Peter Rosin wrote: > While the start condition is correct for the left channel word in the I2S > case, it is not correct that the right channel word follows immediately > after the left channel word. The start of the right channel word should > be

Re: [PATCH v2] net: Add Qualcomm IPC router

From: Bjorn Andersson Date: Tue, 26 Apr 2016 22:48:05 -0700 > + rc = qcom_smd_send(qdev->channel, skb->data, skb->len); I truly dislike adding networking protocols that depend upon some piece of infrastructure that only some platforms can enable, it's even worse

Re: [PATCH v2] net: Add Qualcomm IPC router

From: Bjorn Andersson Date: Tue, 26 Apr 2016 22:48:05 -0700 > + rc = qcom_smd_send(qdev->channel, skb->data, skb->len); I truly dislike adding networking protocols that depend upon some piece of infrastructure that only some platforms can enable, it's even worse when that set of platforms

Re: [PATCH v2 0/2] perf probe fixes for ppc64le

On 2016/04/12 02:40PM, Naveen N Rao wrote: > This patchset fixes three issues found with perf probe on ppc64le: > 1. 'perf test kallsyms' failure on ppc64le (reported by Michael > Ellerman). This was due to the symbols being fixed up during symbol > table load. This is fixed in patch 2 by delaying

Re: [patch V2] lib: GCD: add binary GCD algorithm

I replicated your results in 32- and 64-bit x86: - If __ffs (gcc's __builtin_ctz) is available, the basic (non-even/odd) binary GCD algorithm is faster than the divsion-based or even/odd. - If shifting down has to be done in a loop, the even/odd binary algorithm is fastest. I tried a few

Re: [PATCH v2 0/2] perf probe fixes for ppc64le

On 2016/04/12 02:40PM, Naveen N Rao wrote: > This patchset fixes three issues found with perf probe on ppc64le: > 1. 'perf test kallsyms' failure on ppc64le (reported by Michael > Ellerman). This was due to the symbols being fixed up during symbol > table load. This is fixed in patch 2 by delaying

Re: [patch V2] lib: GCD: add binary GCD algorithm

I replicated your results in 32- and 64-bit x86: - If __ffs (gcc's __builtin_ctz) is available, the basic (non-even/odd) binary GCD algorithm is faster than the divsion-based or even/odd. - If shifting down has to be done in a loop, the even/odd binary algorithm is fastest. I tried a few

Re: [RFC PATCH v1 03/18] x86: Secure Memory Encryption (SME) support

On 03/22/2016 08:03 AM, Pavel Machek wrote: > On Tue 2016-04-26 17:56:26, Tom Lendacky wrote: >> Provide support for Secure Memory Encryption (SME). This initial support >> defines the memory encryption mask as a variable for quick access and an >> accessor for retrieving the number of physical

Re: [RFC PATCH v1 03/18] x86: Secure Memory Encryption (SME) support

On 03/22/2016 08:03 AM, Pavel Machek wrote: > On Tue 2016-04-26 17:56:26, Tom Lendacky wrote: >> Provide support for Secure Memory Encryption (SME). This initial support >> defines the memory encryption mask as a variable for quick access and an >> accessor for retrieving the number of physical

Re: [PATCH] tty: provide tty_name() even without CONFIG_TTY

On Wed, Apr 27, 2016 at 5:56 AM, Arnd Bergmann wrote: > The audit subsystem just started printing the name of the tty, > but that causes a build failure when CONFIG_TTY is disabled: > > kernel/built-in.o: In function `audit_log_task_info': > memremap.c:(.text+0x5e34c): undefined

Re: [PATCH] tty: provide tty_name() even without CONFIG_TTY

On Wed, Apr 27, 2016 at 5:56 AM, Arnd Bergmann wrote: > The audit subsystem just started printing the name of the tty, > but that causes a build failure when CONFIG_TTY is disabled: > > kernel/built-in.o: In function `audit_log_task_info': > memremap.c:(.text+0x5e34c): undefined reference to

Re: [PATCH] dmaengine: pl330: Fix race in pl330_get_desc()

On 27 April 2016 at 19:17, Robin Murphy wrote: >> Instead of churning the code, I would suggest either check in a loop >> that we have a desc OR allocate 2 or NR_DEFAULT_DESC descriptors >> there. Probably we get more descriptors at the same cost of memory. > > > Having had

Re: [PATCH] dmaengine: pl330: Fix race in pl330_get_desc()

On 27 April 2016 at 19:17, Robin Murphy wrote: >> Instead of churning the code, I would suggest either check in a loop >> that we have a desc OR allocate 2 or NR_DEFAULT_DESC descriptors >> there. Probably we get more descriptors at the same cost of memory. > > > Having had a quick look into how

[PATCH v2] cpufreq: st: enable selective initialization based on the platform

The sti-cpufreq does unconditional registration of the cpufreq-dt driver which causes issue on an multi-platform build. For example, on Vexpress TC2 platform, we get the following error on boot: cpu cpu0: OPP-v2 not supported cpu cpu0: Not doing voltage scaling cpu:

[PATCH v2] cpufreq: st: enable selective initialization based on the platform

The sti-cpufreq does unconditional registration of the cpufreq-dt driver which causes issue on an multi-platform build. For example, on Vexpress TC2 platform, we get the following error on boot: cpu cpu0: OPP-v2 not supported cpu cpu0: Not doing voltage scaling cpu:

Re: [PATCH] cpufreq: st: enable selective initialization based on the platform

On 27/04/16 17:07, Lee Jones wrote: On Wed, 27 Apr 2016, Sudeep Holla wrote: [...] + if ((!of_machine_is_compatible("st,stih407-b2120")) && + (!of_machine_is_compatible("st,stih407"))) + return -ENODEV; You need to check for "st,stih407" and

Re: [PATCH] cpufreq: st: enable selective initialization based on the platform

On 27/04/16 17:07, Lee Jones wrote: On Wed, 27 Apr 2016, Sudeep Holla wrote: [...] + if ((!of_machine_is_compatible("st,stih407-b2120")) && + (!of_machine_is_compatible("st,stih407"))) + return -ENODEV; You need to check for "st,stih407" and

Re: [RFC PATCH v2 1/2] [media] tvp5150: Add input connectors DT bindings

Hi Javier, Thank you for the patch. On Tuesday 12 Apr 2016 18:42:52 Javier Martinez Canillas wrote: > The tvp5150 and tvp5151 decoders support different video input source > connections to their AIP1A and AIP1B pins. Either two Composite or a > S-Video input signals are supported. > > The

Re: [RFC PATCH v2 1/2] [media] tvp5150: Add input connectors DT bindings

Hi Javier, Thank you for the patch. On Tuesday 12 Apr 2016 18:42:52 Javier Martinez Canillas wrote: > The tvp5150 and tvp5151 decoders support different video input source > connections to their AIP1A and AIP1B pins. Either two Composite or a > S-Video input signals are supported. > > The

Re: [PATCH] ASoC: pcm: allow changing the playback/capture rates for symmetric links

On Wed, Apr 27, 2016 at 10:49:19AM +0200, Peter Rosin wrote: > The below program fails on a dai link with symmetric rates without this > patch. The patch makes it work. You've not articulated the problem you're trying to fix here, what in concrete terms is the program trying to accomplish and

Re: [PATCH] ASoC: pcm: allow changing the playback/capture rates for symmetric links

On Wed, Apr 27, 2016 at 10:49:19AM +0200, Peter Rosin wrote: > The below program fails on a dai link with symmetric rates without this > patch. The patch makes it work. You've not articulated the problem you're trying to fix here, what in concrete terms is the program trying to accomplish and

Re: [PATCH] scripts/spelling.txt: add "fimware" misspelling

On Tue, Apr 26, 2016 at 9:06 PM, Zhao Lei wrote: > Hi, Kees Cook > > * From: Kees Cook [mailto:keesc...@chromium.org] >> Sent: Wednesday, April 27, 2016 7:48 AM >> To: Andrew Morton >> Cc: Randy Dunlap ; Andy Whitcroft >>

Re: [PATCH] scripts/spelling.txt: add "fimware" misspelling

On Tue, Apr 26, 2016 at 9:06 PM, Zhao Lei wrote: > Hi, Kees Cook > > * From: Kees Cook [mailto:keesc...@chromium.org] >> Sent: Wednesday, April 27, 2016 7:48 AM >> To: Andrew Morton >> Cc: Randy Dunlap ; Andy Whitcroft >> ; Joe Perches ; Zhao Lei >> ; linux-...@vger.kernel.org; >>

Re: [PATCH V6 05/13] acpi, pci: Support IO resources when parsing PCI host bridge resources.

On Wed, Apr 27, 2016 at 04:10:36PM +0100, liviu.du...@arm.com wrote: > On Wed, Apr 27, 2016 at 03:26:59PM +0100, Lorenzo Pieralisi wrote: > > On Tue, Apr 26, 2016 at 09:39:16PM -0500, Bjorn Helgaas wrote: > > > On Fri, Apr 15, 2016 at 07:06:40PM +0200, Tomasz Nowicki wrote: > > > > Platforms that

Re: [PATCH V6 05/13] acpi, pci: Support IO resources when parsing PCI host bridge resources.

On Wed, Apr 27, 2016 at 04:10:36PM +0100, liviu.du...@arm.com wrote: > On Wed, Apr 27, 2016 at 03:26:59PM +0100, Lorenzo Pieralisi wrote: > > On Tue, Apr 26, 2016 at 09:39:16PM -0500, Bjorn Helgaas wrote: > > > On Fri, Apr 15, 2016 at 07:06:40PM +0200, Tomasz Nowicki wrote: > > > > Platforms that

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On Wed, Apr 27, 2016 at 09:53:58AM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Apr 26, 2016 at 11:58:10PM +0200, Frederic Weisbecker escreveu: > > On Mon, Apr 25, 2016 at 09:29:28PM -0300, Arnaldo Carvalho de Melo wrote: > > > commit cd544af4f7fede01cb512d52bb3efe62aa19271d > > > Author:

Re: [PATCH/RFC v3] perf core: Allow setting up max frame stack depth via sysctl

On Wed, Apr 27, 2016 at 09:53:58AM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Apr 26, 2016 at 11:58:10PM +0200, Frederic Weisbecker escreveu: > > On Mon, Apr 25, 2016 at 09:29:28PM -0300, Arnaldo Carvalho de Melo wrote: > > > commit cd544af4f7fede01cb512d52bb3efe62aa19271d > > > Author:

Re: [GIT PULL] platform-drivers-x86 for 4.6-3

On Tue, Apr 26, 2016 at 10:02 PM, Darren Hart wrote: > > Found myself not wanting to send a one patch pull request, but not wanting to > wait until RC6 and possibly miss 4.6. > > Do you have a preference during the RC cycle in terms of balance between patch > count and

Re: [PATCH] cpufreq: st: enable selective initialization based on the platform

On Wed, 27 Apr 2016, Sudeep Holla wrote: > The sti-cpufreq does unconditional registration of the cpufreq-dt driver > which causes issue on an multi-platform build. For example, on Vexpress > TC2 platform, we get the following error on boot: > > cpu cpu0: OPP-v2 not supported > cpu cpu0: Not

Re: [GIT PULL] platform-drivers-x86 for 4.6-3

On Tue, Apr 26, 2016 at 10:02 PM, Darren Hart wrote: > > Found myself not wanting to send a one patch pull request, but not wanting to > wait until RC6 and possibly miss 4.6. > > Do you have a preference during the RC cycle in terms of balance between patch > count and frequency for a small

Re: [PATCH] cpufreq: st: enable selective initialization based on the platform

On Wed, 27 Apr 2016, Sudeep Holla wrote: > The sti-cpufreq does unconditional registration of the cpufreq-dt driver > which causes issue on an multi-platform build. For example, on Vexpress > TC2 platform, we get the following error on boot: > > cpu cpu0: OPP-v2 not supported > cpu cpu0: Not

Re: [PATCH v2 3/3] regulator: axp20x: Fix axp22x ldo_io registration error on cold boot

Hi, On 27-04-16 17:48, Mark Brown wrote: On Wed, Apr 27, 2016 at 05:35:31PM +0200, Hans de Goede wrote: On 27-04-16 17:12, Mark Brown wrote: Why not just implement that? Given the formula in the datasheet to calculate the ldo_io regulator voltage 0x1f maps to 3.8V, but according to the

Re: [PATCH v2 3/3] regulator: axp20x: Fix axp22x ldo_io registration error on cold boot

Hi, On 27-04-16 17:48, Mark Brown wrote: On Wed, Apr 27, 2016 at 05:35:31PM +0200, Hans de Goede wrote: On 27-04-16 17:12, Mark Brown wrote: Why not just implement that? Given the formula in the datasheet to calculate the ldo_io regulator voltage 0x1f maps to 3.8V, but according to the

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Wednesday 27 April 2016 16:50:19 Catalin Marinas wrote: > On Wed, Apr 27, 2016 at 04:11:17PM +0200, Arnd Bergmann wrote: > > On Wednesday 27 April 2016 14:59:00 Catalin Marinas wrote: > > > > > > I would be in favour of a dma_inherit() function as well. We could hack > > > something up in the

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Wednesday 27 April 2016 16:50:19 Catalin Marinas wrote: > On Wed, Apr 27, 2016 at 04:11:17PM +0200, Arnd Bergmann wrote: > > On Wednesday 27 April 2016 14:59:00 Catalin Marinas wrote: > > > > > > I would be in favour of a dma_inherit() function as well. We could hack > > > something up in the

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