Re: [PATCH 6/9] bus: brcmstb_gisb: correct support for 64-bit address output

On Fri, Mar 24, 2017 at 7:46 AM, Doug Berger wrote: > The GISB bus can support addresses beyond 32-bits. So this commit > corrects support for reading a captured 64-bit address into a 64-bit > variable by obtaining the high bits from the ARB_ERR_CAP_HI_ADDR > register (when

Re: [PATCH 6/9] bus: brcmstb_gisb: correct support for 64-bit address output

On Fri, Mar 24, 2017 at 7:46 AM, Doug Berger wrote: > The GISB bus can support addresses beyond 32-bits. So this commit > corrects support for reading a captured 64-bit address into a 64-bit > variable by obtaining the high bits from the ARB_ERR_CAP_HI_ADDR > register (when present) and then

RE: [RFC PATCH] iommu/dma/pci: account pci host bridge dma_mask for IOVA allocation

Hi Robin, I have made 3 separate patches now, which gives clear idea about the changes. we can have discussion there. Regards, Oza. -Original Message- From: Robin Murphy [mailto:robin.mur...@arm.com] Sent: Monday, March 20, 2017 9:14 PM To: Oza Oza Cc: Joerg Roedel;

RE: [RFC PATCH] iommu/dma/pci: account pci host bridge dma_mask for IOVA allocation

Hi Robin, I have made 3 separate patches now, which gives clear idea about the changes. we can have discussion there. Regards, Oza. -Original Message- From: Robin Murphy [mailto:robin.mur...@arm.com] Sent: Monday, March 20, 2017 9:14 PM To: Oza Oza Cc: Joerg Roedel;

[RFC PATCH 2/3] iommu/dma: account pci host bridge dma_mask for IOVA allocation

it is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. As an example, consider NVME SSD device connected to iproc-PCIe controller.

[RFC PATCH 3/3] of: fix node traversing in of_dma_get_range

it jumps to the parent node without examining the child node. also with that, it throws "no dma-ranges found for node" for pci dma-ranges. this patch fixes device node traversing for dma-ranges. Reviewed-by: Anup Patel Signed-off-by: Oza Pawandeep

[RFC PATCH 2/3] iommu/dma: account pci host bridge dma_mask for IOVA allocation

it is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. As an example, consider NVME SSD device connected to iproc-PCIe controller.

[RFC PATCH 3/3] of: fix node traversing in of_dma_get_range

it jumps to the parent node without examining the child node. also with that, it throws "no dma-ranges found for node" for pci dma-ranges. this patch fixes device node traversing for dma-ranges. Reviewed-by: Anup Patel Signed-off-by: Oza Pawandeep diff --git a/drivers/of/address.c

[RFC PATCH 1/3] of/pci: dma-ranges to account highest possible host bridge dma_mask

it is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. As an example, consider NVME SSD device connected to iproc-PCIe controller.

[RFC PATCH 1/3] of/pci: dma-ranges to account highest possible host bridge dma_mask

it is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. As an example, consider NVME SSD device connected to iproc-PCIe controller.

Re: [PATCH v6 03/15] IB/mthca: Replace PCI pool old API

On Sun, 2017-03-19 at 18:03 +0100, Romain Perier wrote: > The PCI pool API is deprecated. This commit replaces the PCI pool old > API by the appropriate function with the DMA pool API. > > Signed-off-by: Romain Perier > Acked-by: Peter Senna Tschudin

Re: [PATCH v6 03/15] IB/mthca: Replace PCI pool old API

On Sun, 2017-03-19 at 18:03 +0100, Romain Perier wrote: > The PCI pool API is deprecated. This commit replaces the PCI pool old > API by the appropriate function with the DMA pool API. > > Signed-off-by: Romain Perier > Acked-by: Peter Senna Tschudin > Tested-by: Peter Senna Tschudin > 

Re: [PATCH 4/9] bus: brcmstb_gisb: Use register offsets with writes too

On Fri, Mar 24, 2017 at 7:46 AM, Doug Berger wrote: > This commit corrects the bug introduced in commit f80835875d3d > ("bus: brcmstb_gisb: Look up register offsets in a table") such > that gisb_write() translates the register enumeration into an > offset from the base address

Re: [PATCH 4/9] bus: brcmstb_gisb: Use register offsets with writes too

On Fri, Mar 24, 2017 at 7:46 AM, Doug Berger wrote: > This commit corrects the bug introduced in commit f80835875d3d > ("bus: brcmstb_gisb: Look up register offsets in a table") such > that gisb_write() translates the register enumeration into an > offset from the base address for writes as well

[PATCH] staging: greybus: compress return logic

Simplify function returns by merging assignment and return. Signed-off-by: Arushi Singhal --- drivers/staging/greybus/loopback.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/staging/greybus/loopback.c

[PATCH] staging: greybus: compress return logic

Simplify function returns by merging assignment and return. Signed-off-by: Arushi Singhal --- drivers/staging/greybus/loopback.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index

Re: [PATCH] regulator: core: Limit propagation of parent voltage count and list

Hello Matthias, On 03/24/2017 05:38 PM, Brian Norris wrote: > On Fri, Mar 24, 2017 at 01:09:52PM -0700, Matthias Kaehlcke wrote: >> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c >> index 53d4fc70dbd0..121838e0125b 100644 >> --- a/drivers/regulator/core.c >> +++

Re: [PATCH] regulator: core: Limit propagation of parent voltage count and list

Hello Matthias, On 03/24/2017 05:38 PM, Brian Norris wrote: > On Fri, Mar 24, 2017 at 01:09:52PM -0700, Matthias Kaehlcke wrote: >> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c >> index 53d4fc70dbd0..121838e0125b 100644 >> --- a/drivers/regulator/core.c >> +++

0324 tree BUG at kernel/auditsc.c:1513!

crc32c_intel nd_pmem serio_raw i2c_core pps_core scsi_transport_sas [last unloaded: scsi_debug] [11231.440342] CPU: 24 PID: 15334 Comm: dio_truncate Not tainted 4.11.0-rc3-linux-next-65b2dc3-next-20170324 #336 [11231.488861] Hardware name: HP ProLiant DL360 Gen9, BIOS P89 05/06/2015

0324 tree BUG at kernel/auditsc.c:1513!

crc32c_intel nd_pmem serio_raw i2c_core pps_core scsi_transport_sas [last unloaded: scsi_debug] [11231.440342] CPU: 24 PID: 15334 Comm: dio_truncate Not tainted 4.11.0-rc3-linux-next-65b2dc3-next-20170324 #336 [11231.488861] Hardware name: HP ProLiant DL360 Gen9, BIOS P89 05/06/2015

[PATCH][RFC] cpufreq: Bring CPUs up even if cpufreq_online failed

There is a report that after commit 27622b061eb4 ("cpufreq: Convert to hotplug state machine"), the normal CPU offline/online cycle failed on some platforms. According to the ftrace result, this problem was triggered on platforms using acpi-freq as the default cpufreq driver, and due to the lack

[PATCH][RFC] cpufreq: Bring CPUs up even if cpufreq_online failed

There is a report that after commit 27622b061eb4 ("cpufreq: Convert to hotplug state machine"), the normal CPU offline/online cycle failed on some platforms. According to the ftrace result, this problem was triggered on platforms using acpi-freq as the default cpufreq driver, and due to the lack

Re: [PATCH 4.10 00/27] 4.10.6-stable review

On 03/24/2017 10:58 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.10.6 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.10 00/27] 4.10.6-stable review

