Re: [PATCH] [media] solo6x10: fix detection of TW2864B chips

On Sat, Jul 01, 2017 at 03:26:01PM +0400, Anton Sviridenko wrote: > This patch enables support for non-Bluecherry labeled solo6110 > based PCI cards which have 3 x TW2864B chips and one TW2865. > These cards are displayed by lspci -nn as > > "Softlogic Co., Ltd. SOLO6110 H.264 Video

Re: [PATCH] [media] solo6x10: fix detection of TW2864B chips

On Sat, Jul 01, 2017 at 03:26:01PM +0400, Anton Sviridenko wrote: > This patch enables support for non-Bluecherry labeled solo6110 > based PCI cards which have 3 x TW2864B chips and one TW2865. > These cards are displayed by lspci -nn as > > "Softlogic Co., Ltd. SOLO6110 H.264 Video

Re: [PATCH NET V5 2/2] net: hns: Use phy_driver to setup Phy loopback

On Sat, Jul 01, 2017 at 11:57:32AM +, linyunsheng wrote: > Hi, Andrew > > I am agreed wih you on this. > But self test is also a feature of our product, and our > customer way choose to diagnose a problem using > self test, even if self test does not give a clear > reason to the problem. > we

Re: [PATCH NET V5 2/2] net: hns: Use phy_driver to setup Phy loopback

On Sat, Jul 01, 2017 at 11:57:32AM +, linyunsheng wrote: > Hi, Andrew > > I am agreed wih you on this. > But self test is also a feature of our product, and our > customer way choose to diagnose a problem using > self test, even if self test does not give a clear > reason to the problem. > we

[PATCHv2] i2c: add sc18is600 driver

This adds an I²C master driver for SPI -> I²C bus bridge chips. It currently supports NXP's SC18IS600 and SC18IS601, as well as Silicon Labs' CP2120. The driver was only tested on SC18IS600. Acked-by: Rob Herring Signed-off-By: Sebastian Reichel --- Changes

[PATCHv2] i2c: add sc18is600 driver

This adds an I²C master driver for SPI -> I²C bus bridge chips. It currently supports NXP's SC18IS600 and SC18IS601, as well as Silicon Labs' CP2120. The driver was only tested on SC18IS600. Acked-by: Rob Herring Signed-off-By: Sebastian Reichel --- Changes since PATCHv1: * Reported by Julia

RE: [PATCH v2 00/52] irqchip: KVM: Add support for GICv4

Hi Marc, I've verified the basic GICv4 functionality with v2 series + Eric's IRQ bypass patches on QDF2400 platform with a minor change in vgic-init.c successfully. Nice, I don't see any deadlock or catastrophic issues running on QCOM hardware. You can add my tested-by, I'll provide comments

RE: [PATCH v2 00/52] irqchip: KVM: Add support for GICv4

Hi Marc, I've verified the basic GICv4 functionality with v2 series + Eric's IRQ bypass patches on QDF2400 platform with a minor change in vgic-init.c successfully. Nice, I don't see any deadlock or catastrophic issues running on QCOM hardware. You can add my tested-by, I'll provide comments

Re: perf script: Question: Python trace processing script contains the tid of the process in the common_pid attribute

Em Fri, Jun 30, 2017 at 03:40:57PM -0700, Arun Kalyanasundaram escreveu: > The handlers in the python script generated from "perf script" have an > attribute: common_pid. This attribute contains the tid of the process > instead of its pid. I would like to know if this is the expected behavior. >

Re: perf script: Question: Python trace processing script contains the tid of the process in the common_pid attribute

Em Fri, Jun 30, 2017 at 03:40:57PM -0700, Arun Kalyanasundaram escreveu: > The handlers in the python script generated from "perf script" have an > attribute: common_pid. This attribute contains the tid of the process > instead of its pid. I would like to know if this is the expected behavior. >

[GIT pull] x86 fixes for 4.12

Linus, please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus For fixlets for x86: - Prevent kexec crash when KASLR is enabled, which was caused by an address calculation bug - Restore the freeing of

[GIT pull] x86 fixes for 4.12

Linus, please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus For fixlets for x86: - Prevent kexec crash when KASLR is enabled, which was caused by an address calculation bug - Restore the freeing of

[GIT pull] perf fixes for 4.12

