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

El Mon, Mar 27, 2017 at 01:54:50PM -0400 Javier Martinez Canillas ha dit: > On 03/27/2017 01:39 PM, Matthias Kaehlcke wrote: > > +if (ops->get_voltage || ops->get_voltage_sel) > >> > >> It's valid to have a .get_voltage_sel callback without a .list_voltage? > >> > >> At least

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

El Mon, Mar 27, 2017 at 01:54:50PM -0400 Javier Martinez Canillas ha dit: > On 03/27/2017 01:39 PM, Matthias Kaehlcke wrote: > > +if (ops->get_voltage || ops->get_voltage_sel) > >> > >> It's valid to have a .get_voltage_sel callback without a .list_voltage? > >> > >> At least

Re: SELinux: Fine-tuning for several function implementations

On Mon, Mar 27, 2017 at 1:48 AM, SF Markus Elfring wrote: >> I've made it through the first half (23/46) and of those >> I've merged patches …, 7, … > > It seems that you dropped this one while integrating the eighth > update step. Yes, my mistake, as I said in my

Re: SELinux: Fine-tuning for several function implementations

On Mon, Mar 27, 2017 at 1:48 AM, SF Markus Elfring wrote: >> I've made it through the first half (23/46) and of those >> I've merged patches …, 7, … > > It seems that you dropped this one while integrating the eighth > update step. Yes, my mistake, as I said in my response to that patch, I do

Re: selinux: Delete unnecessary variable assignments in policydb_index()

On Mon, Mar 27, 2017 at 2:24 AM, SF Markus Elfring wrote: >> However, I agree with Casey that this patch is mostly just code churn >> so I'm going to drop this from your series. > > How do you think about to return only constant error codes in this function? > Would

Re: selinux: Delete unnecessary variable assignments in policydb_index()

On Mon, Mar 27, 2017 at 2:24 AM, SF Markus Elfring wrote: >> However, I agree with Casey that this patch is mostly just code churn >> so I'm going to drop this from your series. > > How do you think about to return only constant error codes in this function? > Would it be acceptable to replace

[PATCH V7 02/18] blk-throttle: prepare support multiple limits

We are going to support low/max limit, each cgroup will have 2 limits after that. This patch prepares for the multiple limits change. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 110 --- 1 file changed, 70 insertions(+), 40

[PATCH V7 02/18] blk-throttle: prepare support multiple limits

We are going to support low/max limit, each cgroup will have 2 limits after that. This patch prepares for the multiple limits change. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 110 --- 1 file changed, 70 insertions(+), 40 deletions(-)

Re: [BUG] Deadlock due due to interactions of block, RCU, and cpu offline

On Mon, Mar 27, 2017 at 12:02:27PM -0600, Jeffrey Hugo wrote: > Hi Paul. > > Thanks for the quick reply. > > On 3/26/2017 5:28 PM, Paul E. McKenney wrote: > >On Sun, Mar 26, 2017 at 05:10:40PM -0600, Jeffrey Hugo wrote: > > >>It is a race between this work running, and the cpu offline

Re: [BUG] Deadlock due due to interactions of block, RCU, and cpu offline

On Mon, Mar 27, 2017 at 12:02:27PM -0600, Jeffrey Hugo wrote: > Hi Paul. > > Thanks for the quick reply. > > On 3/26/2017 5:28 PM, Paul E. McKenney wrote: > >On Sun, Mar 26, 2017 at 05:10:40PM -0600, Jeffrey Hugo wrote: > > >>It is a race between this work running, and the cpu offline

Re: [PATCH V7 00/18] blk-throttle: add .low limit

On 03/27/2017 11:51 AM, Shaohua Li wrote: > V6->V7: > - Don't overload blk stat, which will simplify the code. This will add extra > space in bio/request though with the low interface configure option on. Hmm, why? As far as I can see, it just makes things worse. -- Jens Axboe

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Mon, Mar 27, 2017 at 07:05:40PM +0200, Christoph Hellwig wrote: > Hi Mike, > > does the patch below fix that issue for you? > > diff --git a/drivers/virtio/virtio_pci_common.c > b/drivers/virtio/virtio_pci_common.c > index df548a6fb844..fd1b06368b1f 100644 > ---

Re: [PATCH V7 00/18] blk-throttle: add .low limit