On 03/24/2017 10:58 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.10.6 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.9 00/24] 4.9.18-stable review

On 03/24/2017 10:58 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.18 release. There are 24 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.9 00/24] 4.9.18-stable review

On 03/24/2017 10:58 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.18 release. There are 24 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/30] 4.4.57-stable review

On 03/24/2017 10:58 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.57 release. There are 30 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/30] 4.4.57-stable review

On 03/24/2017 10:58 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.57 release. There are 30 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/30] 4.4.57-stable review

On 03/24/2017 05:10 PM, Kevin Hilman wrote: + at91 maintainers kernelci.org bot writes: stable-rc boot: 496 boots: 1 failed, 492 passed with 2 offline, 1 conflict (v4.4.56-31-gbcd1e808ead3) Full Boot Summary:

Re: [PATCH 4.4 00/30] 4.4.57-stable review

On 03/24/2017 05:10 PM, Kevin Hilman wrote: + at91 maintainers kernelci.org bot writes: stable-rc boot: 496 boots: 1 failed, 492 passed with 2 offline, 1 conflict (v4.4.56-31-gbcd1e808ead3) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/

[PATCH net-next 0/2] netvsc: Fix miscellaneous issues

From: K. Y. Srinivasan Fix miscellaneous issues. K. Y. Srinivasan (2): netvsc: Fix a bug in sub-channel handling netvsc: Properly initialize the return value drivers/net/hyperv/netvsc_drv.c |2 +- drivers/net/hyperv/rndis_filter.c |5 + 2 files changed, 6

