Re: [PATCH 12/16] page-flags: define PG_mlocked behavior on compound pages

On 09/24/2015 10:51 AM, Kirill A. Shutemov wrote: > Transparent huge pages can be mlocked -- whole compund page at once. > Something went wrong if we're trying to mlock() tail page. > Let's use PF_NO_TAIL. Kirill, Hugh, I seem to be hitting this with trinity: [ 242.257552]

Re: [PATCH 12/16] page-flags: define PG_mlocked behavior on compound pages

On 09/24/2015 10:51 AM, Kirill A. Shutemov wrote: > Transparent huge pages can be mlocked -- whole compund page at once. > Something went wrong if we're trying to mlock() tail page. > Let's use PF_NO_TAIL. Kirill, Hugh, I seem to be hitting this with trinity: [ 242.257552]

Re: [PATCH 1/2] iio: magn: Split bmc150 driver in common/i2c parts

On 18/04/16 12:24, Tirdea, Irina wrote: > > >> -Original Message- >> From: Jonathan Cameron [mailto:ji...@kernel.org] >> Sent: 17 April, 2016 13:02 >> To: Baluta, Daniel; Tirdea, Irina >> Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; >> ge...@linux-m68k.org; Dogaru, Vlad;

Re: [PATCH 1/2] iio: magn: Split bmc150 driver in common/i2c parts

On 18/04/16 12:24, Tirdea, Irina wrote: > > >> -Original Message- >> From: Jonathan Cameron [mailto:ji...@kernel.org] >> Sent: 17 April, 2016 13:02 >> To: Baluta, Daniel; Tirdea, Irina >> Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; >> ge...@linux-m68k.org; Dogaru, Vlad;

RE: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Monday, April 18, 2016 10:00 AM > To: KY Srinivasan ; Alexander Duyck > > Cc: David Miller ; Netdev > ;

RE: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Monday, April 18, 2016 10:00 AM > To: KY Srinivasan ; Alexander Duyck > > Cc: David Miller ; Netdev > ; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; Robo Bot > ; Jason Wang ; >

Re: [PATCH -tip 3/3] locking/pvqspinlock: Robustify init_qspinlock_stat()

On 04/18/2016 02:31 AM, Davidlohr Bueso wrote: Specifically around the debugfs file creation calls, I have no idea if they could ever possibly fail, but this is core code (debug aside) so lets at least check the return value and inform anything fishy. Signed-off-by: Davidlohr

Re: [PATCH -tip 3/3] locking/pvqspinlock: Robustify init_qspinlock_stat()

On 04/18/2016 02:31 AM, Davidlohr Bueso wrote: Specifically around the debugfs file creation calls, I have no idea if they could ever possibly fail, but this is core code (debug aside) so lets at least check the return value and inform anything fishy. Signed-off-by: Davidlohr Bueso ---

Re: [PATCH 1/5] max44000: Initial commit

On 18/04/16 11:32, Mark Brown wrote: > On Sun, Apr 17, 2016 at 09:36:10AM +0100, Jonathan Cameron wrote: >> On 11/04/16 16:08, Crestez Dan Leonard wrote: > > Please leave blank lines between paragraphs, it makes things much easier > to read. > >>> Would it be >>> acceptable to just expand the

Re: [PATCH 1/5] max44000: Initial commit

On 18/04/16 11:32, Mark Brown wrote: > On Sun, Apr 17, 2016 at 09:36:10AM +0100, Jonathan Cameron wrote: >> On 11/04/16 16:08, Crestez Dan Leonard wrote: > > Please leave blank lines between paragraphs, it makes things much easier > to read. > >>> Would it be >>> acceptable to just expand the

Re: [PATCH] mm: SLAB freelist randomization

On 04/18/2016 08:59 AM, Thomas Garnier wrote: I will send the next version today. Note that I get_random_bytes_arch is used because at that stage we have 0 bits of entropy. It seemed like a better idea to use the arch version that will fallback on get_random_bytes sub API in the worse case.

Re: [PATCH] mm: SLAB freelist randomization

On 04/18/2016 08:59 AM, Thomas Garnier wrote: I will send the next version today. Note that I get_random_bytes_arch is used because at that stage we have 0 bits of entropy. It seemed like a better idea to use the arch version that will fallback on get_random_bytes sub API in the worse case.