On 03/27/2017 11:51 AM, Shaohua Li wrote: > V6->V7: > - Don't overload blk stat, which will simplify the code. This will add extra > space in bio/request though with the low interface configure option on. Hmm, why? As far as I can see, it just makes things worse. -- Jens Axboe

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Mon, Mar 27, 2017 at 07:05:40PM +0200, Christoph Hellwig wrote: > Hi Mike, > > does the patch below fix that issue for you? > > diff --git a/drivers/virtio/virtio_pci_common.c > b/drivers/virtio/virtio_pci_common.c > index df548a6fb844..fd1b06368b1f 100644 > ---

RE: [PATCH 2/2] pci-hyperv: Fix an atomic bug

> -Original Message- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of k...@exchange.microsoft.com > Sent: Friday, March 24, 2017 11:07 AM > To: helg...@kernel.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org;

RE: [PATCH 2/2] pci-hyperv: Fix an atomic bug

> -Original Message- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of k...@exchange.microsoft.com > Sent: Friday, March 24, 2017 11:07 AM > To: helg...@kernel.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org;

RE: [PATCH 1/2] pci-hyperv: Fix a bug in specifying CPU affinity

> -Original Message- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of k...@exchange.microsoft.com > Sent: Friday, March 24, 2017 11:07 AM > To: helg...@kernel.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org;

RE: [PATCH 1/2] pci-hyperv: Fix a bug in specifying CPU affinity

> -Original Message- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of k...@exchange.microsoft.com > Sent: Friday, March 24, 2017 11:07 AM > To: helg...@kernel.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org;

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

On Mon, Mar 27, 2017 at 01:54:50PM -0400, Javier Martinez Canillas wrote: > On 03/27/2017 01:39 PM, Matthias Kaehlcke wrote: > > I don't know for sure if this condition is superfluous or if there are > > cases where it makes sense to have a .list_voltage but not > > .get_voltage_sel. > I don't

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

On Mon, Mar 27, 2017 at 01:54:50PM -0400, Javier Martinez Canillas wrote: > On 03/27/2017 01:39 PM, Matthias Kaehlcke wrote: > > I don't know for sure if this condition is superfluous or if there are > > cases where it makes sense to have a .list_voltage but not > > .get_voltage_sel. > I don't

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On Mon, Mar 27, 2017 at 07:37:39PM +0200, Rafael J. Wysocki wrote: > One is that if we want *all* drivers to work with schedutil, we need to keep > the kthread for the ones that will never be reworked (because nobody cares > etc). But then perhaps the kthread implementation may be left alone

Re: [PATCH v3 1/3] perf annotate: Fix a bug reading link name from a build-id file

Em Mon, Mar 27, 2017 at 04:10:36PM +0900, Taeung Song escreveu: > It is wrong way to read link name from a build-id file. > Because a build-id file is not symbolic link > but build-id directory of it is symbolic link, so fix it. Ok, applied, in the past it was always a symlink, but the following

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On Mon, Mar 27, 2017 at 07:37:39PM +0200, Rafael J. Wysocki wrote: > One is that if we want *all* drivers to work with schedutil, we need to keep > the kthread for the ones that will never be reworked (because nobody cares > etc). But then perhaps the kthread implementation may be left alone

Re: [PATCH v3 1/3] perf annotate: Fix a bug reading link name from a build-id file

Em Mon, Mar 27, 2017 at 04:10:36PM +0900, Taeung Song escreveu: > It is wrong way to read link name from a build-id file. > Because a build-id file is not symbolic link > but build-id directory of it is symbolic link, so fix it. Ok, applied, in the past it was always a symlink, but the following

Re: [PATCH v2 1/2] dt-bindings: ata: add DT bindings for ahci-dm816 SATA controller

On Tue, Mar 14, 2017 at 12:04:50PM +0100, Bartosz Golaszewski wrote: > Add DT bindings for the onboard SATA controller present on the DM816x > SoCs. > > Signed-off-by: Bartosz Golaszewski Applied to libata/for-4.12. Thanks. -- tejun

Re: [PATCH v2 1/2] dt-bindings: ata: add DT bindings for ahci-dm816 SATA controller