Linus, please pull the latest perf-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus The last fix for perf for this cycles: Prevent a segfault when kernel.kptr_restrict=2 is set by avoiding a null pointer dereference.

[GIT pull] perf fixes for 4.12

Linus, please pull the latest perf-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus The last fix for perf for this cycles: Prevent a segfault when kernel.kptr_restrict=2 is set by avoiding a null pointer dereference.

Re: [f2fs-dev] [PATCH 1/2] f2fs: avoid deadlock caused by lock order of page and lock_op

On 07/01, Chao Yu wrote: > On 2017/7/1 15:28, Jaegeuk Kim wrote: > > On 06/26, Chao Yu wrote: > >> Hi Jaegeuk, > >> > >> On 2017/6/26 22:54, Jaegeuk Kim wrote: > >>> Hi Chao, > >>> > >>> On 06/26, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/6/25 0:25, Jaegeuk Kim wrote: > > -

Re: [f2fs-dev] [PATCH 1/2] f2fs: avoid deadlock caused by lock order of page and lock_op

On 07/01, Chao Yu wrote: > On 2017/7/1 15:28, Jaegeuk Kim wrote: > > On 06/26, Chao Yu wrote: > >> Hi Jaegeuk, > >> > >> On 2017/6/26 22:54, Jaegeuk Kim wrote: > >>> Hi Chao, > >>> > >>> On 06/26, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/6/25 0:25, Jaegeuk Kim wrote: > > -

Re: [PATCH 2/4] ARM/PCI: mv78xx0: pass pci_ops correctly again

Hi Bjorn, On Tue, Jun 27, 2017 at 06:11:43PM -0500, Bjorn Helgaas wrote: > On Thu, Jun 22, 2017 at 10:38:55AM +0100, Lorenzo Pieralisi wrote: > > On Wed, Jun 21, 2017 at 11:53:00PM +0200, Arnd Bergmann wrote: > > > We used to pass the operations when calling pci_scan_root_bus, but > > > that

Re: [PATCH 2/4] ARM/PCI: mv78xx0: pass pci_ops correctly again

Hi Bjorn, On Tue, Jun 27, 2017 at 06:11:43PM -0500, Bjorn Helgaas wrote: > On Thu, Jun 22, 2017 at 10:38:55AM +0100, Lorenzo Pieralisi wrote: > > On Wed, Jun 21, 2017 at 11:53:00PM +0200, Arnd Bergmann wrote: > > > We used to pass the operations when calling pci_scan_root_bus, but > > > that

Re: Consult on the Multifunction Composite Gadget problem

On Sat, Jul 01, 2017 at 08:41:20AM +, Lipengcheng wrote: > Hi, > > Now I am prepared based on 3.18 linux kernel development Multifunction > Composite Gadget, which RNDIS + CDC Serial + USB Webcam Gadget, the kernel > community has this development plan, or what needs attention. I have no

Re: Consult on the Multifunction Composite Gadget problem

On Sat, Jul 01, 2017 at 08:41:20AM +, Lipengcheng wrote: > Hi, > > Now I am prepared based on 3.18 linux kernel development Multifunction > Composite Gadget, which RNDIS + CDC Serial + USB Webcam Gadget, the kernel > community has this development plan, or what needs attention. I have no

[PATCH v8 07/10] mm: soft-dirty: keep soft-dirty bits over thp migration

From: Naoya Horiguchi Soft dirty bit is designed to keep tracked over page migration. This patch makes it work in the same manner for thp migration too. --- ChangeLog v1 -> v2: - separate diff moving _PAGE_SWP_SOFT_DIRTY from bit 7 to bit 1 - clear_soft_dirty_pmd can

[PATCH v8 07/10] mm: soft-dirty: keep soft-dirty bits over thp migration

From: Naoya Horiguchi Soft dirty bit is designed to keep tracked over page migration. This patch makes it work in the same manner for thp migration too. --- ChangeLog v1 -> v2: - separate diff moving _PAGE_SWP_SOFT_DIRTY from bit 7 to bit 1 - clear_soft_dirty_pmd can handle migration entry

[PATCH v8 08/10] mm: mempolicy: mbind and migrate_pages support thp migration

From: Naoya Horiguchi This patch enables thp migration for mbind(2) and migrate_pages(2). ChangeLog v1 -> v2: - support pte-mapped and doubly-mapped thp Signed-off-by: Naoya Horiguchi ChangeLog v2 -> v6: - use the same gfp flag