Re: [PATCH 1/5] max44000: Initial commit

On 18/04/16 13:34, Mark Brown wrote: > On Mon, Apr 18, 2016 at 03:15:54PM +0300, Crestez Dan Leonard wrote: > >> As a further clarification: regmap_write will write to hardware even if >> the cache is known to be up-to-date and no matter the regcache_type. Did >> I understand this correctly? >

Re: [PATCH 1/5] max44000: Initial commit

On 18/04/16 13:34, Mark Brown wrote: > On Mon, Apr 18, 2016 at 03:15:54PM +0300, Crestez Dan Leonard wrote: > >> As a further clarification: regmap_write will write to hardware even if >> the cache is known to be up-to-date and no matter the regcache_type. Did >> I understand this correctly? >

Re: [PATCH -tip 1/3] locking/pvqspinlock: Fix div by 0 in qstats

On 04/18/2016 02:31 AM, Davidlohr Bueso wrote: While playing with such statistics I ran into the following splat on a VM when opening pv_hash_hops: [ 25.267962] divide error: [#1] SMP ... [ 25.268807] CPU: 17 PID: 1018 Comm: cat Not tainted 4.6.0-rc3-debug+ #2 [ 25.268853] Hardware

Re: [PATCH -tip 1/3] locking/pvqspinlock: Fix div by 0 in qstats

On 04/18/2016 02:31 AM, Davidlohr Bueso wrote: While playing with such statistics I ran into the following splat on a VM when opening pv_hash_hops: [ 25.267962] divide error: [#1] SMP ... [ 25.268807] CPU: 17 PID: 1018 Comm: cat Not tainted 4.6.0-rc3-debug+ #2 [ 25.268853] Hardware

[PATCH v4] ARM64: ACPI: Update documentation for latest specification version

The ACPI 6.1 specification was recently released at the end of January 2016, but the arm64 kernel documentation for the use of ACPI was written for the 5.1 version of the spec. There were significant additions to the spec that had not yet been mentioned -- for example, the 6.0 mechanisms added to

[PATCH v4] ARM64: ACPI: Update documentation for latest specification version

The ACPI 6.1 specification was recently released at the end of January 2016, but the arm64 kernel documentation for the use of ACPI was written for the 5.1 version of the spec. There were significant additions to the spec that had not yet been mentioned -- for example, the 6.0 mechanisms added to

Re: [PATCH V6 08/13] PCI: generic, thunder: update to use generic ECAM API

On 18.04.2016 16:44, Arnd Bergmann wrote: On Monday 18 April 2016 15:03:51 Tomasz Nowicki wrote: On 16.04.2016 16:36, Jayachandran C wrote: On Sat, Apr 16, 2016 at 1:01 PM, Arnd Bergmann wrote: On Saturday 16 April 2016 12:50:13 Jayachandran C wrote: The whole pci-thunder-*.c

Re: [PATCH V6 08/13] PCI: generic, thunder: update to use generic ECAM API

On 18.04.2016 16:44, Arnd Bergmann wrote: On Monday 18 April 2016 15:03:51 Tomasz Nowicki wrote: On 16.04.2016 16:36, Jayachandran C wrote: On Sat, Apr 16, 2016 at 1:01 PM, Arnd Bergmann wrote: On Saturday 16 April 2016 12:50:13 Jayachandran C wrote: The whole pci-thunder-*.c is to support

Re: [PATCH 4/4] pinctrl: iproc: Allow PINCONF to be disabled completely

Hi Linus, On 4/15/2016 1:24 AM, Linus Walleij wrote: On Wed, Apr 13, 2016 at 2:15 AM, Ray Jui wrote: In some of the future iProc based SoCs, pinconf is handled by another block and the iProc GPIO controller is solely used as a GPIO controller. This patch adds support of

Re: [PATCH 4/4] pinctrl: iproc: Allow PINCONF to be disabled completely

Hi Linus, On 4/15/2016 1:24 AM, Linus Walleij wrote: On Wed, Apr 13, 2016 at 2:15 AM, Ray Jui wrote: In some of the future iProc based SoCs, pinconf is handled by another block and the iProc GPIO controller is solely used as a GPIO controller. This patch adds support of a new compatible

Re: [PATCH v2 4/5] iio: health: afe4404: use regmap to retrieve struct device

On 18/04/16 16:53, Andrew F. Davis wrote: > On 04/17/2016 11:56 PM, Alison Schofield wrote: >> On Sun, Apr 17, 2016 at 01:07:52PM -0500, Andrew F. Davis wrote: >>> On 04/16/2016 02:22 PM, Jonathan Cameron wrote: On 10/04/16 20:07, Alison Schofield wrote: > Driver includes struct regmap

Re: [PATCH v2 4/5] iio: health: afe4404: use regmap to retrieve struct device

On 18/04/16 16:53, Andrew F. Davis wrote: > On 04/17/2016 11:56 PM, Alison Schofield wrote: >> On Sun, Apr 17, 2016 at 01:07:52PM -0500, Andrew F. Davis wrote: >>> On 04/16/2016 02:22 PM, Jonathan Cameron wrote: On 10/04/16 20:07, Alison Schofield wrote: > Driver includes struct regmap

Re: [PATCH 07/15] reconnect_one(): use lookup_one_len_unlocked()

On Sat, Apr 16, 2016 at 01:55:19AM +0100, Al Viro wrote: > From: Al Viro > > ... and explain the non-obvious logics in case when lookup yields > a different dentry. ACK to this independent of the rest of the series, my only minor gripe is that the point made in this new

Re: [PATCH 07/15] reconnect_one(): use lookup_one_len_unlocked()

On Sat, Apr 16, 2016 at 01:55:19AM +0100, Al Viro wrote: > From: Al Viro > > ... and explain the non-obvious logics in case when lookup yields > a different dentry. ACK to this independent of the rest of the series, my only minor gripe is that the point made in this new comment is also made at

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse wrote: > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > the truth, and even legacy kernels ought to cope with that. > FSVO 'ought to' where I suspect some of them will actually crash with a > NULL

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse wrote: > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > the truth, and even legacy kernels ought to cope with that. > FSVO 'ought to' where I suspect some of them will actually crash with a > NULL pointer dereference if

Re: [PATCH 2/4] pinctrl: iproc: Allow certain PINCONF functions to be disabled

Hi Linus/Rob, On 4/15/2016 1:20 AM, Linus Walleij wrote: On Wed, Apr 13, 2016 at 2:15 AM, Ray Jui wrote: The iProc GPIO controller is shared among multiple iProc based SoCs. In some of these SoCs, certain PINCONF functions are disabled and registers associated with

Re: [PATCH 2/4] pinctrl: iproc: Allow certain PINCONF functions to be disabled

Hi Linus/Rob, On 4/15/2016 1:20 AM, Linus Walleij wrote: On Wed, Apr 13, 2016 at 2:15 AM, Ray Jui wrote: The iProc GPIO controller is shared among multiple iProc based SoCs. In some of these SoCs, certain PINCONF functions are disabled and registers associated with these functions are

Re: [PATCH] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared

[adding clk maintainers/list to cc] On 04/18/2016 09:29 AM, Javier Martinez Canillas wrote: > Hello Marek, > > On 04/18/2016 03:50 AM, Marek Szyprowski wrote: >> Hello, >> >> On 2016-04-16 00:04, Javier Martinez Canillas wrote: >>> The exynos5 I2C controller driver always prepares and enables a

Re: [PATCH] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared

[adding clk maintainers/list to cc] On 04/18/2016 09:29 AM, Javier Martinez Canillas wrote: > Hello Marek, > > On 04/18/2016 03:50 AM, Marek Szyprowski wrote: >> Hello, >> >> On 2016-04-16 00:04, Javier Martinez Canillas wrote: >>> The exynos5 I2C controller driver always prepares and enables a

Re: [PATCH v2 1/5] iio: accel: bmc150: use regmap to retrieve struct device

On 18/04/16 15:59, Srinivas Pandruvada wrote: > On Sat, 2016-04-16 at 20:20 +0100, Jonathan Cameron wrote: >> On 10/04/16 20:05, Alison Schofield wrote: >>> >>> Driver includes struct regmap and struct device in its global data. >>> Remove the struct device and use regmap API to retrieve device

Re: [PATCH v2 1/5] iio: accel: bmc150: use regmap to retrieve struct device

On 18/04/16 15:59, Srinivas Pandruvada wrote: > On Sat, 2016-04-16 at 20:20 +0100, Jonathan Cameron wrote: >> On 10/04/16 20:05, Alison Schofield wrote: >>> >>> Driver includes struct regmap and struct device in its global data. >>> Remove the struct device and use regmap API to retrieve device

Re: mmotm woes, mainly compaction

On 04/14/2016 07:24 PM, Vlastimil Babka wrote: >> > @@ -1459,8 +1459,8 @@ static enum compact_result compact_zone( >> >zone->compact_cached_migrate_pfn[1] = cc->migrate_pfn; >> >} >> > >> > - if (cc->migrate_pfn == start_pfn) >> > - cc->whole_zone = true; >> > +

Re: mmotm woes, mainly compaction

On 04/14/2016 07:24 PM, Vlastimil Babka wrote: >> > @@ -1459,8 +1459,8 @@ static enum compact_result compact_zone( >> >zone->compact_cached_migrate_pfn[1] = cc->migrate_pfn; >> >} >> > >> > - if (cc->migrate_pfn == start_pfn) >> > - cc->whole_zone = true; >> > +

[PATCH v2] fs: define a string representation of the kernel_read_file_id enumeration

A string representation of the kernel_read_file_id enumeration is needed for displaying messages (eg. pr_info, auditing) that can be used by multiple LSMs and the integrity subsystem. To simplify keeping the list of strings up to date with the enumeration, this patch defines two new preprocessing

[PATCH v2] fs: define a string representation of the kernel_read_file_id enumeration

A string representation of the kernel_read_file_id enumeration is needed for displaying messages (eg. pr_info, auditing) that can be used by multiple LSMs and the integrity subsystem. To simplify keeping the list of strings up to date with the enumeration, this patch defines two new preprocessing

Applied "spi: pic32-sqi: add SPI driver for PIC32 SQI controller." to the spi tree

The patch spi: pic32-sqi: add SPI driver for PIC32 SQI controller. has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "spi: pic32-sqi: add SPI driver for PIC32 SQI controller." to the spi tree

The patch spi: pic32-sqi: add SPI driver for PIC32 SQI controller. has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "regulator: s2mps11: Set default ramp delay for S2MPS11 LDOs" to the regulator tree

The patch regulator: s2mps11: Set default ramp delay for S2MPS11 LDOs has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "regulator: s2mps11: Set default ramp delay for S2MPS11 LDOs" to the regulator tree

The patch regulator: s2mps11: Set default ramp delay for S2MPS11 LDOs has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "spi: pic32-sqi: add binding document for PIC32 Quad-SPI driver." to the spi tree

The patch spi: pic32-sqi: add binding document for PIC32 Quad-SPI driver. has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "spi: pic32-sqi: add binding document for PIC32 Quad-SPI driver." to the spi tree

The patch spi: pic32-sqi: add binding document for PIC32 Quad-SPI driver. has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: core: remove lockdep assert from suspend_prepare" to the regulator tree

The patch regulator: core: remove lockdep assert from suspend_prepare has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "regulator: core: remove lockdep assert from suspend_prepare" to the regulator tree

The patch regulator: core: remove lockdep assert from suspend_prepare has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

[PATCH net-next v2 1/2] bpf, trace: add BPF_F_CURRENT_CPU flag for bpf_perf_event_output

Add a BPF_F_CURRENT_CPU flag to optimize the use-case where user space has per-CPU ring buffers and the eBPF program pushes the data into the current CPU's ring buffer which saves us an extra helper function call in eBPF. Also, make sure to properly reserve the remaining flags which are not used.

[PATCH net-next v2 1/2] bpf, trace: add BPF_F_CURRENT_CPU flag for bpf_perf_event_output

Add a BPF_F_CURRENT_CPU flag to optimize the use-case where user space has per-CPU ring buffers and the eBPF program pushes the data into the current CPU's ring buffer which saves us an extra helper function call in eBPF. Also, make sure to properly reserve the remaining flags which are not used.

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 18, 2016 7:46:05 AM PDT, Joerg Roedel wrote: >On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if defined(CONFIG_KASAN) >> +static const unsigned long memory_rand_end = KASAN_SHADOW_START; >> +#elfif defined(CONFIG_X86_ESPFIX64) >> +static const

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 18, 2016 7:46:05 AM PDT, Joerg Roedel wrote: >On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if defined(CONFIG_KASAN) >> +static const unsigned long memory_rand_end = KASAN_SHADOW_START; >> +#elfif defined(CONFIG_X86_ESPFIX64) >> +static const unsigned long

[PATCH net-next v2 2/2] bpf: add event output helper for notifications/sampling/logging

This patch adds a new helper for cls/act programs that can push events to user space applications. For networking, this can be f.e. for sampling, debugging, logging purposes or pushing of arbitrary wake-up events. The idea is similar to a43eec304259 ("bpf: introduce bpf_perf_event_output()

[PATCH net-next v2 2/2] bpf: add event output helper for notifications/sampling/logging

This patch adds a new helper for cls/act programs that can push events to user space applications. For networking, this can be f.e. for sampling, debugging, logging purposes or pushing of arbitrary wake-up events. The idea is similar to a43eec304259 ("bpf: introduce bpf_perf_event_output()

[PATCH net-next v2 0/2] BPF updates

This minor set adds a new helper bpf_event_output() for eBPF cls/act program types which allows to pass events to user space applications. For details, please see individual patches. Thanks! v1 -> v2: - Address kbuild bot found compile issue in patch 2 - Rest as is Daniel Borkmann (2):

[PATCH net-next v2 0/2] BPF updates

This minor set adds a new helper bpf_event_output() for eBPF cls/act program types which allows to pass events to user space applications. For details, please see individual patches. Thanks! v1 -> v2: - Address kbuild bot found compile issue in patch 2 - Rest as is Daniel Borkmann (2):

[PATCH 2/3] MIPS: JZ4740: Probe OHCI platform device via DT

The DT fragment will select the ohci-platform driver, since that can handle the JZ4740 OHCI just fine. While I don't have a JZ4740-based board with anything connected to the USB host controller, I did test the generic OHCI driver successfully on a JZ4770-based board. The device is disabled by

[PATCH 2/3] MIPS: JZ4740: Probe OHCI platform device via DT

The DT fragment will select the ohci-platform driver, since that can handle the JZ4740 OHCI just fine. While I don't have a JZ4740-based board with anything connected to the USB host controller, I did test the generic OHCI driver successfully on a JZ4770-based board. The device is disabled by

[PATCH 1/3] MIPS: JZ4740: Qi LB60: Remove support for AVT2 variant

AVT2 was a prototype board of which about 5 were made, none of which are in use anymore. Signed-off-by: Maarten ter Huurne --- arch/mips/jz4740/board-qi_lb60.c | 52 ++-- 1 file changed, 2 insertions(+), 50 deletions(-) diff --git

[PATCH 3/3] USB: ohci-jz4740: Remove obsolete driver

The ohci-platform driver can control the clock, while usb-nop-xceiv as the PHY can control the vbus regulator. So this JZ4740-specific glue is not needed anymore. Signed-off-by: Maarten ter Huurne --- drivers/usb/host/ohci-hcd.c| 5 - drivers/usb/host/ohci-jz4740.c

[PATCH 1/3] MIPS: JZ4740: Qi LB60: Remove support for AVT2 variant

AVT2 was a prototype board of which about 5 were made, none of which are in use anymore. Signed-off-by: Maarten ter Huurne --- arch/mips/jz4740/board-qi_lb60.c | 52 ++-- 1 file changed, 2 insertions(+), 50 deletions(-) diff --git

[PATCH 3/3] USB: ohci-jz4740: Remove obsolete driver

The ohci-platform driver can control the clock, while usb-nop-xceiv as the PHY can control the vbus regulator. So this JZ4740-specific glue is not needed anymore. Signed-off-by: Maarten ter Huurne --- drivers/usb/host/ohci-hcd.c| 5 - drivers/usb/host/ohci-jz4740.c | 245

Re: [PATCH RFC 2/3] vfio: report group noiommu status

On Mon, 18 Apr 2016 12:58:20 +0300 "Michael S. Tsirkin" wrote: > When using vfio, callers might want to know whether device is added to a > regular group or an non-iommu group. > > Report this status from vfio_add_group_dev. > > Signed-off-by: Michael S. Tsirkin

Re: [PATCH RFC 2/3] vfio: report group noiommu status

On Mon, 18 Apr 2016 12:58:20 +0300 "Michael S. Tsirkin" wrote: > When using vfio, callers might want to know whether device is added to a > regular group or an non-iommu group. > > Report this status from vfio_add_group_dev. > > Signed-off-by: Michael S. Tsirkin > --- What about making an

Re: [PATCH 1/1] mmc: sdhci-pci: add Support of Synopsys DWC_MSHC IP

On Mon, Apr 18, 2016 at 10:30:39AM +, Prabu Thangamuthu wrote: > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h > index 247da8c..01f743b 100644 > --- a/include/linux/pci_ids.h > +++ b/include/linux/pci_ids.h > @@ -2318,6 +2318,9 @@ > #define PCI_DEVICE_ID_CENATEK_IDE0x0001

Re: [PATCH 1/1] mmc: sdhci-pci: add Support of Synopsys DWC_MSHC IP

On Mon, Apr 18, 2016 at 10:30:39AM +, Prabu Thangamuthu wrote: > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h > index 247da8c..01f743b 100644 > --- a/include/linux/pci_ids.h > +++ b/include/linux/pci_ids.h > @@ -2318,6 +2318,9 @@ > #define PCI_DEVICE_ID_CENATEK_IDE0x0001

Re: [PATCH 1/5] clk: qoriq: add __init attribute

On 04/18, Julia Lawall wrote: > Add __init attribute on a function that is only called from other __init > functions and that is not inlined, at least with gcc version 4.8.4 on an > x86 machine with allyesconfig. Currently, the function is put in the > .text.unlikely segment. Declaring it as

Re: [PATCH 1/5] clk: qoriq: add __init attribute

On 04/18, Julia Lawall wrote: > Add __init attribute on a function that is only called from other __init > functions and that is not inlined, at least with gcc version 4.8.4 on an > x86 machine with allyesconfig. Currently, the function is put in the > .text.unlikely segment. Declaring it as

Re: [PATCH 0/3] fec: ethtool: move to new api {get|set}_link_ksettings

From: Philippe Reynes Date: Fri, 15 Apr 2016 00:34:58 +0200 > Ethtool has a new api {get|set}_link_ksettings that deprecate > the old api {get|set}_settings. We update the fec driver to use > this new ethtool api. > > For this first version, I've converted old u32 value in

Re: [PATCH 0/3] fec: ethtool: move to new api {get|set}_link_ksettings

From: Philippe Reynes Date: Fri, 15 Apr 2016 00:34:58 +0200 > Ethtool has a new api {get|set}_link_ksettings that deprecate > the old api {get|set}_settings. We update the fec driver to use > this new ethtool api. > > For this first version, I've converted old u32 value in phy structure > to

[PATCH] drivers: led: is31fl319x: 6/9-channel light effect led driver

This is a driver for the Integrated Silicon Solution Inc. LED driver chips IS31FL3196 and IS31FL3199. They can drive up to 6 or 9 LEDs. Each LED is individually controllable in brightness (through pwm) in 256 steps so that RGB LEDs can show any of ca. 16 Mio colors. The maximum current of the

[PATCH] drivers: led: is31fl319x: 6/9-channel light effect led driver

This is a driver for the Integrated Silicon Solution Inc. LED driver chips IS31FL3196 and IS31FL3199. They can drive up to 6 or 9 LEDs. Each LED is individually controllable in brightness (through pwm) in 256 steps so that RGB LEDs can show any of ca. 16 Mio colors. The maximum current of the

[PATCH] driver: leds: is31fl3196/99 dimmable dual/triple rgb driver

This patch adds a driver for the is31fl3196/99 dimmable dual/triple rgb controller chips from ISSI. H. Nikolaus Schaller (1): drivers: led: is31fl319x: 6/9-channel light effect led driver .../devicetree/bindings/leds/is31fl319x.txt| 41 +++ drivers/leds/Kconfig

Re: [PATCH] netfilter: ctnetlink: add more #ifdef around unused code

On Mon, Apr 18, 2016 at 08:33:15PM +0200, Arnd Bergmann wrote: > On Monday 18 April 2016 20:16:59 Pablo Neira Ayuso wrote: > > On Sat, Apr 16, 2016 at 10:17:43PM +0200, Arnd Bergmann wrote: > > > A recent patch removed many 'inline' annotations for static > > > functions in this file, which has

[PATCH] driver: leds: is31fl3196/99 dimmable dual/triple rgb driver

This patch adds a driver for the is31fl3196/99 dimmable dual/triple rgb controller chips from ISSI. H. Nikolaus Schaller (1): drivers: led: is31fl319x: 6/9-channel light effect led driver .../devicetree/bindings/leds/is31fl319x.txt| 41 +++ drivers/leds/Kconfig

Re: [PATCH] netfilter: ctnetlink: add more #ifdef around unused code

On Mon, Apr 18, 2016 at 08:33:15PM +0200, Arnd Bergmann wrote: > On Monday 18 April 2016 20:16:59 Pablo Neira Ayuso wrote: > > On Sat, Apr 16, 2016 at 10:17:43PM +0200, Arnd Bergmann wrote: > > > A recent patch removed many 'inline' annotations for static > > > functions in this file, which has

[PATCH] arm64: Kconfig: remove redundant HAVE_ARCH_TRANSPARENT_HUGEPAGE definition

HAVE_ARCH_TRANSPARENT_HUGEPAGE has been defined in arch/Kconfig already, the ARM64 version is identical with it and the default value is Y. So remove the redundant definition and just select it under CONFIG_ARM64. Signed-off-by: Yang Shi --- arch/arm64/Kconfig | 4 +--- 1

[PATCH] arm64: Kconfig: remove redundant HAVE_ARCH_TRANSPARENT_HUGEPAGE definition

HAVE_ARCH_TRANSPARENT_HUGEPAGE has been defined in arch/Kconfig already, the ARM64 version is identical with it and the default value is Y. So remove the redundant definition and just select it under CONFIG_ARM64. Signed-off-by: Yang Shi --- arch/arm64/Kconfig | 4 +--- 1 file changed, 1

Re: [PATCH] netfilter: ctnetlink: add more #ifdef around unused code

On Monday 18 April 2016 20:16:59 Pablo Neira Ayuso wrote: > On Sat, Apr 16, 2016 at 10:17:43PM +0200, Arnd Bergmann wrote: > > A recent patch removed many 'inline' annotations for static > > functions in this file, which has caused warnings for functions > > that are not used in a given

Re: [PATCH] netfilter: ctnetlink: add more #ifdef around unused code

On Monday 18 April 2016 20:16:59 Pablo Neira Ayuso wrote: > On Sat, Apr 16, 2016 at 10:17:43PM +0200, Arnd Bergmann wrote: > > A recent patch removed many 'inline' annotations for static > > functions in this file, which has caused warnings for functions > > that are not used in a given

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, 2016-04-18 at 19:27 +0300, Michael S. Tsirkin wrote: > I balk at adding more hacks to a broken system. My goals are > merely to > - make things work correctly with an IOMMU and new guests, >   so people can use userspace drivers with virtio devices > - prevent security risks when guest

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, 2016-04-18 at 19:27 +0300, Michael S. Tsirkin wrote: > I balk at adding more hacks to a broken system. My goals are > merely to > - make things work correctly with an IOMMU and new guests, >   so people can use userspace drivers with virtio devices > - prevent security risks when guest

Re: [PATCH 3/4] dt-bindings: Update iProc GPIO bindings

On 4/14/2016 7:38 AM, Rob Herring wrote: On Tue, Apr 12, 2016 at 05:15:22PM -0700, Ray Jui wrote: Update the iProc GPIO binding document to introduce a new compatible string "brcm,iproc-gpio-only", that allows the generic pinconf function to be disabled completely Signed-off-by: Ray Jui

Re: [PATCH 3/4] dt-bindings: Update iProc GPIO bindings

On 4/14/2016 7:38 AM, Rob Herring wrote: On Tue, Apr 12, 2016 at 05:15:22PM -0700, Ray Jui wrote: Update the iProc GPIO binding document to introduce a new compatible string "brcm,iproc-gpio-only", that allows the generic pinconf function to be disabled completely Signed-off-by: Ray Jui

[PATCH v2 3/5] ARM: dts: omap5: fix range of permitted wakeup pinmux registers

otherwise we can't define gpio1_wk14 Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 38805eb..120b6b8 100644 ---

[PATCH v2 3/5] ARM: dts: omap5: fix range of permitted wakeup pinmux registers

otherwise we can't define gpio1_wk14 Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 38805eb..120b6b8 100644 ---

Re: [PATCH] audit: add tty field to LOGIN event

On 16/04/13, Peter Hurley wrote: > Hi Richard, Hi Peter, > On 04/13/2016 04:25 PM, Richard Guy Briggs wrote: > > The tty field was missing from AUDIT_LOGIN events. > > > > Refactor code to create a new function audit_get_tty(), using it to > > replace the call in audit_log_task_info() and to

Re: [PATCH] audit: add tty field to LOGIN event

On 16/04/13, Peter Hurley wrote: > Hi Richard, Hi Peter, > On 04/13/2016 04:25 PM, Richard Guy Briggs wrote: > > The tty field was missing from AUDIT_LOGIN events. > > > > Refactor code to create a new function audit_get_tty(), using it to > > replace the call in audit_log_task_info() and to

[PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required. Signed-off-by: H.

[PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required. Signed-off-by: H.

Re: [PATCH RESEND 1/2] pinctrl: ns2: add pinmux driver support for Broadcom NS2 SoC

Hi Linus, Reddy, On 4/17/2016 8:34 PM, Yendapally Reddy Dhananjaya Reddy wrote: Hi Linus, On Thu, Apr 14, 2016 at 3:12 PM, Linus Walleij wrote: On Thu, Apr 14, 2016 at 9:53 AM, Yendapally Reddy Dhananjaya Reddy wrote: On Wed, Apr 13,

Re: [PATCH RESEND 1/2] pinctrl: ns2: add pinmux driver support for Broadcom NS2 SoC

Hi Linus, Reddy, On 4/17/2016 8:34 PM, Yendapally Reddy Dhananjaya Reddy wrote: Hi Linus, On Thu, Apr 14, 2016 at 3:12 PM, Linus Walleij wrote: On Thu, Apr 14, 2016 at 9:53 AM, Yendapally Reddy Dhananjaya Reddy wrote: On Wed, Apr 13, 2016 at 6:49 PM, Linus Walleij wrote: On Tue, Mar 29,

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

On Mon, Apr 18, 2016 at 11:40:47AM -0600, Jason Gunthorpe wrote: > I wasn't arguing this should integrate into verbs in some way, only > that the way to access the driver-specific uAPI of a RDMA device should > be through the RDMA common uAPI and not through a random char dev. Well, it's stuff

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

On Mon, Apr 18, 2016 at 11:40:47AM -0600, Jason Gunthorpe wrote: > I wasn't arguing this should integrate into verbs in some way, only > that the way to access the driver-specific uAPI of a RDMA device should > be through the RDMA common uAPI and not through a random char dev. Well, it's stuff

[PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards

This patch series adds DT nodes for: * twl6030 gpadc for omap4 based boards (Pandaboard ES) * twl6037 gpadc for omap5 based board (OMAP5EVM) * omap5-board-common: ckobuffer (needed for high quality twl6040 audio) * fix range problem with omap5 pinmux H. Nikolaus Schaller (5): ARM: dts:

[PATCH v2 0/5] DT Fixes for OMAP4 and OMAP5 boards

This patch series adds DT nodes for: * twl6030 gpadc for omap4 based boards (Pandaboard ES) * twl6037 gpadc for omap5 based board (OMAP5EVM) * omap5-board-common: ckobuffer (needed for high quality twl6040 audio) * fix range problem with omap5 pinmux H. Nikolaus Schaller (5): ARM: dts:

[PATCH v2 5/5] ARM: dts: omap5-board-common: set up ckobuffer for twl6040

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-board-common.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index c0da5ff..e89bef3 100644 ---

[PATCH v2 5/5] ARM: dts: omap5-board-common: set up ckobuffer for twl6040

Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-board-common.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index c0da5ff..e89bef3 100644 ---

[PATCH v2 2/5] ARM: dts: omap5-board-common: describe gpadc for Palmas

tested on OMP5432 EVM Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-board-common.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index

[PATCH v2 1/5] ARM: dts: twl6030: describe gpadc

tested on Pandaboard ES. Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/twl6030.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi index 55eb35f..c45f97f 100644 ---

[PATCH v2 2/5] ARM: dts: omap5-board-common: describe gpadc for Palmas

tested on OMP5432 EVM Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap5-board-common.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index 902657d..c0da5ff 100644 ---

[PATCH v2 1/5] ARM: dts: twl6030: describe gpadc

tested on Pandaboard ES. Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/twl6030.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi index 55eb35f..c45f97f 100644 --- a/arch/arm/boot/dts/twl6030.dtsi +++

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