On Tue, Mar 14, 2017 at 12:04:50PM +0100, Bartosz Golaszewski wrote: > Add DT bindings for the onboard SATA controller present on the DM816x > SoCs. > > Signed-off-by: Bartosz Golaszewski Applied to libata/for-4.12. Thanks. -- tejun

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On Mon, Mar 27, 2017 at 06:50:11PM +0200, Peter Zijlstra wrote: > Taken together this seems to suggest we can rework cpufreq drivers to > function in-context, either directly push the packet on the bus if > available, or queue it and let whoever owns it sort it without blocking. Note that this

Re: [PATCH v6] mfd: Add Cherry Trail Whiskey Cove PMIC driver

Hi Hans, [auto build test ERROR on ljones-mfd/for-mfd-next] [also build test ERROR on v4.11-rc4 next-20170327] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Hans-de-Goede/mfd-Add-Cherry-Trail

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On Mon, Mar 27, 2017 at 06:50:11PM +0200, Peter Zijlstra wrote: > Taken together this seems to suggest we can rework cpufreq drivers to > function in-context, either directly push the packet on the bus if > available, or queue it and let whoever owns it sort it without blocking. Note that this

Re: [PATCH v6] mfd: Add Cherry Trail Whiskey Cove PMIC driver

Hi Hans, [auto build test ERROR on ljones-mfd/for-mfd-next] [also build test ERROR on v4.11-rc4 next-20170327] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Hans-de-Goede/mfd-Add-Cherry-Trail

Re: [BUG] Deadlock due due to interactions of block, RCU, and cpu offline

Hi Paul. Thanks for the quick reply. On 3/26/2017 5:28 PM, Paul E. McKenney wrote: On Sun, Mar 26, 2017 at 05:10:40PM -0600, Jeffrey Hugo wrote: It is a race between this work running, and the cpu offline processing. One quick way to test this assumption is to build a kernel with Kconfig

Re: ata: WARNING in ata_bmdma_qc_issue

On Fri, Mar 24, 2017 at 03:14:14PM +0100, Dmitry Vyukov wrote: > Hello, > > The following program triggers WARNING in ata_bmdma_qc_issue: > https://gist.githubusercontent.com/dvyukov/7497a05853e58598b74a2c48030c41f4/raw/38885f75eb05f72bb47fff9c9de657728f529927/gistfile1.txt Fix is already queued

Re: ata: WARNING in ata_bmdma_qc_issue

On Fri, Mar 24, 2017 at 03:14:14PM +0100, Dmitry Vyukov wrote: > Hello, > > The following program triggers WARNING in ata_bmdma_qc_issue: > https://gist.githubusercontent.com/dvyukov/7497a05853e58598b74a2c48030c41f4/raw/38885f75eb05f72bb47fff9c9de657728f529927/gistfile1.txt Fix is already queued

Re: [BUG] Deadlock due due to interactions of block, RCU, and cpu offline

Hi Paul. Thanks for the quick reply. On 3/26/2017 5:28 PM, Paul E. McKenney wrote: On Sun, Mar 26, 2017 at 05:10:40PM -0600, Jeffrey Hugo wrote: It is a race between this work running, and the cpu offline processing. One quick way to test this assumption is to build a kernel with Kconfig

Re: [PATCH] cgroup: switch to BUG_ON()

On Sun, Mar 26, 2017 at 06:24:06PM +0200, Nicholas Mc Guire wrote: > Use BUG_ON() rather than an explicit if followed by BUG() for > improved readability and also consistency. > > Signed-off-by: Nicholas Mc Guire Applied to cgroup/for-4.12. Thanks. -- tejun

Re: [PATCH] cgroup: switch to BUG_ON()

On Sun, Mar 26, 2017 at 06:24:06PM +0200, Nicholas Mc Guire wrote: > Use BUG_ON() rather than an explicit if followed by BUG() for > improved readability and also consistency. > > Signed-off-by: Nicholas Mc Guire Applied to cgroup/for-4.12. Thanks. -- tejun

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

* Bin Liu [170327 10:17]: > On Mon, Mar 27, 2017 at 09:59:47AM -0700, Tony Lindgren wrote: > > * Moreno Bartalucci [170327 09:23]: > > > If I understood your patch, however, if the device (anyone, not just my > > > one) takes longer to switch, VBUS

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