[PATCH v8 08/10] mm: mempolicy: mbind and migrate_pages support thp migration

From: Naoya Horiguchi This patch enables thp migration for mbind(2) and migrate_pages(2). ChangeLog v1 -> v2: - support pte-mapped and doubly-mapped thp Signed-off-by: Naoya Horiguchi ChangeLog v2 -> v6: - use the same gfp flag (GFP_TRANSHUGE) in mbind() and migrate_pages() for thp

[PATCH v8 05/10] mm: thp: enable thp migration in generic path

From: Zi Yan This patch adds thp migration's core code, including conversions between a PMD entry and a swap entry, setting PMD migration entry, removing PMD migration entry, and waiting on PMD migration entries. This patch makes it possible to support thp migration. If

[PATCH v8 06/10] mm: thp: check pmd migration entry in common path

From: Zi Yan If one of callers of page migration starts to handle thp, memory management code start to see pmd migration entry, so we need to prepare for it before enabling. This patch changes various code point which checks the status of given pmds in order to prevent

[PATCH v8 05/10] mm: thp: enable thp migration in generic path

From: Zi Yan This patch adds thp migration's core code, including conversions between a PMD entry and a swap entry, setting PMD migration entry, removing PMD migration entry, and waiting on PMD migration entries. This patch makes it possible to support thp migration. If you fail to allocate a

[PATCH v8 06/10] mm: thp: check pmd migration entry in common path

From: Zi Yan If one of callers of page migration starts to handle thp, memory management code start to see pmd migration entry, so we need to prepare for it before enabling. This patch changes various code point which checks the status of given pmds in order to prevent race between thp migration

[PATCH v8 03/10] mm: thp: introduce separate TTU flag for thp freezing

From: Naoya Horiguchi TTU_MIGRATION is used to convert pte into migration entry until thp split completes. This behavior conflicts with thp migration added later patches, so let's introduce a new TTU flag specifically for freezing. try_to_unmap() is used both for thp

[PATCH v8 04/10] mm: thp: introduce CONFIG_ARCH_ENABLE_THP_MIGRATION

From: Naoya Horiguchi Introduces CONFIG_ARCH_ENABLE_THP_MIGRATION to limit thp migration functionality to x86_64, which should be safer at the first step. ChangeLog v1 -> v2: - fixed config name in subject and patch description Signed-off-by: Naoya Horiguchi

[PATCH v8 03/10] mm: thp: introduce separate TTU flag for thp freezing

From: Naoya Horiguchi TTU_MIGRATION is used to convert pte into migration entry until thp split completes. This behavior conflicts with thp migration added later patches, so let's introduce a new TTU flag specifically for freezing. try_to_unmap() is used both for thp split (via freeze_page())

[PATCH v8 04/10] mm: thp: introduce CONFIG_ARCH_ENABLE_THP_MIGRATION

From: Naoya Horiguchi Introduces CONFIG_ARCH_ENABLE_THP_MIGRATION to limit thp migration functionality to x86_64, which should be safer at the first step. ChangeLog v1 -> v2: - fixed config name in subject and patch description Signed-off-by: Naoya Horiguchi Reviewed-by: Anshuman Khandual

[PATCH v8 09/10] mm: migrate: move_pages() supports thp migration

From: Naoya Horiguchi This patch enables thp migration for move_pages(2). Signed-off-by: Naoya Horiguchi ChangeLog: v1 -> v5: - fix page counting ChangeLog: v5 -> v6: - drop changes on soft-offline in unmap_and_move() Signed-off-by: Zi

[PATCH v8 09/10] mm: migrate: move_pages() supports thp migration

From: Naoya Horiguchi This patch enables thp migration for move_pages(2). Signed-off-by: Naoya Horiguchi ChangeLog: v1 -> v5: - fix page counting ChangeLog: v5 -> v6: - drop changes on soft-offline in unmap_and_move() Signed-off-by: Zi Yan --- mm/migrate.c | 45

[PATCH v8 10/10] mm: memory_hotplug: memory hotremove supports thp migration

From: Naoya Horiguchi This patch enables thp migration for memory hotremove. --- ChangeLog v1->v2: - base code switched from alloc_migrate_target to new_node_page() Signed-off-by: Naoya Horiguchi ChangeLog v2->v7: - base code switched

