Re: [PATCH] rcu: shift by 1UL rather than 1 to fix sign extension error

On Tue, Dec 13, 2016 at 11:33:19AM +, Colin Ian King wrote: > On 13/12/16 11:21, Boqun Feng wrote: > > On Tue, Dec 13, 2016 at 10:56:46AM +, Colin King wrote: > >> From: Colin Ian King > >> > >> mask and bit are unsigned longs, so if bit is 31 we end up sign > >>

Build failures due to missing 'posix_timer_event'

avr32:allnoconfig: kernel/built-in.o: In function `do_adjtimex': (.text+0x1d748): undefined reference to `posix_timer_event' make[1]: *** [vmlinux] Error 1 metag:allnoconfig: kernel/built-in.o: In function `alarm_handle_timer': alarmtimer.c:(.text.alarm_handle_timer+0x38): undefined reference

Re: [PATCH] rcu: shift by 1UL rather than 1 to fix sign extension error

On Tue, Dec 13, 2016 at 11:33:19AM +, Colin Ian King wrote: > On 13/12/16 11:21, Boqun Feng wrote: > > On Tue, Dec 13, 2016 at 10:56:46AM +, Colin King wrote: > >> From: Colin Ian King > >> > >> mask and bit are unsigned longs, so if bit is 31 we end up sign > >> extending the 1 and mask

Build failures due to missing 'posix_timer_event'

avr32:allnoconfig: kernel/built-in.o: In function `do_adjtimex': (.text+0x1d748): undefined reference to `posix_timer_event' make[1]: *** [vmlinux] Error 1 metag:allnoconfig: kernel/built-in.o: In function `alarm_handle_timer': alarmtimer.c:(.text.alarm_handle_timer+0x38): undefined reference