* Bin Liu [170327 10:17]: > On Mon, Mar 27, 2017 at 09:59:47AM -0700, Tony Lindgren wrote: > > * Moreno Bartalucci [170327 09:23]: > > > If I understood your patch, however, if the device (anyone, not just my > > > one) takes longer to switch, VBUS is deasserted anyway. > > > > Yeah some of

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

Hello Matthias, On 03/27/2017 01:39 PM, Matthias Kaehlcke wrote: > Thanks for the reviews and testing! > You are welcome. [snip] + if (ops->get_voltage || ops->get_voltage_sel) >> >> It's valid to have a .get_voltage_sel callback without a .list_voltage? >> >> At least it seems

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

Hello Matthias, On 03/27/2017 01:39 PM, Matthias Kaehlcke wrote: > Thanks for the reviews and testing! > You are welcome. [snip] + if (ops->get_voltage || ops->get_voltage_sel) >> >> It's valid to have a .get_voltage_sel callback without a .list_voltage? >> >> At least it seems

[PATCH V7 15/18] blk-throttle: ignore idle cgroup limit

Last patch introduces a way to detect idle cgroup. We use it to make upgrade/downgrade decision. And the new algorithm can detect completely idle cgroup too, so we can delete the corresponding code. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 40

[PATCH V7 10/18] blk-throttle: choose a small throtl_slice for SSD

The throtl_slice is 100ms by default. This is a long time for SSD, a lot of IO can run. To make cgroups have smoother throughput, we choose a small value (20ms) for SSD. Signed-off-by: Shaohua Li --- block/blk-sysfs.c| 2 ++ block/blk-throttle.c | 23 ---

Re: [PATCH 2/2] sysfs: add devm_sysfs_create_group() and friends

On Sun, Feb 12, 2017 at 04:36:19PM -0800, Dmitry Torokhov wrote: > Many drivers create additional driver-specific device attributes when > binding to the device and providing managed version of sysfs_create_group() > will simplify unbinding and error handling in probe path for such drivers. > >

[PATCH V7 13/18] blk-throttle: add a simple idle detection

A cgroup gets assigned a low limit, but the cgroup could never dispatch enough IO to cross the low limit. In such case, the queue state machine will remain in LIMIT_LOW state and all other cgroups will be throttled according to low limit. This is unfair for other cgroups. We should treat the

[PATCH V7 01/18] blk-throttle: use U64_MAX/UINT_MAX to replace -1

clean up the code to avoid using -1 Signed-off-by: Shaohua Li --- block/blk-throttle.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index 8fab716..0d5d85b 100644 ---

[PATCH V7 15/18] blk-throttle: ignore idle cgroup limit

Last patch introduces a way to detect idle cgroup. We use it to make upgrade/downgrade decision. And the new algorithm can detect completely idle cgroup too, so we can delete the corresponding code. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 40 ++--

[PATCH V7 10/18] blk-throttle: choose a small throtl_slice for SSD

The throtl_slice is 100ms by default. This is a long time for SSD, a lot of IO can run. To make cgroups have smoother throughput, we choose a small value (20ms) for SSD. Signed-off-by: Shaohua Li --- block/blk-sysfs.c| 2 ++ block/blk-throttle.c | 23 --- block/blk.h

Re: [PATCH 2/2] sysfs: add devm_sysfs_create_group() and friends

On Sun, Feb 12, 2017 at 04:36:19PM -0800, Dmitry Torokhov wrote: > Many drivers create additional driver-specific device attributes when > binding to the device and providing managed version of sysfs_create_group() > will simplify unbinding and error handling in probe path for such drivers. > >

[PATCH V7 13/18] blk-throttle: add a simple idle detection

A cgroup gets assigned a low limit, but the cgroup could never dispatch enough IO to cross the low limit. In such case, the queue state machine will remain in LIMIT_LOW state and all other cgroups will be throttled according to low limit. This is unfair for other cgroups. We should treat the

[PATCH V7 01/18] blk-throttle: use U64_MAX/UINT_MAX to replace -1

clean up the code to avoid using -1 Signed-off-by: Shaohua Li --- block/blk-throttle.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index 8fab716..0d5d85b 100644 --- a/block/blk-throttle.c +++

[PATCH V7 12/18] blk-throttle: make bandwidth change smooth