[PATCH v8 01/10] mm: mempolicy: add queue_pages_required()

From: Naoya Horiguchi Introduce a separate check routine related to MPOL_MF_INVERT flag. This patch just does cleanup, no behavioral change. Signed-off-by: Naoya Horiguchi Signed-off-by: Zi Yan --- mm/mempolicy.c |

[PATCH v8 10/10] mm: memory_hotplug: memory hotremove supports thp migration

From: Naoya Horiguchi This patch enables thp migration for memory hotremove. --- ChangeLog v1->v2: - base code switched from alloc_migrate_target to new_node_page() Signed-off-by: Naoya Horiguchi ChangeLog v2->v7: - base code switched from new_node_page() new_page_nodemask() Signed-off-by:

[PATCH v8 01/10] mm: mempolicy: add queue_pages_required()

From: Naoya Horiguchi Introduce a separate check routine related to MPOL_MF_INVERT flag. This patch just does cleanup, no behavioral change. Signed-off-by: Naoya Horiguchi Signed-off-by: Zi Yan --- mm/mempolicy.c | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-)

Re: [PATCH v2 8/8] iio: counter: Add support for STM32 LPTimer

On Sat, Jul 01, 2017 at 01:25:18PM +0100, Jonathan Cameron wrote: >On Fri, 30 Jun 2017 22:36:48 +0200 >Benjamin Gaignard wrote: > >> 2017-06-30 20:19 GMT+02:00 Jonathan Cameron : >> > On Tue, 27 Jun 2017 10:21:43 +0200 >> > Benjamin Gaignard

Re: [PATCH v2 8/8] iio: counter: Add support for STM32 LPTimer

On Sat, Jul 01, 2017 at 01:25:18PM +0100, Jonathan Cameron wrote: >On Fri, 30 Jun 2017 22:36:48 +0200 >Benjamin Gaignard wrote: > >> 2017-06-30 20:19 GMT+02:00 Jonathan Cameron : >> > On Tue, 27 Jun 2017 10:21:43 +0200 >> > Benjamin Gaignard wrote: >> > >> >> 2017-06-26 22:29 GMT+02:00 William

[PATCH v8 02/10] mm: x86: move _PAGE_SWP_SOFT_DIRTY from bit 7 to bit 1

From: Naoya Horiguchi _PAGE_PSE is used to distinguish between a truly non-present (_PAGE_PRESENT=0) PMD, and a PMD which is undergoing a THP split and should be treated as present. But _PAGE_SWP_SOFT_DIRTY currently uses the _PAGE_PSE bit, which would cause confusion

[PATCH v8 02/10] mm: x86: move _PAGE_SWP_SOFT_DIRTY from bit 7 to bit 1

From: Naoya Horiguchi _PAGE_PSE is used to distinguish between a truly non-present (_PAGE_PRESENT=0) PMD, and a PMD which is undergoing a THP split and should be treated as present. But _PAGE_SWP_SOFT_DIRTY currently uses the _PAGE_PSE bit, which would cause confusion between one of those PMDs

[PATCH v8 00/10] mm: page migration enhancement for thp

From: Zi Yan Hi all, The patches are rebased on mmotm-2017-06-29-16-41 with the feedbacks from v7 patches. Hi Kirill, I have added the changes you suggested to Patch 5 and Patch 6, please let me know if you are OK with them. Patch 1 factors out common code. It could be

[PATCH v8 00/10] mm: page migration enhancement for thp

From: Zi Yan Hi all, The patches are rebased on mmotm-2017-06-29-16-41 with the feedbacks from v7 patches. Hi Kirill, I have added the changes you suggested to Patch 5 and Patch 6, please let me know if you are OK with them. Patch 1 factors out common code. It could be picked up easily. Patch

[PATCH v2] ARM: dts: rockchip: enable saradc for rk3288-evb

saradc in rk3288-evb use 1.8v ref. Signed-off-by: Jacob Chen --- arch/arm/boot/dts/rk3288-evb.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi b/arch/arm/boot/dts/rk3288-evb.dtsi index f226ca7..f549f91 100644 ---

[PATCH v2] ARM: dts: rockchip: enable saradc for rk3288-evb

saradc in rk3288-evb use 1.8v ref. Signed-off-by: Jacob Chen --- arch/arm/boot/dts/rk3288-evb.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi b/arch/arm/boot/dts/rk3288-evb.dtsi index f226ca7..f549f91 100644 ---

