Re: [PATCH v7 0/8] Add PWM and IIO timer drivers for STM32

2017-01-05 15:49 GMT+01:00 Lee Jones : > On Thu, 05 Jan 2017, Benjamin Gaignard wrote: > >> version 7: >> - rebase on v4.10-rc2 >> - remove iio_device code from driver and keep only the trigger part >> >> version 6: >> - rename stm32-gptimer in stm32-timers. >> - change

Re: [PATCH v7 0/8] Add PWM and IIO timer drivers for STM32

2017-01-05 15:49 GMT+01:00 Lee Jones : > On Thu, 05 Jan 2017, Benjamin Gaignard wrote: > >> version 7: >> - rebase on v4.10-rc2 >> - remove iio_device code from driver and keep only the trigger part >> >> version 6: >> - rename stm32-gptimer in stm32-timers. >> - change "st,stm32-gptimer"

Re: INFO: rcu_sched self-detected stall on CPU

On Thu, Jan 05, 2017 at 07:32:45PM +0100, Enrico Mioso wrote: > Here is a new trace in the meanwhile: reporting it in case it proves useful. > Thank you very much for your help and patience. This looks quite similar to the last one. So there appears to be some consistency, which is reassuring.

Re: INFO: rcu_sched self-detected stall on CPU

On Wed, Jan 04, 2017 at 09:59:13PM +0100, Enrico Mioso wrote: > Here is my .config: I send it 'cause I wasn't able to determine if I selected > the right options. > Sorry for this long config: I don't know how to represent those infos more > efficiently. You have RCU tracing configured, which

Re: INFO: rcu_sched self-detected stall on CPU

On Thu, Jan 05, 2017 at 07:32:45PM +0100, Enrico Mioso wrote: > Here is a new trace in the meanwhile: reporting it in case it proves useful. > Thank you very much for your help and patience. This looks quite similar to the last one. So there appears to be some consistency, which is reassuring.

Re: INFO: rcu_sched self-detected stall on CPU

On Wed, Jan 04, 2017 at 09:59:13PM +0100, Enrico Mioso wrote: > Here is my .config: I send it 'cause I wasn't able to determine if I selected > the right options. > Sorry for this long config: I don't know how to represent those infos more > efficiently. You have RCU tracing configured, which

Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

Hi Andi, Thank for your reminder. I will refine the code based on your work. to have elegant code and easy error handling. Sean On Fri, 2017-01-06 at 12:43 +0900, Andi Shyti wrote: > Hi Sean, > > > + ir->rc = rc_allocate_device(); > > Yes, you should use devm_rc_allocate_device(...) > >

Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

Hi Andi, Thank for your reminder. I will refine the code based on your work. to have elegant code and easy error handling. Sean On Fri, 2017-01-06 at 12:43 +0900, Andi Shyti wrote: > Hi Sean, > > > + ir->rc = rc_allocate_device(); > > Yes, you should use devm_rc_allocate_device(...) > >