When cgroups all reach low limit, cgroups can dispatch more IO. This could make some cgroups dispatch more IO but others not, and even some cgroups could dispatch less IO than their low limit. For example, cg1 low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is 120M/s for the

[PATCH V7 17/18] blk-throttle: add a mechanism to estimate IO latency

User configures latency target, but the latency threshold for each request size isn't fixed. For a SSD, the IO latency highly depends on request size. To calculate latency threshold, we sample some data, eg, average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency threshold of each

[PATCH V7 12/18] blk-throttle: make bandwidth change smooth

When cgroups all reach low limit, cgroups can dispatch more IO. This could make some cgroups dispatch more IO but others not, and even some cgroups could dispatch less IO than their low limit. For example, cg1 low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is 120M/s for the

[PATCH V7 17/18] blk-throttle: add a mechanism to estimate IO latency

User configures latency target, but the latency threshold for each request size isn't fixed. For a SSD, the IO latency highly depends on request size. To calculate latency threshold, we sample some data, eg, average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency threshold of each

[PATCH V7 16/18] blk-throttle: add interface for per-cgroup target latency

Here we introduce per-cgroup latency target. The target determines how a cgroup can afford latency increasement. We will use the target latency to calculate a threshold and use it to schedule IO for cgroups. If a cgroup's bandwidth is below its low limit but its average latency is below the

[PATCH V7 16/18] blk-throttle: add interface for per-cgroup target latency

Here we introduce per-cgroup latency target. The target determines how a cgroup can afford latency increasement. We will use the target latency to calculate a threshold and use it to schedule IO for cgroups. If a cgroup's bandwidth is below its low limit but its average latency is below the

[PATCH V7 11/18] blk-throttle: detect completed idle cgroup

cgroup could be assigned a limit, but doesn't dispatch enough IO, eg the cgroup is idle. When this happens, the cgroup doesn't hit its limit, so we can't move the state machine to higher level and all cgroups will be throttled to their lower limit, so we waste bandwidth. Detecting idle cgroup is

[PATCH V7 11/18] blk-throttle: detect completed idle cgroup

cgroup could be assigned a limit, but doesn't dispatch enough IO, eg the cgroup is idle. When this happens, the cgroup doesn't hit its limit, so we can't move the state machine to higher level and all cgroups will be throttled to their lower limit, so we waste bandwidth. Detecting idle cgroup is

[PATCH] HID: sony: remove redundant check for -ve err

From: Colin Ian King err is being checked for failure each time it is being updated so this err check is totally redundant and can be removed Detected with CoverityScan, CID#1420665 ("Logically dead code") Signed-off-by: Colin Ian King ---

[PATCH] HID: sony: remove redundant check for -ve err

From: Colin Ian King err is being checked for failure each time it is being updated so this err check is totally redundant and can be removed Detected with CoverityScan, CID#1420665 ("Logically dead code") Signed-off-by: Colin Ian King --- drivers/hid/hid-sony.c | 3 --- 1 file changed, 3

scsi_debug: shared dev context, BUG or FEATURE?

