Re: [PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

Hi, Baolin Wang writes: >> Also note that the usb_endpoint_xfer_isoc() call on line 2067 of >> gadget.c (as in my testing/next from today) won't even get executed, so >> we're safe there. > > Never will be executed? then we can remove the > usb_endpoint_xfer_isoc()

Re: [PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

Hi, Baolin Wang writes: >> Also note that the usb_endpoint_xfer_isoc() call on line 2067 of >> gadget.c (as in my testing/next from today) won't even get executed, so >> we're safe there. > > Never will be executed? then we can remove the > usb_endpoint_xfer_isoc() (line 2025) at risk? > >

Re: [PATCH v5 00/11] Add HW throttle for Tegra soctherm

Hi, Does there have any comments on this series? Let me know if someone has suggestions. Thanks. Wei. On 05/11/2016 06:20 PM, Wei Ni wrote: > This series add following functions for Tegra soctherm: > 1. add HW throttle function. > 2. enable soctherm node for Tegra124, Tegra132, Tegra210, and >

Re: [PATCH v5 00/11] Add HW throttle for Tegra soctherm

Hi, Does there have any comments on this series? Let me know if someone has suggestions. Thanks. Wei. On 05/11/2016 06:20 PM, Wei Ni wrote: > This series add following functions for Tegra soctherm: > 1. add HW throttle function. > 2. enable soctherm node for Tegra124, Tegra132, Tegra210, and >

[RFC PATCH 2/2] firmware: scpi: Switch scpi drivers to use new Framework calls

Update the include/linux/scpi_protocol.h with the new registry calls. Switch following drivers to use the new SCPI registry layer : - drivers/clk/clk-scpi.c - drivers/cpufreq/scpi-cpufreq.c - drivers/hwmon/scpi-hwmon.c And finally switch drivers/firmware/arm_scpi.c to use

[RFC PATCH 1/2] firmware: Add a SCPI framework to handle multiple vendors implementation

Add a thin "register" interface for SCPI driver in order to register their ops along their node. Since nodes using the SCPI ops are currently sub-nodes, does not implement phandle xlate stuff. Signed-off-by: Neil Armstrong --- drivers/firmware/Makefile | 1 +

[RFC PATCH 2/2] firmware: scpi: Switch scpi drivers to use new Framework calls

Update the include/linux/scpi_protocol.h with the new registry calls. Switch following drivers to use the new SCPI registry layer : - drivers/clk/clk-scpi.c - drivers/cpufreq/scpi-cpufreq.c - drivers/hwmon/scpi-hwmon.c And finally switch drivers/firmware/arm_scpi.c to use

[RFC PATCH 1/2] firmware: Add a SCPI framework to handle multiple vendors implementation

Add a thin "register" interface for SCPI driver in order to register their ops along their node. Since nodes using the SCPI ops are currently sub-nodes, does not implement phandle xlate stuff. Signed-off-by: Neil Armstrong --- drivers/firmware/Makefile | 1 + drivers/firmware/scpi.c | 110

[RFC PATCH 0/2] scpi: Add SCPI framework to handle vendors variants

Since the current SCPI implementation, based on [0]: - is (at leat) JUNO specific - does not specify a strong "standard" - does not specify a strong MHU interface specification SoC vendors could implement a variant with slight changes in message indexes, new messages types, different messages

[RFC PATCH 0/2] scpi: Add SCPI framework to handle vendors variants

Since the current SCPI implementation, based on [0]: - is (at leat) JUNO specific - does not specify a strong "standard" - does not specify a strong MHU interface specification SoC vendors could implement a variant with slight changes in message indexes, new messages types, different messages

[PATCH] hwrng: stm32: fix maybe uninitialized variable warning

This patch fixes the following warning: drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read': drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used uninitialized in this function Reported-by: Sudip Mukherjee

[PATCH] hwrng: stm32: fix maybe uninitialized variable warning

This patch fixes the following warning: drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read': drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used uninitialized in this function Reported-by: Sudip Mukherjee Suggested-by: Arnd

Re: [PATCH v2 0/10] Add RK3399 eDP support and fix some bugs to analogix_dp driver.

Hi Javier, On 05/24/2016 01:01 PM, Yakir Yang wrote: Hi all, This series have been posted about one month, still no comments, help here :( This series works rightly on Rockchip platform, and most of them haven't touch the common analogix_dp driver (except for the hotplug fixed). So i guess

Re: [PATCH v2 0/10] Add RK3399 eDP support and fix some bugs to analogix_dp driver.

Hi Javier, On 05/24/2016 01:01 PM, Yakir Yang wrote: Hi all, This series have been posted about one month, still no comments, help here :( This series works rightly on Rockchip platform, and most of them haven't touch the common analogix_dp driver (except for the hotplug fixed). So i guess

Re: [PATCH 36/54] MAINTAINERS: Add file patterns for pinctrl device tree bindings

On Sun, May 22, 2016 at 11:06 AM, Geert Uytterhoeven wrote: > Submitters of device tree binding documentation may forget to CC > the subsystem maintainer if this is missing. > > Signed-off-by: Geert Uytterhoeven > Cc: Linus Walleij

Re: [PATCH 36/54] MAINTAINERS: Add file patterns for pinctrl device tree bindings

On Sun, May 22, 2016 at 11:06 AM, Geert Uytterhoeven wrote: > Submitters of device tree binding documentation may forget to CC > the subsystem maintainer if this is missing. > > Signed-off-by: Geert Uytterhoeven > Cc: Linus Walleij > Cc: linux-g...@vger.kernel.org > --- > Please apply this

[PATCH v2] efi: fix for_each_efi_memory_desc_in_map() for empty memmaps

Commit 78ce248faa3c ("efi: Iterate over efi.memmap in for_each_efi_memory_desc()") introduced a regression for systems booted with 'noefi' kernel option. In particular, I observe early kernel hang in efi_find_mirror() on for_each_efi_memory_desc() call. As we don't have efi memmap we enter this

[PATCH v2] efi: fix for_each_efi_memory_desc_in_map() for empty memmaps

Commit 78ce248faa3c ("efi: Iterate over efi.memmap in for_each_efi_memory_desc()") introduced a regression for systems booted with 'noefi' kernel option. In particular, I observe early kernel hang in efi_find_mirror() on for_each_efi_memory_desc() call. As we don't have efi memmap we enter this

Re: [RFC PATCH] drivers/pinctrl: Add pinctrl-ast2400

On Wed, May 25, 2016 at 7:22 AM, Andrew Jeffery wrote: > [Me] >> > +#define A4 2 >> > +SSSF_PIN_DECL(A4, GPIOA2, TIMER3, FUNC_DESC_SET(SCU80, 2)); >> > + >> > +FUNC_EXPR_DECL_SINGLE(SD1, FUNC_DESC_SET(SCU90, 0)); >> > + >> > +FUNC_EXPR_DECL_SINGLE(I2C10, FUNC_DESC_SET(SCU90,

Re: [RFC PATCH] drivers/pinctrl: Add pinctrl-ast2400

On Wed, May 25, 2016 at 7:22 AM, Andrew Jeffery wrote: > [Me] >> > +#define A4 2 >> > +SSSF_PIN_DECL(A4, GPIOA2, TIMER3, FUNC_DESC_SET(SCU80, 2)); >> > + >> > +FUNC_EXPR_DECL_SINGLE(SD1, FUNC_DESC_SET(SCU90, 0)); >> > + >> > +FUNC_EXPR_DECL_SINGLE(I2C10, FUNC_DESC_SET(SCU90, 23)); >> > + >> >

Re: [PATCH percpu/for-4.7-fixes 1/2] percpu: fix synchronization between chunk->map_extend_work and chunk destruction

On 05/25/2016 05:44 PM, Tejun Heo wrote: Atomic allocations can trigger async map extensions which is serviced by chunk->map_extend_work. pcpu_balance_work which is responsible for destroying idle chunks wasn't synchronizing properly against chunk->map_extend_work and may end up freeing the

Re: [PATCH percpu/for-4.7-fixes 1/2] percpu: fix synchronization between chunk->map_extend_work and chunk destruction

On 05/25/2016 05:44 PM, Tejun Heo wrote: Atomic allocations can trigger async map extensions which is serviced by chunk->map_extend_work. pcpu_balance_work which is responsible for destroying idle chunks wasn't synchronizing properly against chunk->map_extend_work and may end up freeing the

[PATCH 1/2] sched/fair: Clean up attach_entity_load_avg()

attach_entity_load_avg() is called (indirectly) from: - switched_to_fair(): switch between classes to fair - task_move_group_fair(): move between task groups - enqueue_entity_load_avg(): enqueue entity Only in switched_to_fair() is it possible that the task's last_update_time is not 0 and

[PATCH 1/2] sched/fair: Clean up attach_entity_load_avg()

attach_entity_load_avg() is called (indirectly) from: - switched_to_fair(): switch between classes to fair - task_move_group_fair(): move between task groups - enqueue_entity_load_avg(): enqueue entity Only in switched_to_fair() is it possible that the task's last_update_time is not 0 and

[PATCH 2/2] sched/fair: Skip detach and attach load avgs for new group task

Vincent reported that the first task to a new task group's cfs_rq will be attached in attach_task_cfs_rq() and once more when it is enqueued (see https://lkml.org/lkml/2016/5/25/388). Actually, it is worse, attach_task_cfs_rq() is called for new task even way before

Re: fsl-dcu not works on latest "drm-next"

On Thursday 26 May 2016 08:23:42, Meng Yi wrote: > Hi Mark, > > > You've not specifically described the problem here - what are the > > endiannesses of both the CPU and the device you're talking to? What > > specifically is the endianess problem you are seeing, what are you seeing > > and what

[PATCH 0/2] sched/fair: Skip sched avgs update for new group task before wake_up_new_task()

Hi Peter, Vincent reported this problem, which is there for a while. The first patch is cleanup as well as paving the way to the fix. Thanks, Yuyang --- Yuyang Du (2): sched/fair: Clean up attach_entity_load_avg() sched/fair: Skip detach and attach load avgs for new group task

[PATCH 2/2] sched/fair: Skip detach and attach load avgs for new group task

Vincent reported that the first task to a new task group's cfs_rq will be attached in attach_task_cfs_rq() and once more when it is enqueued (see https://lkml.org/lkml/2016/5/25/388). Actually, it is worse, attach_task_cfs_rq() is called for new task even way before

Re: fsl-dcu not works on latest "drm-next"

On Thursday 26 May 2016 08:23:42, Meng Yi wrote: > Hi Mark, > > > You've not specifically described the problem here - what are the > > endiannesses of both the CPU and the device you're talking to? What > > specifically is the endianess problem you are seeing, what are you seeing > > and what

[PATCH 0/2] sched/fair: Skip sched avgs update for new group task before wake_up_new_task()

Hi Peter, Vincent reported this problem, which is there for a while. The first patch is cleanup as well as paving the way to the fix. Thanks, Yuyang --- Yuyang Du (2): sched/fair: Clean up attach_entity_load_avg() sched/fair: Skip detach and attach load avgs for new group task

Re: fsl-dcu not works on latest "drm-next"

On Thursday 26 May 2016 08:18:30, Meng Yi wrote: > Hi Alexander, > > > From your backtrace I guess wait_event_timeout is called in some atomic > > context (might_sleep(); is called inside wait_event_timeout). This has > > nothing to do with regmap. > > Here is my view of point: > Since IRQ setup

[PATCH v7] platform:x86: Add PMC Driver for Intel Core SoC

This patch adds the Power Management Controller driver as a PCI driver for Intel Core SoC architecture. This driver can utilize debugging capabilities and supported features as exposed by the Power Management Controller. Please refer to the below specification for more details on PMC features.

Re: fsl-dcu not works on latest "drm-next"

On Thursday 26 May 2016 08:18:30, Meng Yi wrote: > Hi Alexander, > > > From your backtrace I guess wait_event_timeout is called in some atomic > > context (might_sleep(); is called inside wait_event_timeout). This has > > nothing to do with regmap. > > Here is my view of point: > Since IRQ setup

[PATCH v7] platform:x86: Add PMC Driver for Intel Core SoC

This patch adds the Power Management Controller driver as a PCI driver for Intel Core SoC architecture. This driver can utilize debugging capabilities and supported features as exposed by the Power Management Controller. Please refer to the below specification for more details on PMC features.

Re: ARM: dts: exynos: Add MFC memory banks for Peach boards

Hi Javier, On Thursday 26 May 2016 01:15 PM, Javier Martinez Canillas wrote: > [adding Kevin and Sjoerd who also noticed issues with this patch] > > Hi Pankaj, > > On 05/25/2016 11:43 PM, pankaj.dubey wrote: >> Hi Javier, >> >> On Wednesday 25 May 2016 08:32 PM, Javier Martinez Canillas wrote:

Re: ARM: dts: exynos: Add MFC memory banks for Peach boards

Hi Javier, On Thursday 26 May 2016 01:15 PM, Javier Martinez Canillas wrote: > [adding Kevin and Sjoerd who also noticed issues with this patch] > > Hi Pankaj, > > On 05/25/2016 11:43 PM, pankaj.dubey wrote: >> Hi Javier, >> >> On Wednesday 25 May 2016 08:32 PM, Javier Martinez Canillas wrote:

Re: [PATCH] pinctrl: samsung: Suppress unbinding to prevent theoretical attacks

On Tue, May 17, 2016 at 8:02 AM, Krzysztof Kozlowski wrote: > Although unbinding a pinctrl driver requires root privileges but it > still might be used theoretically in certain attacks (by triggering NULL > pointer exception or memory corruption). Patch applied with

Re: [PATCH] pinctrl: samsung: Suppress unbinding to prevent theoretical attacks

On Tue, May 17, 2016 at 8:02 AM, Krzysztof Kozlowski wrote: > Although unbinding a pinctrl driver requires root privileges but it > still might be used theoretically in certain attacks (by triggering NULL > pointer exception or memory corruption). Patch applied with Javier's review tag. I

Re: [PATCH v3] gpio: UniPhier: add driver for UniPhier GPIO controller

On Fri, May 20, 2016 at 6:30 AM, Masahiro Yamada wrote: > So, I'd like to know the recommended driver coding style > based on 4.7-rc1. Sure, best is to look at other recently added drivers I guess. > Diving into the git-log so far, I came up the following list: >

Re: [PATCH v3] gpio: UniPhier: add driver for UniPhier GPIO controller

On Fri, May 20, 2016 at 6:30 AM, Masahiro Yamada wrote: > So, I'd like to know the recommended driver coding style > based on 4.7-rc1. Sure, best is to look at other recently added drivers I guess. > Diving into the git-log so far, I came up the following list: > > [1] The "dev" member of

Re: [RESEND PATCH v2] ASoC: rockchip: Add machine driver for MAX98357A/RT5514/DA7219

Hi Rob, On 2016年05月26日 01:32, Rob Herring wrote: On Tue, May 24, 2016 at 09:36:14AM +0800, Xing Zheng wrote: There are multi codec devices on the RK3399 platform, we can use this patch support and control these codecs. Signed-off-by: Xing Zheng --- Changes in v2: -

Re: [RESEND PATCH v2] ASoC: rockchip: Add machine driver for MAX98357A/RT5514/DA7219

Hi Rob, On 2016年05月26日 01:32, Rob Herring wrote: On Tue, May 24, 2016 at 09:36:14AM +0800, Xing Zheng wrote: There are multi codec devices on the RK3399 platform, we can use this patch support and control these codecs. Signed-off-by: Xing Zheng --- Changes in v2: - use the FS 256 to set

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Thu, May 12, 2016 at 8:42 PM, Uwe Kleine-König wrote: > [added Linus Walleij to Cc, there is a question for you/him below] (...) >> +void mdio_device_reset(struct mdio_device *mdiodev, int value) >> +{ >> + if (mdiodev->reset) >> +

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Thu, May 12, 2016 at 8:42 PM, Uwe Kleine-König wrote: > [added Linus Walleij to Cc, there is a question for you/him below] (...) >> +void mdio_device_reset(struct mdio_device *mdiodev, int value) >> +{ >> + if (mdiodev->reset) >> + gpiod_set_value(mdiodev->reset, value); > >

Re: [PATCH v2] sched: fix first task of a task group is attached twice

On 26 May 2016 at 02:40, Yuyang Du wrote: > On Thu, May 26, 2016 at 10:26:54AM +0200, Vincent Guittot wrote: >> On 26 May 2016 at 00:38, Yuyang Du wrote: >> > On Wed, May 25, 2016 at 05:01:11PM +0200, Vincent Guittot wrote: >> >> The

Re: [PATCH v2] sched: fix first task of a task group is attached twice

On 26 May 2016 at 02:40, Yuyang Du wrote: > On Thu, May 26, 2016 at 10:26:54AM +0200, Vincent Guittot wrote: >> On 26 May 2016 at 00:38, Yuyang Du wrote: >> > On Wed, May 25, 2016 at 05:01:11PM +0200, Vincent Guittot wrote: >> >> The cfs_rq->avg.last_update_time is initialize to 0 with the main

RE: [PATCH 3.19.y-ckt 21/40] net/mlx4_en: Fix endianness bug in IPV6 csum calculation

Hi Kamal, It's just a nit, but we would like to keep the patches in the same form as in upstream when possible, i.e. without the line-break here. Thanks, Tariq Toukan -Original Message- From: Kamal Mostafa [mailto:ka...@canonical.com] Sent: Wednesday, May 25, 2016 8:30 PM To:

RE: [PATCH 3.19.y-ckt 21/40] net/mlx4_en: Fix endianness bug in IPV6 csum calculation

Hi Kamal, It's just a nit, but we would like to keep the patches in the same form as in upstream when possible, i.e. without the line-break here. Thanks, Tariq Toukan -Original Message- From: Kamal Mostafa [mailto:ka...@canonical.com] Sent: Wednesday, May 25, 2016 8:30 PM To:

Re: [PATCH] soc/tegra: pmc: Fix "scheduling while atomic"

On 25/05/16 19:51, Dmitry Osipenko wrote: > On 25.05.2016 18:09, Jon Hunter wrote: ... >> If you are able to reproduce this on v3.18, then it would be good if you >> could trace the CCF calls around this WARNING to see what is causing the >> contention. > > I managed to reproduce it with some

Re: [PATCH 1/2] gpio: pca953x: Add support for TI PCA9536

On Thu, May 19, 2016 at 8:47 AM, Vignesh R wrote: > TI PCA9536 is 4-Bit I2C GPIO expander without interrupt support[1]. > Add support for the same. > > [1] TRM: http://www.ti.com/lit/ds/symlink/pca9536.pdf > > Signed-off-by: Vignesh R Patch applied with Rob's

Re: [PATCH] soc/tegra: pmc: Fix "scheduling while atomic"

On 25/05/16 19:51, Dmitry Osipenko wrote: > On 25.05.2016 18:09, Jon Hunter wrote: ... >> If you are able to reproduce this on v3.18, then it would be good if you >> could trace the CCF calls around this WARNING to see what is causing the >> contention. > > I managed to reproduce it with some

Re: [PATCH 1/2] gpio: pca953x: Add support for TI PCA9536

On Thu, May 19, 2016 at 8:47 AM, Vignesh R wrote: > TI PCA9536 is 4-Bit I2C GPIO expander without interrupt support[1]. > Add support for the same. > > [1] TRM: http://www.ti.com/lit/ds/symlink/pca9536.pdf > > Signed-off-by: Vignesh R Patch applied with Rob's ACK. Yours, Linus Walleij

Re: [PATCH 2/2] ARM: dts: am335x-icev2: Add DT node for TI PCA9536

On Thu, May 19, 2016 at 8:47 AM, Vignesh R wrote: > AM335x ICE board has a TI PCA9536 chip connected to I2C0 at address > 0x41. Add DT entry for the same. > > Signed-off-by: Vignesh R Acked-by: Linus Walleij Pls take this through

Re: [PATCH 2/2] ARM: dts: am335x-icev2: Add DT node for TI PCA9536

On Thu, May 19, 2016 at 8:47 AM, Vignesh R wrote: > AM335x ICE board has a TI PCA9536 chip connected to I2C0 at address > 0x41. Add DT entry for the same. > > Signed-off-by: Vignesh R Acked-by: Linus Walleij Pls take this through the ARM SoC TI git tree. Yours, Linus Walleij

Re: [PATCH v2] net: alx: use custom skb allocator

On Wed, May 25, 2016 at 07:53:41PM -0400, David Miller wrote: > From: Feng Tang > Date: Wed, 25 May 2016 14:49:54 +0800 > > > This patch follows Eric Dumazet's commit 7b70176421 for Atheros > > atl1c driver to fix one exactly same bug in alx driver, that the > > network link

Re: [PATCH v2] net: alx: use custom skb allocator

On Wed, May 25, 2016 at 07:53:41PM -0400, David Miller wrote: > From: Feng Tang > Date: Wed, 25 May 2016 14:49:54 +0800 > > > This patch follows Eric Dumazet's commit 7b70176421 for Atheros > > atl1c driver to fix one exactly same bug in alx driver, that the > > network link will be lost in 1-5

Re: [PATCH 11/11] dt/bindings: Correct clk binding example for PIC32 gpio.

On Tue, May 17, 2016 at 7:06 AM, Purna Chandra Mandal wrote: > Update binding example based on new clock binding scheme. > [1] Documentation/devicetree/bindings/clock/microchip,pic32.txt > > Signed-off-by: Purna Chandra Mandal Patch

RE: fsl-dcu not works on latest "drm-next"

Hi Mark, > You've not specifically described the problem here - what are the endiannesses > of both the CPU and the device you're talking to? What specifically is the > endianess problem you are seeing, what are you seeing and what do you > expect to see? > The CPU is little endian and the

Re: [PATCH 11/11] dt/bindings: Correct clk binding example for PIC32 gpio.

On Tue, May 17, 2016 at 7:06 AM, Purna Chandra Mandal wrote: > Update binding example based on new clock binding scheme. > [1] Documentation/devicetree/bindings/clock/microchip,pic32.txt > > Signed-off-by: Purna Chandra Mandal Patch applied and squashed into the other pic32 patch with Rob's

RE: fsl-dcu not works on latest "drm-next"

Hi Mark, > You've not specifically described the problem here - what are the endiannesses > of both the CPU and the device you're talking to? What specifically is the > endianess problem you are seeing, what are you seeing and what do you > expect to see? > The CPU is little endian and the

Re: [PATCH v2] sched: fix first task of a task group is attached twice

On Thu, May 26, 2016 at 10:26:54AM +0200, Vincent Guittot wrote: > On 26 May 2016 at 00:38, Yuyang Du wrote: > > On Wed, May 25, 2016 at 05:01:11PM +0200, Vincent Guittot wrote: > >> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect > >> that the 1st

Re: [PATCH v2] sched: fix first task of a task group is attached twice

On Thu, May 26, 2016 at 10:26:54AM +0200, Vincent Guittot wrote: > On 26 May 2016 at 00:38, Yuyang Du wrote: > > On Wed, May 25, 2016 at 05:01:11PM +0200, Vincent Guittot wrote: > >> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect > >> that the 1st sched_entity that will

Re: [PATCH 07/11] dt/bindings: Correct clk binding example for PIC32 pinctrl

On Tue, May 17, 2016 at 7:05 AM, Purna Chandra Mandal wrote: > Update binding example based on new clock binding scheme. > [1] Documentation/devicetree/bindings/clock/microchip,pic32.txt > > Signed-off-by: Purna Chandra Mandal Patch

Re: [PATCH 07/11] dt/bindings: Correct clk binding example for PIC32 pinctrl

On Tue, May 17, 2016 at 7:05 AM, Purna Chandra Mandal wrote: > Update binding example based on new clock binding scheme. > [1] Documentation/devicetree/bindings/clock/microchip,pic32.txt > > Signed-off-by: Purna Chandra Mandal Patch applied to the pinctrl tree with Rob's ACK. Yours, Linus

Re: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

Hi, Leo Li writes: >>> On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set >>> to be able to do DMA allocations, so use the of_dma_configure() helper >>> to populate the dma properties and assign an appropriate dma_ops. >>> >>> Signed-off-by: Rajesh

Re: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

Hi, Leo Li writes: >>> On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set >>> to be able to do DMA allocations, so use the of_dma_configure() helper >>> to populate the dma properties and assign an appropriate dma_ops. >>> >>> Signed-off-by: Rajesh Bhagat >>> Reviewed-by:

[PATCH] watchdog: Add a device managed API for watchdog_register_device()

This helps in reducing code in .remove callbacks and sometimes dropping .remove callbacks entirely. Signed-off-by: Neil Armstrong --- Documentation/driver-model/devres.txt | 3 +++ drivers/watchdog/watchdog_core.c | 36 +++

[PATCH] watchdog: Add a device managed API for watchdog_register_device()

This helps in reducing code in .remove callbacks and sometimes dropping .remove callbacks entirely. Signed-off-by: Neil Armstrong --- Documentation/driver-model/devres.txt | 3 +++ drivers/watchdog/watchdog_core.c | 36 +++ include/linux/watchdog.h

[PATCH] mutex: Do not spin/queue before performing ww_mutex deadlock avoidance

The ww_mutex has the property of allowing the lock to detect and report when it may be used in deadlocking scenarios (to allow the caller to unwind its locks and avoid the deadlock). This detection needs to be performed before we queue up for the spin, otherwise we wait on the osq_lock() for our

[PATCH] mutex: Do not spin/queue before performing ww_mutex deadlock avoidance

The ww_mutex has the property of allowing the lock to detect and report when it may be used in deadlocking scenarios (to allow the caller to unwind its locks and avoid the deadlock). This detection needs to be performed before we queue up for the spin, otherwise we wait on the osq_lock() for our

Re: [PATCH v2] sched: fix first task of a task group is attached twice

On 26 May 2016 at 00:38, Yuyang Du wrote: > On Wed, May 25, 2016 at 05:01:11PM +0200, Vincent Guittot wrote: >> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect >> that the 1st sched_entity that will be attached, will keep its >> last_update_time set

Re: [PATCH v2] sched: fix first task of a task group is attached twice

On 26 May 2016 at 00:38, Yuyang Du wrote: > On Wed, May 25, 2016 at 05:01:11PM +0200, Vincent Guittot wrote: >> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect >> that the 1st sched_entity that will be attached, will keep its >> last_update_time set to 0 and will attached

Re: [PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

Hi, On 26 May 2016 at 15:48, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> Hi Felipe, >> >> On 26 May 2016 at 14:22, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Baolin Wang writes: When handling the

Re: [PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

Hi, On 26 May 2016 at 15:48, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> Hi Felipe, >> >> On 26 May 2016 at 14:22, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Baolin Wang writes: When handling the endpoint interrupt handler, it maybe disable the endpoint from another core

Re: [PATCH] devicetree - document using aliases to set spi bus number.

On Wed, May 25, 2016 at 8:44 PM, Rob Herring wrote: > On Tue, May 24, 2016 at 06:41:41PM +0100, Mark Rutland wrote: >> On Tue, May 24, 2016 at 06:39:20PM +0200, Christer Weinigel wrote: >> > Document how to use devicetree aliases to assign a stable >> > bus number to a spi bus.

Re: [PATCH] devicetree - document using aliases to set spi bus number.

On Wed, May 25, 2016 at 8:44 PM, Rob Herring wrote: > On Tue, May 24, 2016 at 06:41:41PM +0100, Mark Rutland wrote: >> On Tue, May 24, 2016 at 06:39:20PM +0200, Christer Weinigel wrote: >> > Document how to use devicetree aliases to assign a stable >> > bus number to a spi bus. >> > >> >

RE: fsl-dcu not works on latest "drm-next"

Hi Alexander, > From your backtrace I guess wait_event_timeout is called in some atomic > context (might_sleep(); is called inside wait_event_timeout). This has nothing > to do with regmap. > Here is my view of point: Since IRQ setup codes using regmap, and which is not setup properly, so

RE: fsl-dcu not works on latest "drm-next"

Hi Alexander, > From your backtrace I guess wait_event_timeout is called in some atomic > context (might_sleep(); is called inside wait_event_timeout). This has nothing > to do with regmap. > Here is my view of point: Since IRQ setup codes using regmap, and which is not setup properly, so

[GIT PULL] MMC fixes for v.4.7 rc1

Hi Linus, Here are some mmc fixes intended for v4.7 rc1. They are based on a commit earlier in the merge window and have been tested in linux-next for a while. Details are as usual found in the signed tag. Please pull this in! Kind regards Ulf Hansson The following changes since commit

[GIT PULL] MMC fixes for v.4.7 rc1

Hi Linus, Here are some mmc fixes intended for v4.7 rc1. They are based on a commit earlier in the merge window and have been tested in linux-next for a while. Details are as usual found in the signed tag. Please pull this in! Kind regards Ulf Hansson The following changes since commit

Re: [PATCH V3] brcmfmac: print error if p2p_ifadd firmware command fails

On 26-5-2016 0:44, Rafał Miłecki wrote: > This is helpful for debugging, without this all I was getting from "iw" > command on device with BCM43602 was: >> command failed: Too many open files in system (-23) > > Signed-off-by: Rafał Miłecki > --- > V2: s/in/if/ in commit

Re: [PATCH V3] brcmfmac: print error if p2p_ifadd firmware command fails

On 26-5-2016 0:44, Rafał Miłecki wrote: > This is helpful for debugging, without this all I was getting from "iw" > command on device with BCM43602 was: >> command failed: Too many open files in system (-23) > > Signed-off-by: Rafał Miłecki > --- > V2: s/in/if/ in commit message > V3: Add one

Re: DRM DMA Engine

On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote: > Hi all, > > Currently I am trying to develop a DRM driver that will use > Xilinx VDMA to transfer video data to a HDMI TX Phy and I am > facing a difficulty regarding the understanding of the DRM DMA > Engine. I looked at several

Re: DRM DMA Engine

On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote: > Hi all, > > Currently I am trying to develop a DRM driver that will use > Xilinx VDMA to transfer video data to a HDMI TX Phy and I am > facing a difficulty regarding the understanding of the DRM DMA > Engine. I looked at several

[PATCH 3/5] i2c: designware: Enable fast mode plus

This patch enabled fast mode plus. The fast mode plus and fast speed share the same HCNT and LCNT register. So, the fast mode plus will only run when the HCNT and LCNT value is provided. Else, it will run at fast speed as default. Signed-off-by: Weifeng Voon ---

[PATCH 3/5] i2c: designware: Enable fast mode plus

This patch enabled fast mode plus. The fast mode plus and fast speed share the same HCNT and LCNT register. So, the fast mode plus will only run when the HCNT and LCNT value is provided. Else, it will run at fast speed as default. Signed-off-by: Weifeng Voon ---

Re: [PATCH v3] KVM: halt-polling: poll if emulated lapic timer will fire soon

2016-05-24 2:01 GMT+08:00 David Matlack : > On Sun, May 22, 2016 at 5:42 PM, Wanpeng Li wrote: >> From: Wanpeng Li > > I'm ok with this patch, but I'd like to better understand the target > workloads. What type of workloads do you

Re: [PATCH v3] KVM: halt-polling: poll if emulated lapic timer will fire soon

2016-05-24 2:01 GMT+08:00 David Matlack : > On Sun, May 22, 2016 at 5:42 PM, Wanpeng Li wrote: >> From: Wanpeng Li > > I'm ok with this patch, but I'd like to better understand the target > workloads. What type of workloads do you expect to benefit from this? > In addition, as Paolo great

[PATCH 1/5] i2c: designware: Move clk_freq into struct dw_i2c_dev

I2c designware controller operate speed is configured in the register IC_CON. Previously the operate speed is determined by a local variable clk_freq. This patch will move the local variable clk_freq into struct dw_i2c_dev. This change will ease the set and get of the clk_freq. Signed-off-by:

[PATCH 1/5] i2c: designware: Move clk_freq into struct dw_i2c_dev

I2c designware controller operate speed is configured in the register IC_CON. Previously the operate speed is determined by a local variable clk_freq. This patch will move the local variable clk_freq into struct dw_i2c_dev. This change will ease the set and get of the clk_freq. Signed-off-by:

[PATCH 4/5] i2c: designware: set the common config before the if else

DW_IC_CON_MASTER, DW_IC_CON_SLAVE_DISABLE and DW_IC_CON_RESTART_EN are common config that need to be set for i2c designware master. So, configure it first without having to repeat inside the if else. Signed-off-by: Weifeng Voon ---

[PATCH 4/5] i2c: designware: set the common config before the if else

DW_IC_CON_MASTER, DW_IC_CON_SLAVE_DISABLE and DW_IC_CON_RESTART_EN are common config that need to be set for i2c designware master. So, configure it first without having to repeat inside the if else. Signed-off-by: Weifeng Voon --- drivers/i2c/busses/i2c-designware-platdrv.c | 10 ++ 1

Re: [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem

Hi Moritz, On Wed, 25 May 2016 14:26:46 -0700 Moritz Fischer wrote: > This commit adds documentation describing the bindings for > exposing mtd flash otp regions as nvmem providers via devicetree. > > Signed-off-by: Moritz Fischer > --- >

Re: [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem

Hi Moritz, On Wed, 25 May 2016 14:26:46 -0700 Moritz Fischer wrote: > This commit adds documentation describing the bindings for > exposing mtd flash otp regions as nvmem providers via devicetree. > > Signed-off-by: Moritz Fischer > --- > .../devicetree/bindings/mtd/otp-nvmem.txt |

Re: [PATCH v3 0/6] Introduce ZONE_CMA

On Thu, May 26, 2016 at 02:22:22PM +0800, js1...@gmail.com wrote: > From: Joonsoo Kim Hi Joonsoo, Nice work! > > Hello, > > Changes from v2 > o Rebase on next-20160525 > o No other changes except following description > > There was a discussion with Mel [1] after

[PATCH 5/5] i2c: designware: Enable high speed mode

This patch enabled high speed mode. High speed mode can be turn on by setting the clk_freq to 340. High speed HCNT and LCNT are needed as there is no default value provided. Signed-off-by: Weifeng Voon --- drivers/i2c/busses/i2c-designware-core.c| 26

Re: [PATCH v3 0/6] Introduce ZONE_CMA

On Thu, May 26, 2016 at 02:22:22PM +0800, js1...@gmail.com wrote: > From: Joonsoo Kim Hi Joonsoo, Nice work! > > Hello, > > Changes from v2 > o Rebase on next-20160525 > o No other changes except following description > > There was a discussion with Mel [1] after LSF/MM 2016. I could

[PATCH 5/5] i2c: designware: Enable high speed mode

This patch enabled high speed mode. High speed mode can be turn on by setting the clk_freq to 340. High speed HCNT and LCNT are needed as there is no default value provided. Signed-off-by: Weifeng Voon --- drivers/i2c/busses/i2c-designware-core.c| 26 +-

[PATCH 0/5] i2c: designware: Enable fast mode plus and high speed

Enabled fast mode plus and high speed which supported by APL SoC. Weifeng Voon (5): i2c: designware: Move clk_freq into struct dw_i2c_dev i2c: designware: get fast plus and high speed *CNT configuration i2c: designware: Enable fast mode plus i2c: designware: set the common config before

[PATCH 0/5] i2c: designware: Enable fast mode plus and high speed

Enabled fast mode plus and high speed which supported by APL SoC. Weifeng Voon (5): i2c: designware: Move clk_freq into struct dw_i2c_dev i2c: designware: get fast plus and high speed *CNT configuration i2c: designware: Enable fast mode plus i2c: designware: set the common config before

<    3   4   5   6   7   8   9   >