[PATCH 3/3] arm64: dts: rockchip: enable ARM Mali GPU on rk3399-firefly

Add reference to the Mali GPU device tree node on rk3399-firefly Signed-off-by: Jacob Chen --- arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

[PATCH 2/3] arm64: dts: rockchip: add gpu opp table for rk3399

midgard-t860 gpu in rk3399 support run in 800MHz. Signed-off-by: Jacob Chen --- arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 33 1 file changed, 33 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi

[PATCH 1/3] arm64: dts: rockchip: add ARM Mali GPU node for rk3399

Add Mali GPU device tree node for the rk3399 SoC. Tested with rockchip-forwardports repo. Signed-off-by: Jacob Chen --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi

[PATCH 3/3] arm64: dts: rockchip: enable ARM Mali GPU on rk3399-firefly

Add reference to the Mali GPU device tree node on rk3399-firefly Signed-off-by: Jacob Chen --- arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

[PATCH 2/3] arm64: dts: rockchip: add gpu opp table for rk3399

midgard-t860 gpu in rk3399 support run in 800MHz. Signed-off-by: Jacob Chen --- arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 33 1 file changed, 33 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi

[PATCH 1/3] arm64: dts: rockchip: add ARM Mali GPU node for rk3399

Add Mali GPU device tree node for the rk3399 SoC. Tested with rockchip-forwardports repo. Signed-off-by: Jacob Chen --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi

Re: [PATCH v2] ARM: dts: imx7d-sdb: Set VLDO4 outpt to 2.8V for MIPI CSI/DSI

On Sat, Jul 1, 2017 at 4:39 AM, mindentropy wrote: > From: Gautam Bhat > > * According to mx7sabresd schematics the MIPI CSI/DSI voltage rails >should be 2.8V but the voltage provided is a maximum of 3.3V and >minimum of 1.8V. Providing such

Re: [PATCH v2] ARM: dts: imx7d-sdb: Set VLDO4 outpt to 2.8V for MIPI CSI/DSI

On Sat, Jul 1, 2017 at 4:39 AM, mindentropy wrote: > From: Gautam Bhat > > * According to mx7sabresd schematics the MIPI CSI/DSI voltage rails >should be 2.8V but the voltage provided is a maximum of 3.3V and >minimum of 1.8V. Providing such a higher voltage might damage the >

[PATCH] drm/udl: dma-buf: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by work with const dma_buf_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 2002 112 02114 842

[PATCH] drm/udl: dma-buf: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by work with const dma_buf_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 2002 112 02114 842

[PATCH] tee: tee_shm: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by work with const dma_buf_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 2026 112 02138 85a

[PATCH] tee: tee_shm: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by work with const dma_buf_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 2026 112 02138 85a

[GIT PULL] pinctrl fixes for v4.12 last one

Hi Linus, Brian noticed that this regression has not got a proper fix for the entire merge window and consequently we need to revert the offending commit. It's part of the RT-mainstream work, the dance goes like this, two steps forward, one step back. Please pull it in! Yours, Linus Walleij

[GIT PULL] pinctrl fixes for v4.12 last one

Hi Linus, Brian noticed that this regression has not got a proper fix for the entire merge window and consequently we need to revert the offending commit. It's part of the RT-mainstream work, the dance goes like this, two steps forward, one step back. Please pull it in! Yours, Linus Walleij

Re: [PATCH v2 8/8] iio: counter: Add support for STM32 LPTimer

On Fri, 30 Jun 2017 22:36:48 +0200 Benjamin Gaignard wrote: > 2017-06-30 20:19 GMT+02:00 Jonathan Cameron : > > On Tue, 27 Jun 2017 10:21:43 +0200 > > Benjamin Gaignard wrote: > > > >> 2017-06-26 22:29 GMT+02:00

Re: [PATCH v2 8/8] iio: counter: Add support for STM32 LPTimer

On Fri, 30 Jun 2017 22:36:48 +0200 Benjamin Gaignard wrote: > 2017-06-30 20:19 GMT+02:00 Jonathan Cameron : > > On Tue, 27 Jun 2017 10:21:43 +0200 > > Benjamin Gaignard wrote: > > > >> 2017-06-26 22:29 GMT+02:00 William Breathitt Gray > >> : > >> > On Sat, Jun 24, 2017 at 09:35:39PM +0100,