[PATCH net-next 0/2] netvsc: Fix miscellaneous issues

From: K. Y. Srinivasan Fix miscellaneous issues. K. Y. Srinivasan (2): netvsc: Fix a bug in sub-channel handling netvsc: Properly initialize the return value drivers/net/hyperv/netvsc_drv.c |2 +- drivers/net/hyperv/rndis_filter.c |5 + 2 files changed, 6 insertions(+), 1

[PATCH net-next 1/2] netvsc: Fix a bug in sub-channel handling

From: K. Y. Srinivasan All netvsc channels are handled via NAPI. Setup the "read mode" correctly for the netvsc sub-channels. Signed-off-by: K. Y. Srinivasan --- drivers/net/hyperv/rndis_filter.c |5 + 1 files changed, 5 insertions(+), 0

[PATCH net-next 2/2] netvsc: Properly initialize the return value

From: K. Y. Srinivasan Initialize the return value correctly. Signed-off-by: K. Y. Srinivasan --- drivers/net/hyperv/netvsc_drv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c

[PATCH net-next 1/2] netvsc: Fix a bug in sub-channel handling

From: K. Y. Srinivasan All netvsc channels are handled via NAPI. Setup the "read mode" correctly for the netvsc sub-channels. Signed-off-by: K. Y. Srinivasan --- drivers/net/hyperv/rndis_filter.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git

[PATCH net-next 2/2] netvsc: Properly initialize the return value

From: K. Y. Srinivasan Initialize the return value correctly. Signed-off-by: K. Y. Srinivasan --- drivers/net/hyperv/netvsc_drv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index eb7ae79..f830bbb

Re: [net-next PATCH v3 0/8] Add busy poll support for epoll

From: Alexander Duyck Date: Fri, 24 Mar 2017 10:07:47 -0700 > This patch set adds support for using busy polling with epoll. Series applied, thanks!

Re: [net-next PATCH v3 0/8] Add busy poll support for epoll

From: Alexander Duyck Date: Fri, 24 Mar 2017 10:07:47 -0700 > This patch set adds support for using busy polling with epoll. Series applied, thanks!

Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs

Hi Vincent, On Thu, Mar 23, 2017 at 3:08 PM, Vincent Guittot wrote: [..] >>> So I'm not really aligned with the description of your problem: PELT metric underestimates the load of the CPU. The PELT is just about tracking CFS task utilization but not

Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs

Hi Vincent, On Thu, Mar 23, 2017 at 3:08 PM, Vincent Guittot wrote: [..] >>> So I'm not really aligned with the description of your problem: PELT metric underestimates the load of the CPU. The PELT is just about tracking CFS task utilization but not whole CPU utilization and

Re: [PATCH v6 06/15] mlx5: Replace PCI pool old API

On Mon, 2017-03-20 at 08:31 +0200, Leon Romanovsky wrote: > On Sun, Mar 19, 2017 at 06:03:55PM +0100, Romain Perier wrote: > > > > The PCI pool API is deprecated. This commit replaces the PCI pool > > old > > API by the appropriate function with the DMA pool API. > > > > Signed-off-by: Romain

Re: [PATCH v6 06/15] mlx5: Replace PCI pool old API

