linux-next: manual merge of the staging tree with the devicetree tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: Documentation/devicetree/bindings/vendor-prefixes.txt between commit: 566088d1d2a0 ("devicetree: Add Fujitsu Ltd. vendor prefix") from the devicetree tree and commit: 9b27c270d403 ("devicetree: add Garmin vendor

linux-next: manual merge of the staging tree with the devicetree tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: Documentation/devicetree/bindings/vendor-prefixes.txt between commit: 566088d1d2a0 ("devicetree: Add Fujitsu Ltd. vendor prefix") from the devicetree tree and commit: 9b27c270d403 ("devicetree: add Garmin vendor

Re: [PATCH v5 4/4] usb: doc: add document for USB3 debug port usage

Hi Ingo, On 01/19/2017 05:41 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> Add Documentation/usb/usb3-debug-port.rst. This document includes >> the user guide for USB3 debug port. >> >> Cc: linux-...@vger.kernel.org >> Signed-off-by: Lu Baolu

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

On 2017/1/19 22:13, Ulf Hansson wrote: +Shawn On 13 January 2017 at 06:29, Matt Ranostay wrote: Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc: Tony Lindgren Cc: Ulf

Re: [PATCH v5 4/4] usb: doc: add document for USB3 debug port usage

Hi Ingo, On 01/19/2017 05:41 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> Add Documentation/usb/usb3-debug-port.rst. This document includes >> the user guide for USB3 debug port. >> >> Cc: linux-...@vger.kernel.org >> Signed-off-by: Lu Baolu >> --- >> Documentation/usb/usb3-debug-port.rst |

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

On 2017/1/19 22:13, Ulf Hansson wrote: +Shawn On 13 January 2017 at 06:29, Matt Ranostay wrote: Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc: Tony Lindgren Cc: Ulf Hansson Signed-off-by: Matt Ranostay ---

Re: [PATCH v3] iio: light: acpi-als: Properly enable on ASUS Zenbooks

On Thu, Jan 19, 2017 at 11:01 AM, Josef Gajdusek wrote: > ASUS Zenbooks need several special ACPI calls to enable the ALS peripheral. > Otherwise, reads just return 0. > > Signed-off-by: Josef Gajdusek > --- > drivers/iio/light/acpi-als.c | 60 >

Re: [PATCH] procfs: change the owner of non-dumpable and writeable files

Please verify but the ptrace issue that allowed processes in a container to call setns on our processes should be fixed as of 4.10-rc1. And the change has been marked for backporting. ptrace(2) is not the only issue, the issue that we had in runC is that a process joining a namespace may have

Re: [PATCH v3] iio: light: acpi-als: Properly enable on ASUS Zenbooks

On Thu, Jan 19, 2017 at 11:01 AM, Josef Gajdusek wrote: > ASUS Zenbooks need several special ACPI calls to enable the ALS peripheral. > Otherwise, reads just return 0. > > Signed-off-by: Josef Gajdusek > --- > drivers/iio/light/acpi-als.c | 60 > >

Re: [PATCH] procfs: change the owner of non-dumpable and writeable files

Please verify but the ptrace issue that allowed processes in a container to call setns on our processes should be fixed as of 4.10-rc1. And the change has been marked for backporting. ptrace(2) is not the only issue, the issue that we had in runC is that a process joining a namespace may have

Re: [PATCH v5 3/4] usb: serial: usb_debug: add support for dbc debug device

Hi Ingo, On 01/19/2017 05:39 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> This patch add dbc debug device support in usb_debug driver. > s/add dbc debug device support in usb_debug driver > /adds dbc debug device support to the usb_debug driver > > Please fix the

Re: [PATCH v5 3/4] usb: serial: usb_debug: add support for dbc debug device

Hi Ingo, On 01/19/2017 05:39 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> This patch add dbc debug device support in usb_debug driver. > s/add dbc debug device support in usb_debug driver > /adds dbc debug device support to the usb_debug driver > > Please fix the title as well. Sure. Thank

Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags

On 01/19/2017 04:14 AM, Bharat Kumar Gogada wrote: -Realtek 8192CE chipset maintains local irq flags after enabling/disabling hardware interrupts. -Hardware interrupts are enabled before enabling the local irq flags(these flags are being checked in interrupt handler), leading to race condition

Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags

On 01/19/2017 04:14 AM, Bharat Kumar Gogada wrote: -Realtek 8192CE chipset maintains local irq flags after enabling/disabling hardware interrupts. -Hardware interrupts are enabled before enabling the local irq flags(these flags are being checked in interrupt handler), leading to race condition

Re: [PATCH v5 2/4] x86: add support for earlyprintk via USB3 debug port

Hi Ingo, On 01/19/2017 05:38 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> index 8a12199..c4031b9 100644 >> --- a/arch/x86/kernel/early_printk.c >> +++ b/arch/x86/kernel/early_printk.c >> @@ -17,6 +17,7 @@ >> #include >> #include >> #include >> +#include >>

Re: [PATCH v5 2/4] x86: add support for earlyprintk via USB3 debug port

Hi Ingo, On 01/19/2017 05:38 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> index 8a12199..c4031b9 100644 >> --- a/arch/x86/kernel/early_printk.c >> +++ b/arch/x86/kernel/early_printk.c >> @@ -17,6 +17,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >>

Re: amdgpu: Corrupted video on 32 bit systems (possible fix)

On 20/01/17 04:35 AM, Nils Holland wrote: > Hi folks, > > there seems to be an issue on 32 bit kernels which makes graphics > output look all messed up under X when using the amdgpu drm kernel > driver. > > In fact, the same issue was present at some time in 2015 using the > radeon driver too,

Re: amdgpu: Corrupted video on 32 bit systems (possible fix)

On 20/01/17 04:35 AM, Nils Holland wrote: > Hi folks, > > there seems to be an issue on 32 bit kernels which makes graphics > output look all messed up under X when using the amdgpu drm kernel > driver. > > In fact, the same issue was present at some time in 2015 using the > radeon driver too,

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi Ingo, I'm very appreciated for your review comments. I've put my replies in lines. On 01/19/2017 05:37 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> xHCI debug capability (DbC) is an optional but standalone >> functionality provided by an xHCI host controller.

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi Ingo, I'm very appreciated for your review comments. I've put my replies in lines. On 01/19/2017 05:37 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> xHCI debug capability (DbC) is an optional but standalone >> functionality provided by an xHCI host controller. Software >> learns this

[PATCH V11 1/3] ACPI: Generic GSI: Do not attempt to map non-GSI IRQs during bus scan

ACPI extended IRQ resources may contain a Resource Source field to specify an alternate interrupt controller, attempting to map them as GSIs is incorrect, so just disable the platform resource. Since this field is currently ignored, we make this change conditional on CONFIG_ACPI_GENERIC_GSI to

[PATCH V11 1/3] ACPI: Generic GSI: Do not attempt to map non-GSI IRQs during bus scan

ACPI extended IRQ resources may contain a Resource Source field to specify an alternate interrupt controller, attempting to map them as GSIs is incorrect, so just disable the platform resource. Since this field is currently ignored, we make this change conditional on CONFIG_ACPI_GENERIC_GSI to

[PATCH V11 3/3] irqchip: qcom: Add IRQ combiner driver

Driver for interrupt combiners in the Top-level Control and Status Registers (TCSR) hardware block in Qualcomm Technologies chips. An interrupt combiner in this block combines a set of interrupts by OR'ing the individual interrupt signals into a summary interrupt signal routed to a parent

[PATCH V11 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

ACPI extended IRQ resources may contain a ResourceSource to specify an alternate interrupt controller. Introduce acpi_irq_get and use it to implement ResourceSource/IRQ domain mapping. The new API is similar to of_irq_get and allows re-initialization of a platform resource from the ACPI extended

[PATCH V11 3/3] irqchip: qcom: Add IRQ combiner driver

Driver for interrupt combiners in the Top-level Control and Status Registers (TCSR) hardware block in Qualcomm Technologies chips. An interrupt combiner in this block combines a set of interrupts by OR'ing the individual interrupt signals into a summary interrupt signal routed to a parent

[PATCH V11 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping

ACPI extended IRQ resources may contain a ResourceSource to specify an alternate interrupt controller. Introduce acpi_irq_get and use it to implement ResourceSource/IRQ domain mapping. The new API is similar to of_irq_get and allows re-initialization of a platform resource from the ACPI extended

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote: > I think it could work by making a single socket cgroup controller that > handles all cgroup things that are bound to a socket. Using Such 'socket cgroup controller' would limit usability of the feature to sockets and force all

[PATCH V11 0/3] irqchip: qcom: Add IRQ combiner driver

Add support for IRQ combiners in the Top-level Control and Status Registers (TCSR) hardware block in Qualcomm Technologies chips. The first patch prevents the ACPI core from attempting to map IRQ resources with a valid ResourceSource as GSIs. The second patch adds support for ResourceSource/IRQ

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote: > I think it could work by making a single socket cgroup controller that > handles all cgroup things that are bound to a socket. Using Such 'socket cgroup controller' would limit usability of the feature to sockets and force all

[PATCH V11 0/3] irqchip: qcom: Add IRQ combiner driver

Add support for IRQ combiners in the Top-level Control and Status Registers (TCSR) hardware block in Qualcomm Technologies chips. The first patch prevents the ACPI core from attempting to map IRQ resources with a valid ResourceSource as GSIs. The second patch adds support for ResourceSource/IRQ

Re: [PATCH RFC] vfio error recovery: kernel support

On Thu, Jan 19, 2017 at 03:57:34PM -0700, Alex Williamson wrote: > On Fri, 20 Jan 2017 00:21:02 +0200 > "Michael S. Tsirkin" wrote: > > > On Thu, Jan 19, 2017 at 03:10:56PM -0700, Alex Williamson wrote: > > > On Thu, 19 Jan 2017 22:16:03 +0200 > > > "Michael S. Tsirkin"

Re: [PATCH RFC] vfio error recovery: kernel support

On Thu, Jan 19, 2017 at 03:57:34PM -0700, Alex Williamson wrote: > On Fri, 20 Jan 2017 00:21:02 +0200 > "Michael S. Tsirkin" wrote: > > > On Thu, Jan 19, 2017 at 03:10:56PM -0700, Alex Williamson wrote: > > > On Thu, 19 Jan 2017 22:16:03 +0200 > > > "Michael S. Tsirkin" wrote: > > > > > > >

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

Resending including Thomas , also with some changes. Sorry for the spam Based on Thomas and Peterz feedback Can think of two design variants which target: -Support monitoring and allocating using the same resctrl group. user can use a resctrl group to allocate resources and also monitor them

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

Resending including Thomas , also with some changes. Sorry for the spam Based on Thomas and Peterz feedback Can think of two design variants which target: -Support monitoring and allocating using the same resctrl group. user can use a resctrl group to allocate resources and also monitor them

Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board

On 2017/1/19 10:11, Eddie Cai wrote: This patch add basic support for RK3288-Tinker board. We can boot in to rootfs with this patch. Signed-off-by: Eddie Cai --- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-tinker.dts | 556

Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board

On 2017/1/19 10:11, Eddie Cai wrote: This patch add basic support for RK3288-Tinker board. We can boot in to rootfs with this patch. Signed-off-by: Eddie Cai --- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-tinker.dts | 556 2

[PATCH v2] PM / Domains: Keep the pd status during system PM phases

If a PM domain is powered off before system suspend, we hope do nothing in system runtime suspend noirq phase and system runtime resume noirq phase. This modify is to slove system resume issue for RK3399. RK3399 SOC pd_gpu have voltage domain vdd_gpu, so we must follow open vdd_gpu and power on

Re: [PATCH 2/6] usb: mtu3: add reference clock

On Thu, 2017-01-19 at 13:22 +0100, Matthias Brugger wrote: > > On 18/01/17 07:08, Chunfeng Yun wrote: > > usually, the reference clock comes from 26M oscillator directly, > > but some SoCs are not, add it for compatibility. > > > > Signed-off-by: Chunfeng Yun > > --- >

[PATCH v2] PM / Domains: Keep the pd status during system PM phases

If a PM domain is powered off before system suspend, we hope do nothing in system runtime suspend noirq phase and system runtime resume noirq phase. This modify is to slove system resume issue for RK3399. RK3399 SOC pd_gpu have voltage domain vdd_gpu, so we must follow open vdd_gpu and power on

Re: [PATCH 2/6] usb: mtu3: add reference clock

On Thu, 2017-01-19 at 13:22 +0100, Matthias Brugger wrote: > > On 18/01/17 07:08, Chunfeng Yun wrote: > > usually, the reference clock comes from 26M oscillator directly, > > but some SoCs are not, add it for compatibility. > > > > Signed-off-by: Chunfeng Yun > > --- > > drivers/usb/mtu3/mtu3.h

Re: [PATCH v1] PM / Domains: Keep the pd status during system PM phases

Hi Elaine, [auto build test WARNING on pm/linux-next] [also build test WARNING on v4.10-rc4 next-20170119] [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/Elaine-Zhang/PM-Domains-Keep-the-pd

Re: [PATCH v1] PM / Domains: Keep the pd status during system PM phases

Hi Elaine, [auto build test WARNING on pm/linux-next] [also build test WARNING on v4.10-rc4 next-20170119] [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/Elaine-Zhang/PM-Domains-Keep-the-pd

Re: [PATCH 0/4] Fixes for limits enforcement

On Wed, Jan 18, 2017 at 7:48 PM, Srinivas Pandruvada wrote: > This series includes fixes for sysfs limits enforcement. Only the > patch 1/4 is new in 4.10.rc, others are not new issues. OK I'll queue up the [1/4] as a fix for 4.10 and the rest for 4.11,

Re: [PATCH 0/4] Fixes for limits enforcement

On Wed, Jan 18, 2017 at 7:48 PM, Srinivas Pandruvada wrote: > This series includes fixes for sysfs limits enforcement. Only the > patch 1/4 is new in 4.10.rc, others are not new issues. OK I'll queue up the [1/4] as a fix for 4.10 and the rest for 4.11, then. Thanks, Rafael

Re: [PATCH v1] PM / Domains: Keep the pd status during system PM phases

Hi Elaine, [auto build test WARNING on pm/linux-next] [also build test WARNING on v4.10-rc4 next-20170119] [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/Elaine-Zhang/PM-Domains-Keep-the-pd

Re: [PATCH v1] PM / Domains: Keep the pd status during system PM phases

Hi Elaine, [auto build test WARNING on pm/linux-next] [also build test WARNING on v4.10-rc4 next-20170119] [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/Elaine-Zhang/PM-Domains-Keep-the-pd

Re: [PATCH 0/6] of_graph_get_remote_endpoint()

Hi Rob > This looks okay, but I think we need to be improving the graph api at > a higher level. Each user seems to be doing too much open coding of > walking of the graph. The user typically just wants the remote node > parent of a given port and endpoint number. Why does the user walk the >

Re: [PATCH 0/6] of_graph_get_remote_endpoint()

Hi Rob > This looks okay, but I think we need to be improving the graph api at > a higher level. Each user seems to be doing too much open coding of > walking of the graph. The user typically just wants the remote node > parent of a given port and endpoint number. Why does the user walk the >

Re: [PATCH v5 2/2] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

Hi Andrew, Andrew Lunn writes: >> Maybe I missed it, Andrew, can you confirm that 6341 is a proper Marvell >> family of switch chips? > > My understand is that it is. Marvell have not added it to DSDT. There > is a new SDK called UMSD, also GPLv2 and BSD. They call this family >

Re: [PATCH v5 2/2] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

Hi Andrew, Andrew Lunn writes: >> Maybe I missed it, Andrew, can you confirm that 6341 is a proper Marvell >> family of switch chips? > > My understand is that it is. Marvell have not added it to DSDT. There > is a new SDK called UMSD, also GPLv2 and BSD. They call this family > Topaz, and the

Re: [PATCH v5 1/2] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports

Hi Andrew, Andrew Lunn writes: >> Isn't there an hardware table used to map the PHY addresses on such chip? > > The 6390 has something like this. But if we can avoid it, lets keep it > KISS. I definitely agree. I was just curious about this new chip. Thanks, Vivien

Re: [PATCH v5 1/2] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports

Hi Andrew, Andrew Lunn writes: >> Isn't there an hardware table used to map the PHY addresses on such chip? > > The 6390 has something like this. But if we can avoid it, lets keep it > KISS. I definitely agree. I was just curious about this new chip. Thanks, Vivien

Re: [PATCH v2 1/3] dt: bindings: add documentation for zx2967 family watchdog controller

On Thu, Jan 19, 2017 at 09:59:50AM +0800, Baoyou Xie wrote: > This patch adds dt-binding documentation for zx2967 family > watchdog controller. > > Signed-off-by: Baoyou Xie It seems that the comments I put on v1 remains unresolved. > --- >

Re: [PATCH v2 1/3] dt: bindings: add documentation for zx2967 family watchdog controller

On Thu, Jan 19, 2017 at 09:59:50AM +0800, Baoyou Xie wrote: > This patch adds dt-binding documentation for zx2967 family > watchdog controller. > > Signed-off-by: Baoyou Xie It seems that the comments I put on v1 remains unresolved. > --- > .../bindings/watchdog/zte,zx2967-wdt.txt |

Re: [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support

On 2016/12/15 4:06, Marty Plummer wrote: > On 12/12/2016 01:11 AM, Jiancheng Xue wrote: >> >> >> On 2016/12/9 23:07, Marty Plummer wrote: >>> On 12/04/2016 08:03 PM, Jiancheng Xue wrote: Hi Arnd, On 2016/10/17 21:48, Arnd Bergmann wrote: > On Monday, October 17, 2016 8:07:03

Re: [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support

On 2016/12/15 4:06, Marty Plummer wrote: > On 12/12/2016 01:11 AM, Jiancheng Xue wrote: >> >> >> On 2016/12/9 23:07, Marty Plummer wrote: >>> On 12/04/2016 08:03 PM, Jiancheng Xue wrote: Hi Arnd, On 2016/10/17 21:48, Arnd Bergmann wrote: > On Monday, October 17, 2016 8:07:03

[PATCH v3 1/5] perf report: Refactor common code in srcline.c

Introduce dso__name() and filename_split() out of existing code because these codes will be used in several places in next patch. For filename_split(), it may also solve a potential memory leak in existing code. In existing addr2line(), sep = strchr(filename, ':'); if (sep) {

[PATCH v3 1/5] perf report: Refactor common code in srcline.c

Introduce dso__name() and filename_split() out of existing code because these codes will be used in several places in next patch. For filename_split(), it may also solve a potential memory leak in existing code. In existing addr2line(), sep = strchr(filename, ':'); if (sep) {

[PATCH v3 4/5] perf report: Show inline stack in stdio mode

If the address belongs to an inlined function, the source information back to the first non-inlined function will be printed. For example: perf report --stdio --inline-line |--56.76%--_start | __libc_start_main | main | --41.39%--main |

[PATCH v3 4/5] perf report: Show inline stack in stdio mode

If the address belongs to an inlined function, the source information back to the first non-inlined function will be printed. For example: perf report --stdio --inline-line |--56.76%--_start | __libc_start_main | main | --41.39%--main |

[PATCH v3 0/5] perf report: Show inline stack

v3: Iterate on RIPs of all callchain entries to check if the RIP is in inline functions. Reverse the order of the inliner printout if necessary. Provide new options "--inline-line" / "--inline-name" to print inline function name or print inline function source line. v2: Thanks

[PATCH v3 0/5] perf report: Show inline stack

v3: Iterate on RIPs of all callchain entries to check if the RIP is in inline functions. Reverse the order of the inliner printout if necessary. Provide new options "--inline-line" / "--inline-name" to print inline function name or print inline function source line. v2: Thanks

[PATCH v3 3/5] perf report: Create new inline options

It takes some time to look for inline stack for callgraph addresses. So it provides new options "--inline-line" and "--inline-name" to let user decide if enable this feature. --inline-name: If a callgraph address belongs to an inlined function, the inline stack will be printed. Each entry is the

[PATCH v3 2/5] perf report: Find the inline stack for a given address

It would be useful for perf to support a mode to query the inline stack for a given callgraph address. This would simplify finding the right code in code that does a lot of inlining. The srcline.c has contained the code which supports to translate the address to filename:line_nr. This patch just

[PATCH v3 5/5] perf report: Show inline stack in browser mode

If the address belongs to an inlined function, the source information back to the first non-inlined function will be printed. For example: perf report --inline-line Children Self Command Shared ObjectSymbol - 98.15%56.76% inline inline [.] main + 56.76%

[PATCH v3 3/5] perf report: Create new inline options

It takes some time to look for inline stack for callgraph addresses. So it provides new options "--inline-line" and "--inline-name" to let user decide if enable this feature. --inline-name: If a callgraph address belongs to an inlined function, the inline stack will be printed. Each entry is the

[PATCH v3 2/5] perf report: Find the inline stack for a given address

It would be useful for perf to support a mode to query the inline stack for a given callgraph address. This would simplify finding the right code in code that does a lot of inlining. The srcline.c has contained the code which supports to translate the address to filename:line_nr. This patch just

[PATCH v3 5/5] perf report: Show inline stack in browser mode

If the address belongs to an inlined function, the source information back to the first non-inlined function will be printed. For example: perf report --inline-line Children Self Command Shared ObjectSymbol - 98.15%56.76% inline inline [.] main + 56.76%

Re: [PATCH v2 0/9] Serial slave device bus

On 2017-01-16 23:54, Rob Herring wrote: Here's a new version of the serdev bus support with all the review feedback so far incorporated. I've left it named serdev for now pending any further votes one way or the other, but I did rename the sysfs visible portions to "serial". There's still

Re: [PATCH v2 0/9] Serial slave device bus

On 2017-01-16 23:54, Rob Herring wrote: Here's a new version of the serdev bus support with all the review feedback so far incorporated. I've left it named serdev for now pending any further votes one way or the other, but I did rename the sysfs visible portions to "serial". There's still

Re: [PATCH] ARM: ep93xx: Disable TS-72xx watchdog before uncompressing

On 12/19/2016 08:08 AM, Hartley Sweeten wrote: > On Sunday, December 18, 2016 7:08 PM, Florian Fainelli wrote: >> Le 12/11/16 à 11:16, Florian Fainelli a écrit : >>> The TS-72xx/73xx boards have a CPLD watchdog which is configured to >>> reset the board after 8 seconds, if the kernel is large

Re: [PATCH] ARM: ep93xx: Disable TS-72xx watchdog before uncompressing

On 12/19/2016 08:08 AM, Hartley Sweeten wrote: > On Sunday, December 18, 2016 7:08 PM, Florian Fainelli wrote: >> Le 12/11/16 à 11:16, Florian Fainelli a écrit : >>> The TS-72xx/73xx boards have a CPLD watchdog which is configured to >>> reset the board after 8 seconds, if the kernel is large

[PATCH] mn10300: fix build error of missing fpu_save()

I have 21 occurrences of kbuild test robot reporting this build failure over more than one year and zero (0) attempts to fix it. I have 2 alternate (untested) fixes for it. (If either of them causes a build error, it should be simple to fix and I will do so.) a. #include in so that empty

[PATCH] mn10300: fix build error of missing fpu_save()

I have 21 occurrences of kbuild test robot reporting this build failure over more than one year and zero (0) attempts to fix it. I have 2 alternate (untested) fixes for it. (If either of them causes a build error, it should be simple to fix and I will do so.) a. #include in so that empty

Re: [PATCH v5 2/2] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

On Thu, Jan 19, 2017 at 05:26:03PM -0500, Vivien Didelot wrote: > Gregory CLEMENT writes: > > > +static bool mv88e6xxx_6341_family(struct mv88e6xxx_chip *chip) > > +{ > > + return chip->info->family == MV88E6XXX_FAMILY_6341; > > +} > > I don't want to see

Re: [PATCH v5 2/2] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

On Thu, Jan 19, 2017 at 05:26:03PM -0500, Vivien Didelot wrote: > Gregory CLEMENT writes: > > > +static bool mv88e6xxx_6341_family(struct mv88e6xxx_chip *chip) > > +{ > > + return chip->info->family == MV88E6XXX_FAMILY_6341; > > +} > > I don't want to see these erronous family checks anymore,

[GIT PULL] ARM: SoC fixes

Hi Linus, The following changes since commit 1b9ec81258827001c869f003e0b8dd2ddc104717: Merge tag 'davinci-fixes-for-v4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into fixes (2017-01-04 16:43:00 +0100) are available in the git repository at:

[GIT PULL] ARM: SoC fixes

Hi Linus, The following changes since commit 1b9ec81258827001c869f003e0b8dd2ddc104717: Merge tag 'davinci-fixes-for-v4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into fixes (2017-01-04 16:43:00 +0100) are available in the git repository at:

Re: [PATCH] powerpc/rtas_flash: Move an assignment for the variable "rc" in manage_flash_write()

On 01/19/2017 12:33 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 19 Jan 2017 21:20:09 +0100 > > A local variable was set to an error code before a concrete error situation > was detected. Thus move the corresponding assignment into an if branch

Re: [PATCH] powerpc/rtas_flash: Move an assignment for the variable "rc" in manage_flash_write()

On 01/19/2017 12:33 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 19 Jan 2017 21:20:09 +0100 > > A local variable was set to an error code before a concrete error situation > was detected. Thus move the corresponding assignment into an if branch > to indicate a software

Re: [PATCH 3/8] powerpc/nvram: Move an assignment for the variable "ret" in dev_nvram_write()

On 01/19/2017 08:56 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 19 Jan 2017 15:55:36 +0100 > > A local variable was set to an error code before a concrete error situation > was detected. Thus move the corresponding assignment into an if branch

Re: [PATCH 3/8] powerpc/nvram: Move an assignment for the variable "ret" in dev_nvram_write()

On 01/19/2017 08:56 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 19 Jan 2017 15:55:36 +0100 > > A local variable was set to an error code before a concrete error situation > was detected. Thus move the corresponding assignment into an if branch > to indicate a software

[PATCH v7 3/3] ARM: dts: imx6q-evi: support cyclone-ps-spi

Add support for Altera cyclone V FPGA connected to an spi port to the evi devicetree file Signed-off-by: Joshua Clayton --- arch/arm/boot/dts/imx6q-evi.dts | 16 1 file changed, 16 insertions(+) diff --git a/arch/arm/boot/dts/imx6q-evi.dts

[PATCH v7 3/3] ARM: dts: imx6q-evi: support cyclone-ps-spi

Add support for Altera cyclone V FPGA connected to an spi port to the evi devicetree file Signed-off-by: Joshua Clayton --- arch/arm/boot/dts/imx6q-evi.dts | 16 1 file changed, 16 insertions(+) diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts

[PATCH v7 2/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs

cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial" interface on Altera Cyclone FPGAS. This is one of the simpler ways to set up an FPGA at runtime. The signal interface is close to unidirectional spi with lsb first. Signed-off-by: Joshua Clayton

[PATCH v7 2/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs

cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial" interface on Altera Cyclone FPGAS. This is one of the simpler ways to set up an FPGA at runtime. The signal interface is close to unidirectional spi with lsb first. Signed-off-by: Joshua Clayton --- drivers/fpga/Kconfig

[PATCH v7 0/3] Altera Cyclone Passive Serial SPI FPGA Manager

This series adds an FPGA manager for Altera cyclone FPGAs that can program them using an spi port and a couple of gpios, using Alteras passive serial protocol. Changes from v6: - moved bitrev8x4() out (I'll submit it in a separate patch set) - Changed the dts format to match what is already done

[PATCH v7 0/3] Altera Cyclone Passive Serial SPI FPGA Manager

This series adds an FPGA manager for Altera cyclone FPGAs that can program them using an spi port and a couple of gpios, using Alteras passive serial protocol. Changes from v6: - moved bitrev8x4() out (I'll submit it in a separate patch set) - Changed the dts format to match what is already done

Re: [PATCH 1/3] Input: add STMicroelectronics FingerTip touchscreen driver

Hi Rob, > > +- compatible : must be "st,stmfts" > > Seems too generic. Is this a single device? the device is precisely called ST-Microelectronics FingerTip S (stmfts). There are variants, but they all have the same name and same datasheet. Maybe I can be more specific in the

Re: [PATCH 1/3] Input: add STMicroelectronics FingerTip touchscreen driver

Hi Rob, > > +- compatible : must be "st,stmfts" > > Seems too generic. Is this a single device? the device is precisely called ST-Microelectronics FingerTip S (stmfts). There are variants, but they all have the same name and same datasheet. Maybe I can be more specific in the

[PATCH v7 1/3] doc: dt: add cyclone-ps-spi binding document

Describe a cyclone-ps-spi devicetree entry, required features Signed-off-by: Joshua Clayton --- .../bindings/fpga/altera-passive-serial.txt| 25 ++ 1 file changed, 25 insertions(+) create mode 100644

[PATCH v7 1/3] doc: dt: add cyclone-ps-spi binding document

Describe a cyclone-ps-spi devicetree entry, required features Signed-off-by: Joshua Clayton --- .../bindings/fpga/altera-passive-serial.txt| 25 ++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/fpga/altera-passive-serial.txt

Re: [PATCH v3 06/12] mm: track active portions of a section at boot

On Thu, 19 Jan 2017 14:07:13 -0800 Dan Williams wrote: > Prepare for hot{plug,remove} of sub-ranges of a section by tracking a > section active bitmask, each bit representing 2MB (SECTION_SIZE (128M) / > map_active bitmask length (64)). > > ---

Re: [PATCH v3 06/12] mm: track active portions of a section at boot

On Thu, 19 Jan 2017 14:07:13 -0800 Dan Williams wrote: > Prepare for hot{plug,remove} of sub-ranges of a section by tracking a > section active bitmask, each bit representing 2MB (SECTION_SIZE (128M) / > map_active bitmask length (64)). > > --- a/include/linux/mmzone.h > +++

Re: [RFC for GIT] pull-request: add praise to people doing QA

On Thu, Jan 19, 2017 at 4:06 PM, Joe Perches wrote:>> This sounds interesting to me! When I have some more time to take a >> look at this i might see if I can revive it. > > Can the terminology please be standardized to what > was once called bylines? > >

Re: [RFC for GIT] pull-request: add praise to people doing QA

On Thu, Jan 19, 2017 at 4:06 PM, Joe Perches wrote:>> This sounds interesting to me! When I have some more time to take a >> look at this i might see if I can revive it. > > Can the terminology please be standardized to what > was once called bylines? > >

Re: [PATCH 7/7] ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-eval

Hi Fabrice, [auto build test ERROR on next-20170119] [cannot apply to iio/togreg robh/for-next v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.10-rc4] [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/Fabrice

Re: [PATCH 7/7] ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-eval

Hi Fabrice, [auto build test ERROR on next-20170119] [cannot apply to iio/togreg robh/for-next v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.10-rc4] [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/Fabrice

Re: [PATCH v5 1/2] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports

On Thu, Jan 19, 2017 at 05:13:12PM -0500, Vivien Didelot wrote: > Hi Gregory, > > Gregory CLEMENT writes: > > > From: Romain Perier > > > > Some Marvell ethernet switches have internal ethernet transceivers with > >

Re: [PATCH v5 1/2] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports

On Thu, Jan 19, 2017 at 05:13:12PM -0500, Vivien Didelot wrote: > Hi Gregory, > > Gregory CLEMENT writes: > > > From: Romain Perier > > > > Some Marvell ethernet switches have internal ethernet transceivers with > > hardcoded phy addresses. These addresses can be greater than the number > > of

<    1   2   3   4   5   6   7   8   9   10   >