Re: [RESEND PATCH 3/3] infiniband: hns: avoid gcc-7.0.1 warning for uninitialized data

On Fri, 2017-03-24 at 23:02 +0100, Arnd Bergmann wrote: > hns_roce_v1_cq_set_ci() calls roce_set_bit() on an uninitialized > field, > which will then change only a few of its bits, causing a warning with > the latest gcc: > > infiniband/hw/hns/hns_roce_hw_v1.c: In function >

Re: [RESEND PATCH 3/3] infiniband: hns: avoid gcc-7.0.1 warning for uninitialized data

On Fri, 2017-03-24 at 23:02 +0100, Arnd Bergmann wrote: > hns_roce_v1_cq_set_ci() calls roce_set_bit() on an uninitialized > field, > which will then change only a few of its bits, causing a warning with > the latest gcc: > > infiniband/hw/hns/hns_roce_hw_v1.c: In function >

[GIT PULL rcu/urgent] Make SRCU be built by default

Hello, Ingo, This commit causes SRCU to be built by default. This handles the surprisingly common case where include/linux/srcu.h is included into files being built with CONFIG_SRCU=n. The fact that there is now a Tiny SRCU means that this should be OK from a Linux-kernel tinification

[GIT PULL rcu/urgent] Make SRCU be built by default

Hello, Ingo, This commit causes SRCU to be built by default. This handles the surprisingly common case where include/linux/srcu.h is included into files being built with CONFIG_SRCU=n. The fact that there is now a Tiny SRCU means that this should be OK from a Linux-kernel tinification