On Mon, 2017-03-20 at 08:31 +0200, Leon Romanovsky wrote: > On Sun, Mar 19, 2017 at 06:03:55PM +0100, Romain Perier wrote: > > > > The PCI pool API is deprecated. This commit replaces the PCI pool > > old > > API by the appropriate function with the DMA pool API. > > > > Signed-off-by: Romain

Re: [net-next PATCH v3 5/8] net: Track start of busy loop instead of when it should end

On Fri, 2017-03-24 at 10:08 -0700, Alexander Duyck wrote: > From: Alexander Duyck > > This patch flips the logic we were using to determine if the busy polling > has timed out. The main motivation for this is that we will need to > support two different possible

Re: [net-next PATCH v3 5/8] net: Track start of busy loop instead of when it should end

On Fri, 2017-03-24 at 10:08 -0700, Alexander Duyck wrote: > From: Alexander Duyck > > This patch flips the logic we were using to determine if the busy polling > has timed out. The main motivation for this is that we will need to > support two different possible timeout values in the future and

Re: [net-next PATCH v3 7/8] epoll: Add busy poll support to epoll with socket fds.

On Fri, 2017-03-24 at 10:08 -0700, Alexander Duyck wrote: > From: Sridhar Samudrala > > This patch adds busy poll support to epoll. The implementation is meant to > be opportunistic in that it will take the NAPI ID from the last socket > that is added to the ready

Re: [net-next PATCH v3 7/8] epoll: Add busy poll support to epoll with socket fds.

On Fri, 2017-03-24 at 10:08 -0700, Alexander Duyck wrote: > From: Sridhar Samudrala > > This patch adds busy poll support to epoll. The implementation is meant to > be opportunistic in that it will take the NAPI ID from the last socket > that is added to the ready list that contains a valid NAPI

Re: [PATCH] drm/vmwgfx: Check check that number of mip levels is above zero in vmw_surface_define_ioctl()

Hi, thank you for this patch. Murray McAllister reported this one a couple of months ago, and this is already in our queue. Sinclair On Fri, Mar 24, 2017 at 04:37:10PM +0100, Vladis Dronov wrote: > In vmw_surface_define_ioctl(), a num_sizes parameter is assigned a > user-controlled value which

Re: [PATCH] drm/vmwgfx: Check check that number of mip levels is above zero in vmw_surface_define_ioctl()

Hi, thank you for this patch. Murray McAllister reported this one a couple of months ago, and this is already in our queue. Sinclair On Fri, Mar 24, 2017 at 04:37:10PM +0100, Vladis Dronov wrote: > In vmw_surface_define_ioctl(), a num_sizes parameter is assigned a > user-controlled value which

[PATCH v3] staging: media: davinci_vpfe: Replace a bit shift.

This patch replaces bit shifting on 1 with the BIT(x) macro. This was done with coccinelle: @@ constant c; @@ -1 << c +BIT(c) Signed-off-by: Arushi Singhal --- changes in v3 - change the subject. - remove extra parenthesis.

[PATCH v3] staging: media: davinci_vpfe: Replace a bit shift.

This patch replaces bit shifting on 1 with the BIT(x) macro. This was done with coccinelle: @@ constant c; @@ -1 << c +BIT(c) Signed-off-by: Arushi Singhal --- changes in v3 - change the subject. - remove extra parenthesis. drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 2 +-

Re: [PATCH] ipmi_ssif: use setup_timer

A little nicer, yes. In queue for the next release. Thanks, -corey On 03/24/2017 09:15 AM, Geliang Tang wrote: Use setup_timer() instead of init_timer() to simplify the code. Signed-off-by: Geliang Tang --- drivers/char/ipmi/ipmi_ssif.c | 5 ++--- 1 file changed,

Re: [PATCH] ipmi_ssif: use setup_timer

A little nicer, yes. In queue for the next release. Thanks, -corey On 03/24/2017 09:15 AM, Geliang Tang wrote: Use setup_timer() instead of init_timer() to simplify the code. Signed-off-by: Geliang Tang --- drivers/char/ipmi/ipmi_ssif.c | 5 ++--- 1 file changed, 2 insertions(+), 3

