Re: [PATCH] Coccinelle: Script to remove unnecessary static on local variables

On Thu, 27 Jul 2017, Gustavo A. R. Silva wrote: > Coccinelle script to remove unnecessary static on local variables when > the variables are not used before update. > > Signed-off-by: Gustavo A. R. Silva Acked-by: Julia Lawall > --- >

Re: [PATCH] Coccinelle: Script to remove unnecessary static on local variables

On Thu, 27 Jul 2017, Gustavo A. R. Silva wrote: > Coccinelle script to remove unnecessary static on local variables when > the variables are not used before update. > > Signed-off-by: Gustavo A. R. Silva Acked-by: Julia Lawall > --- > scripts/coccinelle/misc/static_unnecessary.cocci | 89

Re: [PATCH v2] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

Hi Dima, [auto build test WARNING on v4.12] [cannot apply to cgroup/for-next linus/master v4.13-rc2 v4.13-rc1 next-20170728] [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/Dima-Zavin/cpuset-fix

Re: [PATCH v2] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

Hi Dima, [auto build test WARNING on v4.12] [cannot apply to cgroup/for-next linus/master v4.13-rc2 v4.13-rc1 next-20170728] [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/Dima-Zavin/cpuset-fix

[PATCH] futex: split PI support to a file of its own

Split out the priority inheritance support to a file of its own to make futex.c much smaller, easier to understand and, hopefully, to maintain. This also makes it easy to preserve basic futex support and compile out the PI support when RT mutexes are not available. Signed-off-by: Nicolas Pitre

[PATCH] futex: split PI support to a file of its own

Split out the priority inheritance support to a file of its own to make futex.c much smaller, easier to understand and, hopefully, to maintain. This also makes it easy to preserve basic futex support and compile out the PI support when RT mutexes are not available. Signed-off-by: Nicolas Pitre

[PATCH 5/7] arm64: dts: Add SATA DT nodes for Stingray SoC

From: Srinath Mannam Add DT nodes for SATA host controllers and SATA PHYs on Stingray SoC Signed-off-by: Srinath Mannam Reviewed-by: Ray Jui Reviewed-by: Scott Branden ---

[PATCH 7/7] arm64: dts: Add SBA-RAID DT nodes for Stingray SoC

From: Anup Patel This patch adds Broadcom SBA-RAID DT nodes for Stingray SoC. The Stingray SoC has total 32 SBA-RAID FlexRM rings and it has 8 CPUs so we create 8 SBA-RAID instances (one for each CPU). This way Linux DMAENGINE will have one SBA-RAID DMA device for each

[PATCH 6/7] arm64: dts: Add FlexRM DT nodes for Stingray

From: Anup Patel We have two instances of FlexRM on Stingray. One for SBA RAID offload engine and another for SPU2 Crypto offload engine. This patch adds FlexRM mailbox controller DT nodes for Stingray. Signed-off-by: Anup Patel Signed-off-by:

[PATCH 5/7] arm64: dts: Add SATA DT nodes for Stingray SoC

From: Srinath Mannam Add DT nodes for SATA host controllers and SATA PHYs on Stingray SoC Signed-off-by: Srinath Mannam Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 + .../boot/dts/broadcom/stingray/stingray-sata.dtsi |

[PATCH 7/7] arm64: dts: Add SBA-RAID DT nodes for Stingray SoC

From: Anup Patel This patch adds Broadcom SBA-RAID DT nodes for Stingray SoC. The Stingray SoC has total 32 SBA-RAID FlexRM rings and it has 8 CPUs so we create 8 SBA-RAID instances (one for each CPU). This way Linux DMAENGINE will have one SBA-RAID DMA device for each CPU. Signed-off-by: Anup

[PATCH 6/7] arm64: dts: Add FlexRM DT nodes for Stingray

From: Anup Patel We have two instances of FlexRM on Stingray. One for SBA RAID offload engine and another for SPU2 Crypto offload engine. This patch adds FlexRM mailbox controller DT nodes for Stingray. Signed-off-by: Anup Patel Signed-off-by: Raveendra Padasalagi ---

[PATCH 3/7] arm64: dts: Add sp804 DT nodes for Stingray SoC

From: Anup Patel We have 8 instances of sp804 in Stingray SoC. Let's enable it in Stingray DT. Signed-off-by: Anup Patel Reviewed-by: Ray Jui Reviewed-by: Scott Branden ---

[PATCH 4/7] arm64: dts: Add DT node to enable BGMAC driver on Stingray

This patch adds DT node to enable BGMAC driver on Stingray Signed-off-by: Abhishek Shah Reviewed-by: Ray Jui Reviewed-by: Oza Oza Reviewed-by: Scott Branden ---

[PATCH 3/7] arm64: dts: Add sp804 DT nodes for Stingray SoC

From: Anup Patel We have 8 instances of sp804 in Stingray SoC. Let's enable it in Stingray DT. Signed-off-by: Anup Patel Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 87 ++ 1 file changed, 87 insertions(+) diff

[PATCH 4/7] arm64: dts: Add DT node to enable BGMAC driver on Stingray

This patch adds DT node to enable BGMAC driver on Stingray Signed-off-by: Abhishek Shah Reviewed-by: Ray Jui Reviewed-by: Oza Oza Reviewed-by: Scott Branden --- arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi | 14 ++ arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts

[PATCH 2/7] arm64: dts: Add MDIO multiplexer DT node for Stingray

From: Srinath Mannam Added MDIO multiplexer iproc DT node for Stingray, which contains the child nodes of PCIe serdes, RGMII, SATA and USB phy MDIO slaves. Signed-off-by: Srinath Mannam Reviewed-by: Ray Jui

[PATCH 0/7] Add more DT nodes for Stingray SoC

This is round two of adding DT nodes for Stingray SoC. Corresponding drivers and dt binding documents are already checked in the kernel and will be present in v4.14. Abhishek Shah (1): arm64: dts: Add DT node to enable BGMAC driver on Stingray Anup Patel (3): arm64: dts: Add sp804 DT nodes

[PATCH 1/7] arm64: dts: Enable stats for CCN-502 interconnect on Stingray

From: Velibor Markovski This patch enables stats for CCN-502 interconnect on Stingray. Signed-off-by: Velibor Markovski Reviewed-by: Ray Jui Reviewed-by: Scott Branden ---

[PATCH 2/7] arm64: dts: Add MDIO multiplexer DT node for Stingray

From: Srinath Mannam Added MDIO multiplexer iproc DT node for Stingray, which contains the child nodes of PCIe serdes, RGMII, SATA and USB phy MDIO slaves. Signed-off-by: Srinath Mannam Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |

[PATCH 0/7] Add more DT nodes for Stingray SoC

This is round two of adding DT nodes for Stingray SoC. Corresponding drivers and dt binding documents are already checked in the kernel and will be present in v4.14. Abhishek Shah (1): arm64: dts: Add DT node to enable BGMAC driver on Stingray Anup Patel (3): arm64: dts: Add sp804 DT nodes

[PATCH 1/7] arm64: dts: Enable stats for CCN-502 interconnect on Stingray

From: Velibor Markovski This patch enables stats for CCN-502 interconnect on Stingray. Signed-off-by: Velibor Markovski Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git

Re: Possible race condition in oom-killer

Michal Hocko wrote: > On Fri 28-07-17 22:55:51, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Fri 28-07-17 22:15:01, Tetsuo Handa wrote: > > > > task_will_free_mem(current) in out_of_memory() returning false due to > > > > MMF_OOM_SKIP already set allowed each thread sharing that mm to

Re: Possible race condition in oom-killer

Michal Hocko wrote: > On Fri 28-07-17 22:55:51, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Fri 28-07-17 22:15:01, Tetsuo Handa wrote: > > > > task_will_free_mem(current) in out_of_memory() returning false due to > > > > MMF_OOM_SKIP already set allowed each thread sharing that mm to

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

Hi Robin, I am seeing a crash when performing very basic testing on this series with a Mellanox CX4 NIC. I dug into the crash a bit, and think this patch is the culprit, but this rcache business is still mostly witchcraft to me. # ifconfig eth5 up # ifconfig eth5 down Unable to handle kernel

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

Hi Robin, I am seeing a crash when performing very basic testing on this series with a Mellanox CX4 NIC. I dug into the crash a bit, and think this patch is the culprit, but this rcache business is still mostly witchcraft to me. # ifconfig eth5 up # ifconfig eth5 down Unable to handle kernel

Business Proposal

Dear Friend,I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please let me know if this email is valid Regards Adrien Saif Attorney to Quatif Group of Companies

Business Proposal

Dear Friend,I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please let me know if this email is valid Regards Adrien Saif Attorney to Quatif Group of Companies

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

On Fri, Jul 28, 2017 at 07:59:12PM +, Levin, Alexander (Sasha Levin) wrote: > On Fri, Jul 28, 2017 at 01:57:20PM -0500, Josh Poimboeuf wrote: > >Thanks, that's much better. I'm relieved the unwinder didn't screw that > >up, at least. > > > >This looks like a tricky one. Is it easily

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

On Fri, Jul 28, 2017 at 07:59:12PM +, Levin, Alexander (Sasha Levin) wrote: > On Fri, Jul 28, 2017 at 01:57:20PM -0500, Josh Poimboeuf wrote: > >Thanks, that's much better. I'm relieved the unwinder didn't screw that > >up, at least. > > > >This looks like a tricky one. Is it easily

Re: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

On Thu, Jul 27, 2017 at 11:46 PM, Viresh Kumar wrote: > On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU > from policy-A can change frequency of CPUs belonging to policy-B. > > This is quite common in case of ARM platforms where we don't > configure

Re: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

On Thu, Jul 27, 2017 at 11:46 PM, Viresh Kumar wrote: > On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU > from policy-A can change frequency of CPUs belonging to policy-B. > > This is quite common in case of ARM platforms where we don't > configure any per-cpu register. > >

Re: [PATCH 2/2] dt-bindings: ata: add DT bindings for MediaTek SATA controller

On Fri, 2017-07-28 at 12:20 +0300, Sergei Shtylyov wrote: > > +Required properties: > > + - compatible : Must be "mediatek,ahci". > > + - reg: Physical base addresses and length of register > > sets. > > + - interrupts : Interrupt associated with the SATA device. >

Re: [PATCH 2/2] dt-bindings: ata: add DT bindings for MediaTek SATA controller

On Fri, 2017-07-28 at 12:20 +0300, Sergei Shtylyov wrote: > > +Required properties: > > + - compatible : Must be "mediatek,ahci". > > + - reg: Physical base addresses and length of register > > sets. > > + - interrupts : Interrupt associated with the SATA device. >

Re: [RFC] perf: Delayed userspace unwind (Was: [PATCH v3 00/10] x86: ORC unwinder)

> On Jul 25, 2017, at 7:55 AM, Peter Zijlstra wrote: > >> On Thu, Jul 13, 2017 at 11:19:11AM +0200, Ingo Molnar wrote: >> >> * Peter Zijlstra wrote: >> One gloriously ugly hack would be to delay the userspace unwind to return-to-userspace, at

Re: [RFC] perf: Delayed userspace unwind (Was: [PATCH v3 00/10] x86: ORC unwinder)

> On Jul 25, 2017, at 7:55 AM, Peter Zijlstra wrote: > >> On Thu, Jul 13, 2017 at 11:19:11AM +0200, Ingo Molnar wrote: >> >> * Peter Zijlstra wrote: >> One gloriously ugly hack would be to delay the userspace unwind to return-to-userspace, at which point we have a schedulable context

Re: [PATCH 0/3] memdelay: memory health metric for systems and workloads

On Sat, 2017-07-29 at 04:48 +0200, Mike Galbraith wrote: > On Thu, 2017-07-27 at 11:30 -0400, Johannes Weiner wrote: > > > > Structure > > > > The first patch cleans up the different loadavg callsites and macros > > as the memdelay averages are going to be tracked using these. > > > > The

Re: [PATCH 0/3] memdelay: memory health metric for systems and workloads

On Sat, 2017-07-29 at 04:48 +0200, Mike Galbraith wrote: > On Thu, 2017-07-27 at 11:30 -0400, Johannes Weiner wrote: > > > > Structure > > > > The first patch cleans up the different loadavg callsites and macros > > as the memdelay averages are going to be tracked using these. > > > > The

Re: [PATCH 0/3] memdelay: memory health metric for systems and workloads

On Thu, 2017-07-27 at 11:30 -0400, Johannes Weiner wrote: > > Structure > > The first patch cleans up the different loadavg callsites and macros > as the memdelay averages are going to be tracked using these. > > The second patch adds a distinction between page cache transitions > (inactive

Re: [PATCH 0/3] memdelay: memory health metric for systems and workloads

On Thu, 2017-07-27 at 11:30 -0400, Johannes Weiner wrote: > > Structure > > The first patch cleans up the different loadavg callsites and macros > as the memdelay averages are going to be tracked using these. > > The second patch adds a distinction between page cache transitions > (inactive

[PATCH] ipmi: fix unsigned long overflow

When I set the timeout to a specific value such as 500ms, the timeout event will not happen in time due to the overflow in function check_msg_timeout: ... ent->timeout -= timeout_period; if (ent->timeout > 0) return; ... The type of timeout_period is long, but

[PATCH] ipmi: fix unsigned long overflow

When I set the timeout to a specific value such as 500ms, the timeout event will not happen in time due to the overflow in function check_msg_timeout: ... ent->timeout -= timeout_period; if (ent->timeout > 0) return; ... The type of timeout_period is long, but

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

On Fri, 28 Jul 2017, Zdenek Kabelac wrote: > Dne 28.7.2017 v 20:33 Alan Stern napsal(a): > > On Thu, 27 Jul 2017, Zdenek Kabelac wrote: > > > >>> Zdenek, you check this explanation by commenting out these last two > >>> lines at the end of hub_port_connect() in drivers/usb/core/hub.c: > >>> >

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

On Fri, 28 Jul 2017, Zdenek Kabelac wrote: > Dne 28.7.2017 v 20:33 Alan Stern napsal(a): > > On Thu, 27 Jul 2017, Zdenek Kabelac wrote: > > > >>> Zdenek, you check this explanation by commenting out these last two > >>> lines at the end of hub_port_connect() in drivers/usb/core/hub.c: > >>> >

Re: [PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer

From: Alexandru Gagniuc Date: Fri, 28 Jul 2017 15:07:03 -0700 > Before the GMAC on the Anarion chip can be used, the PHY interface > selection must be configured with the DWMAC block in reset. > > This layer covers a block containing only two registers. Although it > is

Re: [PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer

From: Alexandru Gagniuc Date: Fri, 28 Jul 2017 15:07:03 -0700 > Before the GMAC on the Anarion chip can be used, the PHY interface > selection must be configured with the DWMAC block in reset. > > This layer covers a block containing only two registers. Although it > is possible to model this

Re: [RFC PATCH v2] membarrier: expedited private command

On Fri, 28 Jul 2017 17:06:53 + (UTC) Mathieu Desnoyers wrote: > - On Jul 28, 2017, at 12:46 PM, Peter Zijlstra pet...@infradead.org wrote: > > > On Fri, Jul 28, 2017 at 03:38:15PM +, Mathieu Desnoyers wrote: > >> > Which only leaves PPC stranded..

Re: [RFC PATCH v2] membarrier: expedited private command

On Fri, 28 Jul 2017 17:06:53 + (UTC) Mathieu Desnoyers wrote: > - On Jul 28, 2017, at 12:46 PM, Peter Zijlstra pet...@infradead.org wrote: > > > On Fri, Jul 28, 2017 at 03:38:15PM +, Mathieu Desnoyers wrote: > >> > Which only leaves PPC stranded.. but the 'good' news is that mpe

Re: [PATCH 0/2] constify inet6_protocol structures

From: Julia Lawall Date: Fri, 28 Jul 2017 22:18:56 +0200 > The inet6_protocol structure is only passed as the first argument to > inet6_add_protocol or inet6_del_protocol, both of which are declared as > const. Thus the inet6_protocol structure itself can be const. > >

Re: [PATCH 0/2] constify inet6_protocol structures

From: Julia Lawall Date: Fri, 28 Jul 2017 22:18:56 +0200 > The inet6_protocol structure is only passed as the first argument to > inet6_add_protocol or inet6_del_protocol, both of which are declared as > const. Thus the inet6_protocol structure itself can be const. > > Done with the help of

drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.o: warning: objtool: xgbe_phy_sfp_eeprom_info()+0xc: return with modified stack frame

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0a07b238e5f488b459b6113a62e06b6aab017f71 commit: 6974f0c4555e285ab217cee58b6e874f776ff409 include/linux/string.h: add the option of fortified string.h functions date: 2 weeks ago config:

drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.o: warning: objtool: xgbe_phy_sfp_eeprom_info()+0xc: return with modified stack frame

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0a07b238e5f488b459b6113a62e06b6aab017f71 commit: 6974f0c4555e285ab217cee58b6e874f776ff409 include/linux/string.h: add the option of fortified string.h functions date: 2 weeks ago config:

Re: [PATCH] irqchip: brcmstb-l2: Define an irq_pm_shutdown function

On Thu, Jul 27, 2017 at 3:38 PM, Florian Fainelli wrote: > The Broadcom STB platforms support S5 and we allow specific hardware > wake-up events to take us out of this state. Because we were not > defining an irq_pm_shutdown() function pointer, we would not be > correctly

Re: [PATCH] irqchip: brcmstb-l2: Define an irq_pm_shutdown function

On Thu, Jul 27, 2017 at 3:38 PM, Florian Fainelli wrote: > The Broadcom STB platforms support S5 and we allow specific hardware > wake-up events to take us out of this state. Because we were not > defining an irq_pm_shutdown() function pointer, we would not be > correctly masking non-wakeup

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

On Fri, 2017-07-28 at 15:30 -0700, Linus Torvalds wrote: > So we'd have files like "rdma", "dma", "omap", "pm", "dri", "pci", > "wireless" etc, all of which sound sane. [] > it looks like a promising approach to me, and I like how > the names seem to end up all fairly sane. > > Comments? Seems

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

On Fri, 2017-07-28 at 15:30 -0700, Linus Torvalds wrote: > So we'd have files like "rdma", "dma", "omap", "pm", "dri", "pci", > "wireless" etc, all of which sound sane. [] > it looks like a promising approach to me, and I like how > the names seem to end up all fairly sane. > > Comments? Seems

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

El Fri, Jul 28, 2017 at 07:55:21PM -0500 Josh Poimboeuf ha dit: > On Fri, Jul 28, 2017 at 05:38:52PM -0700, Matthias Kaehlcke wrote: > > El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit: > > > > > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote: > > > > FWIW bellow

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

El Fri, Jul 28, 2017 at 07:55:21PM -0500 Josh Poimboeuf ha dit: > On Fri, Jul 28, 2017 at 05:38:52PM -0700, Matthias Kaehlcke wrote: > > El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit: > > > > > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote: > > > > FWIW bellow

[PATCH v1] i2c: aspeed: fixed potential null pointer dereference

Before I skipped null checks when the master is in the STOP state; this fixes that. Signed-off-by: Brendan Higgins --- drivers/i2c/busses/i2c-aspeed.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-aspeed.c

[PATCH v1] i2c: aspeed: fixed potential null pointer dereference

Before I skipped null checks when the master is in the STOP state; this fixes that. Signed-off-by: Brendan Higgins --- drivers/i2c/busses/i2c-aspeed.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c index

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

On Fri, Jul 28, 2017 at 07:55:21PM -0500, Josh Poimboeuf wrote: > +#define ASM_CALL(str, outputs, inputs, clobbers...) \ > + asm volatile(str : outputs : inputs : "sp", ## clobbers) And note this part isn't right, the sp should be in the output operands. -- Josh

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

On Fri, Jul 28, 2017 at 07:55:21PM -0500, Josh Poimboeuf wrote: > +#define ASM_CALL(str, outputs, inputs, clobbers...) \ > + asm volatile(str : outputs : inputs : "sp", ## clobbers) And note this part isn't right, the sp should be in the output operands. -- Josh

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

On Fri, Jul 28, 2017 at 05:38:52PM -0700, Matthias Kaehlcke wrote: > El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit: > > > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote: > > > FWIW bellow is my understanding of what's going on. > > > > > > It seems clang treats

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

On Fri, Jul 28, 2017 at 05:38:52PM -0700, Matthias Kaehlcke wrote: > El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit: > > > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote: > > > FWIW bellow is my understanding of what's going on. > > > > > > It seems clang treats

Re: [PATCH v2 1/3] drm/vc4: Start using u64_to_user_ptr.

Daniel Vetter writes: > On Tue, Jul 25, 2017 at 11:27:16AM -0700, Eric Anholt wrote: >> Chris Wilson pointed out this little cleanup in a review of new code, >> so let's fix up the code I was copying from. >> >> Signed-off-by: Eric Anholt > > Reviewed-by:

Re: [PATCH v2 1/3] drm/vc4: Start using u64_to_user_ptr.

Daniel Vetter writes: > On Tue, Jul 25, 2017 at 11:27:16AM -0700, Eric Anholt wrote: >> Chris Wilson pointed out this little cleanup in a review of new code, >> so let's fix up the code I was copying from. >> >> Signed-off-by: Eric Anholt > > Reviewed-by: Daniel Vetter Thanks! With Chris's

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit: > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote: > > FWIW bellow is my understanding of what's going on. > > > > It seems clang treats local named register almost the same as ordinary > > local variables. > > The

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit: > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote: > > FWIW bellow is my understanding of what's going on. > > > > It seems clang treats local named register almost the same as ordinary > > local variables. > > The

[PATCH v6 1/3] mfd: Add new mfd device TPS68470

The TPS68470 device is an advanced power management unit that powers a Compact Camera Module (CCM), generates clocks for image sensors, drives a dual LED for Flash and incorporates two LED drivers for general purpose indicators. This patch adds support for TPS68470 mfd device. Signed-off-by:

[PATCH v6 1/3] mfd: Add new mfd device TPS68470

The TPS68470 device is an advanced power management unit that powers a Compact Camera Module (CCM), generates clocks for image sensors, drives a dual LED for Flash and incorporates two LED drivers for general purpose indicators. This patch adds support for TPS68470 mfd device. Signed-off-by:

[PATCH v6 0/3] TPS68470 PMIC drivers

This is the patch series for TPS68470 PMIC that works as a camera PMIC. The patch series provide the following 3 drivers, to help configure the voltage regulators, clocks and GPIOs provided by the TPS68470 PMIC, to be able to use the camera sensors connected to this PMIC. TPS68470 MFD driver:

[PATCH v6 0/3] TPS68470 PMIC drivers

This is the patch series for TPS68470 PMIC that works as a camera PMIC. The patch series provide the following 3 drivers, to help configure the voltage regulators, clocks and GPIOs provided by the TPS68470 PMIC, to be able to use the camera sensors connected to this PMIC. TPS68470 MFD driver:

[PATCH v6 3/3] ACPI / PMIC: Add TI PMIC TPS68470 operation region driver

The Kabylake platform coreboot (Chrome OS equivalent of BIOS) has defined 4 operation regions for the TI TPS68470 PMIC. These operation regions are to enable/disable voltage regulators, configure voltage regulators, enable/disable clocks and to configure clocks. This config adds ACPI operation

[PATCH v6 3/3] ACPI / PMIC: Add TI PMIC TPS68470 operation region driver

The Kabylake platform coreboot (Chrome OS equivalent of BIOS) has defined 4 operation regions for the TI TPS68470 PMIC. These operation regions are to enable/disable voltage regulators, configure voltage regulators, enable/disable clocks and to configure clocks. This config adds ACPI operation

[PATCH v6 2/3] gpio: Add support for TPS68470 GPIOs

This patch adds support for TPS68470 GPIOs. There are 7 GPIOs and a few sensor related GPIOs. These GPIOs can be requested and configured as appropriate. The GPIOs are also provided with descriptive names. However, the typical use case is that the OS GPIO driver will interact with TPS68470 GPIO

[PATCH v6 2/3] gpio: Add support for TPS68470 GPIOs

This patch adds support for TPS68470 GPIOs. There are 7 GPIOs and a few sensor related GPIOs. These GPIOs can be requested and configured as appropriate. The GPIOs are also provided with descriptive names. However, the typical use case is that the OS GPIO driver will interact with TPS68470 GPIO

Re: [RFC PATCH] f2fs: obsolete FI_ACL_MODE

Hi Jaegeuk, Could you take time to have a look at this? Is this change reasonable? Thanks, On 2017/7/26 22:33, Chao Yu wrote: > From: Chao Yu > > Previously, in order to avoid losing important inode metadata after > checkpoint & sudden power-off, f2fs uses synchronous

Re: [RFC PATCH] f2fs: obsolete FI_ACL_MODE

Hi Jaegeuk, Could you take time to have a look at this? Is this change reasonable? Thanks, On 2017/7/26 22:33, Chao Yu wrote: > From: Chao Yu > > Previously, in order to avoid losing important inode metadata after > checkpoint & sudden power-off, f2fs uses synchronous approach for > updating

Re: [f2fs-dev] [PATCH 1/2 v3] f2fs: expose /sys/fs/f2fs/features

On 2017/7/29 3:41, Jaegeuk Kim wrote: > Change log from v2: > - add missing new features > - fix print out features > > Change log from v1: > - add /sys/fs/f2fs/dev/features > >>From cf512bfeed89d760138ade12014f17fc5779ca04 Mon Sep 17 00:00:00 2001 > From: Jaegeuk Kim

Re: [f2fs-dev] [PATCH 1/2 v3] f2fs: expose /sys/fs/f2fs/features

On 2017/7/29 3:41, Jaegeuk Kim wrote: > Change log from v2: > - add missing new features > - fix print out features > > Change log from v1: > - add /sys/fs/f2fs/dev/features > >>From cf512bfeed89d760138ade12014f17fc5779ca04 Mon Sep 17 00:00:00 2001 > From: Jaegeuk Kim > Date: Fri, 21

Re: [PATCH v2] f2fs: provide f2fs_balance_fs to __write_node_page

Hi Yunlong, On 2017/7/27 20:13, Yunlong Song wrote: > v1->v2, fix some dead lock problems under some heavy load test > > On 2017/7/27 20:11, Yunlong Song wrote: >> Let node writeback also do f2fs_balance_fs to ensure there are always enough >> free >> segments. Could we cover __write_data_page

Re: [PATCH v2] f2fs: provide f2fs_balance_fs to __write_node_page

Hi Yunlong, On 2017/7/27 20:13, Yunlong Song wrote: > v1->v2, fix some dead lock problems under some heavy load test > > On 2017/7/27 20:11, Yunlong Song wrote: >> Let node writeback also do f2fs_balance_fs to ensure there are always enough >> free >> segments. Could we cover __write_data_page

[PATCH] staging: lustre: lov: remove dead code

This #if 0 block has been commented out for years. Assume it is not needed and remove it. Signed-off-by: Dmitriy Cherkasov --- drivers/staging/lustre/lustre/lov/lov_io.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/staging/lustre/lustre/lov/lov_io.c

[PATCH] staging: lustre: lov: remove dead code

This #if 0 block has been commented out for years. Assume it is not needed and remove it. Signed-off-by: Dmitriy Cherkasov --- drivers/staging/lustre/lustre/lov/lov_io.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/staging/lustre/lustre/lov/lov_io.c

Re: [PATCH v5 0/2] ZII RAVE platform driver

On Fri, Jul 28, 2017 at 4:30 PM, Greg Kroah-Hartman wrote: > On Fri, Jul 28, 2017 at 07:27:02AM -0700, Andrey Smirnov wrote: >> Greg, >> >> I am not sure if you are the right person to send these to, if you are >> not, please let me know who would be the appropriate

Re: [PATCH v5 0/2] ZII RAVE platform driver

On Fri, Jul 28, 2017 at 4:30 PM, Greg Kroah-Hartman wrote: > On Fri, Jul 28, 2017 at 07:27:02AM -0700, Andrey Smirnov wrote: >> Greg, >> >> I am not sure if you are the right person to send these to, if you are >> not, please let me know who would be the appropriate recepient and sorry for >>

Re: [PATCH v2 1/1] i2c: aspeed: add proper support fo 24xx clock params

On Fri, Jul 28, 2017 at 2:00 PM, Rick Altherr wrote: > Is clk_fractional_divider from include/linux/clk-provider.h appropriate here? > Alas, no. clk_fractional_divider is not flexible enough to specify the divider the way that it is represented in the Aspeed 24xx/25xx parts

Re: [PATCH v2 1/1] i2c: aspeed: add proper support fo 24xx clock params

On Fri, Jul 28, 2017 at 2:00 PM, Rick Altherr wrote: > Is clk_fractional_divider from include/linux/clk-provider.h appropriate here? > Alas, no. clk_fractional_divider is not flexible enough to specify the divider the way that it is represented in the Aspeed 24xx/25xx parts which have the

Re: [PATCH] staging: vboxvideo: select CONFIG_GENERIC_ALLOCATOR

On Fri, Jul 28, 2017 at 03:21:01PM +0200, Arnd Bergmann wrote: > vboxvideo fails to link without genalloc: > > drivers/staging/vboxvideo/vbox_hgsmi.o: In function `hgsmi_buffer_alloc': > vbox_hgsmi.c:(.text+0x1e): undefined reference to `gen_pool_dma_alloc' >

Re: [PATCH] staging: vboxvideo: select CONFIG_GENERIC_ALLOCATOR

On Fri, Jul 28, 2017 at 03:21:01PM +0200, Arnd Bergmann wrote: > vboxvideo fails to link without genalloc: > > drivers/staging/vboxvideo/vbox_hgsmi.o: In function `hgsmi_buffer_alloc': > vbox_hgsmi.c:(.text+0x1e): undefined reference to `gen_pool_dma_alloc' >

Re: [PATCH 1/3] ARM: dts: NSP: Add dma-coherent to relevant DT entries

On 07/25/2017 03:06 PM, Jon Mason wrote: > Cache related issues with DMA rings and performance issues related to > caching are being caused by not properly setting the "dma-coherent" flag > in the device tree entries. Adding it here to correct the issue. > > Signed-off-by: Jon Mason

Re: [PATCH 1/3] ARM: dts: NSP: Add dma-coherent to relevant DT entries

On 07/25/2017 03:06 PM, Jon Mason wrote: > Cache related issues with DMA rings and performance issues related to > caching are being caused by not properly setting the "dma-coherent" flag > in the device tree entries. Adding it here to correct the issue. > > Signed-off-by: Jon Mason > Fixes:

Re: [PATCH 1/1][staging-next] staging: pi433: Make functions rf69_set_dc_cut_off_frequency_intern static

On Thu, Jul 20, 2017 at 01:01:46PM +0200, Wolf Entwicklungen wrote: > Declare rf69_set_dc_cut_off_frequency_intern as static since it > is used internaly only > > Fixes: 874bcba65f9a ("staging: pi433: New driver") > Signed-off-by: Marcus Wolf > > diff --git

Re: [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation

On Thu, Jul 20, 2017 at 05:56:36PM +0200, Marcus Wolf wrote: > Fixes problem with division in rf69_set_deviation > > Fixes: 874bcba65f9a ("staging: pi433: New driver") > Signed-off-by: Marcus Wolf > > diff --git a/drivers/staging/pi433/rf69.c

Re: [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation

On Thu, Jul 20, 2017 at 05:56:36PM +0200, Marcus Wolf wrote: > Fixes problem with division in rf69_set_deviation > > Fixes: 874bcba65f9a ("staging: pi433: New driver") > Signed-off-by: Marcus Wolf > > diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c > ---

Re: [PATCH 1/1][staging-next] staging: pi433: Make functions rf69_set_dc_cut_off_frequency_intern static

On Thu, Jul 20, 2017 at 01:01:46PM +0200, Wolf Entwicklungen wrote: > Declare rf69_set_dc_cut_off_frequency_intern as static since it > is used internaly only > > Fixes: 874bcba65f9a ("staging: pi433: New driver") > Signed-off-by: Marcus Wolf > > diff --git a/drivers/staging/pi433/rf69.c

Re: [PATCH v3 0/4] Broadcom STB S2/S3/S5 support for ARM and MIPS

On 07/18/2017 12:52 PM, Florian Fainelli wrote: > On 07/06/2017 03:22 PM, Florian Fainelli wrote: >> Hi, >> >> This patch series adds support for S2/S3/S5 suspend/resume states on >> ARM and MIPS based Broadcom STB SoCs. >> >> This was submitted a long time ago by Brian, and I am now picking this

Re: [PATCH v3 0/4] Broadcom STB S2/S3/S5 support for ARM and MIPS

On 07/18/2017 12:52 PM, Florian Fainelli wrote: > On 07/06/2017 03:22 PM, Florian Fainelli wrote: >> Hi, >> >> This patch series adds support for S2/S3/S5 suspend/resume states on >> ARM and MIPS based Broadcom STB SoCs. >> >> This was submitted a long time ago by Brian, and I am now picking this

Re: [PATCH 1/3][staging-next] staging: pi433: Make a couple of functions static

On Tue, Jul 18, 2017 at 02:03:58PM +0100, Colin King wrote: > From: Colin Ian King > > The functions pi433_receive and pi433_tx_thread are local to the source > and do not need to be in global scope, so make them static > > Cleans up sparse warnings: > symbol

Re: [PATCH 1/3][staging-next] staging: pi433: Make a couple of functions static

On Tue, Jul 18, 2017 at 02:03:58PM +0100, Colin King wrote: > From: Colin Ian King > > The functions pi433_receive and pi433_tx_thread are local to the source > and do not need to be in global scope, so make them static > > Cleans up sparse warnings: > symbol 'pi433_receive' was not declared.

  1   2   3   4   5   6   7   8   9   10   >