Hi scsi_debug has very strange structure from one point it supports dynamic number of devices but from other point context is common for all devices: - dif_storep (array of t10 dif tuples) - map_storep (block map for thinprovision) - fake_storep (in memory data storage) - sdebug_q_arr (queue

scsi_debug: shared dev context, BUG or FEATURE?

Hi scsi_debug has very strange structure from one point it supports dynamic number of devices but from other point context is common for all devices: - dif_storep (array of t10 dif tuples) - map_storep (block map for thinprovision) - fake_storep (in memory data storage) - sdebug_q_arr (queue

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On Monday, March 27, 2017 06:13:36 PM Juri Lelli wrote: > On 27/03/17 19:05, Rafael J. Wysocki wrote: > > On Monday, March 27, 2017 06:01:34 PM Juri Lelli wrote: > > > On 27/03/17 18:50, Peter Zijlstra wrote: > > > > On Fri, Mar 24, 2017 at 02:08:58PM +, Juri Lelli wrote: > > > > > Worker

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On Monday, March 27, 2017 06:13:36 PM Juri Lelli wrote: > On 27/03/17 19:05, Rafael J. Wysocki wrote: > > On Monday, March 27, 2017 06:01:34 PM Juri Lelli wrote: > > > On 27/03/17 18:50, Peter Zijlstra wrote: > > > > On Fri, Mar 24, 2017 at 02:08:58PM +, Juri Lelli wrote: > > > > > Worker

[PATCH] tile: prefer to __need_int_reg_t

As part of some work in glibc to move away from the "__need" prefix, this commit breaks away the definitions of __int_reg_t, __uint_reg_t, __INT_REG_BITS, and __INT_REG_FMT to a separate "microheader". It is then included from to preserve the semantics of the previous header. For now, we

[PATCH] tile: prefer to __need_int_reg_t

As part of some work in glibc to move away from the "__need" prefix, this commit breaks away the definitions of __int_reg_t, __uint_reg_t, __INT_REG_BITS, and __INT_REG_FMT to a separate "microheader". It is then included from to preserve the semantics of the previous header. For now, we

Re: [PATCH 1/1] ethtool : added get_phy_stats,get_strings,get_sset_count

On Mon, Mar 27, 2017 at 09:44:37AM -0700, Florian Fainelli wrote: > Hello, > > On 03/27/2017 03:12 AM, Thomas Scariah wrote: > > From: "Scariah, Thomas" > > > > Added functions to support ethtool to print the phy statistics and error > > information along with other

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

Thanks for the reviews and testing! El Sat, Mar 25, 2017 at 02:05:47AM -0300 Javier Martinez Canillas ha dit: 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

Re: [PATCH 1/1] ethtool : added get_phy_stats,get_strings,get_sset_count

On Mon, Mar 27, 2017 at 09:44:37AM -0700, Florian Fainelli wrote: > Hello, > > On 03/27/2017 03:12 AM, Thomas Scariah wrote: > > From: "Scariah, Thomas" > > > > Added functions to support ethtool to print the phy statistics and error > > information along with other ethtool statistics. This

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

Thanks for the reviews and testing! El Sat, Mar 25, 2017 at 02:05:47AM -0300 Javier Martinez Canillas ha dit: 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

Re: [BUG nohz]: wrong user and system time accounting

On Mon, 2017-03-27 at 09:56 +0800, Wanpeng Li wrote: > > Actually after I bisect, the first bad commit is ff9a9b4c4334 > ("sched, > time: Switch VIRT_CPU_ACCOUNTING_GEN to jiffy granularity"). The bug > can be reproduced readily if CONFIG_CONTEXT_TRACKING_FORCE is true At the time, we thought it

Re: [BUG nohz]: wrong user and system time accounting

On Mon, 2017-03-27 at 09:56 +0800, Wanpeng Li wrote: > > Actually after I bisect, the first bad commit is ff9a9b4c4334 > ("sched, > time: Switch VIRT_CPU_ACCOUNTING_GEN to jiffy granularity"). The bug > can be reproduced readily if CONFIG_CONTEXT_TRACKING_FORCE is true At the time, we thought it

Re: [PATCH 1/1] ethtool : added get_phy_stats,get_strings,get_sset_count

> > static int cpsw_get_sset_count(struct net_device *ndev, int sset) > > { > > + struct cpsw_priv *priv = netdev_priv(ndev); > > + int slave_no = cpsw_slave_index(priv); > > + int count; > > + > > switch (sset) { > > case ETH_SS_STATS: > > - return CPSW_STATS_LEN; > > +

Re: [PATCH 1/1] ethtool : added get_phy_stats,get_strings,get_sset_count

> > static int cpsw_get_sset_count(struct net_device *ndev, int sset) > > { > > + struct cpsw_priv *priv = netdev_priv(ndev); > > + int slave_no = cpsw_slave_index(priv); > > + int count; > > + > > switch (sset) { > > case ETH_SS_STATS: > > - return CPSW_STATS_LEN; > > +

Re: [PATCH 1/2] x86/mce/AMD: Redo use of SMCA MCA_DE{STAT,ADDR} registers

On Wed, Mar 22, 2017 at 02:29:30PM -0500, Yazen Ghannam wrote: > 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

Re: [PATCH 1/2] x86/mce/AMD: Redo use of SMCA MCA_DE{STAT,ADDR} registers

On Wed, Mar 22, 2017 at 02:29:30PM -0500, Yazen Ghannam wrote: > 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

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

Hello Kevin, On 03/27/2017 12:55 PM, Kevin Hilman wrote: > Hi Javier, > > Javier Martinez Canillas writes: > >> Hello Kevin, >> >> On 03/24/2017 08:57 PM, Kevin Hilman wrote: >>> + Sjoerd, Javier, >>> >>> kernelci.org bot writes: >>> stable-rc

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

Hello Kevin, On 03/27/2017 12:55 PM, Kevin Hilman wrote: > Hi Javier, > > Javier Martinez Canillas writes: > >> 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

Re: __link_block_group uses GFP_KERNEL

On Sat, Mar 25, 2017 at 09:48:28AM +0300, Denis Kirjanov wrote: > On 3/25/17, Jeff Mahoney wrote: > > On 3/24/17 5:02 AM, Denis Kirjanov wrote: > >> Hi guys, > >> > >> Looks like that current code does GFP_KERNEL allocation inside > >> __link_block_group. > >> the function invokes

Re: __link_block_group uses GFP_KERNEL

On Sat, Mar 25, 2017 at 09:48:28AM +0300, Denis Kirjanov wrote: > On 3/25/17, Jeff Mahoney wrote: > > On 3/24/17 5:02 AM, Denis Kirjanov wrote: > >> Hi guys, > >> > >> Looks like that current code does GFP_KERNEL allocation inside > >> __link_block_group. > >> the function invokes kobject_add and

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On Monday, March 27, 2017 06:01:34 PM Juri Lelli wrote: > On 27/03/17 18:50, Peter Zijlstra wrote: > > On Fri, Mar 24, 2017 at 02:08:58PM +, Juri Lelli wrote: > > > Worker kthread needs to be able to change frequency for all other > > > threads. > > > > > > Make it special, just under STOP

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On Monday, March 27, 2017 06:01:34 PM Juri Lelli wrote: > On 27/03/17 18:50, Peter Zijlstra wrote: > > On Fri, Mar 24, 2017 at 02:08:58PM +, Juri Lelli wrote: > > > Worker kthread needs to be able to change frequency for all other > > > threads. > > > > > > Make it special, just under STOP

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

On Mon, Mar 27, 2017 at 09:59:47AM -0700, Tony Lindgren wrote: > * Moreno Bartalucci [170327 09:23]: > > If I understood your patch, however, if the device (anyone, not just my > > one) takes longer to switch, VBUS is deasserted anyway. > > Yeah some of them can

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

On Mon, Mar 27, 2017 at 09:59:47AM -0700, Tony Lindgren wrote: > * Moreno Bartalucci [170327 09:23]: > > If I understood your patch, however, if the device (anyone, not just my > > one) takes longer to switch, VBUS is deasserted anyway. > > Yeah some of them can take at least 10 seconds even to

Re: [PATCH v3] block: trace completion of all bios.

On Mon, Mar 27, 2017 at 08:49:57PM +1100, NeilBrown wrote: > On Mon, Mar 27 2017, Christoph Hellwig wrote: > > > I don't really like the flag at all. I'd much prefer a __bio_endio > > with a 'bool trace' flag. Also please remove the manual tracing in > > dm.ċ. Once that is done I suspect we

Re: [PATCH v3] block: trace completion of all bios.

On Mon, Mar 27, 2017 at 08:49:57PM +1100, NeilBrown wrote: > On Mon, Mar 27 2017, Christoph Hellwig wrote: > > > I don't really like the flag at all. I'd much prefer a __bio_endio > > with a 'bool trace' flag. Also please remove the manual tracing in > > dm.ċ. Once that is done I suspect we

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On 27/03/17 19:05, Rafael J. Wysocki wrote: > On Monday, March 27, 2017 06:01:34 PM Juri Lelli wrote: > > On 27/03/17 18:50, Peter Zijlstra wrote: > > > On Fri, Mar 24, 2017 at 02:08:58PM +, Juri Lelli wrote: > > > > Worker kthread needs to be able to change frequency for all other > > > >

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On 27/03/17 19:05, Rafael J. Wysocki wrote: > On Monday, March 27, 2017 06:01:34 PM Juri Lelli wrote: > > On 27/03/17 18:50, Peter Zijlstra wrote: > > > On Fri, Mar 24, 2017 at 02:08:58PM +, Juri Lelli wrote: > > > > Worker kthread needs to be able to change frequency for all other > > > >

RE: [PATCH V2 1/2] x86/msr: add msr_set/clear_bit_on_cpu/cpus access functions

> > On Mon, Mar 27, 2017 at 08:47:37AM -0700, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Having msr_set/clear_bit on many cpus or given CPU can avoid extra > > unnecessory IPIs > > How does that happen? > My previous patch did a read-modify-write operation.

RE: [PATCH V2 1/2] x86/msr: add msr_set/clear_bit_on_cpu/cpus access functions

> > On Mon, Mar 27, 2017 at 08:47:37AM -0700, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Having msr_set/clear_bit on many cpus or given CPU can avoid extra > > unnecessory IPIs > > How does that happen? > My previous patch did a read-modify-write operation. Compared with the

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On 27/03/17 18:50, Peter Zijlstra wrote: > On Fri, Mar 24, 2017 at 02:08:58PM +, Juri Lelli wrote: > > Worker kthread needs to be able to change frequency for all other > > threads. > > > > Make it special, just under STOP class. > > *yuck* ;-) > Eh, I know. :/ > So imagine our I2C/SPI

RE: [PATCH v3 4/7] arm: dts: r7s72100: Add pin controller node

Hi Jacopo, On Friday, March 24, 2017, Jacopo Mondi > + pinctrl: pinctrl@fcfe3000 { > + compatible = "renesas,r7s72100-ports"; > + > + #pinctrl-cells = <1>; > + > + reg = <0xfcfe3000 0x42C0>; Out of curiosity, why did you change this from 0x4248 to 0x42C0?

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On 27/03/17 18:50, Peter Zijlstra wrote: > On Fri, Mar 24, 2017 at 02:08:58PM +, Juri Lelli wrote: > > Worker kthread needs to be able to change frequency for all other > > threads. > > > > Make it special, just under STOP class. > > *yuck* ;-) > Eh, I know. :/ > So imagine our I2C/SPI

RE: [PATCH v3 4/7] arm: dts: r7s72100: Add pin controller node

Hi Jacopo, On Friday, March 24, 2017, Jacopo Mondi > + pinctrl: pinctrl@fcfe3000 { > + compatible = "renesas,r7s72100-ports"; > + > + #pinctrl-cells = <1>; > + > + reg = <0xfcfe3000 0x42C0>; Out of curiosity, why did you change this from 0x4248 to 0x42C0?

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

* Moreno Bartalucci [170327 09:23]: > If I understood your patch, however, if the device (anyone, not just my one) > takes longer to switch, VBUS is deasserted anyway. Yeah some of them can take at least 10 seconds even to enumerate. So probably we need to have

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

* Moreno Bartalucci [170327 09:23]: > If I understood your patch, however, if the device (anyone, not just my one) > takes longer to switch, VBUS is deasserted anyway. Yeah some of them can take at least 10 seconds even to enumerate. So probably we need to have to have some longer timeout set

Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

On 27/03/17 16:53, Mason wrote: > On 24/03/2017 19:47, Marc Zyngier wrote: > >> On 23/03/17 17:03, Mason wrote: >> >>> On 23/03/2017 15:22, Marc Zyngier wrote: >>> On 23/03/17 13:05, Mason wrote: > + writel_relaxed(status, pcie->msi_status); /* clear IRQs */ Why isn't this

Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

On 27/03/17 16:53, Mason wrote: > On 24/03/2017 19:47, Marc Zyngier wrote: > >> On 23/03/17 17:03, Mason wrote: >> >>> On 23/03/2017 15:22, Marc Zyngier wrote: >>> On 23/03/17 13:05, Mason wrote: > + writel_relaxed(status, pcie->msi_status); /* clear IRQs */ Why isn't this

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

Hi Mike, does the patch below fix that issue for you? diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c index df548a6fb844..fd1b06368b1f 100644 --- a/drivers/virtio/virtio_pci_common.c +++ b/drivers/virtio/virtio_pci_common.c @@ -176,7 +176,7 @@ static int

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

Hi Mike, does the patch below fix that issue for you? diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c index df548a6fb844..fd1b06368b1f 100644 --- a/drivers/virtio/virtio_pci_common.c +++ b/drivers/virtio/virtio_pci_common.c @@ -176,7 +176,7 @@ static int

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