Re: [PATCH] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

Oops, yes, this is an issue. However, it should probably depend on IPMI_HANDLER, not the individual interface types. -corey On 03/23/2017 10:53 AM, Sinan Kaya wrote: ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI) driver to be enabled. IPMI_SI driver only handles KCS,

Re: [PATCH] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

Oops, yes, this is an issue. However, it should probably depend on IPMI_HANDLER, not the individual interface types. -corey On 03/23/2017 10:53 AM, Sinan Kaya wrote: ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI) driver to be enabled. IPMI_SI driver only handles KCS,

Re: [PATCH] ACPI / IPMI: change warning to debug on timeout

Why would a timeout for a message be expected? The BMC should at least respond with an error for an incorrect message. -corey On 03/23/2017 10:32 AM, Sinan Kaya wrote: Getting timeout message from BMC when trying to read from a non-existent FRU. This is expected but warning is not. Let's

[PATCH] Staging: atomisp - octal permissions, style fix

Changed permissions to octal style Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c | 9 +++-- drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 8 2 files changed, 7 insertions(+), 10

[PATCH] Staging: atomisp - octal permissions, style fix

Changed permissions to octal style Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c | 9 +++-- drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 8 2 files changed, 7 insertions(+), 10 deletions(-) diff

Re: [PATCH] ACPI / IPMI: change warning to debug on timeout

Why would a timeout for a message be expected? The BMC should at least respond with an error for an incorrect message. -corey On 03/23/2017 10:32 AM, Sinan Kaya wrote: Getting timeout message from BMC when trying to read from a non-existent FRU. This is expected but warning is not. Let's

Re: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

This is incorrect. These values *must* be set before ssif_i2c_send() is done. Once ssif_i2c_send() is called, msg_written_handler can be called at any time after that, including before where you moved the new code. If I understand this correctly, I think you need to add a variable, maybe named

Re: [PATCH] ipmi: Fix kernel panic at ipmi_ssif_thread()

This is incorrect. These values *must* be set before ssif_i2c_send() is done. Once ssif_i2c_send() is called, msg_written_handler can be called at any time after that, including before where you moved the new code. If I understand this correctly, I think you need to add a variable, maybe named

Re: [RESEND PATCH] IB/qib: fix false-postive maybe-uninitialized warning

On Tue, 2017-03-14 at 13:18 +0100, Arnd Bergmann wrote: > aarch64-linux-gcc-7 complains about code it doesn't fully understand: > > drivers/infiniband/hw/qib/qib_iba7322.c: In function > 'qib_7322_txchk_change': > include/asm-generic/bitops/non-atomic.h:105:35: error: 'shadow' may > be used

Re: [RESEND PATCH] IB/qib: fix false-postive maybe-uninitialized warning

On Tue, 2017-03-14 at 13:18 +0100, Arnd Bergmann wrote: > aarch64-linux-gcc-7 complains about code it doesn't fully understand: > > drivers/infiniband/hw/qib/qib_iba7322.c: In function > 'qib_7322_txchk_change': > include/asm-generic/bitops/non-atomic.h:105:35: error: 'shadow' may > be used

Re: [PATCH v2 09/23] MAINTAINERS: Add file patterns for infiniband device tree bindings

On Sun, 2017-03-12 at 14:16 +0100, Geert Uytterhoeven wrote: > Submitters of device tree binding documentation may forget to CC > the subsystem maintainer if this is missing. > > Signed-off-by: Geert Uytterhoeven > Cc: Doug Ledford > Cc: Sean Hefty

Re: [PATCH v2 09/23] MAINTAINERS: Add file patterns for infiniband device tree bindings

On Sun, 2017-03-12 at 14:16 +0100, Geert Uytterhoeven wrote: > Submitters of device tree binding documentation may forget to CC > the subsystem maintainer if this is missing. > > Signed-off-by: Geert Uytterhoeven > Cc: Doug Ledford > Cc: Sean Hefty > Cc: Hal Rosenstock > Cc:

Re: [RFC v5 5/9] sched/deadline: do not reclaim the whole CPU bandwidth