[PATCH] media: vb2 dma-sg: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by work with const dma_buf_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 5238 112 4535414ea

[PATCH] media: vb2 dma-sg: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by work with const dma_buf_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 5238 112 4535414ea

[GIT PULL] GPIO fixes for v4.12 last one

Hi Linus, just when I thought everything was setting down nicely last minute fixes appear. Like sunspots. Please pull it in, I would have sent earlier this week but the 0day builder was unresponsive so I wanted it to land in linux-next first. (If it's too late, it's too late, I just fold it

[GIT PULL] GPIO fixes for v4.12 last one

Hi Linus, just when I thought everything was setting down nicely last minute fixes appear. Like sunspots. Please pull it in, I would have sent earlier this week but the 0day builder was unresponsive so I wanted it to land in linux-next first. (If it's too late, it's too late, I just fold it

Re: [PATCH] iio: magnetometer: Only declare ACPI table when ACPI is enable

On Thu, 29 Jun 2017 14:51:56 +0200 Linus Walleij wrote: > On Tue, Jun 27, 2017 at 2:25 AM, Matthias Kaehlcke wrote: > > > Don't inflate the kernel size with data that isn't used. The conditional > > declaration also fixes the following warning when

Re: [PATCH] iio: magnetometer: Only declare ACPI table when ACPI is enable

On Thu, 29 Jun 2017 14:51:56 +0200 Linus Walleij wrote: > On Tue, Jun 27, 2017 at 2:25 AM, Matthias Kaehlcke wrote: > > > Don't inflate the kernel size with data that isn't used. The conditional > > declaration also fixes the following warning when building with clang: > > > >

Re: [PATCH 5/6] staging: iio: tsl2x7x: refactor {read,write}_event_value to allow handling multiple iio_event_infos

On Sat, 1 Jul 2017 06:37:07 -0400 Brian Masney wrote: > On Sat, Jul 01, 2017 at 10:40:20AM +0100, Jonathan Cameron wrote: > > On Thu, 29 Jun 2017 13:03:51 -0400 > > Brian Masney wrote: > > > > > tsl2x7x_read_thresh() and tsl2x7x_write_thresh()

Re: [PATCH 5/6] staging: iio: tsl2x7x: refactor {read,write}_event_value to allow handling multiple iio_event_infos

On Sat, 1 Jul 2017 06:37:07 -0400 Brian Masney wrote: > On Sat, Jul 01, 2017 at 10:40:20AM +0100, Jonathan Cameron wrote: > > On Thu, 29 Jun 2017 13:03:51 -0400 > > Brian Masney wrote: > > > > > tsl2x7x_read_thresh() and tsl2x7x_write_thresh() currently assumes > > > that IIO_EV_INFO_VALUE

Re: [PATCH v4] iio: adc: Add support for DLN2 ADC

On Tue, 27 Jun 2017 15:05:19 -1000 Jack Andersen wrote: > This patch adds support for Diolan DLN2 ADC via IIO's ADC interface. > ADC is the fourth and final component of the DLN2 for the kernel. > > Signed-off-by: Jack Andersen Given it touches files

Re: [PATCH v4] iio: adc: Add support for DLN2 ADC

On Tue, 27 Jun 2017 15:05:19 -1000 Jack Andersen wrote: > This patch adds support for Diolan DLN2 ADC via IIO's ADC interface. > ADC is the fourth and final component of the DLN2 for the kernel. > > Signed-off-by: Jack Andersen Given it touches files in mfd, this needs an ack from Lee. Please

Re: [PATCH v7 0/2] More fixes for twl4030 charger

Hi Sebastian, > Am 19.06.2017 um 10:41 schrieb H. Nikolaus Schaller : > > Changes V7: > * removed already merged patches from patch set > * further fix for potentially wrong irq and notifier initialization sequence > (suggested by Sebastian Reichel) > * NULLify transceiver

Re: [PATCH v7 0/2] More fixes for twl4030 charger

Hi Sebastian, > Am 19.06.2017 um 10:41 schrieb H. Nikolaus Schaller : > > Changes V7: > * removed already merged patches from patch set > * further fix for potentially wrong irq and notifier initialization sequence > (suggested by Sebastian Reichel) > * NULLify transceiver pointer in case of

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

Michal Hocko wrote: > I really do appreciate your testing because it uncovers corner cases > most people do not test for and we can actually make the code better in > the end. That statement does not get to my heart at all. Collision between your approach and my approach is wasting both your time

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

Michal Hocko wrote: > I really do appreciate your testing because it uncovers corner cases > most people do not test for and we can actually make the code better in > the end. That statement does not get to my heart at all. Collision between your approach and my approach is wasting both your time

[PATCH] media: vb2 vmalloc: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by work with const dma_buf_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 3171 192 03363 d23

[PATCH] media: vb2 vmalloc: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by work with const dma_buf_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 3171 192 03363 d23

[PATCH] [media] solo6x10: fix detection of TW2864B chips

This patch enables support for non-Bluecherry labeled solo6110 based PCI cards which have 3 x TW2864B chips and one TW2865. These cards are displayed by lspci -nn as "Softlogic Co., Ltd. SOLO6110 H.264 Video encoder/decoder [9413:6110]" Bluecherry cards have 4 x TW2864A. According to datasheet

[PATCH] [media] solo6x10: fix detection of TW2864B chips

This patch enables support for non-Bluecherry labeled solo6110 based PCI cards which have 3 x TW2864B chips and one TW2865. These cards are displayed by lspci -nn as "Softlogic Co., Ltd. SOLO6110 H.264 Video encoder/decoder [9413:6110]" Bluecherry cards have 4 x TW2864A. According to datasheet

[PATCH] media: vb2 dma-contig: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by work with const dma_buf_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 6035 272 0630718a3

[PATCH] media: vb2 dma-contig: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by work with const dma_buf_ops. So mark the non-const structs as const. File size before: textdata bss dec hex filename 6035 272 0630718a3

Re: [PATCH 1/2] mailbox: reset txdone_method TXDONE_BY_POLL if client knows_txdone

On Fri, Jun 30, 2017 at 8:44 PM, Sudeep Holla wrote: > Currently the mailbox framework sets txdone_method to TXDONE_BY_POLL if > the controller sets txdone_by_poll. However some clients can have a > mechanism to do TXDONE_BY_ACK which they can specify by knows_txdone. >

Re: [PATCH 1/2] mailbox: reset txdone_method TXDONE_BY_POLL if client knows_txdone

On Fri, Jun 30, 2017 at 8:44 PM, Sudeep Holla wrote: > Currently the mailbox framework sets txdone_method to TXDONE_BY_POLL if > the controller sets txdone_by_poll. However some clients can have a > mechanism to do TXDONE_BY_ACK which they can specify by knows_txdone. > However, we endup setting

[PATCH] drm: armada: Constify drm_prop_enum_list structures.

drm_prop_enum_lists are not supposed to change at runtime. All functions working with drm_prop_enum_list provided by work with const drm_prop_enum_list. So mark the non-const structs as const. File size before: textdata bss dec hex filename 3594 176 03770

[PATCH] drm: armada: Constify drm_prop_enum_list structures.

drm_prop_enum_lists are not supposed to change at runtime. All functions working with drm_prop_enum_list provided by work with const drm_prop_enum_list. So mark the non-const structs as const. File size before: textdata bss dec hex filename 3594 176 03770

[PATCH] Staging : rtl8188eu: Fix Camel Case warning

Remove Camel Case warning found using checkpatch.pl --- drivers/staging/rtl8188eu/core/rtw_ap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c b/drivers/staging/rtl8188eu/core/rtw_ap.c index 647a922d79d1..6c63a9bbb876 100644 ---

[PATCH] Staging : rtl8188eu: Fix Camel Case warning

Remove Camel Case warning found using checkpatch.pl --- drivers/staging/rtl8188eu/core/rtw_ap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c b/drivers/staging/rtl8188eu/core/rtw_ap.c index 647a922d79d1..6c63a9bbb876 100644 ---

Re: [PATCH 5/6] staging: iio: tsl2x7x: refactor {read,write}_event_value to allow handling multiple iio_event_infos

On Sat, Jul 01, 2017 at 10:40:20AM +0100, Jonathan Cameron wrote: > On Thu, 29 Jun 2017 13:03:51 -0400 > Brian Masney wrote: > > > tsl2x7x_read_thresh() and tsl2x7x_write_thresh() currently assumes > > that IIO_EV_INFO_VALUE is the only iio_event_info that will be > >

Re: [PATCH 5/6] staging: iio: tsl2x7x: refactor {read,write}_event_value to allow handling multiple iio_event_infos

On Sat, Jul 01, 2017 at 10:40:20AM +0100, Jonathan Cameron wrote: > On Thu, 29 Jun 2017 13:03:51 -0400 > Brian Masney wrote: > > > tsl2x7x_read_thresh() and tsl2x7x_write_thresh() currently assumes > > that IIO_EV_INFO_VALUE is the only iio_event_info that will be > > passed in. This patch

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Richard Weinberger wrote: > Florian, > > Am 30.06.2017 um 21:55 schrieb Florian Westphal: > >>> Why not use a hash of the address? > >> > >> Would also work. Or xor it with a random number. > >> > >> On the other hand, for user space it would be more useful when the > >>

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Richard Weinberger wrote: > Florian, > > Am 30.06.2017 um 21:55 schrieb Florian Westphal: > >>> Why not use a hash of the address? > >> > >> Would also work. Or xor it with a random number. > >> > >> On the other hand, for user space it would be more useful when the > >> conntrack id > >> does

[PATCH] platform/x86: silead_dmi: Add touchscreen info for I.T.Works TW891 2-in-1

Add touchscreen info for I.T.Works TW891 2-in-1. Signed-off-by: Hans de Goede --- drivers/platform/x86/silead_dmi.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/platform/x86/silead_dmi.c b/drivers/platform/x86/silead_dmi.c index

[PATCH] platform/x86: silead_dmi: Add touchscreen info for I.T.Works TW891 2-in-1

Add touchscreen info for I.T.Works TW891 2-in-1. Signed-off-by: Hans de Goede --- drivers/platform/x86/silead_dmi.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/platform/x86/silead_dmi.c b/drivers/platform/x86/silead_dmi.c index 25cbea307a5e..6218deb22319

[PATCH 2/2] mfd: intel_soc_pmic: Differentiate between Bay and Cherry Trail CRC variants

Both Bay and Cherry Trail devices may be used together with a Crystal Cove PMIC. Each platform has its own variant of the PMIC, which both use the same ACPI HID, but they are not 100% compatible. This commits makes the intel_soc_pmic_core code check the _HRV of the ACPI-firmware-node and selects

Re: [PATCH][iio-next] iio: adc: stm32: make array stm32h7_adc_ckmodes_spec static

On Wed, 28 Jun 2017 16:35:04 +0200 Fabrice Gasnier wrote: > On 06/28/2017 03:06 PM, Colin King wrote: > > From: Colin Ian King > > > > The array stm32h7_adc_ckmodes_spec does not need to be in global scope, so > > make it static. > > > >

[PATCH 2/2] mfd: intel_soc_pmic: Differentiate between Bay and Cherry Trail CRC variants

Both Bay and Cherry Trail devices may be used together with a Crystal Cove PMIC. Each platform has its own variant of the PMIC, which both use the same ACPI HID, but they are not 100% compatible. This commits makes the intel_soc_pmic_core code check the _HRV of the ACPI-firmware-node and selects

Re: [PATCH][iio-next] iio: adc: stm32: make array stm32h7_adc_ckmodes_spec static

On Wed, 28 Jun 2017 16:35:04 +0200 Fabrice Gasnier wrote: > On 06/28/2017 03:06 PM, Colin King wrote: > > From: Colin Ian King > > > > The array stm32h7_adc_ckmodes_spec does not need to be in global scope, so > > make it static. > > > > Cleans up sparse warning: > > "symbol

[PATCH 1/2] mfd: intel_soc_pmic: Export separate mfd-cell configs for BYT and CHT

Both Bay and Cherry Trail devices may be used together with a Crystal Cove PMIC. Each platform has its own variant of the PMIC, which both use the same ACPI HID, but they are not 100% compatible. Looking at the android x86 kernel sources where most of the Crystal Cove code comes from, it talks

[PATCH 1/2] mfd: intel_soc_pmic: Export separate mfd-cell configs for BYT and CHT

Both Bay and Cherry Trail devices may be used together with a Crystal Cove PMIC. Each platform has its own variant of the PMIC, which both use the same ACPI HID, but they are not 100% compatible. Looking at the android x86 kernel sources where most of the Crystal Cove code comes from, it talks

<    1   2   3   4   >