Re: [v1] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Hi Arvind, [auto build test ERROR on net-next/master] [also build test ERROR on v4.9 next-20161214] [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/Arvind-Yadav/net-ethernet-cavium-octeon

Re: [v1] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Hi Arvind, [auto build test ERROR on net-next/master] [also build test ERROR on v4.9 next-20161214] [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/Arvind-Yadav/net-ethernet-cavium-octeon

[RESEND PATCH 0/2] fix some trivial bug involving the contiguous bit

From: zhong jiang Hi, The following patch have sent it last week, but it fails to receive any reply. These patch is simple but reasonable. I hope it can merge to next version. So, if anyone has any objection, just please let me know. Thanks zhongjiang zhong jiang

[RESEND PATCH 0/2] fix some trivial bug involving the contiguous bit

From: zhong jiang Hi, The following patch have sent it last week, but it fails to receive any reply. These patch is simple but reasonable. I hope it can merge to next version. So, if anyone has any objection, just please let me know. Thanks zhongjiang zhong jiang (2): arm64: change

Re: [PATCH] spi: SPI_FSL_DSPI should depend on HAS_DMA

Hi Mark, On Wed, Dec 14, 2016 at 3:37 PM, Mark Brown wrote: > On Wed, Dec 14, 2016 at 01:28:05PM +0100, Geert Uytterhoeven wrote: >> If NO_DMA=y: > >> ERROR: "bad_dma_ops" [drivers/spi/spi-fsl-dspi.ko] undefined! > >> Add a dependency on HAS_DMA to fix this. > > Honestly

Re: [PATCH] spi: SPI_FSL_DSPI should depend on HAS_DMA

Hi Mark, On Wed, Dec 14, 2016 at 3:37 PM, Mark Brown wrote: > On Wed, Dec 14, 2016 at 01:28:05PM +0100, Geert Uytterhoeven wrote: >> If NO_DMA=y: > >> ERROR: "bad_dma_ops" [drivers/spi/spi-fsl-dspi.ko] undefined! > >> Add a dependency on HAS_DMA to fix this. > > Honestly I think we should

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hello Bartlomiej, On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote: >> >> Hello Bartlomiej, >> >> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote: >>> >>> On Tuesday, December 13, 2016

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hello Bartlomiej, On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote: >> >> Hello Bartlomiej, >> >> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote: >>> >>> On Tuesday, December 13, 2016

[PATCH] usb: hub: Move hub_port_disable() to fix warning if PM is disabled

If CONFIG_PM=n: drivers/usb/core/hub.c:107: warning: ‘hub_usb3_port_prepare_disable’ declared inline after being called drivers/usb/core/hub.c:107: warning: previous declaration of ‘hub_usb3_port_prepare_disable’ was here To fix this, move hub_port_disable() after

Re: [PATCH] spi: SPI_FSL_DSPI should depend on HAS_DMA

On Wed, Dec 14, 2016 at 01:28:05PM +0100, Geert Uytterhoeven wrote: > If NO_DMA=y: > ERROR: "bad_dma_ops" [drivers/spi/spi-fsl-dspi.ko] undefined! > Add a dependency on HAS_DMA to fix this. Honestly I think we should just fix the architectures that don't support DMA to provide compile out

[PATCH] usb: hub: Move hub_port_disable() to fix warning if PM is disabled

If CONFIG_PM=n: drivers/usb/core/hub.c:107: warning: ‘hub_usb3_port_prepare_disable’ declared inline after being called drivers/usb/core/hub.c:107: warning: previous declaration of ‘hub_usb3_port_prepare_disable’ was here To fix this, move hub_port_disable() after

Re: [PATCH] spi: SPI_FSL_DSPI should depend on HAS_DMA

On Wed, Dec 14, 2016 at 01:28:05PM +0100, Geert Uytterhoeven wrote: > If NO_DMA=y: > ERROR: "bad_dma_ops" [drivers/spi/spi-fsl-dspi.ko] undefined! > Add a dependency on HAS_DMA to fix this. Honestly I think we should just fix the architectures that don't support DMA to provide compile out

Re: [PATCH 1/8] dax: add region-available-size attribute

Hi Dan, On Sat, Dec 10, 2016 at 10:28:30PM -0800, Dan Williams wrote: > In preparation for a facility that enables dax regions to be > sub-divided, introduce a 'dax/available_size' attribute. This attribute > appears under the parent device that registered the device-dax region, > and it assumes

Re: [PATCH 1/8] dax: add region-available-size attribute

Hi Dan, On Sat, Dec 10, 2016 at 10:28:30PM -0800, Dan Williams wrote: > In preparation for a facility that enables dax regions to be > sub-divided, introduce a 'dax/available_size' attribute. This attribute > appears under the parent device that registered the device-dax region, > and it assumes

[RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT

From: zhong jiang I think that CONT_PTE_SHIFT is more reasonable even if they are some value. and the patch is not any functional change. Signed-off-by: zhong jiang --- arch/arm64/mm/hugetlbpage.c | 2 +- 1 file changed, 1 insertion(+), 1

[RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT

From: zhong jiang I think that CONT_PTE_SHIFT is more reasonable even if they are some value. and the patch is not any functional change. Signed-off-by: zhong jiang --- arch/arm64/mm/hugetlbpage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/mm/hugetlbpage.c

[RESEND PATCH 2/2] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE

From: zhong jiang when HUGETLB_PAGE is disable, WANT_HUGE_PMD_SHARE contains the fuctions should not be use. therefore, we add the dependency. Signed-off-by: zhong jiang --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git

[RESEND PATCH 2/2] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE

From: zhong jiang when HUGETLB_PAGE is disable, WANT_HUGE_PMD_SHARE contains the fuctions should not be use. therefore, we add the dependency. Signed-off-by: zhong jiang --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index

Re: [PATCH 2/3] selftests: do not require bash to run bpf tests

On 12/14/2016 04:03 AM, Daniel Borkmann wrote: > On 12/14/2016 11:58 AM, Rolf Eike Beer wrote: >> From b9d6c1b7427d708ef2d4d57aac17b700b3694d71 Mon Sep 17 00:00:00 2001 >> From: Rolf Eike Beer >> Date: Wed, 14 Dec 2016 09:58:12 +0100 >> Subject: [PATCH 2/3] selftests: do

Re: [PATCH 2/3] selftests: do not require bash to run bpf tests

On 12/14/2016 04:03 AM, Daniel Borkmann wrote: > On 12/14/2016 11:58 AM, Rolf Eike Beer wrote: >> From b9d6c1b7427d708ef2d4d57aac17b700b3694d71 Mon Sep 17 00:00:00 2001 >> From: Rolf Eike Beer >> Date: Wed, 14 Dec 2016 09:58:12 +0100 >> Subject: [PATCH 2/3] selftests: do not require bash to run

jemalloc testsuite stalls in memset

When running the jemalloc-4.4.0 testsuite on aarch64 with glibc 2.24 the test/unit/junk test hangs in memset: (gdb) r Starting program: /tmp/jemalloc/jemalloc-4.4.0/test/unit/junk [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1".

jemalloc testsuite stalls in memset

When running the jemalloc-4.4.0 testsuite on aarch64 with glibc 2.24 the test/unit/junk test hangs in memset: (gdb) r Starting program: /tmp/jemalloc/jemalloc-4.4.0/test/unit/junk [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1".

Re: xhci_reset_endpoint() doesn't reset endpoint

On 14.12.2016 12:58, Michal Necasek wrote: prior to the endpoint reset. SetFeature(CLEAR_HALT) resets the toggle on the device, but not on the host. But we know for a fact that the device sends a packet (with data toggle 0) which the host USB stack never sees, and a data toggle mismatch explains

Re: xhci_reset_endpoint() doesn't reset endpoint

On 14.12.2016 12:58, Michal Necasek wrote: prior to the endpoint reset. SetFeature(CLEAR_HALT) resets the toggle on the device, but not on the host. But we know for a fact that the device sends a packet (with data toggle 0) which the host USB stack never sees, and a data toggle mismatch explains

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hi, On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote: > > Hello Bartlomiej, > > On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote: > > > > On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote: > >> Hello Bartlomiej, > > > > Hi, > > > >> On

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hi, On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote: > > Hello Bartlomiej, > > On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote: > > > > On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote: > >> Hello Bartlomiej, > > > > Hi, > > > >> On

Re: Revised request_key(2) man page for review

Hi David, Might you also have a chance to take a look at this page? Cheers, Michael On 4 November 2016 at 16:45, Michael Kerrisk (man-pages) wrote: > Hi David (and anyone else with an interest to review) > > Triggered by Eugene Syromyatnikov's recent input for the

Re: Revised request_key(2) man page for review

Hi David, Might you also have a chance to take a look at this page? Cheers, Michael On 4 November 2016 at 16:45, Michael Kerrisk (man-pages) wrote: > Hi David (and anyone else with an interest to review) > > Triggered by Eugene Syromyatnikov's recent input for the keyctl(2) > man page, I've

[PATCH] pinctrl: stm32: activate strict mux mode

From: Gabriel Fernandez This activates strict mode muxing for the STM32 pin controllers, as these do not allow GPIO and functions to use the same pin simultaneously. Signed-off-by: Gabriel Fernandez --- drivers/pinctrl/stm32/pinctrl-stm32.c

Re: [GIT PULL] trivial for 4.10

On Wed, 2016-12-14 at 11:05 +0100, Jiri Kosina wrote: > Linus, > > please pull from > >   git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git for-linus > > to receive 4.10 merge window updates from trivial tree > > I hereby confess to having rebased the for-next branch, because I

[PATCH] pinctrl: stm32: activate strict mux mode

From: Gabriel Fernandez This activates strict mode muxing for the STM32 pin controllers, as these do not allow GPIO and functions to use the same pin simultaneously. Signed-off-by: Gabriel Fernandez --- drivers/pinctrl/stm32/pinctrl-stm32.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [GIT PULL] trivial for 4.10

On Wed, 2016-12-14 at 11:05 +0100, Jiri Kosina wrote: > Linus, > > please pull from > >   git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git for-linus > > to receive 4.10 merge window updates from trivial tree > > I hereby confess to having rebased the for-next branch, because I

[PATCH] clk: stm32f4: Use CLK_OF_DECLARE_DRIVER initialization method

From: Gabriel Fernandez Clock and reset controller use same compatible strings (same IP). Since commit 989eafd0b609 ("clk: core: Avoid double initialization of clocks") the OF core flags clock controllers registered with the CLK_OF_DECLARE() macro as OF_POPULATED, so

[PATCH] clk: stm32f4: Use CLK_OF_DECLARE_DRIVER initialization method

From: Gabriel Fernandez Clock and reset controller use same compatible strings (same IP). Since commit 989eafd0b609 ("clk: core: Avoid double initialization of clocks") the OF core flags clock controllers registered with the CLK_OF_DECLARE() macro as OF_POPULATED, so platform devices with the

[PATCH] dt-bindings: mfd: stm32f429: Add QSPI & DSI constants into DT include file

From: Gabriel Fernandez It will be used by clock and reset drivers, and DT bindings. Signed-off-by: Gabriel Fernandez --- include/dt-bindings/mfd/stm32f4-rcc.h | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH] dt-bindings: mfd: stm32f429: Add QSPI & DSI constants into DT include file

From: Gabriel Fernandez It will be used by clock and reset drivers, and DT bindings. Signed-off-by: Gabriel Fernandez --- include/dt-bindings/mfd/stm32f4-rcc.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h

Re: [PATCH] include/linux/kernel.h: fixed coding style issues

On Wed, Dec 14 2016, Piotr Gregor wrote: > Apply coding style suggested by Documentation/CodingStyle > and checkpatch.pl script. Fix 59 warnings and 24 errors > reported by checkpatch.pl > > Signed-off-by: Piotr Gregor Acked-by: Michal Nazarewicz but

Re: Issue with DRM and "reimplement IDR and IDA using the radix tree"

Forgot to add the most relevant list for this issue (linux-next). Stephen, maybe you will want to temporarily revert this patch until this is cleared? This probably affects other users than DRM. On 12/13/2016 04:14 PM, Alexandre Courbot wrote: > Hi Matthew, > > Trying the latest -next on the

Re: [PATCH] include/linux/kernel.h: fixed coding style issues

On Wed, Dec 14 2016, Piotr Gregor wrote: > Apply coding style suggested by Documentation/CodingStyle > and checkpatch.pl script. Fix 59 warnings and 24 errors > reported by checkpatch.pl > > Signed-off-by: Piotr Gregor Acked-by: Michal Nazarewicz but I wouldn’t be surprised to see push-back

Re: Issue with DRM and "reimplement IDR and IDA using the radix tree"

Forgot to add the most relevant list for this issue (linux-next). Stephen, maybe you will want to temporarily revert this patch until this is cleared? This probably affects other users than DRM. On 12/13/2016 04:14 PM, Alexandre Courbot wrote: > Hi Matthew, > > Trying the latest -next on the

Re: [PATCH linux v1 0/4] Seven segment display support

On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote: > On 12/14/2016 01:56 PM, Greg KH wrote: > > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote: > >> Hello, > >> > >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder > >> Natarajan wrote: > >> >

Re: [PATCH linux v1 0/4] Seven segment display support

On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote: > On 12/14/2016 01:56 PM, Greg KH wrote: > > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote: > >> Hello, > >> > >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder > >> Natarajan wrote: > >> >

Re: [PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

On 14.12.2016 07:04, Hoegeun Kwon wrote: > This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel > driver. This panel has 1440x2560 resolution in 5.7-inch physical > panel in the TM2 device. > > Signed-off-by: Donghwa Lee > Signed-off-by: Hyungwon Hwang

Re: [PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

On 14.12.2016 07:04, Hoegeun Kwon wrote: > This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel > driver. This panel has 1440x2560 resolution in 5.7-inch physical > panel in the TM2 device. > > Signed-off-by: Donghwa Lee > Signed-off-by: Hyungwon Hwang > Signed-off-by: Hoegeun Kwon

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On 09.12.2016 17:03, Greg Kroah-Hartman wrote: > On Sat, Dec 10, 2016 at 01:56:53AM +1000, Nicholas Piggin wrote: >> On Fri, 9 Dec 2016 15:36:04 +0100 >> Stanislav Kozina wrote: >> >>> The question is how to provide a similar guarantee if a different way? >> As a

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On 09.12.2016 17:03, Greg Kroah-Hartman wrote: > On Sat, Dec 10, 2016 at 01:56:53AM +1000, Nicholas Piggin wrote: >> On Fri, 9 Dec 2016 15:36:04 +0100 >> Stanislav Kozina wrote: >> >>> The question is how to provide a similar guarantee if a different way? >> As a tool to aid distro

Re: [PATCH] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc

Hi Emmanuel, On Wed, Dec 14, 2016 at 11:08:56AM +0100, Emmanuel Vadot wrote: > The node name for the power seq pin is mmc2@0 like the mmc2_pins_a one. > This makes the original node (mmc2_pins_a) scrapped out of the dtb and > result in a unusable eMMC if U-Boot didn't configured the pins to the >

Re: [PATCH] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc

Hi Emmanuel, On Wed, Dec 14, 2016 at 11:08:56AM +0100, Emmanuel Vadot wrote: > The node name for the power seq pin is mmc2@0 like the mmc2_pins_a one. > This makes the original node (mmc2_pins_a) scrapped out of the dtb and > result in a unusable eMMC if U-Boot didn't configured the pins to the >

[RFC] btrfs: lockdep says "possible recursive locking detected" in btrfs_clear_lock_blocking_rw()

With lockdep enabled I managed to trigger the following lockdep splat: | = | [ INFO: possible recursive locking detected ] | 4.9.0-rt0 #804 Tainted: GW | - | kworker/u16:4/154 is trying to acquire

[RFC] btrfs: lockdep says "possible recursive locking detected" in btrfs_clear_lock_blocking_rw()

With lockdep enabled I managed to trigger the following lockdep splat: | = | [ INFO: possible recursive locking detected ] | 4.9.0-rt0 #804 Tainted: GW | - | kworker/u16:4/154 is trying to acquire

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hello Bartlomiej, On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote: > > On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote: >> Hello Bartlomiej, > > Hi, > >> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote: >>> Add missing 2000MHz & 1900MHz OPPs (for A15

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hello Bartlomiej, On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote: > > On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote: >> Hello Bartlomiej, > > Hi, > >> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote: >>> Add missing 2000MHz & 1900MHz OPPs (for A15

[PATCH 2/2] btrfs: swap free() and trace point in run_ordered_work()

The previous patch removed a trace point due to a use after free problem with tracing enabled. While looking at the backtrace it took me a while to find the right spot. While doing so I noticed that this trace point could be used after one of two clean-up functions were invoked: -

[PATCH 2/2] btrfs: swap free() and trace point in run_ordered_work()

The previous patch removed a trace point due to a use after free problem with tracing enabled. While looking at the backtrace it took me a while to find the right spot. While doing so I noticed that this trace point could be used after one of two clean-up functions were invoked: -

[PATCH 1/2] btrfs: drop trace_btrfs_all_work_done() from normal_work_helper()

For btrfs_scrubparity_helper() the ->func() is set to scrub_parity_bio_endio_worker(). This functions invokes scrub_free_parity() which kfrees() the `work' object. All is good as long as trace events are not enabled because we boom with a backtrace like this: | Workqueue: btrfs-endio

[PATCH 1/2] btrfs: drop trace_btrfs_all_work_done() from normal_work_helper()

For btrfs_scrubparity_helper() the ->func() is set to scrub_parity_bio_endio_worker(). This functions invokes scrub_free_parity() which kfrees() the `work' object. All is good as long as trace events are not enabled because we boom with a backtrace like this: | Workqueue: btrfs-endio

Re: [PATCH 12/23] drm: omapdrm: plane: update fifo size on atomic update

Hi, On Wed, Dec 14, 2016 at 11:14:32AM +0200, Tomi Valkeinen wrote: > On 14/12/16 11:10, Laurent Pinchart wrote: > > Hi Tomi, > > > > On Wednesday 14 Dec 2016 10:43:18 Tomi Valkeinen wrote: > >> On 13/12/16 19:35, Laurent Pinchart wrote: > >>> On Tuesday 08 Mar 2016 17:39:44 Sebastian Reichel

Re: [PATCH 12/23] drm: omapdrm: plane: update fifo size on atomic update

Hi, On Wed, Dec 14, 2016 at 11:14:32AM +0200, Tomi Valkeinen wrote: > On 14/12/16 11:10, Laurent Pinchart wrote: > > Hi Tomi, > > > > On Wednesday 14 Dec 2016 10:43:18 Tomi Valkeinen wrote: > >> On 13/12/16 19:35, Laurent Pinchart wrote: > >>> On Tuesday 08 Mar 2016 17:39:44 Sebastian Reichel

[PATCH v4 4/6] [media] rc-ir-raw: do not generate any receiving thread for raw transmitters

Raw IR transmitters do not need any thread listening for occurring events. Check the driver type before running the thread. Signed-off-by: Andi Shyti Reviewed-by: Sean Young --- drivers/media/rc/rc-ir-raw.c | 17 - 1 file changed, 12

[PATCH v4 4/6] [media] rc-ir-raw: do not generate any receiving thread for raw transmitters

Raw IR transmitters do not need any thread listening for occurring events. Check the driver type before running the thread. Signed-off-by: Andi Shyti Reviewed-by: Sean Young --- drivers/media/rc/rc-ir-raw.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git

[GIT PULL] ACPI CPPC fixes for v4.10-rc1

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-urgent-4.10-rc1 with top-most commit cc31e9b718dafd8a1bdc593234ddbbf4faa2511c Merge branch 'acpi-cppc' on top of commit a67485d4bf97918225dfb5246e531643755a7ee1 Merge tag

[GIT PULL] ACPI CPPC fixes for v4.10-rc1

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-urgent-4.10-rc1 with top-most commit cc31e9b718dafd8a1bdc593234ddbbf4faa2511c Merge branch 'acpi-cppc' on top of commit a67485d4bf97918225dfb5246e531643755a7ee1 Merge tag

[PATCH v4 2/6] [media] rc-main: split setup and unregister functions

Move the input device allocation, map and protocol handling to different functions. Signed-off-by: Andi Shyti Reviewed-by: Sean Young --- drivers/media/rc/rc-main.c | 143 + 1 file changed, 81 insertions(+), 62

[PATCH v4 2/6] [media] rc-main: split setup and unregister functions

Move the input device allocation, map and protocol handling to different functions. Signed-off-by: Andi Shyti Reviewed-by: Sean Young --- drivers/media/rc/rc-main.c | 143 + 1 file changed, 81 insertions(+), 62 deletions(-) diff --git

[PATCH v4 3/6] [media] rc-core: add support for IR raw transmitters

IR raw transmitter driver type is specified in the enum rc_driver_type as RC_DRIVER_IR_RAW_TX which includes all those devices that transmit raw stream of bit to a receiver. The data are provided by userspace applications, therefore they don't need any input device allocation, but still they need

[PATCH v4 3/6] [media] rc-core: add support for IR raw transmitters

IR raw transmitter driver type is specified in the enum rc_driver_type as RC_DRIVER_IR_RAW_TX which includes all those devices that transmit raw stream of bit to a receiver. The data are provided by userspace applications, therefore they don't need any input device allocation, but still they need

[PATCH v4 5/6] Documentation: bindings: add documentation for ir-spi device driver

Document the ir-spi driver's binding which is a IR led driven through the SPI line. Signed-off-by: Andi Shyti Reviewed-by: Sean Young --- .../devicetree/bindings/leds/irled/spi-ir-led.txt | 29 ++ 1 file changed, 29 insertions(+)

[PATCH v4 6/6] [media] rc: add support for IR LEDs driven through SPI

The ir-spi is a simple device driver which supports the connection between an IR LED and the MOSI line of an SPI device. The driver, indeed, uses the SPI framework to stream the raw data provided by userspace through an rc character device. The chardev is handled by the LIRC framework and its

[PATCH v4 1/6] [media] rc-main: assign driver type during allocation

The driver type can be assigned immediately when an RC device requests to the framework to allocate the device. This is an 'enum rc_driver_type' data type and specifies whether the device is a raw receiver or scancode receiver. The type will be given as parameter to the rc_allocate_device device.

[PATCH v4 5/6] Documentation: bindings: add documentation for ir-spi device driver

Document the ir-spi driver's binding which is a IR led driven through the SPI line. Signed-off-by: Andi Shyti Reviewed-by: Sean Young --- .../devicetree/bindings/leds/irled/spi-ir-led.txt | 29 ++ 1 file changed, 29 insertions(+) create mode 100644

[PATCH v4 6/6] [media] rc: add support for IR LEDs driven through SPI

The ir-spi is a simple device driver which supports the connection between an IR LED and the MOSI line of an SPI device. The driver, indeed, uses the SPI framework to stream the raw data provided by userspace through an rc character device. The chardev is handled by the LIRC framework and its

[PATCH v4 1/6] [media] rc-main: assign driver type during allocation

The driver type can be assigned immediately when an RC device requests to the framework to allocate the device. This is an 'enum rc_driver_type' data type and specifies whether the device is a raw receiver or scancode receiver. The type will be given as parameter to the rc_allocate_device device.

[PATCH v4 0/6] Add support for IR transmitters

Hi, The main goal is to add support in the rc framework for IR transmitters, which currently is only supported by lirc but that is not the preferred way. The last patch adds support for an IR transmitter driven by the MOSI line of an SPI controller, it's the case of the Samsung TM2(e) board

[PATCH v4 0/6] Add support for IR transmitters

Hi, The main goal is to add support in the rc framework for IR transmitters, which currently is only supported by lirc but that is not the preferred way. The last patch adds support for an IR transmitter driven by the MOSI line of an SPI controller, it's the case of the Samsung TM2(e) board

Re: [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot

On Wed, Dec 14, 2016 at 12:47 AM, Mark Brown wrote: > On Fri, Dec 09, 2016 at 11:20:18AM +, Lee Jones wrote: > >> Is the following valid/necessary? > >> On Wed, 23 Nov 2016, Chen-Yu Tsai wrote: >> > The AXP806 supports either master/standalone or slave mode. >> > Slave

Re: [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot

On Wed, Dec 14, 2016 at 12:47 AM, Mark Brown wrote: > On Fri, Dec 09, 2016 at 11:20:18AM +, Lee Jones wrote: > >> Is the following valid/necessary? > >> On Wed, 23 Nov 2016, Chen-Yu Tsai wrote: >> > The AXP806 supports either master/standalone or slave mode. >> > Slave mode allows sharing the

[PATCH v3 1/2] watchdog: introduce watchdog_worker_should_ping helper

This will be useful when the condition becomes slightly more complicated in the next patch. Signed-off-by: Rasmus Villemoes --- drivers/watchdog/watchdog_dev.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/watchdog/watchdog_dev.c

[PATCH v3 0/2] watchdog: allow setting deadline for opening /dev/watchdogN

If a watchdog driver tells the framework that the device is running, the framework takes care of feeding the watchdog until userspace opens the device. If the userspace application which is supposed to do that never comes up properly, the watchdog is fed indefinitely by the kernel. This can be

[PATCH v3 1/2] watchdog: introduce watchdog_worker_should_ping helper

This will be useful when the condition becomes slightly more complicated in the next patch. Signed-off-by: Rasmus Villemoes --- drivers/watchdog/watchdog_dev.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/watchdog/watchdog_dev.c

[PATCH v3 0/2] watchdog: allow setting deadline for opening /dev/watchdogN

If a watchdog driver tells the framework that the device is running, the framework takes care of feeding the watchdog until userspace opens the device. If the userspace application which is supposed to do that never comes up properly, the watchdog is fed indefinitely by the kernel. This can be

[PATCH v3 2/2] watchdog: introduce CONFIG_WATCHDOG_OPEN_TIMEOUT

The watchdog framework takes care of feeding a hardware watchdog until userspace opens /dev/watchdogN. If that never happens for some reason (buggy init script, corrupt root filesystem or whatnot) but the kernel itself is fine, the machine stays up indefinitely. This patch allows setting an upper

[PATCH v3 2/2] watchdog: introduce CONFIG_WATCHDOG_OPEN_TIMEOUT

The watchdog framework takes care of feeding a hardware watchdog until userspace opens /dev/watchdogN. If that never happens for some reason (buggy init script, corrupt root filesystem or whatnot) but the kernel itself is fine, the machine stays up indefinitely. This patch allows setting an upper

[PATCH] doc: Explain light-handed markup preference a bit better

We already had a super-short blurb, but worth extending it I think: We're still pretty far away from anything like a consensus, but there's clearly a lot of people who prefer an as-light as possible approach to converting existing .txt files to .rst. Make sure this is properly taken into account

[PATCH] doc: Explain light-handed markup preference a bit better

We already had a super-short blurb, but worth extending it I think: We're still pretty far away from anything like a consensus, but there's clearly a lot of people who prefer an as-light as possible approach to converting existing .txt files to .rst. Make sure this is properly taken into account

[GIT PULL] power-supply changes for 4.10

Hi Linus, Not much this time around, since I was quite busy this merge window. I still have quite a few unreviewed patches, so expect a bigger pull request for v4.11 (and probably a second one for v4.10 with fixes that I missed so far). Here is the usual output of request-pull, that looks fine to

[GIT PULL] power-supply changes for 4.10

Hi Linus, Not much this time around, since I was quite busy this merge window. I still have quite a few unreviewed patches, so expect a bigger pull request for v4.11 (and probably a second one for v4.10 with fixes that I missed so far). Here is the usual output of request-pull, that looks fine to

[PATCH] drivers: staging: comedi: fix function prototypes

Add names of parameters to function prototypes in comedi PCI. Checkpatch reports now no errors. Signed-off-by: Piotr Gregor --- drivers/staging/comedi/comedi_pci.h | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git

[PATCH] drivers: staging: comedi: fix function prototypes

Add names of parameters to function prototypes in comedi PCI. Checkpatch reports now no errors. Signed-off-by: Piotr Gregor --- drivers/staging/comedi/comedi_pci.h | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/staging/comedi/comedi_pci.h

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi Hannes, Thanks for the feedback. > __packed not only removes all padding of the struct but also changes the > alignment assumptions for the whole struct itself. The rule, the struct > is aligned by its maximum alignment of a member is no longer true. That > said, the code accessing this

Re: [V9fs-developer] [Patch] 9p: fix a potential acl leak

On Tue, 13 Dec 2016 10:33:34 -0800 Cong Wang wrote: > posix_acl_update_mode() could possibly clear 'acl', if so > we leak the memory pointed by 'acl'. Save this pointer > before calling posix_acl_update_mode() and release the memory > if 'acl' really gets cleared. > >

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi Hannes, Thanks for the feedback. > __packed not only removes all padding of the struct but also changes the > alignment assumptions for the whole struct itself. The rule, the struct > is aligned by its maximum alignment of a member is no longer true. That > said, the code accessing this

Re: [V9fs-developer] [Patch] 9p: fix a potential acl leak

On Tue, 13 Dec 2016 10:33:34 -0800 Cong Wang wrote: > posix_acl_update_mode() could possibly clear 'acl', if so > we leak the memory pointed by 'acl'. Save this pointer > before calling posix_acl_update_mode() and release the memory > if 'acl' really gets cleared. > > Reported-by: Mark Salyzyn

Re: [PATCH v2 2/4] KVM: x86: replace kvm_apic_id with kvm_{x,x2}apic_id

2016-12-14 13:39+0100, David Hildenbrand: > Am 13.12.2016 um 17:29 schrieb Radim Krčmář: >> There were three calls sites: >> - recalculate_apic_map and kvm_apic_match_physical_addr, where it would >>only complicate implementation of x2APIC hotplug; >> - in apic_debug, where it was still

Re: [PATCH v2 2/4] KVM: x86: replace kvm_apic_id with kvm_{x,x2}apic_id

2016-12-14 13:39+0100, David Hildenbrand: > Am 13.12.2016 um 17:29 schrieb Radim Krčmář: >> There were three calls sites: >> - recalculate_apic_map and kvm_apic_match_physical_addr, where it would >>only complicate implementation of x2APIC hotplug; >> - in apic_debug, where it was still

[PATCH] x86/platform/intel-mid: switch MPU3050 driver to IIO

The Intel Mid goes in and creates a I2C device for the MPU3050 if the input driver for MPU-3050 is activated. As of commit 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") there is a proper and fully featured IIO driver for this device, so deprecate the use of the incomplete input

[PATCH] x86/platform/intel-mid: switch MPU3050 driver to IIO

The Intel Mid goes in and creates a I2C device for the MPU3050 if the input driver for MPU-3050 is activated. As of commit 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") there is a proper and fully featured IIO driver for this device, so deprecate the use of the incomplete input

<    8   9   10   11   12   13   14   15   16   17   >