Re: [PATCH v3 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and ldo25

On Fri, Jan 06, 2017 at 12:59:05PM +0900, Jaechul Lee wrote: > From: Chanwoo Choi > > This patch fixes the wrong information of ldo23 and ldo25 on both TM2 and > TM2E. Please describe what is exactly wrong and how it affects the system/user. This is going to the fixes so

Re: [PATCH v3 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and ldo25

On Fri, Jan 06, 2017 at 12:59:05PM +0900, Jaechul Lee wrote: > From: Chanwoo Choi > > This patch fixes the wrong information of ldo23 and ldo25 on both TM2 and > TM2E. Please describe what is exactly wrong and how it affects the system/user. This is going to the fixes so it needs a good

Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

Hi Sean, Thanks for your effort for code reviewing. I add comments inline. On Thu, 2017-01-05 at 17:12 +, Sean Young wrote: > Hi Sean, > > Some review comments. > > On Fri, Jan 06, 2017 at 12:06:24AM +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > >

Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

Hi Sean, Thanks for your effort for code reviewing. I add comments inline. On Thu, 2017-01-05 at 17:12 +, Sean Young wrote: > Hi Sean, > > Some review comments. > > On Fri, Jan 06, 2017 at 12:06:24AM +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > This patch adds driver

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

On 17/1/6 15:03, Eric Ren wrote: On 01/06/2017 02:07 PM, Joseph Qi wrote: Hi Eric, On 17/1/5 23:31, Eric Ren wrote: We are in the situation that we have to avoid recursive cluster locking, but there is no way to check if a cluster lock has been taken by a precess already. Mostly, we can

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

On 17/1/6 15:03, Eric Ren wrote: On 01/06/2017 02:07 PM, Joseph Qi wrote: Hi Eric, On 17/1/5 23:31, Eric Ren wrote: We are in the situation that we have to avoid recursive cluster locking, but there is no way to check if a cluster lock has been taken by a precess already. Mostly, we can

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

On 17/1/6 14:56, Eric Ren wrote: On 01/06/2017 02:09 PM, Joseph Qi wrote: Hi Eric, On 17/1/5 23:31, Eric Ren wrote: Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") results in a deadlock, as the author "Tariq Saeed" realized shortly after the patch was merged. The

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

On 17/1/6 14:56, Eric Ren wrote: On 01/06/2017 02:09 PM, Joseph Qi wrote: Hi Eric, On 17/1/5 23:31, Eric Ren wrote: Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") results in a deadlock, as the author "Tariq Saeed" realized shortly after the patch was merged. The

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

On Tue 20 Dec 09:03 PST 2016, Vivek Gautam wrote: > diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c [..] > +static int qcom_qmp_phy_poweron(struct phy *phy) [..] > + > +err3: Rather than naming your labels errX, it's idiomatic to give them descriptive names, e.g.

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

On Tue 20 Dec 09:03 PST 2016, Vivek Gautam wrote: > diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c [..] > +static int qcom_qmp_phy_poweron(struct phy *phy) [..] > + > +err3: Rather than naming your labels errX, it's idiomatic to give them descriptive names, e.g.

[PATCH v2 01/2] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

'commit 2584cf83578c ("arch, drivers: don't include directly, use instead")' Make uniform definition of ioremap, ioremap_wc, ioremap_wt and ioremap_cache, tree-wide. Signed-off-by: Arvind Yadav --- drivers/staging/rtl8192u/r8192U.h | 2 +- 1 file changed, 1

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

On 01/06/2017 02:09 PM, Joseph Qi wrote: Hi Eric, On 17/1/5 23:31, Eric Ren wrote: Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") results in a deadlock, as the author "Tariq Saeed" realized shortly after the patch was merged. The discussion happened here

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

On 01/06/2017 02:09 PM, Joseph Qi wrote: Hi Eric, On 17/1/5 23:31, Eric Ren wrote: Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") results in a deadlock, as the author "Tariq Saeed" realized shortly after the patch was merged. The discussion happened here

[PATCH v2 01/2] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

'commit 2584cf83578c ("arch, drivers: don't include directly, use instead")' Make uniform definition of ioremap, ioremap_wc, ioremap_wt and ioremap_cache, tree-wide. Signed-off-by: Arvind Yadav --- drivers/staging/rtl8192u/r8192U.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH] drm/via: use get_user_pages_unlocked()

On 3 January 2017 at 20:23, Lorenzo Stoakes wrote: > Hi All, > > Just a gentle ping on this one :) > > Cheers, Lorenzo > > On 1 November 2016 at 19:43, Lorenzo Stoakes wrote: >> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code

Re: [PATCH v3 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other

On Fri, Jan 06, 2017 at 12:59:06PM +0900, Jaechul Lee wrote: > From: Andi Shyti > > Currently tm2e dts includes tm2 but there are some differences > between the two boards and tm2 has some properties that tm2e > doesn't have. > > That's why it's important to keep the two

Re: [PATCH] drm/via: use get_user_pages_unlocked()

On 3 January 2017 at 20:23, Lorenzo Stoakes wrote: > Hi All, > > Just a gentle ping on this one :) > > Cheers, Lorenzo > > On 1 November 2016 at 19:43, Lorenzo Stoakes wrote: >> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code >> and takes advantage of VM_FAULT_RETRY

Re: [PATCH v3 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other

On Fri, Jan 06, 2017 at 12:59:06PM +0900, Jaechul Lee wrote: > From: Andi Shyti > > Currently tm2e dts includes tm2 but there are some differences > between the two boards and tm2 has some properties that tm2e > doesn't have. > > That's why it's important to keep the two dts files independent >

Re: [RFC 1/1] Changes to support the driver for platform device registration

Hi Florian, On Thu, Jan 5, 2017 at 11:13 PM, Florian Fainelli wrote: > On 01/05/2017 12:23 AM, Raviteja Garimella wrote: >> -- Add OF based platform device registration >> -- Modify debug prints to be compatible with both pci and platform devices >> -- Add members to

Re: [RFC 1/1] Changes to support the driver for platform device registration

Hi Florian, On Thu, Jan 5, 2017 at 11:13 PM, Florian Fainelli wrote: > On 01/05/2017 12:23 AM, Raviteja Garimella wrote: >> -- Add OF based platform device registration >> -- Modify debug prints to be compatible with both pci and platform devices >> -- Add members to 'struct udc' for extcon and

[PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle

For the SoCs such as SAMA5D2 and SAMA5D4 which have L2 cache, flush the L2 cache first before entering the cpu idle. Signed-off-by: Wenyou Yang --- arch/arm/mach-at91/pm.c | 19 +++ drivers/memory/atmel-sdramc.c | 1 + 2 files changed, 20

[PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle

For the SoCs such as SAMA5D2 and SAMA5D4 which have L2 cache, flush the L2 cache first before entering the cpu idle. Signed-off-by: Wenyou Yang --- arch/arm/mach-at91/pm.c | 19 +++ drivers/memory/atmel-sdramc.c | 1 + 2 files changed, 20 insertions(+) diff --git

[PATCH 0/3] ARM: at91: fix cpuidle crash on SAMA5D4 Xplained board

Fix cpuidle crash on SAMA5D4 Xplained board when enable CONFIG_ARM_AT91_CPUIDLE. Because some SoCs have the L2 cache, we should flush the L2 cache before entering the cpu idle. Wenyou Yang (3): ARM: at91: flush the L2 cache before entering cpu idle doc: binding: add new compatible for

[PATCH 0/3] ARM: at91: fix cpuidle crash on SAMA5D4 Xplained board

Fix cpuidle crash on SAMA5D4 Xplained board when enable CONFIG_ARM_AT91_CPUIDLE. Because some SoCs have the L2 cache, we should flush the L2 cache before entering the cpu idle. Wenyou Yang (3): ARM: at91: flush the L2 cache before entering cpu idle doc: binding: add new compatible for

[PATCH 2/3] doc: binding: add new compatible for SDRAM/DDR Controller

Add the new compatible "atmel,sama5d4-ddramc" for the SDRAM/DDR Controller. Signed-off-by: Wenyou Yang --- Documentation/devicetree/bindings/arm/atmel-at91.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt

Re: [PATCH v4 07/11] pwm: imx: Provide atomic PWM support for i.MX PWMv2

On Thu, 5 Jan 2017 23:15:06 +0200 Andy Shevchenko wrote: > On Thu, Jan 5, 2017 at 11:19 AM, Boris Brezillon > wrote: > > On Thu, 5 Jan 2017 10:03:47 +0100 > > Lukasz Majewski wrote: > >> > /* > >> >

[PATCH 2/3] doc: binding: add new compatible for SDRAM/DDR Controller

Add the new compatible "atmel,sama5d4-ddramc" for the SDRAM/DDR Controller. Signed-off-by: Wenyou Yang --- Documentation/devicetree/bindings/arm/atmel-at91.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt

Re: [PATCH v4 07/11] pwm: imx: Provide atomic PWM support for i.MX PWMv2

On Thu, 5 Jan 2017 23:15:06 +0200 Andy Shevchenko wrote: > On Thu, Jan 5, 2017 at 11:19 AM, Boris Brezillon > wrote: > > On Thu, 5 Jan 2017 10:03:47 +0100 > > Lukasz Majewski wrote: > >> > /* > >> > * Wait for a free FIFO slot if the PWM is already > >> > enabled,

[PATCH 3/3] ARM: dts: at91: use "atmel,sama5d4-ddramc" for ramc

Use the new compatible "atmel,sama5d4-ddramc" for the ramc of SAMA5D2 and SAMA5D4. Signed-off-by: Wenyou Yang --- arch/arm/boot/dts/sama5d2.dtsi | 2 +- arch/arm/boot/dts/sama5d4.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 3/3] ARM: dts: at91: use "atmel,sama5d4-ddramc" for ramc

Use the new compatible "atmel,sama5d4-ddramc" for the ramc of SAMA5D2 and SAMA5D4. Signed-off-by: Wenyou Yang --- arch/arm/boot/dts/sama5d2.dtsi | 2 +- arch/arm/boot/dts/sama5d4.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/sama5d2.dtsi

Re: [PATCH v3 2/3] drivers: crypto: Add the Virtual Function driver for CPT

Hi Corentin, On 12/21/2016 07:31 PM, Corentin Labbe wrote: Hello I have some comment inline On Wed, Dec 21, 2016 at 11:56:12AM +, george.cher...@cavium.com wrote: From: George Cherian Enable the CPT VF driver. CPT is the cryptographic Accelaration Unit

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

On 01/06/2017 02:07 PM, Joseph Qi wrote: Hi Eric, On 17/1/5 23:31, Eric Ren wrote: We are in the situation that we have to avoid recursive cluster locking, but there is no way to check if a cluster lock has been taken by a precess already. Mostly, we can avoid recursive locking by writing

Re: [PATCH v3 2/3] drivers: crypto: Add the Virtual Function driver for CPT

Hi Corentin, On 12/21/2016 07:31 PM, Corentin Labbe wrote: Hello I have some comment inline On Wed, Dec 21, 2016 at 11:56:12AM +, george.cher...@cavium.com wrote: From: George Cherian Enable the CPT VF driver. CPT is the cryptographic Accelaration Unit typo acceleration will fix

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

On 01/06/2017 02:07 PM, Joseph Qi wrote: Hi Eric, On 17/1/5 23:31, Eric Ren wrote: We are in the situation that we have to avoid recursive cluster locking, but there is no way to check if a cluster lock has been taken by a precess already. Mostly, we can avoid recursive locking by writing

[PATCH] arm64: dts: exynos: Remove unsupported regulator-always-off property from TM2E

The regulator property 'regulator-always-off' is not documented and not supported. Signed-off-by: Krzysztof Kozlowski --- arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts

[PATCH] arm64: dts: exynos: Remove unsupported regulator-always-off property from TM2E

The regulator property 'regulator-always-off' is not documented and not supported. Signed-off-by: Krzysztof Kozlowski --- arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts

Re: [PATCH v2 01/2] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

On Fri, Jan 06, 2017 at 11:46:11AM +0530, Arvind Yadav wrote: > 'commit 2584cf83578c ("arch, drivers: don't > include directly, use instead")' > Make uniform definition of ioremap, ioremap_wc, ioremap_wt and > ioremap_cache, tree-wide. I still don't understand what this means at all, do you?

Re: [PATCH v2 01/2] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

On Fri, Jan 06, 2017 at 11:46:11AM +0530, Arvind Yadav wrote: > 'commit 2584cf83578c ("arch, drivers: don't > include directly, use instead")' > Make uniform definition of ioremap, ioremap_wc, ioremap_wt and > ioremap_cache, tree-wide. I still don't understand what this means at all, do you?

Re: [RFC 0/1] Platform driver support for 'amd5536udc' driver

Hi Arnd, On Fri, Jan 6, 2017 at 3:33 AM, Arnd Bergmann wrote: > On Thursday, January 5, 2017 1:53:16 PM CET Raviteja Garimella wrote: >> The UDC is based on Synopsys Designware core USB (2.0) Device controller >> IP. > ... >> This is a request for comments from maintainers/others

Re: [RFC 0/1] Platform driver support for 'amd5536udc' driver

Hi Arnd, On Fri, Jan 6, 2017 at 3:33 AM, Arnd Bergmann wrote: > On Thursday, January 5, 2017 1:53:16 PM CET Raviteja Garimella wrote: >> The UDC is based on Synopsys Designware core USB (2.0) Device controller >> IP. > ... >> This is a request for comments from maintainers/others regarding

Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

On Fri, Dec 30, 2016 at 01:14:20PM +0900, Andi Shyti wrote: > Use the macros defined in include/dt-bindings/pinctrl/samsung.h > instead of hardcoded values. > > Signed-off-by: Andi Shyti > --- > arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 348 >

Re: [PATCH v2 4/4] ARM64: dts: TM2: comply to the samsung pinctrl naming convention

On Fri, Dec 30, 2016 at 01:14:21PM +0900, Andi Shyti wrote: > Change the PIN() macro definition so that it can use the macros > from pinctrl/samsung.h header file. > > Signed-off-by: Andi Shyti > --- > arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 25 +- >

RE: [PATCH 1/3] dt-bindings: Update QorIQ TMU thermal bindings

Seems like Troy's email client has issues which causes his reply is unreadable in patchwork. Please ignore it in patchwork. Regards, Yuantian > -Original Message- > From: Troy Jia > Sent: Thursday, January 05, 2017 10:29 AM > To: Scott Wood ; rui.zh...@intel.com; >

Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

On Fri, Dec 30, 2016 at 01:14:20PM +0900, Andi Shyti wrote: > Use the macros defined in include/dt-bindings/pinctrl/samsung.h > instead of hardcoded values. > > Signed-off-by: Andi Shyti > --- > arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 348 > +++-- > 1 file changed,

Re: [PATCH v2 4/4] ARM64: dts: TM2: comply to the samsung pinctrl naming convention

On Fri, Dec 30, 2016 at 01:14:21PM +0900, Andi Shyti wrote: > Change the PIN() macro definition so that it can use the macros > from pinctrl/samsung.h header file. > > Signed-off-by: Andi Shyti > --- > arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 25 +- >

RE: [PATCH 1/3] dt-bindings: Update QorIQ TMU thermal bindings

Seems like Troy's email client has issues which causes his reply is unreadable in patchwork. Please ignore it in patchwork. Regards, Yuantian > -Original Message- > From: Troy Jia > Sent: Thursday, January 05, 2017 10:29 AM > To: Scott Wood ; rui.zh...@intel.com; > edubez...@gmail.com;

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier wrote: > >> Not sure I fully understood and I don't want to miss an important point. > >> Do > >> you mean making GDT (remapping and per-cpu) read-only and switch the > >> writeable flag only when we write to the per-cpu entry? > > > > What I mean is:

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier wrote: > >> Not sure I fully understood and I don't want to miss an important point. > >> Do > >> you mean making GDT (remapping and per-cpu) read-only and switch the > >> writeable flag only when we write to the per-cpu entry? > > > > What I mean is: write to the GDT

Re: [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface

On Wed, 2017-01-04 at 15:11 +, Robin Murphy wrote: > [+Yong Wu for mtk_iommu] > > On 03/01/17 17:34, Lorenzo Pieralisi wrote: > > With the introduction of the new iommu_{register/get}_instance() > > interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT > > agnostic") (based

Re: [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface

On Wed, 2017-01-04 at 15:11 +, Robin Murphy wrote: > [+Yong Wu for mtk_iommu] > > On 03/01/17 17:34, Lorenzo Pieralisi wrote: > > With the introduction of the new iommu_{register/get}_instance() > > interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT > > agnostic") (based

Re: [PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433

On Fri, Dec 30, 2016 at 02:30:47PM +0100, Linus Walleij wrote: > On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti wrote: > > > Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with > > values used for configuration") has added a header file for defining the > >

Re: [PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433

On Fri, Dec 30, 2016 at 02:30:47PM +0100, Linus Walleij wrote: > On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti wrote: > > > Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with > > values used for configuration") has added a header file for defining the > > pinctrl values in order

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Arjan van de Ven wrote: > On 1/5/2017 9:54 AM, Thomas Garnier wrote: > > > That's my goal too. I started by doing a RO remap and got couple problems > > with > > hibernation. I can try again for the next iteration or delay it for another > > patch. I also need to

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Arjan van de Ven wrote: > On 1/5/2017 9:54 AM, Thomas Garnier wrote: > > > That's my goal too. I started by doing a RO remap and got couple problems > > with > > hibernation. I can try again for the next iteration or delay it for another > > patch. I also need to look at KVM GDT usage, I

Re: [PATCHv3 2/5] arm: mvebu: support for SMP on 98DX3336 SoC

On 01/06, Chris Packham wrote: > diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c > index 46c742d3bd41..3c9ab9a008ad 100644 > --- a/arch/arm/mach-mvebu/platsmp.c > +++ b/arch/arm/mach-mvebu/platsmp.c > @@ -182,5 +182,48 @@ const struct smp_operations armada_xp_smp_ops >

Re: [PATCHv3 2/5] arm: mvebu: support for SMP on 98DX3336 SoC

On 01/06, Chris Packham wrote: > diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c > index 46c742d3bd41..3c9ab9a008ad 100644 > --- a/arch/arm/mach-mvebu/platsmp.c > +++ b/arch/arm/mach-mvebu/platsmp.c > @@ -182,5 +182,48 @@ const struct smp_operations armada_xp_smp_ops >

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier wrote: > > Thanks, > > > > Ingo > > Ingo: I saw the 5-level page table support being sent through. Do you > want me to wait for it to be -next? (Given it will need to be changed > too). Please just base your bits on Linus's latest tree - we'll

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

* Thomas Garnier wrote: > > Thanks, > > > > Ingo > > Ingo: I saw the 5-level page table support being sent through. Do you > want me to wait for it to be -next? (Given it will need to be changed > too). Please just base your bits on Linus's latest tree - we'll sort out any conflicts

Re: [PATCH v2 perf/core] perf script: fix a use after free crash.

On Wed, Jan 04, 2017 at 12:37:39AM -0800, Krister Johansen wrote: > On Mon, Jan 02, 2017 at 09:30:33PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Mon, Jan 02, 2017 at 04:39:04PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Mon, Jan 02, 2017 at 02:36:57PM -0300, Arnaldo Carvalho de Melo >

Re: [PATCH] MAINTAINERS: Add EXYNOS5433 ARM architectures entry as a supporter

On Fri, Jan 06, 2017 at 12:21:44PM +0900, Chanwoo Choi wrote: > On 2017년 01월 06일 01:59, Krzysztof Kozlowski wrote: > > On Thu, Jan 05, 2017 at 10:41:04PM +0900, Andi Shyti wrote: > >> Hi Daniel, > >> > +ARM/SAMSUNG EXYNOS5433 ARM ARCHITECTURES > +M: Chanwoo Choi

Re: [PATCH] MAINTAINERS: Add EXYNOS5433 ARM architectures entry as a supporter

On Fri, Jan 06, 2017 at 12:21:44PM +0900, Chanwoo Choi wrote: > On 2017년 01월 06일 01:59, Krzysztof Kozlowski wrote: > > On Thu, Jan 05, 2017 at 10:41:04PM +0900, Andi Shyti wrote: > >> Hi Daniel, > >> > +ARM/SAMSUNG EXYNOS5433 ARM ARCHITECTURES > +M: Chanwoo Choi > +R:

Re: [PATCH v2 perf/core] perf script: fix a use after free crash.

On Wed, Jan 04, 2017 at 12:37:39AM -0800, Krister Johansen wrote: > On Mon, Jan 02, 2017 at 09:30:33PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Mon, Jan 02, 2017 at 04:39:04PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Mon, Jan 02, 2017 at 02:36:57PM -0300, Arnaldo Carvalho de Melo >

[PATCH v3 perf/core] perf script: fix a use after free crash.

If dso__load_kcore frees all of the existing maps, but one has already been attached to a callchain cursor node, then we can get a SIGSEGV in any function that happens to try to use this invalid cursor. Use the existing map refcount mechanism to forestall cleanup of a map until the cursor

[PATCH v3 perf/core] perf script: fix a use after free crash.

If dso__load_kcore frees all of the existing maps, but one has already been attached to a callchain cursor node, then we can get a SIGSEGV in any function that happens to try to use this invalid cursor. Use the existing map refcount mechanism to forestall cleanup of a map until the cursor

Re: [v1] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

Thanks for your suggestion :). I have done the changes as per your concern . Please review it. Thanks :) -Arvind On Thursday 05 January 2017 05:35 PM, Greg KH wrote: On Thu, Jan 05, 2017 at 05:25:05PM +0530, Arvind Yadav wrote: Please find my comment below. Where? What happened to your

Re: [v1] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

Thanks for your suggestion :). I have done the changes as per your concern . Please review it. Thanks :) -Arvind On Thursday 05 January 2017 05:35 PM, Greg KH wrote: On Thu, Jan 05, 2017 at 05:25:05PM +0530, Arvind Yadav wrote: Please find my comment below. Where? What happened to your

Re: [PATCH v3 1/3] drivers: crypto: Add Support for Octeon-tx CPT Engine

Hi Corentin, Thank you very much for the review. I was on vacation and now am back, I will fix your comments and send a new version. On 12/21/2016 06:53 PM, Corentin Labbe wrote: Hello I have some comment inline On Wed, Dec 21, 2016 at 11:56:11AM +, george.cher...@cavium.com wrote:

Re: [PATCH v3 1/3] drivers: crypto: Add Support for Octeon-tx CPT Engine

Hi Corentin, Thank you very much for the review. I was on vacation and now am back, I will fix your comments and send a new version. On 12/21/2016 06:53 PM, Corentin Labbe wrote: Hello I have some comment inline On Wed, Dec 21, 2016 at 11:56:11AM +, george.cher...@cavium.com wrote:

[PATCH v2 02/2] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

'commit 2584cf83578c ("arch, drivers: don't include directly, use instead")' Make uniform definition of ioremap, ioremap_wc, ioremap_wt and ioremap_cache, tree-wide. Signed-off-by: Arvind Yadav --- drivers/staging/i4l/act2000/act2000.h | 2 +- 1 file changed, 1

[PATCH v2 02/2] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

'commit 2584cf83578c ("arch, drivers: don't include directly, use instead")' Make uniform definition of ioremap, ioremap_wc, ioremap_wt and ioremap_cache, tree-wide. Signed-off-by: Arvind Yadav --- drivers/staging/i4l/act2000/act2000.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

On Fri, Jan 06, 2017 at 11:23:43AM +0900, Andi Shyti wrote: > Hi Krzysztof, > > > Andi, > > Please fix missing Signed-off-by and resend with Linus' tags for #1 and > > #2 and with other accumulated tags. > > patch #1 has already been merged in mainline: > >

Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

On Fri, Jan 06, 2017 at 11:23:43AM +0900, Andi Shyti wrote: > Hi Krzysztof, > > > Andi, > > Please fix missing Signed-off-by and resend with Linus' tags for #1 and > > #2 and with other accumulated tags. > > patch #1 has already been merged in mainline: > >

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

Hi Eric, On 17/1/5 23:31, Eric Ren wrote: Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") results in a deadlock, as the author "Tariq Saeed" realized shortly after the patch was merged. The discussion happened here

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

Hi Eric, On 17/1/5 23:31, Eric Ren wrote: Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") results in a deadlock, as the author "Tariq Saeed" realized shortly after the patch was merged. The discussion happened here

[PATCH v4] rfkill: Add rfkill-any LED trigger

Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any, which may be useful on laptops with a single "radio LED" and multiple radio transmitters. The trigger is meant to turn a LED on whenever there is at least one radio transmitter active and turn it off otherwise.

[PATCH v4] rfkill: Add rfkill-any LED trigger

Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any, which may be useful on laptops with a single "radio LED" and multiple radio transmitters. The trigger is meant to turn a LED on whenever there is at least one radio transmitter active and turn it off otherwise.

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

Hi Eric, On 17/1/5 23:31, Eric Ren wrote: We are in the situation that we have to avoid recursive cluster locking, but there is no way to check if a cluster lock has been taken by a precess already. Mostly, we can avoid recursive locking by writing code carefully. However, we found that it's

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

Hi Eric, On 17/1/5 23:31, Eric Ren wrote: We are in the situation that we have to avoid recursive cluster locking, but there is no way to check if a cluster lock has been taken by a precess already. Mostly, we can avoid recursive locking by writing code carefully. However, we found that it's

[PATCH 1/2] thermal: arm: dra752: Remove TSHUT configuration

Technical Reference Manual [1] mandates that software should not be configuring the thermal shutdown thresholds. Hence removing TSHUT_CONFIG. [1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf Signed-off-by: Keerthy Reported-by: Ravikumar Kattekola ---

[PATCH 1/2] thermal: arm: dra752: Remove TSHUT configuration

Technical Reference Manual [1] mandates that software should not be configuring the thermal shutdown thresholds. Hence removing TSHUT_CONFIG. [1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf Signed-off-by: Keerthy Reported-by: Ravikumar Kattekola ---

[PATCH 2/2] thermal: arm: dra752: Remove all TSHUT related definitions

No configuration needs to be done for TSHUT from software. Hence remove all the unnecessary definitions. Signed-off-by: Keerthy --- drivers/thermal/ti-soc-thermal/dra752-bandgap.h| 19 .../thermal/ti-soc-thermal/dra752-thermal-data.c | 25

[PATCH 2/2] thermal: arm: dra752: Remove all TSHUT related definitions

No configuration needs to be done for TSHUT from software. Hence remove all the unnecessary definitions. Signed-off-by: Keerthy --- drivers/thermal/ti-soc-thermal/dra752-bandgap.h| 19 .../thermal/ti-soc-thermal/dra752-thermal-data.c | 25 -- 2 files

[PATCH 0/2] thermal: omap: dra752: Remove TSHUT configuration

Technical Reference Manual [1] mandates that software should not be configuring the thermal shutdown thresholds. Hence removing TSHUT_CONFIG. [1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf Keerthy (2): thermal: omap: dra752: Remove TSHUT configuration thermal: omap: dra752: Remove all

[PATCH 0/2] thermal: omap: dra752: Remove TSHUT configuration

Technical Reference Manual [1] mandates that software should not be configuring the thermal shutdown thresholds. Hence removing TSHUT_CONFIG. [1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf Keerthy (2): thermal: omap: dra752: Remove TSHUT configuration thermal: omap: dra752: Remove all

RE: [PATCH v4 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

Hi Rob, Thanks for the review... [Snip] > > -- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt > >> > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt > >> > @@ -66,6 +66,8 @@ Optional child node properties: > >> > Optional child node properties for VDMA:

RE: [PATCH v4 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

Hi Rob, Thanks for the review... [Snip] > > -- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt > >> > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt > >> > @@ -66,6 +66,8 @@ Optional child node properties: > >> > Optional child node properties for VDMA:

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017년 01월 06일 14:22에 Andi Shyti 이(가) 쓴 글: > Hi Hoegeun, > >> +static const struct drm_display_mode default_mode = { >> +.clock = 222372, >> +.hdisplay = 1440, >> +.hsync_start = 1440 + 1, >> +.hsync_end = 1440 + 1 + 1, >> +.htotal = 1440 + 1 + 1 + 1, >> +.vdisplay =

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017년 01월 06일 14:22에 Andi Shyti 이(가) 쓴 글: > Hi Hoegeun, > >> +static const struct drm_display_mode default_mode = { >> +.clock = 222372, >> +.hdisplay = 1440, >> +.hsync_start = 1440 + 1, >> +.hsync_end = 1440 + 1 + 1, >> +.htotal = 1440 + 1 + 1 + 1, >> +.vdisplay =

Re: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue

Hi Russel, On Fri, Jan 6, 2017 at 12:25 AM, Russell King - ARM Linux wrote: > On Mon, Nov 28, 2016 at 09:54:28AM -0800, Florian Fainelli wrote: >> If we start supporting generic "enable", "disable" type of properties >> with values that map directly to register definitions

Re: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue

Hi Russel, On Fri, Jan 6, 2017 at 12:25 AM, Russell King - ARM Linux wrote: > On Mon, Nov 28, 2016 at 09:54:28AM -0800, Florian Fainelli wrote: >> If we start supporting generic "enable", "disable" type of properties >> with values that map directly to register definitions of the HW, we >> leave

[PATCH 2/2] cpufreq: Documentation: Updates based on current code

The cpufreq core has gone though lots of updates in recent times, but on many occasions the documentation wasn't updated along with the code. This patch tries to catchup the documentation with the code. Also add Rafael and Viresh as the contributors to the documentation. Based on a patch from

[PATCH 2/2] cpufreq: Documentation: Updates based on current code

The cpufreq core has gone though lots of updates in recent times, but on many occasions the documentation wasn't updated along with the code. This patch tries to catchup the documentation with the code. Also add Rafael and Viresh as the contributors to the documentation. Based on a patch from

  1   2   3   4   5   6   7   8   9   10   >