On Fri, 24 Mar 2017 22:58:27 +0100 luca abeni wrote: > Hi Peter, > > On Fri, 24 Mar 2017 15:00:15 +0100 > Peter Zijlstra wrote: > > > On Fri, Mar 24, 2017 at 04:52:58AM +0100, luca abeni wrote: > > > > > diff --git a/kernel/sched/core.c

Re: [RFC v5 5/9] sched/deadline: do not reclaim the whole CPU bandwidth

On Fri, 24 Mar 2017 22:58:27 +0100 luca abeni wrote: > Hi Peter, > > On Fri, 24 Mar 2017 15:00:15 +0100 > Peter Zijlstra wrote: > > > On Fri, Mar 24, 2017 at 04:52:58AM +0100, luca abeni wrote: > > > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > > index 20c62e7..efa88eb

Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization

On Fri, 24 Mar 2017 22:47:15 +0100 luca abeni wrote: > Ok... Since I am not good at ascii art, would it be ok to add a textual > description? If yes, I'll add a comment like: > " > The utilization of a task is added to the runqueue's active utilization > when the task

Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization

On Fri, 24 Mar 2017 22:47:15 +0100 luca abeni wrote: > Ok... Since I am not good at ascii art, would it be ok to add a textual > description? If yes, I'll add a comment like: > " > The utilization of a task is added to the runqueue's active utilization > when the task becomes active (is enqueued

Re: [net-next PATCH v3 0/8] Add busy poll support for epoll

From: Alexander Duyck Date: Fri, 24 Mar 2017 10:07:47 -0700 > v3: Split off the code for limiting busy_poll and busy_read into a separate > patch for net. > Updated patch that changed busy loop time tracking so that it uses > "local_clock() >> 10" as we

Re: [net-next PATCH v3 0/8] Add busy poll support for epoll

From: Alexander Duyck Date: Fri, 24 Mar 2017 10:07:47 -0700 > v3: Split off the code for limiting busy_poll and busy_read into a separate > patch for net. > Updated patch that changed busy loop time tracking so that it uses > "local_clock() >> 10" as we originally did. > Tweaked

Re: [PATCH] uapi: fix rdma/mlx5-abi.h userspace compilation errors

On Fri, 2017-02-24 at 03:28 +0300, Dmitry V. Levin wrote: > Consistently use types from linux/types.h to fix the following > rdma/mlx5-abi.h userspace compilation errors: > > /usr/include/rdma/mlx5-abi.h:69:25: error: 'u64' undeclared here (not > in a function) >   MLX5_LIB_CAP_4K_UAR = (u64)1 <<

Re: [PATCH] uapi: fix rdma/mlx5-abi.h userspace compilation errors

On Fri, 2017-02-24 at 03:28 +0300, Dmitry V. Levin wrote: > Consistently use types from linux/types.h to fix the following > rdma/mlx5-abi.h userspace compilation errors: > > /usr/include/rdma/mlx5-abi.h:69:25: error: 'u64' undeclared here (not > in a function) >   MLX5_LIB_CAP_4K_UAR = (u64)1 <<

Re: [PATCH v3 1/2] module: verify address is read-only

On Fri, Mar 24, 2017 at 5:42 PM, Jessica Yu wrote: > +++ Kees Cook [23/03/17 14:13 -0700]: >> >> On Wed, Mar 22, 2017 at 7:55 PM, Eddie Kovsky wrote: >>> >>> Implement a mechanism to check if a module's address is in >>> the rodata or ro_after_init sections.

Re: [PATCH v3 1/2] module: verify address is read-only

On Fri, Mar 24, 2017 at 5:42 PM, Jessica Yu wrote: > +++ Kees Cook [23/03/17 14:13 -0700]: >> >> On Wed, Mar 22, 2017 at 7:55 PM, Eddie Kovsky wrote: >>> >>> Implement a mechanism to check if a module's address is in >>> the rodata or ro_after_init sections. It mimics the exsiting functions >>>

Re: [PATCH v3 1/2] module: verify address is read-only

On Fri, Mar 24, 2017 at 6:41 PM, Eddie Kovsky wrote: > On 03/24/17, Jessica Yu wrote: >> +++ Eddie Kovsky [22/03/17 20:55 -0600]: >> > Implement a mechanism to check if a module's address is in >> > the rodata or ro_after_init sections. It mimics the exsiting functions >> >

Re: [PATCH v3 1/2] module: verify address is read-only

On Fri, Mar 24, 2017 at 6:41 PM, Eddie Kovsky wrote: > On 03/24/17, Jessica Yu wrote: >> +++ Eddie Kovsky [22/03/17 20:55 -0600]: >> > Implement a mechanism to check if a module's address is in >> > the rodata or ro_after_init sections. It mimics the exsiting functions >> > that test if an

[PATCH] Staging: vt6655 - block comments style fix

Fixed style of block comments Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/vt6655/rf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6655/rf.h b/drivers/staging/vt6655/rf.h index b6e853784a26..37600093cab2

[PATCH] Staging: vt6655 - block comments style fix

Fixed style of block comments Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/vt6655/rf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6655/rf.h b/drivers/staging/vt6655/rf.h index b6e853784a26..37600093cab2 100644 ---

Re: [PATCH v3 1/2] module: verify address is read-only

On 03/24/17, Jessica Yu wrote: > +++ Eddie Kovsky [22/03/17 20:55 -0600]: > > Implement a mechanism to check if a module's address is in > > the rodata or ro_after_init sections. It mimics the exsiting functions > > that test if an address is inside a module's text section. > > > > Functions that

Re: [PATCH v3 1/2] module: verify address is read-only

On 03/24/17, Jessica Yu wrote: > +++ Eddie Kovsky [22/03/17 20:55 -0600]: > > Implement a mechanism to check if a module's address is in > > the rodata or ro_after_init sections. It mimics the exsiting functions > > that test if an address is inside a module's text section. > > > > Functions that

Re: [PATCH 4.9 00/24] 4.9.18-stable review

Hello Kevin, On 03/24/2017 08:57 PM, Kevin Hilman wrote: > + Sjoerd, Javier, > > kernelci.org bot writes: > >> stable-rc boot: 233 boots: 1 failed, 222 passed with 10 offline >> (v4.9.17-25-g4d90baeca3c8) >> >> Full Boot Summary: >>

Re: [PATCH 4.9 00/24] 4.9.18-stable review

Hello Kevin, On 03/24/2017 08:57 PM, Kevin Hilman wrote: > + Sjoerd, Javier, > > kernelci.org bot writes: > >> stable-rc boot: 233 boots: 1 failed, 222 passed with 10 offline >> (v4.9.17-25-g4d90baeca3c8) >> >> Full Boot Summary: >>

Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely

On Sat, Mar 25, 2017 at 2:14 AM, Sai Gurrappadi wrote: > Hi Rafael, > > On 03/21/2017 04:08 PM, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> The way the schedutil governor uses the PELT metric causes it to >> underestimate the CPU

Re: lockdep warning: console vs. mem hotplug

On (03/24/17 21:08), Steven Rostedt wrote: > > Sebastian, does this change make lockdep happy? > > > > it removes console drivers from the __offline_isolated_pages(). not the > > best solution I can think of, but the simplest one. > > > > --- > > > > mm/page_alloc.c | 2 +- > > 1 file changed,

Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely

On Sat, Mar 25, 2017 at 2:14 AM, Sai Gurrappadi wrote: > Hi Rafael, > > On 03/21/2017 04:08 PM, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> The way the schedutil governor uses the PELT metric causes it to >> underestimate the CPU utilization in some cases. >> >> That can be easily

Re: lockdep warning: console vs. mem hotplug

On (03/24/17 21:08), Steven Rostedt wrote: > > Sebastian, does this change make lockdep happy? > > > > it removes console drivers from the __offline_isolated_pages(). not the > > best solution I can think of, but the simplest one. > > > > --- > > > > mm/page_alloc.c | 2 +- > > 1 file changed,

Re: maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

I think we can all agree that the *ideal* situation would be, for the balloon driver to not immediately hotplug memory so it can add 11 more pages, so maybe I just need to figure out why the balloon driver thinks it needs 11 more pages, and fix that. How does the new memory appear in the

Re: maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

I think we can all agree that the *ideal* situation would be, for the balloon driver to not immediately hotplug memory so it can add 11 more pages, so maybe I just need to figure out why the balloon driver thinks it needs 11 more pages, and fix that. How does the new memory appear in the

Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely

Hi Rafael, On 03/21/2017 04:08 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The way the schedutil governor uses the PELT metric causes it to > underestimate the CPU utilization in some cases. > > That can be easily demonstrated by running kernel

Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely

Hi Rafael, On 03/21/2017 04:08 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The way the schedutil governor uses the PELT metric causes it to > underestimate the CPU utilization in some cases. > > That can be easily demonstrated by running kernel compilation on > a Sandy Bridge

Re: lockdep warning: console vs. mem hotplug

On Sat, 25 Mar 2017 09:04:42 +0900 Sergey Senozhatsky wrote: > On (03/21/17 13:44), Sergey Senozhatsky wrote: > [..] > > so we probably can > > > > > > 1) move pr_info() out of zone->lock in __offline_isolated_pages(). > >meh... > > > > > > 2) switch to

