On 7/26/2018 7:49 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_probe':
> sound/soc/amd/acp-da7219-max98357a.c:367:3: warning: 'ret'
On 7/26/2018 7:49 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_probe':
> sound/soc/amd/acp-da7219-max98357a.c:367:3: warning: 'ret'
Fixes
sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_probe':
sound/soc/amd/acp-da7219-max98357a.c:367:3: warning: 'ret' may
be used uninitialized in this function [-Wmaybe-uninitialized]
dev_err(>dev, "Failed to register regulator: %d\n",
ret);
Signed-off-by: Akshu Agrawal
---
Fixes
sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_probe':
sound/soc/amd/acp-da7219-max98357a.c:367:3: warning: 'ret' may
be used uninitialized in this function [-Wmaybe-uninitialized]
dev_err(>dev, "Failed to register regulator: %d\n",
ret);
Signed-off-by: Akshu Agrawal
---
Fix kprobe string argument testcase to not probe notrace
function. Instead, it probes tracefs function which must
be available with ftrace.
Signed-off-by: Masami Hiramatsu
---
.../ftrace/test.d/kprobe/kprobe_args_string.tc | 30
1 file changed, 12 insertions(+), 18
Fix kprobe string argument testcase to not probe notrace
function. Instead, it probes tracefs function which must
be available with ftrace.
Signed-off-by: Masami Hiramatsu
---
.../ftrace/test.d/kprobe/kprobe_args_string.tc | 30
1 file changed, 12 insertions(+), 18
From: Francis Deslauriers
Move selftest function to its own compile unit so it can be compiled
with the ftrace cflags (CC_FLAGS_FTRACE) allowing it to be probed
during the ftrace startup tests.
Signed-off-by: Francis Deslauriers
Acked-by: Masami Hiramatsu
---
kernel/trace/Makefile
From: Francis Deslauriers
Move selftest function to its own compile unit so it can be compiled
with the ftrace cflags (CC_FLAGS_FTRACE) allowing it to be probed
during the ftrace startup tests.
Signed-off-by: Francis Deslauriers
Acked-by: Masami Hiramatsu
---
kernel/trace/Makefile
Prohibit kprobe-events probing on notrace function.
Since probing on the notrace function can cause recursive
event call. In most case those are just skipped, but
in some case it falls into infinit recursive call.
This protection can be disabled by the kconfig
CONFIG_KPROBE_EVENTS_ON_NOTRACE=y,
Prohibit kprobe-events probing on notrace function.
Since probing on the notrace function can cause recursive
event call. In most case those are just skipped, but
in some case it falls into infinit recursive call.
This protection can be disabled by the kconfig
CONFIG_KPROBE_EVENTS_ON_NOTRACE=y,
Reporting the crash: BUG: soft lockup in snd_virmidi_output_trigger
This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this
report.
Note that this bug is previously reported by Syzkaller a few month ago.
Reporting the crash: BUG: soft lockup in snd_virmidi_output_trigger
This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this
report.
Note that this bug is previously reported by Syzkaller a few month ago.
Hello, this is the 2nd version of the series to prohibit kprobe
on notrace functions which Francis sent before.
Here is v1 series:
https://lkml.org/lkml/2018/7/12/678
In this version, I've add a kconfig option to remove notrace
protection just for debugging, and also fix ftracetest testcase
to
Hello, this is the 2nd version of the series to prohibit kprobe
on notrace functions which Francis sent before.
Here is v1 series:
https://lkml.org/lkml/2018/7/12/678
In this version, I've add a kconfig option to remove notrace
protection just for debugging, and also fix ftracetest testcase
to
On Wed, Jul 25, 2018 at 01:40:53PM -0700, Stephen Boyd wrote:
> Quoting Nicholas Mc Guire (2018-07-15 03:18:24)
> > Refactoring of code to make it more readable and at the same time make
> > sparse happy again.
> >
> > Signed-off-by: Nicholas Mc Guire
> > ---
> >
> > sparse complained about:
>
On Wed, Jul 25, 2018 at 01:40:53PM -0700, Stephen Boyd wrote:
> Quoting Nicholas Mc Guire (2018-07-15 03:18:24)
> > Refactoring of code to make it more readable and at the same time make
> > sparse happy again.
> >
> > Signed-off-by: Nicholas Mc Guire
> > ---
> >
> > sparse complained about:
>
On Wed, Jul 25, 2018 at 01:41:38PM -0700, Stephen Boyd wrote:
> Quoting Nicholas Mc Guire (2018-07-15 03:18:23)
> > While the return value of clkgen_get_register_base() is being checked
> > at the call site, there is no indication of failure cause thus making
> > diagnosis of the issues hard. The
On Wed, Jul 25, 2018 at 01:41:38PM -0700, Stephen Boyd wrote:
> Quoting Nicholas Mc Guire (2018-07-15 03:18:23)
> > While the return value of clkgen_get_register_base() is being checked
> > at the call site, there is no indication of failure cause thus making
> > diagnosis of the issues hard. The
Hi Guenter,
Thank you.. I sent next version patch with modification.
Regards,
Srinath.
On Thu, Jul 26, 2018 at 10:39 AM, Guenter Roeck wrote:
> On 07/25/2018 09:47 PM, Srinath Mannam wrote:
>>
>> Hi Guenter,
>>
>> It was my mistake sorry for that. I thought to add as Rivewed-by your
>> name..
Hi Guenter,
Thank you.. I sent next version patch with modification.
Regards,
Srinath.
On Thu, Jul 26, 2018 at 10:39 AM, Guenter Roeck wrote:
> On 07/25/2018 09:47 PM, Srinath Mannam wrote:
>>
>> Hi Guenter,
>>
>> It was my mistake sorry for that. I thought to add as Rivewed-by your
>> name..
Hi Alan,
Thanks for the review...
> > In Zynq Case it supports two types of the readback (Configuration registers,
> Configuration data(fpga image)) which may not be the same case for other
> vendors.
> > Since I need to support both the use cases I have differentiated them using
>
Hi Alan,
Thanks for the review...
> > In Zynq Case it supports two types of the readback (Configuration registers,
> Configuration data(fpga image)) which may not be the same case for other
> vendors.
> > Since I need to support both the use cases I have differentiated them using
>
On Wed, 2018-07-25 at 21:05 -0600, Jason Gunthorpe wrote:
> On Thu, Jul 26, 2018 at 10:55:53AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the rdma tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > net/sunrpc/xprtrdma/svc_rdma_rw.c:
On Wed, 2018-07-25 at 21:05 -0600, Jason Gunthorpe wrote:
> On Thu, Jul 26, 2018 at 10:55:53AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the rdma tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > net/sunrpc/xprtrdma/svc_rdma_rw.c:
On 07/25/2018 09:47 PM, Srinath Mannam wrote:
Hi Guenter,
It was my mistake sorry for that. I thought to add as Rivewed-by your name..
Many changes are made based on your review comments and suggestions.
So, Can I add your name in Reviewed list?
You did that already below, and I am ok with
On 07/25/2018 09:47 PM, Srinath Mannam wrote:
Hi Guenter,
It was my mistake sorry for that. I thought to add as Rivewed-by your name..
Many changes are made based on your review comments and suggestions.
So, Can I add your name in Reviewed list?
You did that already below, and I am ok with
Add entry for Actions Semi Owl SoCs DMA driver under ARM/ACTIONS.
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 09b54e9ebc6f..56d9c7715c2a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1145,12 +1145,14
Add entry for Actions Semi Owl SoCs DMA driver under ARM/ACTIONS.
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 09b54e9ebc6f..56d9c7715c2a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1145,12 +1145,14
This patchset adds DMA controller support for Actions Semi Owl family
S900 SoC. This driver has been structured in a way such that there will be only
one controller driver for the whole Owl family series (S500, S700 and
S900 SoCs).
There are 12 physical channels and 46 logical channels supported
Add Actions Semi Owl family S900 DMA driver.
Signed-off-by: Manivannan Sadhasivam
---
drivers/dma/Kconfig | 8 +
drivers/dma/Makefile | 1 +
drivers/dma/owl-dma.c | 971 ++
3 files changed, 980 insertions(+)
create mode 100644
This patchset adds DMA controller support for Actions Semi Owl family
S900 SoC. This driver has been structured in a way such that there will be only
one controller driver for the whole Owl family series (S500, S700 and
S900 SoCs).
There are 12 physical channels and 46 logical channels supported
Add Actions Semi Owl family S900 DMA driver.
Signed-off-by: Manivannan Sadhasivam
---
drivers/dma/Kconfig | 8 +
drivers/dma/Makefile | 1 +
drivers/dma/owl-dma.c | 971 ++
3 files changed, 980 insertions(+)
create mode 100644
Add devicetree binding for Actions Semi Owl SoCs DMA controller.
Signed-off-by: Manivannan Sadhasivam
---
.../devicetree/bindings/dma/owl-dma.txt | 47 +++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
diff --git
Add DMA controller node for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index
Add devicetree binding for Actions Semi Owl SoCs DMA controller.
Signed-off-by: Manivannan Sadhasivam
---
.../devicetree/bindings/dma/owl-dma.txt | 47 +++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
diff --git
Add DMA controller node for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index
Hi Ulf Hansson,
Kindly review this patch.
Thank you,
Regards,
Srinath.
On Tue, Jul 17, 2018 at 10:15 PM, Srinath Mannam
wrote:
> Add ACPI support to all IPROC SDHCI varients
>
> Signed-off-by: Srinath Mannam
> Reviewed-by: Ray Jui
> Reviewed-by: Scott Branden
> Reviewed-by: Vladimir
Hi Ulf Hansson,
Kindly review this patch.
Thank you,
Regards,
Srinath.
On Tue, Jul 17, 2018 at 10:15 PM, Srinath Mannam
wrote:
> Add ACPI support to all IPROC SDHCI varients
>
> Signed-off-by: Srinath Mannam
> Reviewed-by: Ray Jui
> Reviewed-by: Scott Branden
> Reviewed-by: Vladimir
Use clock-frequency property given in _DSD object
of ACPI device to calculate Watchdog rate as binding
clock devices are not available as device tree.
Note: There is no formal review process for _DSD
properties
Signed-off-by: Srinath Mannam
Reviewed-by: Guenter Roeck
Reviewed-by: Ray Jui
Use clock-frequency property given in _DSD object
of ACPI device to calculate Watchdog rate as binding
clock devices are not available as device tree.
Note: There is no formal review process for _DSD
properties
Signed-off-by: Srinath Mannam
Reviewed-by: Guenter Roeck
Reviewed-by: Ray Jui
On 07/26/2018 06:36 AM, Santosh Shilimkar wrote:
On 7/25/2018 3:20 PM, Anders Roxell wrote:
Build error, implicit declaration of function __inet6_ehashfn shows up
When RDS is enabled but not IPV6.
net/rds/connection.c: In function ‘rds_conn_bucket’:
net/rds/connection.c:67:9: error: implicit
On 07/26/2018 06:36 AM, Santosh Shilimkar wrote:
On 7/25/2018 3:20 PM, Anders Roxell wrote:
Build error, implicit declaration of function __inet6_ehashfn shows up
When RDS is enabled but not IPV6.
net/rds/connection.c: In function ‘rds_conn_bucket’:
net/rds/connection.c:67:9: error: implicit
Hi all,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/nvme/target/rdma.c: In function 'nvmet_rdma_find_get_device':
drivers/nvme/target/rdma.c:894:26: error: 'struct ib_device_attr' has no member
named 'max_sge'; did you mean 'max_cqe'?
Hi all,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/nvme/target/rdma.c: In function 'nvmet_rdma_find_get_device':
drivers/nvme/target/rdma.c:894:26: error: 'struct ib_device_attr' has no member
named 'max_sge'; did you mean 'max_cqe'?
Hi Vinod,
On Tue, Jul 24, 2018 at 06:39:43PM +0530, Vinod wrote:
> somehow this got stuck so sending again...
>
> On 24-07-18, 18:16, Vinod wrote:
> > On 23-07-18, 09:47, Manivannan Sadhasivam wrote:
> >
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > >
Hi Vinod,
On Tue, Jul 24, 2018 at 06:39:43PM +0530, Vinod wrote:
> somehow this got stuck so sending again...
>
> On 24-07-18, 18:16, Vinod wrote:
> > On 23-07-18, 09:47, Manivannan Sadhasivam wrote:
> >
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > >
Hi Guenter,
It was my mistake sorry for that. I thought to add as Rivewed-by your name..
Many changes are made based on your review comments and suggestions.
So, Can I add your name in Reviewed list?
I will modify and send next patchset.
thank you.
Regards,
Srinath.
On Thu, Jul 26, 2018 at
Hi Guenter,
It was my mistake sorry for that. I thought to add as Rivewed-by your name..
Many changes are made based on your review comments and suggestions.
So, Can I add your name in Reviewed list?
I will modify and send next patchset.
thank you.
Regards,
Srinath.
On Thu, Jul 26, 2018 at
On 07/23/2018 01:37 AM, Srinath Mannam wrote:
Use clock-frequency property given in _DSD object
of ACPI device to calculate Watchdog rate as binding
clock devices are not available as device tree.
Note: There is no formal review process for _DSD
properties
Signed-off-by: Srinath Mannam
On 07/23/2018 01:37 AM, Srinath Mannam wrote:
Use clock-frequency property given in _DSD object
of ACPI device to calculate Watchdog rate as binding
clock devices are not available as device tree.
Note: There is no formal review process for _DSD
properties
Signed-off-by: Srinath Mannam
On Wed, Jul 25, 2018 at 08:44:57PM -0500, Richard Kuo wrote:
> On Wed, Jul 25, 2018 at 08:29:54AM +0300, Mike Rapoport wrote:
> > This patch adds registration of the system memory with memblock, eliminates
> > bootmem initialization and converts early memory reservations from bootmem
> > to
On Wed, Jul 25, 2018 at 08:44:57PM -0500, Richard Kuo wrote:
> On Wed, Jul 25, 2018 at 08:29:54AM +0300, Mike Rapoport wrote:
> > This patch adds registration of the system memory with memblock, eliminates
> > bootmem initialization and converts early memory reservations from bootmem
> > to
Update the 98dx3236 SoC and dependent boards to use
"nand-controller" instead of "nand".
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-db-dxbc2.dts | 2 +-
arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 2 +-
3 files
Update the 98dx3236 SoC and dependent boards to use
"nand-controller" instead of "nand".
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-db-dxbc2.dts | 2 +-
arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 2 +-
3 files
Update the nand flash binding to the new style.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-db-dxbc2.dts | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
b/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
Update the nand flash binding to the new style.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
This board is a plugin card for some of Marvell's switch development
kits. It's similar to the non-amc board except that it has no SATA
support.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/armada-385-db-88f6820-amc.dts| 147
This series updates the armada-xp-98dx3236 SoC and related boards to use the
new style dts bindings for nand.
I've also added a new db-88f6820-amc board which is an Armada-385 based
reference board from Marvell's switch team. It's a plugin card for either the
db-dxbc2 or db-xc3-24g4 which can be
Update the nand flash binding to the new style.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-db-dxbc2.dts | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
b/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
Update the nand flash binding to the new style.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
This board is a plugin card for some of Marvell's switch development
kits. It's similar to the non-amc board except that it has no SATA
support.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/armada-385-db-88f6820-amc.dts| 147
This series updates the armada-xp-98dx3236 SoC and related boards to use the
new style dts bindings for nand.
I've also added a new db-88f6820-amc board which is an Armada-385 based
reference board from Marvell's switch team. It's a plugin card for either the
db-dxbc2 or db-xc3-24g4 which can be
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/nvme/target/rdma.c
between commit:
23f96d1f15a7 ("nvmet-rdma: Simplify ib_post_(send|recv|srq_recv)() calls")
202093848cac ("nvmet-rdma: add an error flow for post_recv failures")
from the rdma tree and
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/nvme/target/rdma.c
between commit:
23f96d1f15a7 ("nvmet-rdma: Simplify ib_post_(send|recv|srq_recv)() calls")
202093848cac ("nvmet-rdma: add an error flow for post_recv failures")
from the rdma tree and
We need to maintain backwards compatibility with device trees that don't
define an enable method. At the same time we want the device tree to be
able to specify an enable-method and have it stick.
Previously by having smp assigned in the DT_MACHINE definition this
would be picked up by
We need to maintain backwards compatibility with device trees that don't
define an enable method. At the same time we want the device tree to be
able to specify an enable-method and have it stick.
Previously by having smp assigned in the DT_MACHINE definition this
would be picked up by
On Mon, 2018-07-23 at 09:29 +0200, Joerg Roedel wrote:
> Hey David,
>
> On Sun, Jul 22, 2018 at 11:49:00PM -0400, David H. Gutteridge wrote:
> > Unfortunately, I can trigger a bug in KVM+QEMU with the Bochs VGA
> > driver. (This is the same VM definition I shared with you in a PM
> > back on Feb.
On Mon, 2018-07-23 at 09:29 +0200, Joerg Roedel wrote:
> Hey David,
>
> On Sun, Jul 22, 2018 at 11:49:00PM -0400, David H. Gutteridge wrote:
> > Unfortunately, I can trigger a bug in KVM+QEMU with the Bochs VGA
> > driver. (This is the same VM definition I shared with you in a PM
> > back on Feb.
Hi Rafael,
> On 2018Jul24, at 18:36, Rafael J. Wysocki wrote:
>
> On Tuesday, July 24, 2018 11:13:42 AM CEST Rafael J. Wysocki wrote:
>> On Tuesday, July 24, 2018 10:46:09 AM CEST Kai Heng Feng wrote:
>>> Hi Rafael,
>>>
On Jun 13, 2018, at 7:17 PM, Rafael J. Wysocki wrote:
Hi Rafael,
> On 2018Jul24, at 18:36, Rafael J. Wysocki wrote:
>
> On Tuesday, July 24, 2018 11:13:42 AM CEST Rafael J. Wysocki wrote:
>> On Tuesday, July 24, 2018 10:46:09 AM CEST Kai Heng Feng wrote:
>>> Hi Rafael,
>>>
On Jun 13, 2018, at 7:17 PM, Rafael J. Wysocki wrote:
On Wed, Jul 25, 2018 at 4:54 PM, Christoph Hellwig wrote:
> On Wed, Jul 25, 2018 at 12:18:39PM +0100, Marc Zyngier wrote:
>> This feels odd. It means that you cannot have the following sequence:
>>
>> local_irq_disable();
>> enable_irq(x); // where x is owned by a remote hart
>>
>> as
On Wed, Jul 25, 2018 at 4:54 PM, Christoph Hellwig wrote:
> On Wed, Jul 25, 2018 at 12:18:39PM +0100, Marc Zyngier wrote:
>> This feels odd. It means that you cannot have the following sequence:
>>
>> local_irq_disable();
>> enable_irq(x); // where x is owned by a remote hart
>>
>> as
On Wed, 25 Jul 2018 17:47:49 +0800 Jisheng Zhang wrote:
> When using DMA, if the DMA addr spans 128MB boundary, we have to split
> the DMA transfer into two so that each one doesn't exceed the boundary.
>
> Signed-off-by: Jisheng Zhang
> ---
> drivers/mmc/host/sdhci-of-dwcmshc.c | 41
On Wed, 25 Jul 2018 17:47:49 +0800 Jisheng Zhang wrote:
> When using DMA, if the DMA addr spans 128MB boundary, we have to split
> the DMA transfer into two so that each one doesn't exceed the boundary.
>
> Signed-off-by: Jisheng Zhang
> ---
> drivers/mmc/host/sdhci-of-dwcmshc.c | 41
Hi Vincent,
On Fri, 29 Jun 2018 at 03:07, Vincent Guittot
wrote:
>
> interrupt and steal time are the only remaining activities tracked by
> rt_avg. Like for sched classes, we can use PELT to track their average
> utilization of the CPU. But unlike sched class, we don't track when
>
Hi Vincent,
On Fri, 29 Jun 2018 at 03:07, Vincent Guittot
wrote:
>
> interrupt and steal time are the only remaining activities tracked by
> rt_avg. Like for sched classes, we can use PELT to track their average
> utilization of the CPU. But unlike sched class, we don't track when
>
On Thu, Jul 26, 2018 at 10:55:53AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the rdma tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> net/sunrpc/xprtrdma/svc_rdma_rw.c: In function 'svc_rdma_post_chunk_ctxt':
>
On Thu, Jul 26, 2018 at 10:55:53AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the rdma tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> net/sunrpc/xprtrdma/svc_rdma_rw.c: In function 'svc_rdma_post_chunk_ctxt':
>
Potential patches should have a commit description.
Emit a warning when there isn't one.
Suggested-by: Prakruthi Deepak Heragu
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 13 +
1 file changed, 13 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
Potential patches should have a commit description.
Emit a warning when there isn't one.
Suggested-by: Prakruthi Deepak Heragu
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 13 +
1 file changed, 13 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_probe':
sound/soc/amd/acp-da7219-max98357a.c:367:3: warning: 'ret' may be used
uninitialized in this function
Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_probe':
sound/soc/amd/acp-da7219-max98357a.c:367:3: warning: 'ret' may be used
uninitialized in this function
On Tue, 2018-07-10 at 20:24 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Richard Weinberger
>
> commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.
>
> Fastmap cannot track the LEB unmap
On Tue, 2018-07-10 at 20:24 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Richard Weinberger
>
> commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.
>
> Fastmap cannot track the LEB unmap
Hi Tino,
On Wed, Jul 25, 2018 at 05:12:13PM +0200, Tino Lehnig wrote:
> Hi,
>
> On 07/25/2018 03:21 PM, Minchan Kim wrote:
> > It would be much helpful if you could check more versions with git-bisect.
>
> I started bisecting today, but my results are not conclusive yet. It is
> certain that
Hi Tino,
On Wed, Jul 25, 2018 at 05:12:13PM +0200, Tino Lehnig wrote:
> Hi,
>
> On 07/25/2018 03:21 PM, Minchan Kim wrote:
> > It would be much helpful if you could check more versions with git-bisect.
>
> I started bisecting today, but my results are not conclusive yet. It is
> certain that
Hi Stephen,
Do you have a chance to look at it?
This patch series has been pending for quite a long time without much comments.
Regards
Dong Aisheng
> -Original Message-
> From: A.s. Dong
> Sent: Wednesday, July 18, 2018 9:37 PM
> To: linux-...@vger.kernel.org
> Cc:
Hi Stephen,
Do you have a chance to look at it?
This patch series has been pending for quite a long time without much comments.
Regards
Dong Aisheng
> -Original Message-
> From: A.s. Dong
> Sent: Wednesday, July 18, 2018 9:37 PM
> To: linux-...@vger.kernel.org
> Cc:
On Wed, Jul 25, 2018 at 08:29:54AM +0300, Mike Rapoport wrote:
> This patch adds registration of the system memory with memblock, eliminates
> bootmem initialization and converts early memory reservations from bootmem
> to memblock.
>
> Signed-off-by: Mike Rapoport
> ---
> v2: fix calculation of
On Wed, Jul 25, 2018 at 08:29:54AM +0300, Mike Rapoport wrote:
> This patch adds registration of the system memory with memblock, eliminates
> bootmem initialization and converts early memory reservations from bootmem
> to memblock.
>
> Signed-off-by: Mike Rapoport
> ---
> v2: fix calculation of
On Wed, 2018-07-25 at 16:14 -0700, Prakruthi Deepak Heragu wrote:
> The #if 0 or #if 1 is used to toggle features. Warn if #if 0 or #if 1
> is present and suggest that they can be removed.
>
> Signed-off-by: Abhijeet Dharmapurikar
> Signed-off-by: Prakruthi Deepak Heragu
> ---
> Changes in v1:
On Wed, 2018-07-25 at 16:14 -0700, Prakruthi Deepak Heragu wrote:
> The #if 0 or #if 1 is used to toggle features. Warn if #if 0 or #if 1
> is present and suggest that they can be removed.
>
> Signed-off-by: Abhijeet Dharmapurikar
> Signed-off-by: Prakruthi Deepak Heragu
> ---
> Changes in v1:
On Wed, 2018-07-25 at 08:48 -0700, Casey Schaufler wrote:
> On 7/24/2018 10:39 PM, Ian Kent wrote:
> > On Tue, 2018-07-24 at 11:57 -0700, Casey Schaufler wrote:
> > > On 7/24/2018 9:00 AM, David Howells wrote:
> > > > Casey Schaufler wrote:
> > > >
> > > > > > (1) Mount topology and
On Wed, 2018-07-25 at 08:48 -0700, Casey Schaufler wrote:
> On 7/24/2018 10:39 PM, Ian Kent wrote:
> > On Tue, 2018-07-24 at 11:57 -0700, Casey Schaufler wrote:
> > > On 7/24/2018 9:00 AM, David Howells wrote:
> > > > Casey Schaufler wrote:
> > > >
> > > > > > (1) Mount topology and
On Thu, 26 Jul 2018 09:41:06 +0900
Masami Hiramatsu wrote:
> On Fri, 13 Jul 2018 08:18:03 -0400
> Steven Rostedt wrote:
>
> > On Fri, 13 Jul 2018 11:53:01 +0900
> > Masami Hiramatsu wrote:
> >
> > > On Thu, 12 Jul 2018 13:54:12 -0400
> > > Francis Deslauriers wrote:
> > >
> > > > From:
On Thu, 26 Jul 2018 09:41:06 +0900
Masami Hiramatsu wrote:
> On Fri, 13 Jul 2018 08:18:03 -0400
> Steven Rostedt wrote:
>
> > On Fri, 13 Jul 2018 11:53:01 +0900
> > Masami Hiramatsu wrote:
> >
> > > On Thu, 12 Jul 2018 13:54:12 -0400
> > > Francis Deslauriers wrote:
> > >
> > > > From:
Hi Doug,
On Wed, Jul 25, 2018 at 04:19:56PM -0700, Doug Anderson wrote:
> On Tue, Jul 24, 2018 at 4:46 PM, Matthias Kaehlcke wrote:
> > +static int qpnp_tm_update_critical_trip_temp(struct qpnp_tm_chip *chip,
> > +int temp)
> > +{
> > + u8 reg;
Hi Doug,
On Wed, Jul 25, 2018 at 04:19:56PM -0700, Doug Anderson wrote:
> On Tue, Jul 24, 2018 at 4:46 PM, Matthias Kaehlcke wrote:
> > +static int qpnp_tm_update_critical_trip_temp(struct qpnp_tm_chip *chip,
> > +int temp)
> > +{
> > + u8 reg;
On 7/25/18 1:15 AM, Johannes Weiner wrote:
> Hi Balbir,
>
> On Tue, Jul 24, 2018 at 07:14:02AM +1000, Balbir Singh wrote:
>> Does the mechanism scale? I am a little concerned about how frequently
>> this infrastructure is monitored/read/acted upon.
>
> I expect most users to poll in the
On 7/25/18 1:15 AM, Johannes Weiner wrote:
> Hi Balbir,
>
> On Tue, Jul 24, 2018 at 07:14:02AM +1000, Balbir Singh wrote:
>> Does the mechanism scale? I am a little concerned about how frequently
>> this infrastructure is monitored/read/acted upon.
>
> I expect most users to poll in the
1 - 100 of 1900 matches
Mail list logo