Re: [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: > And what happens when there is a scheduling event right here? > __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong > path. So the whole thing we're doing right now is wrong: set bit and then clear bit. We should

Re: [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: > And what happens when there is a scheduling event right here? > __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong > path. So the whole thing we're doing right now is wrong: set bit and then clear bit. We should

[PATCH v3 2/2] x86/mce/AMD: Carve out SMCA bank configuration

From: Yazen Ghannam Scalable MCA systems have a new MCA_CONFIG register that we use to configure each bank. We currently use this when we set up thresholding. However, this is logically separate. Group all SMCA-related initialization into a single, separate function. This

[PATCH v3 2/2] x86/mce/AMD: Carve out SMCA bank configuration

From: Yazen Ghannam Scalable MCA systems have a new MCA_CONFIG register that we use to configure each bank. We currently use this when we set up thresholding. However, this is logically separate. Group all SMCA-related initialization into a single, separate function. This includes setting

[PATCH v3 1/2] x86/mce/AMD: Redo logging of errors from APIC LVT interrupts

From: Yazen Ghannam We have support for the new SMCA MCA_DE{STAT,ADDR} registers in Linux. So we've used these registers in place of MCA_{STATUS,ADDR} on SMCA systems. However, the guidance for current implementations of SMCA is to continue using MCA_{STATUS,ADDR} and to

[PATCH v3 1/2] x86/mce/AMD: Redo logging of errors from APIC LVT interrupts

From: Yazen Ghannam We have support for the new SMCA MCA_DE{STAT,ADDR} registers in Linux. So we've used these registers in place of MCA_{STATUS,ADDR} on SMCA systems. However, the guidance for current implementations of SMCA is to continue using MCA_{STATUS,ADDR} and to use MCA_DE{STAT,ADDR}

Re: [PATCH] [media] s5p-jpeg: fix recursive spinlock acquisition

Hi Alexandre, Thanks for the patch. On 04/25/2017 08:19 AM, Alexandre Courbot wrote: > v4l2_m2m_job_finish(), which is called from the interrupt handler with > slock acquired, can call the device_run() hook immediately if another > context was in the queue. This hook also acquires slock,

Re: [PATCH] [media] s5p-jpeg: fix recursive spinlock acquisition

Hi Alexandre, Thanks for the patch. On 04/25/2017 08:19 AM, Alexandre Courbot wrote: > v4l2_m2m_job_finish(), which is called from the interrupt handler with > slock acquired, can call the device_run() hook immediately if another > context was in the queue. This hook also acquires slock,

Re: [PATCH] staging: ks7010: fix few checkpatch warnings in ks_wlan_net.c

On Tue, Apr 25, 2017 at 09:02:48PM +0200, Ilia Sergachev wrote: > Fixes few warnings and checks in drivers/staging/ks7010/ks_wlan_net.c What type of warnings? What checks? It builds just fine for me here. You need to be very specific. And only do one type of thing per patch, a big "fixes all

Re: [PATCH] staging: ks7010: fix few checkpatch warnings in ks_wlan_net.c

On Tue, Apr 25, 2017 at 09:02:48PM +0200, Ilia Sergachev wrote: > Fixes few warnings and checks in drivers/staging/ks7010/ks_wlan_net.c What type of warnings? What checks? It builds just fine for me here. You need to be very specific. And only do one type of thing per patch, a big "fixes all

Re: [PATCH] ARM: dts: bcm-cygnus: Add 911360's V3D device.

On Tue, 18 Apr 2017 16:32:34 -0700, Eric Anholt wrote: > This loads the VC4 driver on the 911360_entphn platform (with the > corresponding series sent to dri-devel), which is supported by master > of the Mesa tree. > > Signed-off-by: Eric Anholt > --- Applied,

Re: [PATCH] ARM: dts: bcm-cygnus: Add 911360's V3D device.

On Tue, 18 Apr 2017 16:32:34 -0700, Eric Anholt wrote: > This loads the VC4 driver on the 911360_entphn platform (with the > corresponding series sent to dri-devel), which is supported by master > of the Mesa tree. > > Signed-off-by: Eric Anholt > --- Applied, thanks! -- Florian

Re: [PATCH v3] soc: brcmstb: enable drivers for ARM64 and BMIPS

On 04/20/2017 09:55 AM, Markus Mayer wrote: > From: Markus Mayer > > We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64 and > BMIPS. > > Signed-off-by: Markus Mayer Applied, thanks! -- Florian

Re: [PATCH v3] soc: brcmstb: enable drivers for ARM64 and BMIPS

On 04/20/2017 09:55 AM, Markus Mayer wrote: > From: Markus Mayer > > We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64 and > BMIPS. > > Signed-off-by: Markus Mayer Applied, thanks! -- Florian

Re: [PATCH] PCI: imx6: fix spelling mistake: "contol" -> "control"

On Fri, Apr 21, 2017 at 08:02:30AM +0100, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in dev_err message > > Signed-off-by: Colin Ian King Applied with Richard's ack to pci/host-imx6 for v4.12, thanks. FWIW,

Re: [PATCH] PCI: imx6: fix spelling mistake: "contol" -> "control"

On Fri, Apr 21, 2017 at 08:02:30AM +0100, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in dev_err message > > Signed-off-by: Colin Ian King Applied with Richard's ack to pci/host-imx6 for v4.12, thanks. FWIW, there are about 25 other occurrences of "contol" in

Re: [PATCH] x86/mm/64: Fix crash in remove_pagetable()

On Tue, Apr 25, 2017 at 11:53 AM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> On Tue, Apr 25, 2017 at 2:25 AM, Kirill A. Shutemov >> wrote: >> > remove_pagetable() does page walk using p*d_page_vaddr() plus cast.

Re: [PATCH] x86/mm/64: Fix crash in remove_pagetable()

On Tue, Apr 25, 2017 at 11:53 AM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> On Tue, Apr 25, 2017 at 2:25 AM, Kirill A. Shutemov >> wrote: >> > remove_pagetable() does page walk using p*d_page_vaddr() plus cast. >> > It's not canonical approach -- we usually use p*d_offset() for that. >>

Re: [PATCH] staging: android: ion: fix coding style issue

On Sun, Apr 23, 2017 at 03:37:29PM +0530, Adheer Chandravanshi wrote: > Use tab instead of spaces for indentation, as reported by checkpatch.pl > > Signed-off-by: Adheer Chandravanshi > --- > drivers/staging/android/ion/ion_cma_heap.c | 6 +++--- > 1 file changed,

Re: [PATCH] staging: android: ion: fix coding style issue

On Sun, Apr 23, 2017 at 03:37:29PM +0530, Adheer Chandravanshi wrote: > Use tab instead of spaces for indentation, as reported by checkpatch.pl > > Signed-off-by: Adheer Chandravanshi > --- > drivers/staging/android/ion/ion_cma_heap.c | 6 +++--- > 1 file changed, 3 insertions(+), 3

Re: [RFC 0/6] optimize ctx switch with rb-tree

> > If I disable traversing in the per-process case then the overhead disappears. > > For the system-wide case the ctx->pinned_groups and ctx->flexible_groups > lists are parts of per-cpu perf_cpu_context object and count of iterations is > small (#events == 29). Yes, seems like it would

Re: [PATCH] net: ipv6: check route protocol when deleting routes

On 4/24/17 3:48 AM, Lorenzo Colitti wrote: > For non-stable kernels, it seems that the proper fix would be: > > 1. Ensure that when an RA creates a route, it properly sets > rtm_protocol at time of route creation. > 2. When we dump routes to userspace, we don't overwrite the rtm_protocol. +1

Re: [RFC 0/6] optimize ctx switch with rb-tree

> > If I disable traversing in the per-process case then the overhead disappears. > > For the system-wide case the ctx->pinned_groups and ctx->flexible_groups > lists are parts of per-cpu perf_cpu_context object and count of iterations is > small (#events == 29). Yes, seems like it would

Re: [PATCH] net: ipv6: check route protocol when deleting routes

On 4/24/17 3:48 AM, Lorenzo Colitti wrote: > For non-stable kernels, it seems that the proper fix would be: > > 1. Ensure that when an RA creates a route, it properly sets > rtm_protocol at time of route creation. > 2. When we dump routes to userspace, we don't overwrite the rtm_protocol. +1

Re: [PATCH] x86/mm/64: Fix crash in remove_pagetable()

* Dan Williams wrote: > On Tue, Apr 25, 2017 at 2:25 AM, Kirill A. Shutemov > wrote: > > remove_pagetable() does page walk using p*d_page_vaddr() plus cast. > > It's not canonical approach -- we usually use p*d_offset() for that. > > >

Re: [PATCH] x86/mm/64: Fix crash in remove_pagetable()

* Dan Williams wrote: > On Tue, Apr 25, 2017 at 2:25 AM, Kirill A. Shutemov > wrote: > > remove_pagetable() does page walk using p*d_page_vaddr() plus cast. > > It's not canonical approach -- we usually use p*d_offset() for that. > > > > It works fine as long as all page table levels are

Re: Revised statx(2) man page for review

Hi Michael On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote: > > [...] > > Could you please carefully review the text below, in case > I added any errors. Just a few comments below. > [...] > >Invoking statx(): >To access a file's status, no

Re: Revised statx(2) man page for review

Hi Michael On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote: > > [...] > > Could you please carefully review the text below, in case > I added any errors. Just a few comments below. > [...] > >Invoking statx(): >To access a file's status, no

Re: [PATCH 2/2] sched/fair: Always propagate runnable_load_avg

Hello, On Tue, Apr 25, 2017 at 02:59:18PM +0200, Vincent Guittot wrote: > >> So you are changing the purpose of propagate_entity_load_avg which > >> aims to propagate load_avg/util_avg changes only when a task migrate > >> and you also want to propagate the enqueue/dequeue in the parent > >>

Re: [PATCH 2/2] sched/fair: Always propagate runnable_load_avg

Hello, On Tue, Apr 25, 2017 at 02:59:18PM +0200, Vincent Guittot wrote: > >> So you are changing the purpose of propagate_entity_load_avg which > >> aims to propagate load_avg/util_avg changes only when a task migrate > >> and you also want to propagate the enqueue/dequeue in the parent > >>

Re: [PATCH 1/2] kvm: Fix mmu_notifier release race

2017-04-24 11:10+0100, Suzuki K Poulose: > The KVM uses mmu_notifier (wherever available) to keep track > of the changes to the mm of the guest. The guest shadow page > tables are released when the VM exits via mmu_notifier->ops.release(). > There is a rare chance that the mmu_notifier->release

Re: [PATCH 1/2] kvm: Fix mmu_notifier release race

2017-04-24 11:10+0100, Suzuki K Poulose: > The KVM uses mmu_notifier (wherever available) to keep track > of the changes to the mm of the guest. The guest shadow page > tables are released when the VM exits via mmu_notifier->ops.release(). > There is a rare chance that the mmu_notifier->release

[PATCH v6 3/5] rxrpc: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- net/rxrpc/rxkad.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 4374e7b9c7bf..dcf46c9c3ece 100644 --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c @@ -229,7 +229,9

[PATCH v6 3/5] rxrpc: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- net/rxrpc/rxkad.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 4374e7b9c7bf..dcf46c9c3ece 100644 --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c @@ -229,7 +229,9 @@ static int

[PATCH v6 2/5] ipsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 30 -- net/ipv6/ah6.c | 8 ++-- net/ipv6/esp6.c | 31 +-- 4 files changed, 53 insertions(+), 24 deletions(-) diff --git

[PATCH v6 5/5] virtio_net: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- drivers/net/virtio_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index f36584616e7d..1709fd0b4bf7 100644 --- a/drivers/net/virtio_net.c +++

[PATCH v6 4/5] macsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- drivers/net/macsec.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index dbab05afcdbe..d846f42b99ec 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c

[PATCH v6 2/5] ipsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 30 -- net/ipv6/ah6.c | 8 ++-- net/ipv6/esp6.c | 31 +-- 4 files changed, 53 insertions(+), 24 deletions(-) diff --git a/net/ipv4/ah4.c

[PATCH v6 5/5] virtio_net: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- drivers/net/virtio_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index f36584616e7d..1709fd0b4bf7 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@

[PATCH v6 4/5] macsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- drivers/net/macsec.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index dbab05afcdbe..d846f42b99ec 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c @@ -733,7

[PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

This is a defense-in-depth measure in response to bugs like 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While we're at it, we also limit the amount of recursion this function is allowed to do. Not actually providing a bounded base case is a future diaster that we can easily avoid

[PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

This is a defense-in-depth measure in response to bugs like 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While we're at it, we also limit the amount of recursion this function is allowed to do. Not actually providing a bounded base case is a future diaster that we can easily avoid

Re: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

On Fri, Apr 21, 2017 at 2:46 AM, Patel, Mayurkumar wrote: > Hi Bjorn/Kaya, > > >> >>On 4/17/2017 12:38 PM, Bjorn Helgaas wrote: Like you said, what do we do by default is the question. Should we opt for safe like we are doing, or try to save some power. >>> I

Re: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

On Fri, Apr 21, 2017 at 2:46 AM, Patel, Mayurkumar wrote: > Hi Bjorn/Kaya, > > >> >>On 4/17/2017 12:38 PM, Bjorn Helgaas wrote: Like you said, what do we do by default is the question. Should we opt for safe like we are doing, or try to save some power. >>> I think safety is paramount.

[PATCH] drm/nouveau: Add support for clockgating on Fermi+

This adds support for enabling automatic clockgating on nvidia GPUs for Fermi and later generations. This saves a little bit of power, bringing my fermi GPU's power consumption from ~28.3W on idle to ~27W, and my kepler's idle power consumption from ~23.6W to ~21.65W. Similar to how the nvidia

[PATCH] drm/nouveau: Add support for clockgating on Fermi+

This adds support for enabling automatic clockgating on nvidia GPUs for Fermi and later generations. This saves a little bit of power, bringing my fermi GPU's power consumption from ~28.3W on idle to ~27W, and my kepler's idle power consumption from ~23.6W to ~21.65W. Similar to how the nvidia

Re: [PATCH v3] Staging: most: use __func__ instead of the function name

On Mon, Apr 24, 2017 at 11:20:22PM -0700, Chandra Annamaneni wrote: > > Change video.c to use %s, __func__ instead of function names. > Warnings flagged by checkpatch.pl > > Signed-off-by: Chandra Annamaneni Why is this indented? Why is your subject a

Re: [PATCH v3] Staging: most: use __func__ instead of the function name

On Mon, Apr 24, 2017 at 11:20:22PM -0700, Chandra Annamaneni wrote: > > Change video.c to use %s, __func__ instead of function names. > Warnings flagged by checkpatch.pl > > Signed-off-by: Chandra Annamaneni Why is this indented? Why is your subject a "Re:"?

Re: [RFC PATCH] drivers: dma-mapping: Do not attempt to create a scatterlist for from_coherent buffers

On Tue, Apr 25, 2017 at 07:05:26PM +0100, Russell King - ARM Linux wrote: > On Tue, Apr 25, 2017 at 06:57:39PM +0100, Catalin Marinas wrote: > > Memory returned by dma_alloc_from_coherent() is not backed by struct > > page and creating a scatterlist would use invalid page pointers. The > > patch

Re: [RFC PATCH] drivers: dma-mapping: Do not attempt to create a scatterlist for from_coherent buffers

On Tue, Apr 25, 2017 at 07:05:26PM +0100, Russell King - ARM Linux wrote: > On Tue, Apr 25, 2017 at 06:57:39PM +0100, Catalin Marinas wrote: > > Memory returned by dma_alloc_from_coherent() is not backed by struct > > page and creating a scatterlist would use invalid page pointers. The > > patch

[PATCH v2 04/21] target: Make use of the new sg_map function at 16 call sites

Fairly straightforward conversions in all spots. In a couple of cases any error gets propogated up should sg_map fail. In other cases a warning is issued if the kmap fails seeing there's no clear error path. This should not be an issue until someone tries to use unmappable memory in the sgl with

[PATCH v3 0/2] of: Add unit tests for applying overlays

From: Frank Rowand Existing overlay unit tests examine individual pieces of the overlay code. The new tests target the entire process of applying an overlay. Changes from v2: - of_private.h: move __unflatten_device_tree() outside #ifdef CONFIG_OF_UNITTEST -

[PATCH v2 04/21] target: Make use of the new sg_map function at 16 call sites

Fairly straightforward conversions in all spots. In a couple of cases any error gets propogated up should sg_map fail. In other cases a warning is issued if the kmap fails seeing there's no clear error path. This should not be an issue until someone tries to use unmappable memory in the sgl with

[PATCH v3 0/2] of: Add unit tests for applying overlays

From: Frank Rowand Existing overlay unit tests examine individual pieces of the overlay code. The new tests target the entire process of applying an overlay. Changes from v2: - of_private.h: move __unflatten_device_tree() outside #ifdef CONFIG_OF_UNITTEST - unittest.c: move overlay

[PATCH v3 1/2] of: support dtc compiler flags for overlays

From: Frank Rowand The dtc compiler version that adds initial support was available in 4.11-rc1. Add the ability to set the dtc compiler flags needed by overlays. Signed-off-by: Frank Rowand --- scripts/Makefile.lib | 2 ++ 1 file changed, 2

[PATCH v3 1/2] of: support dtc compiler flags for overlays

From: Frank Rowand The dtc compiler version that adds initial support was available in 4.11-rc1. Add the ability to set the dtc compiler flags needed by overlays. Signed-off-by: Frank Rowand --- scripts/Makefile.lib | 2 ++ 1 file changed, 2 insertions(+) diff --git a/scripts/Makefile.lib

Re: [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 20:24, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:00:14PM +0200, Juergen Gross wrote: >> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set >> on AMD cpus. Xen will disable this via setup_clear_cpu_cap(), so test >> cpu_caps_cleared to not have disabled this

Re: [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 20:24, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:00:14PM +0200, Juergen Gross wrote: >> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set >> on AMD cpus. Xen will disable this via setup_clear_cpu_cap(), so test >> cpu_caps_cleared to not have disabled this

Re: [PATCH 1/1 linux-next] staging: media: atomisp: kmap() can't fail

On Tue, Apr 25, 2017 at 08:10:19PM +0200, Fabian Frederick wrote: > Remove NULL test on kmap() That says _what_ you did, which is obvious if you read the patch. You need to say _why_ you are doing what you are doing in this patch in the changelog description. thanks, greg k-h

Re: [PATCH 1/1 linux-next] staging: media: atomisp: kmap() can't fail

On Tue, Apr 25, 2017 at 08:10:19PM +0200, Fabian Frederick wrote: > Remove NULL test on kmap() That says _what_ you did, which is obvious if you read the patch. You need to say _why_ you are doing what you are doing in this patch in the changelog description. thanks, greg k-h

[PATCH v3 2/2] of: Add unit tests for applying overlays

From: Frank Rowand Existing overlay unit tests examine individual pieces of the overlay code. The new tests target the entire process of applying an overlay. Signed-off-by: Frank Rowand --- There are checkpatch warnings. I have reviewed them and

[PATCH v3 2/2] of: Add unit tests for applying overlays

From: Frank Rowand Existing overlay unit tests examine individual pieces of the overlay code. The new tests target the entire process of applying an overlay. Signed-off-by: Frank Rowand --- There are checkpatch warnings. I have reviewed them and feel they can be ignored. drivers/of/fdt.c

[PATCH net-next] dt-bindings: mdio: Clarify binding document

The described GPIO reset property is applicable to *all* child PHYs. If we have one reset line per PHY present on the MDIO bus, these automatically become properties of the child PHY nodes. Finally, indicate how the RESET pulse width must be defined, which is the maximum value of all individual

[RESEND][PATCH V2 4/4] regulator: Add ROHM BD9571MWV-M PMIC regulator driver

Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC. This block supports three voltage monitors, VD18, VD25, VD33 for the 1V8, 2V5, 3V3 voltage rails and a single voltage regulator for the DVFS rail. Signed-off-by: Marek Vasut Cc:

[PATCH net-next] dt-bindings: mdio: Clarify binding document

The described GPIO reset property is applicable to *all* child PHYs. If we have one reset line per PHY present on the MDIO bus, these automatically become properties of the child PHY nodes. Finally, indicate how the RESET pulse width must be defined, which is the maximum value of all individual

[RESEND][PATCH V2 4/4] regulator: Add ROHM BD9571MWV-M PMIC regulator driver

Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC. This block supports three voltage monitors, VD18, VD25, VD33 for the 1V8, 2V5, 3V3 voltage rails and a single voltage regulator for the DVFS rail. Signed-off-by: Marek Vasut Cc: linux-kernel@vger.kernel.org Cc: Liam Girdwood

Re: [PATCH v4 00/21] PCI: fix config space memory mappings

Ack. Tested-by: Khuong Dinh On Tue, Apr 25, 2017 at 9:20 AM, Jingoo Han wrote: > On Tuesday, April 25, 2017 2:41 AM, Jon Masters wrote: >> >> On 04/19/2017 12:48 PM, Lorenzo Pieralisi wrote: >> >> > On some platforms (ie ARM/ARM64) ioremap fails to comply

[RESEND][PATCH V2 2/4] mfd: Add ROHM BD9571MWV-M MFD PMIC driver

Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS entry. The MFD part only specifies the regmap bits for the PMIC and binds the subdevs together. Signed-off-by: Marek Vasut Cc: linux-kernel@vger.kernel.org Cc: Geert Uytterhoeven

Re: [PATCH v4 00/21] PCI: fix config space memory mappings

Ack. Tested-by: Khuong Dinh On Tue, Apr 25, 2017 at 9:20 AM, Jingoo Han wrote: > On Tuesday, April 25, 2017 2:41 AM, Jon Masters wrote: >> >> On 04/19/2017 12:48 PM, Lorenzo Pieralisi wrote: >> >> > On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI >> > configuration

[RESEND][PATCH V2 2/4] mfd: Add ROHM BD9571MWV-M MFD PMIC driver

Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS entry. The MFD part only specifies the regmap bits for the PMIC and binds the subdevs together. Signed-off-by: Marek Vasut Cc: linux-kernel@vger.kernel.org Cc: Geert Uytterhoeven Cc: Lee Jones --- V2: - Change

[PATCH v2 03/21] libiscsi: Make use of new the sg_map helper function

Convert the kmap and kmap_atomic uses to the sg_map function. We now store the flags for the kmap instead of a boolean to indicate atomicitiy. We use ISCSI_TCP_INTERNAL_ERR error type that was prepared earlier for this. Signed-off-by: Logan Gunthorpe Cc: Lee Duncan

[PATCH v2 03/21] libiscsi: Make use of new the sg_map helper function

Convert the kmap and kmap_atomic uses to the sg_map function. We now store the flags for the kmap instead of a boolean to indicate atomicitiy. We use ISCSI_TCP_INTERNAL_ERR error type that was prepared earlier for this. Signed-off-by: Logan Gunthorpe Cc: Lee Duncan Cc: Chris Leech ---

[PATCH v2 14/21] scsi: libfc, csiostor: Change to sg_copy_buffer in two drivers

These two drivers appear to duplicate the functionality of sg_copy_buffer. So we clean them up to use the common code. This helps us remove a couple of instances that would otherwise be slightly tricky sg_map usages. Signed-off-by: Logan Gunthorpe Cc: Johannes Thumshirn

[PATCH v2 14/21] scsi: libfc, csiostor: Change to sg_copy_buffer in two drivers

These two drivers appear to duplicate the functionality of sg_copy_buffer. So we clean them up to use the common code. This helps us remove a couple of instances that would otherwise be slightly tricky sg_map usages. Signed-off-by: Logan Gunthorpe Cc: Johannes Thumshirn ---

[PATCH] spi: cadence: Allow for GPIO pins to be used as chipselects

This adds support for using GPIOs for chipselects as described by the default dt-bindings. Signed-off-by: Moritz Fischer --- Hi Mark, I've tested this on my Zynq-7000 based system with GPIO and non-gpio based chipselects mixed. Thanks for your time, Moritz ---

[PATCH] spi: cadence: Allow for GPIO pins to be used as chipselects

This adds support for using GPIOs for chipselects as described by the default dt-bindings. Signed-off-by: Moritz Fischer --- Hi Mark, I've tested this on my Zynq-7000 based system with GPIO and non-gpio based chipselects mixed. Thanks for your time, Moritz --- drivers/spi/spi-cadence.c |

[PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

Very straightforward conversion to the new function in the caam driver and shash library. Signed-off-by: Logan Gunthorpe Cc: Herbert Xu Cc: "David S. Miller" --- crypto/shash.c| 9 ++---

[PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

Very straightforward conversion to the new function in the caam driver and shash library. Signed-off-by: Logan Gunthorpe Cc: Herbert Xu Cc: "David S. Miller" --- crypto/shash.c| 9 ++--- drivers/crypto/caam/caamalg.c | 8 +++- 2 files changed, 9 insertions(+), 8

[PATCH v2 00/21] Introduce common scatterlist map function

Changes since v1: * Rebased onto next-20170424 * Removed the _offset version of these functions per Christoph's suggestion * Added an SG_MAP_MUST_NOT_FAIL flag which will BUG_ON in future cases that can't gracefully fail. This removes a bunch of the noise added in v1 to a couple of the

[PATCH v2 00/21] Introduce common scatterlist map function

Changes since v1: * Rebased onto next-20170424 * Removed the _offset version of these functions per Christoph's suggestion * Added an SG_MAP_MUST_NOT_FAIL flag which will BUG_ON in future cases that can't gracefully fail. This removes a bunch of the noise added in v1 to a couple of the

[PATCH v2 16/21] mmc: sdhci: Make use of the new sg_map helper function

Straightforward conversion, except due to the lack of an error path we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe Cc: Adrian Hunter Cc: Ulf Hansson ---

[PATCH v2 16/21] mmc: sdhci: Make use of the new sg_map helper function

Straightforward conversion, except due to the lack of an error path we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe Cc: Adrian Hunter Cc: Ulf Hansson --- drivers/mmc/host/sdhci.c | 14 +- 1 file changed, 9

[PATCH v2 18/21] mmc: tmio: Make use of the new sg_map helper function

Straightforward conversion to sg_map helper. Seeing there is no cleare error path, SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe Cc: Wolfram Sang Cc: Ulf Hansson

[PATCH v2 17/21] mmc: spi: Make use of the new sg_map helper function

We use the sg_map helper but it's slightly more complicated as we only check for the error when the mapping actually gets used. Such that if the mapping failed but wasn't needed then no error occurs. Signed-off-by: Logan Gunthorpe Cc: Ulf Hansson ---

[PATCH v2 18/21] mmc: tmio: Make use of the new sg_map helper function

Straightforward conversion to sg_map helper. Seeing there is no cleare error path, SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe Cc: Wolfram Sang Cc: Ulf Hansson --- drivers/mmc/host/tmio_mmc.h | 7 +--

[PATCH v2 17/21] mmc: spi: Make use of the new sg_map helper function

We use the sg_map helper but it's slightly more complicated as we only check for the error when the mapping actually gets used. Such that if the mapping failed but wasn't needed then no error occurs. Signed-off-by: Logan Gunthorpe Cc: Ulf Hansson --- drivers/mmc/host/mmc_spi.c | 26

[PATCH v2 06/21] crypto: hifn_795x: Make use of the new sg_map helper function

Conversion of a couple kmap_atomic instances to the sg_map helper function. However, it looks like there was a bug in the original code: the source scatter lists offset (t->offset) was passed to ablkcipher_get which added it to the destination address. This doesn't make a lot of sense, but

[PATCH v2 06/21] crypto: hifn_795x: Make use of the new sg_map helper function

Conversion of a couple kmap_atomic instances to the sg_map helper function. However, it looks like there was a bug in the original code: the source scatter lists offset (t->offset) was passed to ablkcipher_get which added it to the destination address. This doesn't make a lot of sense, but

Re: [PATCH] IB/fmr_pool: Convert the cleanup thread into kthread worker API

On Mon, 2016-10-17 at 17:39 +0200, Petr Mladek wrote: > Kthreads are currently implemented as an infinite loop. Each > has its own variant of checks for terminating, freezing, > awakening. In many cases it is unclear to say in which state > it is and sometimes it is done a wrong way. > > The plan

Re: [PATCH] IB/fmr_pool: Convert the cleanup thread into kthread worker API

On Mon, 2016-10-17 at 17:39 +0200, Petr Mladek wrote: > Kthreads are currently implemented as an infinite loop. Each > has its own variant of checks for terminating, freezing, > awakening. In many cases it is unclear to say in which state > it is and sometimes it is done a wrong way. > > The plan

[PATCH v2 21/21] memstick: Make use of the new sg_map helper function

Straightforward conversion, but we have to make use of SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe Cc: Alex Dubov --- drivers/memstick/host/jmb38x_ms.c | 11 ++-

[PATCH v2 21/21] memstick: Make use of the new sg_map helper function

Straightforward conversion, but we have to make use of SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases in the future. Signed-off-by: Logan Gunthorpe Cc: Alex Dubov --- drivers/memstick/host/jmb38x_ms.c | 11 ++- drivers/memstick/host/tifm_ms.c | 11 ++- 2 files

[PATCH v2 09/21] staging: unisys: visorbus: Make use of the new sg_map helper function

Straightforward conversion to the new function. Signed-off-by: Logan Gunthorpe Acked-by: David Kershner --- drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git

[PATCH v2 09/21] staging: unisys: visorbus: Make use of the new sg_map helper function

Straightforward conversion to the new function. Signed-off-by: Logan Gunthorpe Acked-by: David Kershner --- drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c

[PATCH v2 11/21] scsi: ipr, pmcraid, isci: Make use of the new sg_map helper

Very straightforward conversion of three scsi drivers. Signed-off-by: Logan Gunthorpe Cc: Brian King Cc: Artur Paszkiewicz --- drivers/scsi/ipr.c | 27 ++- drivers/scsi/isci/request.c | 42

[PATCH v2 11/21] scsi: ipr, pmcraid, isci: Make use of the new sg_map helper

Very straightforward conversion of three scsi drivers. Signed-off-by: Logan Gunthorpe Cc: Brian King Cc: Artur Paszkiewicz --- drivers/scsi/ipr.c | 27 ++- drivers/scsi/isci/request.c | 42 +- drivers/scsi/pmcraid.c

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