Re: [PATCH 9/9] net, bpf: use kvzalloc helper

Andrew, please ignore this one. On Mon 30-01-17 10:49:40, Michal Hocko wrote: > From: Michal Hocko > > both bpf_map_area_alloc and xt_alloc_table_info try really hard to > play nicely with large memory requests which can be triggered from > the userspace (by an admin). See 5bad87348c70

Re: [RFC V2 02/12] mm: Isolate HugeTLB allocations away from CDM nodes

On 01/29/2017 07:35 PM, Anshuman Khandual wrote: > HugeTLB allocation/release/accounting currently spans across all the nodes > under N_MEMORY node mask. Coherent memory nodes should not be part of these > allocations. So use system_ram() call to fetch system RAM only nodes on the > platform which

Re: [RFC v2 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer

Hi Christoffer, On Mon, Jan 30, 2017 at 9:49 AM, Christoffer Dall wrote: > On Thu, Jan 26, 2017 at 08:04:53PM -0500, Jintack Lim wrote: >> Now that we have a separate structure for timer context, make functions >> general so that they can work with any timer context,

Re: [RFC v2 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer

Hi Christoffer, On Mon, Jan 30, 2017 at 9:49 AM, Christoffer Dall wrote: > On Thu, Jan 26, 2017 at 08:04:53PM -0500, Jintack Lim wrote: >> Now that we have a separate structure for timer context, make functions >> general so that they can work with any timer context, not just the >> virtual

Re: [RFC v2 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer

On Sun, Jan 29, 2017 at 7:01 AM, Marc Zyngier wrote: > On Fri, Jan 27 2017 at 01:04:53 AM, Jintack Lim > wrote: >> Now that we have a separate structure for timer context, make functions >> general so that they can work with any timer context, not

Re: [RFC v2 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer

On Sun, Jan 29, 2017 at 7:01 AM, Marc Zyngier wrote: > On Fri, Jan 27 2017 at 01:04:53 AM, Jintack Lim > wrote: >> Now that we have a separate structure for timer context, make functions >> general so that they can work with any timer context, not just the > > generic? yes, thanks! > >>

[PATCH] iio: stx104: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the Apex Embedded Systems STX104. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William

[PATCH] iio: stx104: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the Apex Embedded Systems STX104. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William

[PATCH 1/2] ARM: cache-uniphier: include instead of

Nothing in this header file depends on . Rather, should be included for -ENODEV. Signed-off-by: Masahiro Yamada --- KernelVersion: 4.10-rc1 arch/arm/include/asm/hardware/cache-uniphier.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/2] ARM: cache-uniphier: clean up active way setup code

Now, the active way setup function is called with a fixed value zero for the second argument. The code can be simpler. Signed-off-by: Masahiro Yamada --- KernelVersion: 4.10-rc1 arch/arm/mm/cache-uniphier.c | 23 +-- 1 file changed, 9

[PATCH 1/2] ARM: cache-uniphier: include instead of

Nothing in this header file depends on . Rather, should be included for -ENODEV. Signed-off-by: Masahiro Yamada --- KernelVersion: 4.10-rc1 arch/arm/include/asm/hardware/cache-uniphier.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/2] ARM: cache-uniphier: clean up active way setup code

Now, the active way setup function is called with a fixed value zero for the second argument. The code can be simpler. Signed-off-by: Masahiro Yamada --- KernelVersion: 4.10-rc1 arch/arm/mm/cache-uniphier.c | 23 +-- 1 file changed, 9 insertions(+), 14 deletions(-) diff

[RFC 2/3] kernel: Wire up system power framework

From: Thierry Reding Instead of relying on the globally defined pm_power_off_prepare() and pm_power_off() function pointers, use the equivalent global functions from the system-power framework. The system-power framework implements a fallback that relies on these global

[RFC 2/3] kernel: Wire up system power framework

From: Thierry Reding Instead of relying on the globally defined pm_power_off_prepare() and pm_power_off() function pointers, use the equivalent global functions from the system-power framework. The system-power framework implements a fallback that relies on these global functions in case no

[PATCH 3/5] gpio: 104-idio-16: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the ACCES 104-IDIO-16. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt Gray

[PATCH 4/5] gpio: gpio-mm: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the Diamond Systems GPIO-MM. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt

[PATCH 3/5] gpio: 104-idio-16: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the ACCES 104-IDIO-16. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt Gray

[PATCH 4/5] gpio: gpio-mm: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the Diamond Systems GPIO-MM. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt

[PATCH v3] iio: cros_ec_light_prox: add ChromeOS EC Light and Proximity Sensors

From: Gwendal Grignou Handle Light and Proximity sensors presented by the ChromeOS EC Sensor hub. Creates an IIO device for each functions. Signed-off-by: Gwendal Grignou Signed-off-by: Guenter Roeck Signed-off-by: Enric

[PATCH v3] iio: cros_ec_light_prox: add ChromeOS EC Light and Proximity Sensors

From: Gwendal Grignou Handle Light and Proximity sensors presented by the ChromeOS EC Sensor hub. Creates an IIO device for each functions. Signed-off-by: Gwendal Grignou Signed-off-by: Guenter Roeck Signed-off-by: Enric Balletbo i Serra --- Changes since v3: - Move to iio/light directory.

[PATCH 0/2] ARM: cache-uniphier: two cleanup patches

Sorry that I had not replied earlier. I came back to this finally. I guess we were seeing different code base the last time. This seems correct to me, so I'd like to put it in Russell's patch tracker. Masahiro Yamada (2): ARM: cache-uniphier: include instead of ARM: cache-uniphier:

[PATCH 0/2] ARM: cache-uniphier: two cleanup patches

Sorry that I had not replied earlier. I came back to this finally. I guess we were seeing different code base the last time. This seems correct to me, so I'd like to put it in Russell's patch tracker. Masahiro Yamada (2): ARM: cache-uniphier: include instead of ARM: cache-uniphier:

[PATCH 5/5] gpio: ws16c48: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the WinSystems WS16C48. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt Gray

[PATCH 5/5] gpio: ws16c48: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the WinSystems WS16C48. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt Gray

Re: [PATCH 0/6 v3] kvmalloc

On 01/30/2017 05:28 PM, Michal Hocko wrote: On Mon 30-01-17 17:15:08, Daniel Borkmann wrote: On 01/30/2017 08:56 AM, Michal Hocko wrote: On Fri 27-01-17 21:12:26, Daniel Borkmann wrote: On 01/27/2017 11:05 AM, Michal Hocko wrote: On Thu 26-01-17 21:34:04, Daniel Borkmann wrote: [...] So to

[PATCH 1/5] gpio: 104-dio-48e: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the ACCES 104-DIO-48E. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt Gray

Re: [PATCH 0/6 v3] kvmalloc

On 01/30/2017 05:28 PM, Michal Hocko wrote: On Mon 30-01-17 17:15:08, Daniel Borkmann wrote: On 01/30/2017 08:56 AM, Michal Hocko wrote: On Fri 27-01-17 21:12:26, Daniel Borkmann wrote: On 01/27/2017 11:05 AM, Michal Hocko wrote: On Thu 26-01-17 21:34:04, Daniel Borkmann wrote: [...] So to

[PATCH 1/5] gpio: 104-dio-48e: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the ACCES 104-DIO-48E. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt Gray

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/30/2017 09:06 AM, Boris Ostrovsky wrote: On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote: 2. It tickles a latent bug during resume where the timer triggers before we re-connect. The trouble is that we now try to dereference queue->rx.sring which is NULL since we disconnect in

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/30/2017 09:06 AM, Boris Ostrovsky wrote: On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote: 2. It tickles a latent bug during resume where the timer triggers before we re-connect. The trouble is that we now try to dereference queue->rx.sring which is NULL since we disconnect in

Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

On 01/24/2017 08:05 AM, zhichang.yuan wrote: Low-pin-count interface is integrated into some SoCs. The accesses to those peripherals under LPC make use of I/O ports rather than the memory mapped I/O. To drive these devices, this patch introduces a method named indirect-IO. In this method the

Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

On 01/24/2017 08:05 AM, zhichang.yuan wrote: Low-pin-count interface is integrated into some SoCs. The accesses to those peripherals under LPC make use of I/O ports rather than the memory mapped I/O. To drive these devices, this patch introduces a method named indirect-IO. In this method the

Re: [PATCH 0/6 v3] kvmalloc

On 01/30/2017 08:56 AM, Michal Hocko wrote: On Fri 27-01-17 21:12:26, Daniel Borkmann wrote: On 01/27/2017 11:05 AM, Michal Hocko wrote: On Thu 26-01-17 21:34:04, Daniel Borkmann wrote: [...] So to answer your second email with the bpf and netfilter hunks, why not replacing them with

Re: [PATCH 0/6 v3] kvmalloc

On 01/30/2017 08:56 AM, Michal Hocko wrote: On Fri 27-01-17 21:12:26, Daniel Borkmann wrote: On 01/27/2017 11:05 AM, Michal Hocko wrote: On Thu 26-01-17 21:34:04, Daniel Borkmann wrote: [...] So to answer your second email with the bpf and netfilter hunks, why not replacing them with

Re: [PATCH] Documentation/sphinx: make targets independent of Sphinx work for HAVE_SPHINX=0

On Mon, 30 Jan 2017, Jani Nikula wrote: > Make targets that don't depend on Sphinx work without warnings about > missing Sphinx. 'make cleandocs' will work without Sphinx just fine, and > the targets that are no-ops for Sphinx should just be skipped. Move them > outside of

[PATCH 0/5] gpio: Add support for GPIO names for several ISA_BUS_API drivers

This patchset sets the gpio_chip names option of several ISA_BUS_API GPIO drivers with an array of GPIO line names that match their respective manual documentation. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on their device. William

[PATCH 0/5] gpio: Add support for GPIO names for several ISA_BUS_API drivers

This patchset sets the gpio_chip names option of several ISA_BUS_API GPIO drivers with an array of GPIO line names that match their respective manual documentation. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on their device. William

Re: [PATCH] Documentation/sphinx: make targets independent of Sphinx work for HAVE_SPHINX=0

On Mon, 30 Jan 2017, Jani Nikula wrote: > Make targets that don't depend on Sphinx work without warnings about > missing Sphinx. 'make cleandocs' will work without Sphinx just fine, and > the targets that are no-ops for Sphinx should just be skipped. Move them > outside of the HAVE_SPHINX checks

[PATCH 2/5] gpio: 104-idi-48: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the ACCES 104-IDI-48. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt Gray

[PATCH 2/5] gpio: 104-idi-48: Add support for GPIO names

This patch sets the gpio_chip names option with an array of GPIO line names that match the manual documentation for the ACCES 104-IDI-48. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on the device. Signed-off-by: William Breathitt Gray ---

Re: [PATCH] Staging: media: lirc: style fix, using octal file permissions

On Sat, Jan 07, 2017 at 04:02:55PM +1300, Derek Robson wrote: > Change file permissions to octal style. > Found using checkpatch > > Signed-off-by: Derek Robson > --- > drivers/staging/media/lirc/lirc_imon.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

Re: [PATCH] Staging: media: lirc: style fix, using octal file permissions

On Sat, Jan 07, 2017 at 04:02:55PM +1300, Derek Robson wrote: > Change file permissions to octal style. > Found using checkpatch > > Signed-off-by: Derek Robson > --- > drivers/staging/media/lirc/lirc_imon.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

On Sat, 28 Jan 2017, Peter Senna Tschudin wrote: > On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote: > Hi Archit, > > Thank you for the comments! > > [...] >> > + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH; >> > + if (total_size >

Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

On Sat, 28 Jan 2017, Peter Senna Tschudin wrote: > On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote: > Hi Archit, > > Thank you for the comments! > > [...] >> > + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH; >> > + if (total_size > EDID_LENGTH) { >> > +

Re: [RFC v2 10/10] KVM: arm/arm64: Emulate the EL1 phys timer register access

Hi Marc, On Sun, Jan 29, 2017 at 10:44 AM, Marc Zyngier wrote: > On Fri, Jan 27 2017 at 01:05:00 AM, Jintack Lim > wrote: >> Emulate read and write operations to CNTP_TVAL, CNTP_CVAL and CNTP_CTL. >> Now VMs are able to use the EL1 physical timer.

Re: [RFC v2 10/10] KVM: arm/arm64: Emulate the EL1 phys timer register access

Hi Marc, On Sun, Jan 29, 2017 at 10:44 AM, Marc Zyngier wrote: > On Fri, Jan 27 2017 at 01:05:00 AM, Jintack Lim > wrote: >> Emulate read and write operations to CNTP_TVAL, CNTP_CVAL and CNTP_CTL. >> Now VMs are able to use the EL1 physical timer. >> >> Signed-off-by: Jintack Lim >> --- >>

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote: > >> 2. It tickles a latent bug during resume where the timer triggers >> before we re-connect. The trouble is that we now try to dereference >> queue->rx.sring which is NULL since we disconnect in >> netfront_resume(). (Curiously, I only

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote: > >> 2. It tickles a latent bug during resume where the timer triggers >> before we re-connect. The trouble is that we now try to dereference >> queue->rx.sring which is NULL since we disconnect in >> netfront_resume(). (Curiously, I only

Re: [PATCH] printk: fix printk.devkmsg sysctl

On Mon, Jan 30, 2017 at 02:38:03PM +0100, Petr Mladek wrote: > We must not access userspace pointer directly. One solution would be > to use get_user(). Good point. > But a better solution might be to check also the trailing '\0' in > __control_devkmsg, see below. I has several advantages: > >

Re: linux-next: manual merge of the gpio tree with the staging tree

On Mon, Jan 30, 2017 at 03:28:55PM +1100, Stephen Rothwell wrote: > Hi Linus, > > Today's linux-next merge of the gpio tree got a conflict in: > > drivers/staging/greybus/gpio.c > > between commit: > > 1d3dfbd1dd34 ("staging: greybus: fix checkpatch unsigned warnings") > > from the

Re: [PATCH] printk: fix printk.devkmsg sysctl

On Mon, Jan 30, 2017 at 02:38:03PM +0100, Petr Mladek wrote: > We must not access userspace pointer directly. One solution would be > to use get_user(). Good point. > But a better solution might be to check also the trailing '\0' in > __control_devkmsg, see below. I has several advantages: > >

Re: linux-next: manual merge of the gpio tree with the staging tree

On Mon, Jan 30, 2017 at 03:28:55PM +1100, Stephen Rothwell wrote: > Hi Linus, > > Today's linux-next merge of the gpio tree got a conflict in: > > drivers/staging/greybus/gpio.c > > between commit: > > 1d3dfbd1dd34 ("staging: greybus: fix checkpatch unsigned warnings") > > from the

Re: [PATCH v6 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family

On Fri, Jan 27, 2017 at 10:40:09AM +0800, Baoyou Xie wrote: > On 27 January 2017 at 00:17, Mathieu Poirier > wrote: > > > On Thu, Jan 26, 2017 at 09:32:56AM +0800, Baoyou Xie wrote: > > > On 26 January 2017 at 00:23, Mathieu Poirier > > >

Re: [PATCH v6 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family

On Fri, Jan 27, 2017 at 10:40:09AM +0800, Baoyou Xie wrote: > On 27 January 2017 at 00:17, Mathieu Poirier > wrote: > > > On Thu, Jan 26, 2017 at 09:32:56AM +0800, Baoyou Xie wrote: > > > On 26 January 2017 at 00:23, Mathieu Poirier > > > > > wrote: > > > > > > > On Wed, Jan 25, 2017 at

Re: [PATCH] perf/x86/intel/rapl: Rename rapl_cpu_prepare() to rapl_cpu_starting()

On Mon, 30 Jan 2017, Yasuaki Ishimatsu wrote: > Hi Thomas, > > Do you have any idea to fix the issue? > If you have the idea, please send me the patch. Yes, I have a patch, but need to do some tests and get changelogs written. Will keep you updated. Thanks, tglx

Re: [PATCH] perf/x86/intel/rapl: Rename rapl_cpu_prepare() to rapl_cpu_starting()

On Mon, 30 Jan 2017, Yasuaki Ishimatsu wrote: > Hi Thomas, > > Do you have any idea to fix the issue? > If you have the idea, please send me the patch. Yes, I have a patch, but need to do some tests and get changelogs written. Will keep you updated. Thanks, tglx

Re: scsi: use-after-free in sg_start_req

On Mon, Jan 30, 2017 at 5:36 PM, Bart Van Assche wrote: > On Mon, 2017-01-30 at 08:25 +0100, Dmitry Vyukov wrote: >> On commit ca63ff9b11f958efafd8c8fa60fda14baec6149c > > What kernel have you been testing? That commit is not in any upstream kernel. This is mmotm

Re: scsi: use-after-free in sg_start_req

On Mon, Jan 30, 2017 at 5:36 PM, Bart Van Assche wrote: > On Mon, 2017-01-30 at 08:25 +0100, Dmitry Vyukov wrote: >> On commit ca63ff9b11f958efafd8c8fa60fda14baec6149c > > What kernel have you been testing? That commit is not in any upstream kernel. This is mmotm

[PATCH] Documentation/sphinx: make targets independent of Sphinx work for HAVE_SPHINX=0

Make targets that don't depend on Sphinx work without warnings about missing Sphinx. 'make cleandocs' will work without Sphinx just fine, and the targets that are no-ops for Sphinx should just be skipped. Move them outside of the HAVE_SPHINX checks to take precedence over the .DEFAULT target for

[PATCH] Documentation/sphinx: make targets independent of Sphinx work for HAVE_SPHINX=0

Make targets that don't depend on Sphinx work without warnings about missing Sphinx. 'make cleandocs' will work without Sphinx just fine, and the targets that are no-ops for Sphinx should just be skipped. Move them outside of the HAVE_SPHINX checks to take precedence over the .DEFAULT target for

[PATCH] perf: fix topology test on systems with sparse CPUs

Topology test fails on systems with sparse CPUs, e.g. CPU not present or offline: 36: Test topology in session : --- start --- test child forked, pid 23703 templ file: /tmp/perf-test-i2rNki failed to write feature 13 perf: Segmentation fault available: 2 nodes

[PATCH] perf: fix topology test on systems with sparse CPUs

Topology test fails on systems with sparse CPUs, e.g. CPU not present or offline: 36: Test topology in session : --- start --- test child forked, pid 23703 templ file: /tmp/perf-test-i2rNki failed to write feature 13 perf: Segmentation fault available: 2 nodes

Re: [PATCH RESEND 2/5] dmaengine: Provide a wrapper for memcpy operations

On Fri, Jan 27, 2017 at 05:42:01PM +0100, Boris Brezillon wrote: > Almost all ->device_prep_dma_xx() methods have a wrapper defined in > dmaengine.h. Add one for ->device_prep_dma_memcpy(). Looks good to me. Acked-by: Vinod Koul -- ~Vinod

Re: [PATCH 7/9] md: use kvmalloc rather than opencoded variant

On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko copy_params uses kmalloc with vmalloc fallback. We already have a helper for that - kvmalloc. This caller requires GFP_NOIO semantic so it hasn't been converted with many others by previous patches. All we need to

Re: [PATCH RESEND 2/5] dmaengine: Provide a wrapper for memcpy operations

On Fri, Jan 27, 2017 at 05:42:01PM +0100, Boris Brezillon wrote: > Almost all ->device_prep_dma_xx() methods have a wrapper defined in > dmaengine.h. Add one for ->device_prep_dma_memcpy(). Looks good to me. Acked-by: Vinod Koul -- ~Vinod

Re: [PATCH 7/9] md: use kvmalloc rather than opencoded variant

On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko copy_params uses kmalloc with vmalloc fallback. We already have a helper for that - kvmalloc. This caller requires GFP_NOIO semantic so it hasn't been converted with many others by previous patches. All we need to achieve this

Re: [PATCH] PCI: mvebu: Handle changes to the bridge windows while enabled

On Mon, Jan 30, 2017 at 09:41:36AM -0600, Bjorn Helgaas wrote: > On Mon, Dec 12, 2016 at 11:30:20AM -0700, Jason Gunthorpe wrote: > > The PCI core will write to the bridge window config multiple times > > while they are enabled. This can lead to mbus failures like: > > > > mvebu_mbus: cannot add

Re: [PATCH] PCI: mvebu: Handle changes to the bridge windows while enabled

On Mon, Jan 30, 2017 at 09:41:36AM -0600, Bjorn Helgaas wrote: > On Mon, Dec 12, 2016 at 11:30:20AM -0700, Jason Gunthorpe wrote: > > The PCI core will write to the bridge window config multiple times > > while they are enabled. This can lead to mbus failures like: > > > > mvebu_mbus: cannot add

Re: [PATCH] Dma - Fix possible NULL derefrence.

On Fri, Jan 27, 2017 at 04:55:59PM +0530, Shailendra Verma wrote: > of_match_device could return NULL, and so cause a NULL > pointer dereference later. Why is this tagged Dma - Please look at he git log for the file before coming up with random tags Worst part, this patch fails to apply,

Re: [PATCH] Dma - Fix possible NULL derefrence.

On Fri, Jan 27, 2017 at 04:55:59PM +0530, Shailendra Verma wrote: > of_match_device could return NULL, and so cause a NULL > pointer dereference later. Why is this tagged Dma - Please look at he git log for the file before coming up with random tags Worst part, this patch fails to apply,

Re: [PATCH 1/2] dt-bindings: Document the VC4 DSI module nodes.

On Fri, Jan 27, 2017 at 8:41 PM, Eric Anholt wrote: > Rob Herring writes: > >> Need to cc DT list if you want it in my queue. >> >> On Mon, Jan 23, 2017 at 6:38 PM, Eric Anholt wrote: >>> These are part of the vc4 display pipeline. >>> >>>

Re: [PATCH 1/2] dt-bindings: Document the VC4 DSI module nodes.

On Fri, Jan 27, 2017 at 8:41 PM, Eric Anholt wrote: > Rob Herring writes: > >> Need to cc DT list if you want it in my queue. >> >> On Mon, Jan 23, 2017 at 6:38 PM, Eric Anholt wrote: >>> These are part of the vc4 display pipeline. >>> >>> Signed-off-by: Eric Anholt >>> --- >>>

Re: [PATCH v3 08/10] dmaengine: sun6i: allow build on ARM64 platforms (sun50i)

On Sun, Jan 29, 2017 at 10:33:29AM +0800, Icenowy Zheng wrote: > As 64-bit Allwinner H5 SoC has the same DMA engine with H3, the DMA > driver should be allowed to be built for ARM64, in order to make it work on > H5. > > Signed-off-by: Icenowy Zheng > Acked-by: Maxime Ripard

Re: [PATCH v3 08/10] dmaengine: sun6i: allow build on ARM64 platforms (sun50i)

On Sun, Jan 29, 2017 at 10:33:29AM +0800, Icenowy Zheng wrote: > As 64-bit Allwinner H5 SoC has the same DMA engine with H3, the DMA > driver should be allowed to be built for ARM64, in order to make it work on > H5. > > Signed-off-by: Icenowy Zheng > Acked-by: Maxime Ripard > Acked-by:

[PATCH] spi: fix device-node leaks

Make sure to release the device-node reference taken in of_register_spi_device() on errors and when deregistering the device. Fixes: 284b01897340 ("spi: Add OF binding support for SPI busses") Signed-off-by: Johan Hovold --- drivers/spi/spi.c | 8 ++-- 1 file changed, 6

[PATCH] spi: fix device-node leaks

Make sure to release the device-node reference taken in of_register_spi_device() on errors and when deregistering the device. Fixes: 284b01897340 ("spi: Add OF binding support for SPI busses") Signed-off-by: Johan Hovold --- drivers/spi/spi.c | 8 ++-- 1 file changed, 6 insertions(+), 2

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/29/2017 03:09 PM, Boris Ostrovsky wrote: There are couple of problems with this patch. 1. The 'if' clause now evaluates to true on pretty much every call to xennet_alloc_rx_buffers(). Thanks for catching this. In my testing I did not notice this - mostly because of the nature of the

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/29/2017 03:09 PM, Boris Ostrovsky wrote: There are couple of problems with this patch. 1. The 'if' clause now evaluates to true on pretty much every call to xennet_alloc_rx_buffers(). Thanks for catching this. In my testing I did not notice this - mostly because of the nature of the

Re: [PATCH 8/9] bcache: use kvmalloc

On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko bcache_device_init uses kmalloc for small requests and vmalloc for those which are larger than 64 pages. This alone is a strange criterion. Moreover kmalloc can fallback to vmalloc on the failure. Let's simply use

Re: [PATCH 8/9] bcache: use kvmalloc

On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko bcache_device_init uses kmalloc for small requests and vmalloc for those which are larger than 64 pages. This alone is a strange criterion. Moreover kmalloc can fallback to vmalloc on the failure. Let's simply use kvmalloc instead

Re: [PATCH v3 12/14] fbdev: jz4740-fb: Let the pinctrl driver configure the pins

Hi, On Wednesday, January 25, 2017 07:52:05 PM Paul Cercueil wrote: > Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on > the pins being properly configured before the driver probes. > > Signed-off-by: Paul Cercueil Acked-by: Bartlomiej

Re: [PATCH v3 12/14] fbdev: jz4740-fb: Let the pinctrl driver configure the pins

Hi, On Wednesday, January 25, 2017 07:52:05 PM Paul Cercueil wrote: > Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on > the pins being properly configured before the driver probes. > > Signed-off-by: Paul Cercueil Acked-by: Bartlomiej Zolnierkiewicz Best regards, --

Re: [PATCH 001] staging: wlan-ng: Add tabstop preceding the statement

On Mon, Jan 30, 2017 at 11:31:42AM -0500, Maksymilian Piechota wrote: > This patch fixes the checkpatch.pl warning: > > WARNING: Statements should start on a tabstop > > Signed-off-by: Maksymilian Piechota > --- > drivers/staging/wlan-ng/prism2mgmt.c | 2 +- > 1

Re: [PATCH 001] staging: wlan-ng: Add tabstop preceding the statement

On Mon, Jan 30, 2017 at 11:31:42AM -0500, Maksymilian Piechota wrote: > This patch fixes the checkpatch.pl warning: > > WARNING: Statements should start on a tabstop > > Signed-off-by: Maksymilian Piechota > --- > drivers/staging/wlan-ng/prism2mgmt.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [tip:x86/mm] x86/mm/cpa: Avoid wbinvd() for PREEMPT

* tip-bot for John Ogness wrote: > Commit-ID: 459fbe00693449fade2d1bc802791b081c94edcf > Gitweb: http://git.kernel.org/tip/459fbe00693449fade2d1bc802791b081c94edcf > Author: John Ogness > AuthorDate: Mon, 30 Jan 2017 09:41:21 +0100 >

Re: [tip:x86/mm] x86/mm/cpa: Avoid wbinvd() for PREEMPT

* tip-bot for John Ogness wrote: > Commit-ID: 459fbe00693449fade2d1bc802791b081c94edcf > Gitweb: http://git.kernel.org/tip/459fbe00693449fade2d1bc802791b081c94edcf > Author: John Ogness > AuthorDate: Mon, 30 Jan 2017 09:41:21 +0100 > Committer: Thomas Gleixner > CommitDate: Mon, 30

Re: scsi: use-after-free in sg_start_req

On Mon, 2017-01-30 at 08:25 +0100, Dmitry Vyukov wrote: > On commit ca63ff9b11f958efafd8c8fa60fda14baec6149c What kernel have you been testing? That commit is not in any upstream kernel. Bart.

Re: scsi: use-after-free in sg_start_req

On Mon, 2017-01-30 at 08:25 +0100, Dmitry Vyukov wrote: > On commit ca63ff9b11f958efafd8c8fa60fda14baec6149c What kernel have you been testing? That commit is not in any upstream kernel. Bart.

Re: Device or HBA level QD throttling creates randomness in sequetial workload

On 01/30/2017 09:30 AM, Bart Van Assche wrote: > On Mon, 2017-01-30 at 19:22 +0530, Kashyap Desai wrote: >> - if (atomic_inc_return(>fw_outstanding) > >> - instance->host->can_queue) { >> - atomic_dec(>fw_outstanding); >> - return SCSI_MLQUEUE_HOST_BUSY; >> - } >> + if

Re: Device or HBA level QD throttling creates randomness in sequetial workload

On 01/30/2017 09:30 AM, Bart Van Assche wrote: > On Mon, 2017-01-30 at 19:22 +0530, Kashyap Desai wrote: >> - if (atomic_inc_return(>fw_outstanding) > >> - instance->host->can_queue) { >> - atomic_dec(>fw_outstanding); >> - return SCSI_MLQUEUE_HOST_BUSY; >> - } >> + if

Re: [PATCH 2/2] gpio: mcp23s08: add pinconf support

Hi Linus, On Mon, Jan 30, 2017 at 04:08:01PM +0100, Linus Walleij wrote: > On Fri, Jan 27, 2017 at 3:47 PM, Sebastian Reichel wrote: > > > mcp23xxx device have configurable 100k pullup resistors. This adds > > support for enabling them using pinctrl's pinconf interface. > > > >

Re: [PATCH 2/2] gpio: mcp23s08: add pinconf support

Hi Linus, On Mon, Jan 30, 2017 at 04:08:01PM +0100, Linus Walleij wrote: > On Fri, Jan 27, 2017 at 3:47 PM, Sebastian Reichel wrote: > > > mcp23xxx device have configurable 100k pullup resistors. This adds > > support for enabling them using pinctrl's pinconf interface. > > > > Signed-off-by:

[PATCH 001] staging: wlan-ng: Add tabstop preceding the statement

This patch fixes the checkpatch.pl warning: WARNING: Statements should start on a tabstop Signed-off-by: Maksymilian Piechota --- drivers/staging/wlan-ng/prism2mgmt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 001] staging: wlan-ng: Add tabstop preceding the statement

This patch fixes the checkpatch.pl warning: WARNING: Statements should start on a tabstop Signed-off-by: Maksymilian Piechota --- drivers/staging/wlan-ng/prism2mgmt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/prism2mgmt.c

Re: [PATCH v4 2/2] HWPOISON: soft offlining for non-lru movable page

On Mon 30-01-17 23:04:13, Yisheng Xie wrote: > Hi, Michal, > Sorry for late reply. > > On 01/26/2017 05:27 PM, Michal Hocko wrote: > > On Wed 25-01-17 23:05:38, ys...@foxmail.com wrote: > >> From: Yisheng Xie > >> > >> This patch is to extends soft offlining framework to

Re: [PATCH v4 2/2] HWPOISON: soft offlining for non-lru movable page

On Mon 30-01-17 23:04:13, Yisheng Xie wrote: > Hi, Michal, > Sorry for late reply. > > On 01/26/2017 05:27 PM, Michal Hocko wrote: > > On Wed 25-01-17 23:05:38, ys...@foxmail.com wrote: > >> From: Yisheng Xie > >> > >> This patch is to extends soft offlining framework to support > >> non-lru

Re: [PATCH] perf/x86/intel/rapl: Rename rapl_cpu_prepare() to rapl_cpu_starting()

Hi Thomas, Do you have any idea to fix the issue? If you have the idea, please send me the patch. Thanks, Yasuaki Ishimatsu On 01/24/2017 02:54 PM, Thomas Gleixner wrote: On Tue, 24 Jan 2017, Yasuaki Ishimatsu wrote: rapl_cpu_prepare() must be called after logical package id of CPU is set by

Re: [PATCH] perf/x86/intel/rapl: Rename rapl_cpu_prepare() to rapl_cpu_starting()

Hi Thomas, Do you have any idea to fix the issue? If you have the idea, please send me the patch. Thanks, Yasuaki Ishimatsu On 01/24/2017 02:54 PM, Thomas Gleixner wrote: On Tue, 24 Jan 2017, Yasuaki Ishimatsu wrote: rapl_cpu_prepare() must be called after logical package id of CPU is set by

Re: [PATCH 6/9] net: use kvmalloc with __GFP_REPEAT rather than open coded variant

On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko fq_alloc_node, alloc_netdev_mqs and netif_alloc* open code kmalloc with vmalloc fallback. Use the kvmalloc variant instead. Keep the __GFP_REPEAT flag based on explanation from Eric: " At the time, tests on the

Re: [PATCH 6/9] net: use kvmalloc with __GFP_REPEAT rather than open coded variant

On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko fq_alloc_node, alloc_netdev_mqs and netif_alloc* open code kmalloc with vmalloc fallback. Use the kvmalloc variant instead. Keep the __GFP_REPEAT flag based on explanation from Eric: " At the time, tests on the hardware I had in my

<    7   8   9   10   11   12   13   14   15   16   >