Re: [PATCH] nvme-loop: add configfs dependency

On Sun, 2016-07-10 at 14:14 +0200, Christoph Hellwig wrote: > On Thu, Jul 07, 2016 at 08:35:17AM -0600, Jens Axboe wrote: > > Thanks Arnd, applied. > > Actually I think we should replace the select with the depends. In > fact I though I had done that a while ago, but I must have messed it > up.

Re: [PATCH] nvme-loop: add configfs dependency

On Sun, 2016-07-10 at 14:14 +0200, Christoph Hellwig wrote: > On Thu, Jul 07, 2016 at 08:35:17AM -0600, Jens Axboe wrote: > > Thanks Arnd, applied. > > Actually I think we should replace the select with the depends. In > fact I though I had done that a while ago, but I must have messed it > up.

[RESEND PATCH] drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency

Commit aeefb36832e5 ("drm/exynos: gsc: add device tree support and remove usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use the same HW IP block. But added the dependency as depends on

[RESEND PATCH] drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency

Commit aeefb36832e5 ("drm/exynos: gsc: add device tree support and remove usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use the same HW IP block. But added the dependency as depends on

Re: [PATCH V2 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

On 07/11/2016 08:14 AM, Rob Herring wrote: On Thu, Jul 07, 2016 at 12:35:02PM -0600, Stephen Warren wrote: On 07/07/2016 12:13 PM, Sivaram Nair wrote: On Tue, Jul 05, 2016 at 05:04:22PM +0800, Joseph Lo wrote: Add DT binding for the Hardware Synchronization Primitives (HSP). The HSP is

Re: [PATCH V2 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

On 07/11/2016 08:14 AM, Rob Herring wrote: On Thu, Jul 07, 2016 at 12:35:02PM -0600, Stephen Warren wrote: On 07/07/2016 12:13 PM, Sivaram Nair wrote: On Tue, Jul 05, 2016 at 05:04:22PM +0800, Joseph Lo wrote: Add DT binding for the Hardware Synchronization Primitives (HSP). The HSP is

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

On Mon, 2016-07-11 at 11:18 -0400, Prarit Bhargava wrote: > Didn't get any feedback or review comments on this patch.  Resending > ... > > P. Sorry, this got flooded down my inbox. > ---8<--- > > The iwlwifi driver implements a thermal zone and hwmon device, but > returns -EIO on temperature

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

On Mon, 2016-07-11 at 11:18 -0400, Prarit Bhargava wrote: > Didn't get any feedback or review comments on this patch.  Resending > ... > > P. Sorry, this got flooded down my inbox. > ---8<--- > > The iwlwifi driver implements a thermal zone and hwmon device, but > returns -EIO on temperature

Re: [PATCH 2/2] bus: mvebu-mbus: make mvebu_mbus_syscore_ops static

Hi Ben, On mar., juin 21 2016, Arnd Bergmann wrote: > On Tuesday, June 21, 2016 4:16:19 PM CEST Ben Dooks wrote: >> >> -struct syscore_ops mvebu_mbus_syscore_ops = { >> +static struct syscore_ops mvebu_mbus_syscore_ops = { >> .suspend= mvebu_mbus_suspend, >>

Re: [PATCH 2/2] bus: mvebu-mbus: make mvebu_mbus_syscore_ops static

Hi Ben, On mar., juin 21 2016, Arnd Bergmann wrote: > On Tuesday, June 21, 2016 4:16:19 PM CEST Ben Dooks wrote: >> >> -struct syscore_ops mvebu_mbus_syscore_ops = { >> +static struct syscore_ops mvebu_mbus_syscore_ops = { >> .suspend= mvebu_mbus_suspend, >> .resume

Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

On 07/11/2016 08:22 AM, Rob Herring wrote: On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote: The BPMP is a specific processor in Tegra chip, which is designed for booting process handling and offloading the power management, clock management, and reset control tasks from the CPU. The

Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

On 07/11/2016 08:22 AM, Rob Herring wrote: On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote: The BPMP is a specific processor in Tegra chip, which is designed for booting process handling and offloading the power management, clock management, and reset control tasks from the CPU. The

Re: [PATCH] capabilities: audit capability use

On 07/11/16 15:25, Serge E. Hallyn wrote: > Quoting Topi Miettinen (toiwo...@gmail.com): >> There are many basic ways to control processes, including capabilities, >> cgroups and resource limits. However, there are far fewer ways to find >> out useful values for the limits, except blind trial and

Re: [PATCH] capabilities: audit capability use

On 07/11/16 15:25, Serge E. Hallyn wrote: > Quoting Topi Miettinen (toiwo...@gmail.com): >> There are many basic ways to control processes, including capabilities, >> cgroups and resource limits. However, there are far fewer ways to find >> out useful values for the limits, except blind trial and

Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map

On 11/07/2016 17:52, Radim Krčmář wrote: > 2016-07-11 16:14+0200, Paolo Bonzini: >> On 11/07/2016 15:48, Radim Krčmář wrote: > I guess the easiest solution is to replace kvm_apic_id with a field in > struct kvm_lapic, which is already shifted right by 24 in xAPIC mode. >>> >>> (I guess

Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map

On 11/07/2016 17:52, Radim Krčmář wrote: > 2016-07-11 16:14+0200, Paolo Bonzini: >> On 11/07/2016 15:48, Radim Krčmář wrote: > I guess the easiest solution is to replace kvm_apic_id with a field in > struct kvm_lapic, which is already shifted right by 24 in xAPIC mode. >>> >>> (I guess

Re: [PATCH v2 01/10] ARM: NUC900: Add nuc970 machine support

On Sunday, July 10, 2016 3:27:21 PM CEST Wan Zongshun wrote: > +ifeq ($(CONFIG_SOC_NUC970),) > obj-y := irq.o time.o mfp.o gpio.o clock.o > obj-y += clksel.o dev.o cpu.o > +endif > # W90X900 CPU support files When mfp.o is disabled like this, I

Re: [PATCH v2 01/10] ARM: NUC900: Add nuc970 machine support

On Sunday, July 10, 2016 3:27:21 PM CEST Wan Zongshun wrote: > +ifeq ($(CONFIG_SOC_NUC970),) > obj-y := irq.o time.o mfp.o gpio.o clock.o > obj-y += clksel.o dev.o cpu.o > +endif > # W90X900 CPU support files When mfp.o is disabled like this, I

Re: [patch 53/66] MIPS: Loongson-3: Convert oprofile to hotplug state machine

Thank, looks ok. I assume you want to merge this with the remainder of of the series, so: Acked-by: Ralf Baechle Ralf

Re: [patch 53/66] MIPS: Loongson-3: Convert oprofile to hotplug state machine

Thank, looks ok. I assume you want to merge this with the remainder of of the series, so: Acked-by: Ralf Baechle Ralf

Re: [PATCH 10/10] perf script python: Fix string vs byte array resolving

On Sun, 10 Jul 2016 13:08:02 +0200 Jiri Olsa wrote: > Jirka reported that python code returns all arrays as strings. > This makes impossible to get all items for byte array tracepoint > field containing 0x00 value item. > > Fixing this by scanning full length of the array and

Re: [PATCH 10/10] perf script python: Fix string vs byte array resolving

On Sun, 10 Jul 2016 13:08:02 +0200 Jiri Olsa wrote: > Jirka reported that python code returns all arrays as strings. > This makes impossible to get all items for byte array tracepoint > field containing 0x00 value item. > > Fixing this by scanning full length of the array and returning > it as

RE: [PATCH 1/3] iio: accel: bma220_spi: set up buffer timestamps for non-zero values

> -Original Message- > From: Alison Schofield [mailto:amsfiel...@gmail.com] > Sent: Monday, July 11, 2016 6:25 PM > To: ji...@kernel.org > Cc: Breana, Tiberiu A ; mranos...@gmail.com; > knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; linux- >

RE: [PATCH 1/3] iio: accel: bma220_spi: set up buffer timestamps for non-zero values

> -Original Message- > From: Alison Schofield [mailto:amsfiel...@gmail.com] > Sent: Monday, July 11, 2016 6:25 PM > To: ji...@kernel.org > Cc: Breana, Tiberiu A ; mranos...@gmail.com; > knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; linux- > i...@vger.kernel.org;

RE: [PATCH 2/3] iio: humidity: am2315: set up buffer timestamps for non-zero values

> -Original Message- > From: Alison Schofield [mailto:amsfiel...@gmail.com] > Sent: Monday, July 11, 2016 6:26 PM > To: ji...@kernel.org > Cc: Breana, Tiberiu A ; mranos...@gmail.com; > knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; linux- >

RE: [PATCH 2/3] iio: humidity: am2315: set up buffer timestamps for non-zero values

> -Original Message- > From: Alison Schofield [mailto:amsfiel...@gmail.com] > Sent: Monday, July 11, 2016 6:26 PM > To: ji...@kernel.org > Cc: Breana, Tiberiu A ; mranos...@gmail.com; > knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; linux- > i...@vger.kernel.org;

Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map

2016-07-11 16:14+0200, Paolo Bonzini: > On 11/07/2016 15:48, Radim Krčmář wrote: I guess the easiest solution is to replace kvm_apic_id with a field in struct kvm_lapic, which is already shifted right by 24 in xAPIC mode. >> >> (I guess the fewest LOC is to look at vcpu->vcpu_id, which

Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map

2016-07-11 16:14+0200, Paolo Bonzini: > On 11/07/2016 15:48, Radim Krčmář wrote: I guess the easiest solution is to replace kvm_apic_id with a field in struct kvm_lapic, which is already shifted right by 24 in xAPIC mode. >> >> (I guess the fewest LOC is to look at vcpu->vcpu_id, which

Re: PCIe MSI address is not written at pci_enable_msi_range call

On 11/07/16 11:51, Bharat Kumar Gogada wrote: >>> Hi Marc, >>> >>> Thanks for the reply. >>> >>> From PCIe Spec: >>> MSI Enable Bit: >>> If 1 and the MSI-X Enable bit in the MSI-X Message >>> Control register (see Section 6.8.2.3) is 0, the >>> function is permitted to use MSI to request service

Re: [PATCH v8 4/4] serial: pl011: add console matching function

On 11/07/16 16:40, Matthias Brugger wrote: I tried to apply these patches against linux-next. They needed some changes to apply, which is quite normal after such a long time. Apart from that the DBG2 subtype patch didn't end up in mainline, so this patches do not compile. I followed up on

Re: [PATCH v8 4/4] serial: pl011: add console matching function

On 11/07/16 16:40, Matthias Brugger wrote: I tried to apply these patches against linux-next. They needed some changes to apply, which is quite normal after such a long time. Apart from that the DBG2 subtype patch didn't end up in mainline, so this patches do not compile. I followed up on

Re: PCIe MSI address is not written at pci_enable_msi_range call

On 11/07/16 11:51, Bharat Kumar Gogada wrote: >>> Hi Marc, >>> >>> Thanks for the reply. >>> >>> From PCIe Spec: >>> MSI Enable Bit: >>> If 1 and the MSI-X Enable bit in the MSI-X Message >>> Control register (see Section 6.8.2.3) is 0, the >>> function is permitted to use MSI to request service

Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

On 07/11/2016 07:45 AM, Andy Lutomirski wrote: > On Mon, Jul 11, 2016 at 7:34 AM, Dave Hansen wrote: >> Should we instead just recommend to userspace that they lock down access >> to keys by default in all threads as a best practice? > > Is that really better than doing it

Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

On 07/11/2016 07:45 AM, Andy Lutomirski wrote: > On Mon, Jul 11, 2016 at 7:34 AM, Dave Hansen wrote: >> Should we instead just recommend to userspace that they lock down access >> to keys by default in all threads as a best practice? > > Is that really better than doing it in-kernel? My concern

Re: [Query] Preemption (hogging) of the work handler

it some time ago (not the current version, tho), but I think I lost it by now, don't have to deal with 3.10 anymore. I'll re-spin the series in a day or two, I think. A rebased version (against next-20160711), basically, has only that KERN_CONT patch as part of 0001 now: http://marc.info/?l=linux-kernel=146717692431893 hopefully it will re-fresh the discussion and I'll be able to polish the series so Andrew will be less sceptical about the whole thing. -ss

Re: [Query] Preemption (hogging) of the work handler

it some time ago (not the current version, tho), but I think I lost it by now, don't have to deal with 3.10 anymore. I'll re-spin the series in a day or two, I think. A rebased version (against next-20160711), basically, has only that KERN_CONT patch as part of 0001 now: http://marc.info/?l=linux-kernel=146717692431893 hopefully it will re-fresh the discussion and I'll be able to polish the series so Andrew will be less sceptical about the whole thing. -ss

Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

On Sunday, July 10, 2016 3:27:22 PM CEST Wan Zongshun wrote: > + > +#if !defined(CONFIG_SOC_NUC900) > #define NR_IRQS(IRQ_ADC+1) > +#else > +#define NR_IRQS62 > +#endif > The Kconfig symbols are a bit confusing here: CONFIG_SOC_NUC900 controls the compilation of

Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

On Sunday, July 10, 2016 3:27:22 PM CEST Wan Zongshun wrote: > + > +#if !defined(CONFIG_SOC_NUC900) > #define NR_IRQS(IRQ_ADC+1) > +#else > +#define NR_IRQS62 > +#endif > The Kconfig symbols are a bit confusing here: CONFIG_SOC_NUC900 controls the compilation of

Re: System freezes after OOM

On Mon, 11 Jul 2016, Ondrej Kozina wrote: > On 07/11/2016 01:55 PM, Jerome Marchand wrote: > > On 07/11/2016 01:03 PM, Stanislav Kozina wrote: > > > Hi Jerome, > > > > > > On upstream mailing lists there have been reports of freezing systems > > > due to OOM. Ondra (on CC) managed to reproduce

Re: System freezes after OOM

On Mon, 11 Jul 2016, Ondrej Kozina wrote: > On 07/11/2016 01:55 PM, Jerome Marchand wrote: > > On 07/11/2016 01:03 PM, Stanislav Kozina wrote: > > > Hi Jerome, > > > > > > On upstream mailing lists there have been reports of freezing systems > > > due to OOM. Ondra (on CC) managed to reproduce

Re: KASAN vs vmapped stacks

On 07/11/2016 01:29 PM, Dmitry Vyukov wrote: > On Mon, Jul 11, 2016 at 11:57 AM, Andrey Ryabinin > wrote: >> >> >> On 07/10/2016 03:47 PM, Andy Lutomirski wrote: >>> Hi all- >>> >>> I found two nasty issues with virtually mapped stacks if KASAN is >>> enabled. The

Re: KASAN vs vmapped stacks

On 07/11/2016 01:29 PM, Dmitry Vyukov wrote: > On Mon, Jul 11, 2016 at 11:57 AM, Andrey Ryabinin > wrote: >> >> >> On 07/10/2016 03:47 PM, Andy Lutomirski wrote: >>> Hi all- >>> >>> I found two nasty issues with virtually mapped stacks if KASAN is >>> enabled. The first issue is a crash: the

Re: Hi, Ingo, would you please help drop the TSC MSR calibration patch

On Mon, 11 Jul 2016 07:59:19 -0700 "Chen, Yu C" wrote: > Currently it is in your x86/timer tree: > > commit fc273eeef314cdaf0ac992b400d126f8184a4d1c > Author: Len Brown > Date: Fri Jun 17 01:22:49 2016 -0400 > > x86/tsc_msr: Extend to include

Re: Hi, Ingo, would you please help drop the TSC MSR calibration patch

On Mon, 11 Jul 2016 07:59:19 -0700 "Chen, Yu C" wrote: > Currently it is in your x86/timer tree: > > commit fc273eeef314cdaf0ac992b400d126f8184a4d1c > Author: Len Brown > Date: Fri Jun 17 01:22:49 2016 -0400 > > x86/tsc_msr: Extend to include Intel Core Architecture > > > Previously

Re: Resend: Another 4.4 to 4.5 floppy issue

On Tue, 5 Jul 2016, Mark Hounschell wrote: > From: Jiri Kosina > > Commit 09954bad4 ("floppy: refactor open() flags handling"), as a > side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that > this is being used setfdprm userspace for ioctl-only open(). > >

Re: Resend: Another 4.4 to 4.5 floppy issue

On Tue, 5 Jul 2016, Mark Hounschell wrote: > From: Jiri Kosina > > Commit 09954bad4 ("floppy: refactor open() flags handling"), as a > side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that > this is being used setfdprm userspace for ioctl-only open(). > > Reintroduce back

Re: [PATCH v2 03/10] Clocksource: add nuc970 clocksource driver

On Sunday, July 10, 2016 3:27:23 PM CEST Wan Zongshun wrote: > > +config NUC900_TIMER > +bool "Clocksource timer for nuc900 platform" if COMPILE_TEST > +depends on ARM > +select CLKSRC_OF if OF > +select CLKSRC_MMIO > +help > + Enables the

Re: [PATCH v2 03/10] Clocksource: add nuc970 clocksource driver

On Sunday, July 10, 2016 3:27:23 PM CEST Wan Zongshun wrote: > > +config NUC900_TIMER > +bool "Clocksource timer for nuc900 platform" if COMPILE_TEST > +depends on ARM > +select CLKSRC_OF if OF > +select CLKSRC_MMIO > +help > + Enables the

Re: [PATCH] mtd: nand: brcmnand: Change BUG_ON in brcmnand_send_cmd

On Sat, Jul 9, 2016 at 9:30 PM, Brian Norris wrote: > On Fri, Jul 08, 2016 at 10:36:39AM -0700, Florian Fainelli wrote: >> Change the BUG_ON() condition in brcmnand_send_cmd() which checks for >> the interrupt status "controller ready" bit to a WARN_ON. >> >> There is

Re: [PATCH] mtd: nand: brcmnand: Change BUG_ON in brcmnand_send_cmd

On Sat, Jul 9, 2016 at 9:30 PM, Brian Norris wrote: > On Fri, Jul 08, 2016 at 10:36:39AM -0700, Florian Fainelli wrote: >> Change the BUG_ON() condition in brcmnand_send_cmd() which checks for >> the interrupt status "controller ready" bit to a WARN_ON. >> >> There is no good reason to kill the

Re: [PATCH 3/7] security,overlayfs: Provide security hook for copy up of xattrs for overlay file

On 07/08/2016 12:19 PM, Vivek Goyal wrote: > Provide a security hook which is called when xattrs of a file are being > copied up. This hook is called once for each xattr and LSM can return 0 > to access the xattr, 1 to reject xattr, -EOPNOTSUPP if none of the lsms > claim to know xattr and a

Re: [PATCH 3/7] security,overlayfs: Provide security hook for copy up of xattrs for overlay file

On 07/08/2016 12:19 PM, Vivek Goyal wrote: > Provide a security hook which is called when xattrs of a file are being > copied up. This hook is called once for each xattr and LSM can return 0 > to access the xattr, 1 to reject xattr, -EOPNOTSUPP if none of the lsms > claim to know xattr and a

[tip:irq/core] irqdomain: Fix irq_domain_alloc_irqs_recursive() error handling

Commit-ID: a1b7b1a57b9919a0abb6c93fca04ac9cf840c992 Gitweb: http://git.kernel.org/tip/a1b7b1a57b9919a0abb6c93fca04ac9cf840c992 Author: Alexander Popov AuthorDate: Sun, 3 Jul 2016 03:24:08 +0300 Committer: Thomas Gleixner CommitDate: Mon, 11 Jul

[tip:irq/core] irqdomain: Fix irq_domain_alloc_irqs_recursive() error handling

Commit-ID: a1b7b1a57b9919a0abb6c93fca04ac9cf840c992 Gitweb: http://git.kernel.org/tip/a1b7b1a57b9919a0abb6c93fca04ac9cf840c992 Author: Alexander Popov AuthorDate: Sun, 3 Jul 2016 03:24:08 +0300 Committer: Thomas Gleixner CommitDate: Mon, 11 Jul 2016 17:23:48 +0200 irqdomain: Fix

[tip:timers/urgent] posix_cpu_timer: Exit early when process has been reaped

Commit-ID: 2c13ce8f6b2f6fd9ba2f9261b1939fc0f62d1307 Gitweb: http://git.kernel.org/tip/2c13ce8f6b2f6fd9ba2f9261b1939fc0f62d1307 Author: Alexey Dobriyan AuthorDate: Fri, 8 Jul 2016 01:39:11 +0300 Committer: Thomas Gleixner CommitDate: Mon, 11 Jul

[tip:timers/urgent] posix_cpu_timer: Exit early when process has been reaped

Commit-ID: 2c13ce8f6b2f6fd9ba2f9261b1939fc0f62d1307 Gitweb: http://git.kernel.org/tip/2c13ce8f6b2f6fd9ba2f9261b1939fc0f62d1307 Author: Alexey Dobriyan AuthorDate: Fri, 8 Jul 2016 01:39:11 +0300 Committer: Thomas Gleixner CommitDate: Mon, 11 Jul 2016 17:20:12 +0200 posix_cpu_timer:

[PATCH 3/3] iio: proximity: as3935: set up buffer timestamps for non-zero values

Use the iio_pollfunc_store_time parameter during triggered buffer set-up to get valid timestamps. Signed-off-by: Alison Schofield Cc: Daniel Baluta --- drivers/iio/proximity/as3935.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 3/3] iio: proximity: as3935: set up buffer timestamps for non-zero values

Use the iio_pollfunc_store_time parameter during triggered buffer set-up to get valid timestamps. Signed-off-by: Alison Schofield Cc: Daniel Baluta --- drivers/iio/proximity/as3935.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/proximity/as3935.c

[PATCH 2/3] iio: humidity: am2315: set up buffer timestamps for non-zero values

Use the iio_pollfunc_store_time parameter during triggered buffer set-up to get valid timestamps. Signed-off-by: Alison Schofield Cc: Daniel Baluta --- drivers/iio/humidity/am2315.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/3] iio: humidity: am2315: set up buffer timestamps for non-zero values

Use the iio_pollfunc_store_time parameter during triggered buffer set-up to get valid timestamps. Signed-off-by: Alison Schofield Cc: Daniel Baluta --- drivers/iio/humidity/am2315.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/humidity/am2315.c

Re: [PATCH] ARM: dts: da850: Add new ECAP and EPWM bindings

On 07/04/2016 07:47 AM, Sekhar Nori wrote: > On Monday 27 June 2016 07:44 PM, Franklin S Cooper Jr wrote: >> From: "Cooper Jr., Franklin" >> >> Switch to a new ECAP and EPWM bindings that doesn't depend on hwmod to >> provide the various required clocks. > > there is nothing

[PATCH 1/3] iio: accel: bma220_spi: set up buffer timestamps for non-zero values

Use the iio_pollfunc_store_time parameter during triggered buffer set-up to get valid timestamps. Signed-off-by: Alison Schofield Cc: Daniel Baluta --- drivers/iio/accel/bma220_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH] ARM: dts: da850: Add new ECAP and EPWM bindings

On 07/04/2016 07:47 AM, Sekhar Nori wrote: > On Monday 27 June 2016 07:44 PM, Franklin S Cooper Jr wrote: >> From: "Cooper Jr., Franklin" >> >> Switch to a new ECAP and EPWM bindings that doesn't depend on hwmod to >> provide the various required clocks. > > there is nothing called hwmod on

[PATCH 1/3] iio: accel: bma220_spi: set up buffer timestamps for non-zero values

Use the iio_pollfunc_store_time parameter during triggered buffer set-up to get valid timestamps. Signed-off-by: Alison Schofield Cc: Daniel Baluta --- drivers/iio/accel/bma220_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/accel/bma220_spi.c

Re: [PATCH] capabilities: audit capability use

Quoting Topi Miettinen (toiwo...@gmail.com): > There are many basic ways to control processes, including capabilities, > cgroups and resource limits. However, there are far fewer ways to find > out useful values for the limits, except blind trial and error. > > Currently, there is no way to know

Re: [PATCH] capabilities: audit capability use

Quoting Topi Miettinen (toiwo...@gmail.com): > There are many basic ways to control processes, including capabilities, > cgroups and resource limits. However, there are far fewer ways to find > out useful values for the limits, except blind trial and error. > > Currently, there is no way to know

[PATCH 0/3] iio: complete the setup of buffer timestamps

These drivers are using iio_poll_func->timestamp in their triggered buffer handler as the timestamp pushed to buffer. Problem is that it was not set up at probe time via iio_triggered_buffer_setup(), so timestamp is always 0. Buffer space has been allocated for the timestamp, so it seems to be

Re: [PATCH v2 6/6] dmaengine: pl330: Make sure microcode is privileged-executable

On 09/07/16 03:09, Mitchel Humpherys wrote: > The PL330 can perform privileged instruction fetches. This can result Nit: "can" is a bit of an understatement. Instruction fetches on both the manager and channel threads have the "privileged" and "instruction" AxPROT bits hard-coded whether you

[PATCH 0/3] iio: complete the setup of buffer timestamps

These drivers are using iio_poll_func->timestamp in their triggered buffer handler as the timestamp pushed to buffer. Problem is that it was not set up at probe time via iio_triggered_buffer_setup(), so timestamp is always 0. Buffer space has been allocated for the timestamp, so it seems to be

Re: [PATCH v2 6/6] dmaengine: pl330: Make sure microcode is privileged-executable

On 09/07/16 03:09, Mitchel Humpherys wrote: > The PL330 can perform privileged instruction fetches. This can result Nit: "can" is a bit of an understatement. Instruction fetches on both the manager and channel threads have the "privileged" and "instruction" AxPROT bits hard-coded whether you

Re: [PATCH 1/7] security, overlayfs: provide copy up security hook for unioned files

On 07/08/2016 12:19 PM, Vivek Goyal wrote: > Provide a security hook to label new file correctly when a file is copied > up from lower layer to upper layer of a overlay/union mount. > > This hook can prepare a new set of creds which are suitable for new file > creation during copy up. Caller will

Re: [PATCH 1/7] security, overlayfs: provide copy up security hook for unioned files

On 07/08/2016 12:19 PM, Vivek Goyal wrote: > Provide a security hook to label new file correctly when a file is copied > up from lower layer to upper layer of a overlay/union mount. > > This hook can prepare a new set of creds which are suitable for new file > creation during copy up. Caller will

Re: [PATCH 00/30] ACPICA: 20160318 Release

On 11/07/16 16:54, Rafael J. Wysocki wrote: On Monday, July 11, 2016 04:48:26 PM Rafael J. Wysocki wrote: On Monday, July 11, 2016 04:38:17 PM Matthias Brugger wrote: Hi Rafael, On 24/03/16 14:08, Rafael J. Wysocki wrote: On Thu, Mar 24, 2016 at 2:38 AM, Lv Zheng

Re: [PATCH 00/30] ACPICA: 20160318 Release

On 11/07/16 16:54, Rafael J. Wysocki wrote: On Monday, July 11, 2016 04:48:26 PM Rafael J. Wysocki wrote: On Monday, July 11, 2016 04:38:17 PM Matthias Brugger wrote: Hi Rafael, On 24/03/16 14:08, Rafael J. Wysocki wrote: On Thu, Mar 24, 2016 at 2:38 AM, Lv Zheng wrote: The 20160318

Re: [PATCH 1/1] irqdomain: Fix irq_domain_alloc_irqs_recursive() error handling

On 03/07/16 01:24, Alexander Popov wrote: > If an irq_domain is auto-recursive and irq_domain_alloc_irqs_recursive() > for its parent has returned an error, then do return and avoid calling > irq_domain_free_irqs_recursive() uselessly, because: > - if domain->ops->alloc() had failed for an

Re: [PATCH 1/1] irqdomain: Fix irq_domain_alloc_irqs_recursive() error handling

On 03/07/16 01:24, Alexander Popov wrote: > If an irq_domain is auto-recursive and irq_domain_alloc_irqs_recursive() > for its parent has returned an error, then do return and avoid calling > irq_domain_free_irqs_recursive() uselessly, because: > - if domain->ops->alloc() had failed for an

[PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

Didn't get any feedback or review comments on this patch. Resending ... P. ---8<--- The iwlwifi driver implements a thermal zone and hwmon device, but returns -EIO on temperature reads if the firmware isn't loaded. This results in the error iwlwifi-virtual-0 Adapter: Virtual device ERROR:

[PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

Didn't get any feedback or review comments on this patch. Resending ... P. ---8<--- The iwlwifi driver implements a thermal zone and hwmon device, but returns -EIO on temperature reads if the firmware isn't loaded. This results in the error iwlwifi-virtual-0 Adapter: Virtual device ERROR:

Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct

On Mon, Jul 11, 2016 at 07:55:17AM -0700, Andy Lutomirski wrote: > On Jul 11, 2016 3:08 AM, "Mark Rutland" wrote: > > > > Hi, > > > > On Sun, Jun 26, 2016 at 02:55:48PM -0700, Andy Lutomirski wrote: > > > If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT, > > >

Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct

On Mon, Jul 11, 2016 at 07:55:17AM -0700, Andy Lutomirski wrote: > On Jul 11, 2016 3:08 AM, "Mark Rutland" wrote: > > > > Hi, > > > > On Sun, Jun 26, 2016 at 02:55:48PM -0700, Andy Lutomirski wrote: > > > If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT, > > > then thread_info is

Re: [PATCH] rpaphp: fix slot registration for multiple slots under a PHB

On 07/08/2016 04:57 PM, Nathan Fontenot wrote: > On 07/08/2016 06:19 PM, Tyrel Datwyler wrote: >> PowerVM seems to only ever provide a single hotplug slot per PHB. >> The under lying slot hotplug registration code assumed multiple slots, >> but the actual implementation is broken for multiple

Re: [PATCH] rpaphp: fix slot registration for multiple slots under a PHB

On 07/08/2016 04:57 PM, Nathan Fontenot wrote: > On 07/08/2016 06:19 PM, Tyrel Datwyler wrote: >> PowerVM seems to only ever provide a single hotplug slot per PHB. >> The under lying slot hotplug registration code assumed multiple slots, >> but the actual implementation is broken for multiple

Re: [PATCH v6 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

On Thu, Jul 07, 2016 at 10:58:44AM +0800, William Wu wrote: > This patch adds the devicetree documentation required for Rockchip > USB3.0 core wrapper consisting of USB3.0 IP from Synopsys. > > It supports DRD mode, and could operate in device mode (SS, HS, FS) > and host mode (SS, HS, FS, LS). >

Re: [PATCH v6 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

On Thu, Jul 07, 2016 at 10:58:44AM +0800, William Wu wrote: > This patch adds the devicetree documentation required for Rockchip > USB3.0 core wrapper consisting of USB3.0 IP from Synopsys. > > It supports DRD mode, and could operate in device mode (SS, HS, FS) > and host mode (SS, HS, FS, LS). >

Re: [PATCH v6 4/5] usb: dwc3: add dis_del_phy_power_chg_quirk

On Thu, Jul 07, 2016 at 10:54:25AM +0800, William Wu wrote: > Add a quirk to clear the GUSB3PIPECTL.DELAYP1TRANS bit, > which specifies whether disable delay PHY power change > from P0 to P1/P2/P3 when link state changing from U0 > to U1/U2/U3 respectively. > > Signed-off-by: William Wu

Re: [PATCH v6 4/5] usb: dwc3: add dis_del_phy_power_chg_quirk

On Thu, Jul 07, 2016 at 10:54:25AM +0800, William Wu wrote: > Add a quirk to clear the GUSB3PIPECTL.DELAYP1TRANS bit, > which specifies whether disable delay PHY power change > from P0 to P1/P2/P3 when link state changing from U0 > to U1/U2/U3 respectively. > > Signed-off-by: William Wu > --- >

Re: [PATCH v2 5/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED_EXECUTABLE

On 09/07/16 03:09, Mitchel Humpherys wrote: > The newly added DMA_ATTR_PRIVILEGED_EXECUTABLE is useful for creating > mappings that are executable by privileged DMA engines. Implement it in > dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it. > > Signed-off-by: Mitchel Humpherys

Re: [PATCH v2 5/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED_EXECUTABLE

On 09/07/16 03:09, Mitchel Humpherys wrote: > The newly added DMA_ATTR_PRIVILEGED_EXECUTABLE is useful for creating > mappings that are executable by privileged DMA engines. Implement it in > dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it. > > Signed-off-by: Mitchel Humpherys

[PATCH v16 net-next 1/1] hv_sock: introduce Hyper-V Sockets

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

[PATCH v16 net-next 1/1] hv_sock: introduce Hyper-V Sockets

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

Re: [PATCH v2 0/6] Add support for privileged mappings

On Mon, Jul 11, 2016 at 03:02:24PM +0100, Robin Murphy wrote: > Hey Mitch, > > Thanks for having the necessary go at the DMA API - I think the series > looks broadly workable now. > > On 09/07/16 03:09, Mitchel Humpherys wrote: > > The following patch to the ARM SMMU driver: > > > > commit

Re: [PATCH v2 0/6] Add support for privileged mappings

On Mon, Jul 11, 2016 at 03:02:24PM +0100, Robin Murphy wrote: > Hey Mitch, > > Thanks for having the necessary go at the DMA API - I think the series > looks broadly workable now. > > On 09/07/16 03:09, Mitchel Humpherys wrote: > > The following patch to the ARM SMMU driver: > > > > commit

[PATCH RFC V1] mfd: da9063: Update author information to remove incorrect e-mail addresses

From: Steve Twiss Remove incorrect e-mail addresses from the copyright header and MODULE_AUTHOR() macro. These e-mail addresses are no longer in use. The author names have not been changed, only the e-mail address have been deleted from the source files.

[PATCH RFC V1] mfd: da9063: Update author information to remove incorrect e-mail addresses

From: Steve Twiss Remove incorrect e-mail addresses from the copyright header and MODULE_AUTHOR() macro. These e-mail addresses are no longer in use. The author names have not been changed, only the e-mail address have been deleted from the source files. Signed-off-by: Steve Twiss --- Hi

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

On Thu, Jul 07, 2016 at 10:54:24AM +0800, William Wu wrote: > Add a quirk to configure the core to support the > UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY > interface is hardware property, and it's platform > dependent. Normall, the PHYIf can be configured s/Normall/Normally/

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

On Thu, Jul 07, 2016 at 10:54:24AM +0800, William Wu wrote: > Add a quirk to configure the core to support the > UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY > interface is hardware property, and it's platform > dependent. Normall, the PHYIf can be configured s/Normall/Normally/

[PATCH] pinctrl: stm32f429: driver init call change

As nothing special is done in driver init then device_initcall() can be changed in builtin_platform_driver() call. Signed-off-by: Alexandre TORGUE diff --git a/drivers/pinctrl/stm32/pinctrl-stm32f429.c b/drivers/pinctrl/stm32/pinctrl-stm32f429.c index e9b15dc..a5d50ca

Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct

On Jul 11, 2016 3:08 AM, "Mark Rutland" wrote: > > Hi, > > On Sun, Jun 26, 2016 at 02:55:48PM -0700, Andy Lutomirski wrote: > > If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT, > > then thread_info is defined as a single 'u32 flags' and is the first > > entry

[PATCH] pinctrl: stm32f429: driver init call change

As nothing special is done in driver init then device_initcall() can be changed in builtin_platform_driver() call. Signed-off-by: Alexandre TORGUE diff --git a/drivers/pinctrl/stm32/pinctrl-stm32f429.c b/drivers/pinctrl/stm32/pinctrl-stm32f429.c index e9b15dc..a5d50ca 100644 ---

Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct

On Jul 11, 2016 3:08 AM, "Mark Rutland" wrote: > > Hi, > > On Sun, Jun 26, 2016 at 02:55:48PM -0700, Andy Lutomirski wrote: > > If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT, > > then thread_info is defined as a single 'u32 flags' and is the first > > entry of task_struct.

<    3   4   5   6   7   8   9   10   11   12   >