Re: lockdep warning: console vs. mem hotplug

On Sat, 25 Mar 2017 09:04:42 +0900 Sergey Senozhatsky wrote: > On (03/21/17 13:44), Sergey Senozhatsky wrote: > [..] > > so we probably can > > > > > > 1) move pr_info() out of zone->lock in __offline_isolated_pages(). > >meh... > > > > > > 2) switch to printk_deferred() in

[PATCH] cfg80211: Fix array-bounds warning in fragment copy

__ieee80211_amsdu_copy_frag intentionally initializes a pointer to array[-1] to increment it later to valid values. clang rightfully generates an array-bounds warning on the initialization statement. Work around this by initializing the pointer to array[0] and decrementing it later, which allows

[PATCH] cfg80211: Fix array-bounds warning in fragment copy

__ieee80211_amsdu_copy_frag intentionally initializes a pointer to array[-1] to increment it later to valid values. clang rightfully generates an array-bounds warning on the initialization statement. Work around this by initializing the pointer to array[0] and decrementing it later, which allows

[GIT PULL] clk fixes for v4.11-rc3

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-fixes-for-linus for you to fetch changes up to

[GIT PULL] clk fixes for v4.11-rc3

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-fixes-for-linus for you to fetch changes up to

Re: lockdep warning: console vs. mem hotplug

On Sat, 25 Mar 2017 09:00:05 +0900 Sergey Senozhatsky wrote: > Hello, > > On (03/24/17 12:39), Steven Rostedt wrote: > [..] > > Is there a stack trace of where the lockdep dump happened? That is > > useful too. Otherwise we don't see where the inverse happened. >

Re: lockdep warning: console vs. mem hotplug

On Sat, 25 Mar 2017 09:00:05 +0900 Sergey Senozhatsky wrote: > Hello, > > On (03/24/17 12:39), Steven Rostedt wrote: > [..] > > Is there a stack trace of where the lockdep dump happened? That is > > useful too. Otherwise we don't see where the inverse happened. > > Steven, isn't it the

Re: [PATCH] perf auxtrace: Fix no_size logic in addr_filter__resolve_kernel_syms()

Em Fri, Mar 24, 2017 at 04:20:12PM -0700, Andi Kleen escreveu: > On Fri, Mar 24, 2017 at 02:15:52PM +0200, Adrian Hunter wrote: > > Address filtering with kernel symbols incorrectly resulted in the error > > "Cannot determine size of symbol" because the no_size logic was the wrong > > way around.

Re: [PATCH] perf auxtrace: Fix no_size logic in addr_filter__resolve_kernel_syms()

Em Fri, Mar 24, 2017 at 04:20:12PM -0700, Andi Kleen escreveu: > On Fri, Mar 24, 2017 at 02:15:52PM +0200, Adrian Hunter wrote: > > Address filtering with kernel symbols incorrectly resulted in the error > > "Cannot determine size of symbol" because the no_size logic was the wrong > > way around.

  1   2   3   4   5   6   7   8   9   10   >