Hi Vincent,
On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> The problem with reflecting directly the capping is that it happens
> far more often than the pace at which cpu_capacity_orig is updated in
> the scheduler.
Hmm, how can you be so sure ? That most likely depends
Hi Vincent,
On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> The problem with reflecting directly the capping is that it happens
> far more often than the pace at which cpu_capacity_orig is updated in
> the scheduler.
Hmm, how can you be so sure ? That most likely depends
On 2018-10-10 11:45:32 [+0200], Dmitry Vyukov wrote:
> > Should I repost Clark's patch?
>
>
> I am much more comfortable with just changing the type of the lock.
Yes, that is what Clark's patch does. Should I resent it?
> What are the bad implications of using the raw spinlock? Will it help
>
On 2018-10-10 11:45:32 [+0200], Dmitry Vyukov wrote:
> > Should I repost Clark's patch?
>
>
> I am much more comfortable with just changing the type of the lock.
Yes, that is what Clark's patch does. Should I resent it?
> What are the bad implications of using the raw spinlock? Will it help
>
Commit-ID: d59e0ba19481c0046d2ea2bd0e5344eeaf45aace
Gitweb: https://git.kernel.org/tip/d59e0ba19481c0046d2ea2bd0e5344eeaf45aace
Author: Peng Hao
AuthorDate: Tue, 9 Oct 2018 11:43:35 -0400
Committer: Thomas Gleixner
CommitDate: Wed, 10 Oct 2018 11:47:20 +0200
tick/sched : Remove
Commit-ID: d59e0ba19481c0046d2ea2bd0e5344eeaf45aace
Gitweb: https://git.kernel.org/tip/d59e0ba19481c0046d2ea2bd0e5344eeaf45aace
Author: Peng Hao
AuthorDate: Tue, 9 Oct 2018 11:43:35 -0400
Committer: Thomas Gleixner
CommitDate: Wed, 10 Oct 2018 11:47:20 +0200
tick/sched : Remove
On Wed, Oct 10, 2018 at 11:29 AM, Sebastian Andrzej Siewior
wrote:
> On 2018-10-10 10:25:42 [+0200], Dmitry Vyukov wrote:
>> > That loop should behave like your on_each_cpu() except it does not
>> > involve the remote CPU.
>>
>>
>> The problem is that it can squeeze in between:
>>
>> +
On Wed, Oct 10, 2018 at 11:29 AM, Sebastian Andrzej Siewior
wrote:
> On 2018-10-10 10:25:42 [+0200], Dmitry Vyukov wrote:
>> > That loop should behave like your on_each_cpu() except it does not
>> > involve the remote CPU.
>>
>>
>> The problem is that it can squeeze in between:
>>
>> +
On Wed 10-10-18 08:39:22, Anshuman Khandual wrote:
[...]
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 9df1d59..4bcbf1e 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -504,6 +504,16 @@ static inline bool hugepage_migration_supported(struct
>
On Tue, Oct 02, 2018 at 10:38:20AM -0400, Masayoshi Mizuma wrote:
> From: Pavel Tatashin
>
> When checking for valid pfns in zero_resv_unavail(), it is not necessary to
> verify that pfns within pageblock_nr_pages ranges are valid, only the first
> one needs to be checked. This is because memory
On Tue, Oct 9, 2018 at 1:20 PM Rasmus Villemoes
wrote:
>
> If CONFIG_DYNAMIC_DEBUG is not set, acpi_handle_debug directly invokes
> acpi_handle_printk (if DEBUG) or does a no-printk (if !DEBUG). So this
> macro is never used.
>
> Cc: linux-a...@vger.kernel.org
> Acked-by: Jason Baron
>
On Wed 10-10-18 08:39:22, Anshuman Khandual wrote:
[...]
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 9df1d59..4bcbf1e 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -504,6 +504,16 @@ static inline bool hugepage_migration_supported(struct
>
On Tue, Oct 02, 2018 at 10:38:20AM -0400, Masayoshi Mizuma wrote:
> From: Pavel Tatashin
>
> When checking for valid pfns in zero_resv_unavail(), it is not necessary to
> verify that pfns within pageblock_nr_pages ranges are valid, only the first
> one needs to be checked. This is because memory
On Tue, Oct 9, 2018 at 1:20 PM Rasmus Villemoes
wrote:
>
> If CONFIG_DYNAMIC_DEBUG is not set, acpi_handle_debug directly invokes
> acpi_handle_printk (if DEBUG) or does a no-printk (if !DEBUG). So this
> macro is never used.
>
> Cc: linux-a...@vger.kernel.org
> Acked-by: Jason Baron
>
On Tue, Oct 9, 2018 at 1:21 PM Rasmus Villemoes
wrote:
>
> dynamic debug may be implemented via static keys, but ACPI is missing
> out on that runtime benefit since it open-codes one possible definition
> of DYNAMIC_DEBUG_BRANCH.
>
> Cc: linux-a...@vger.kernel.org
> Acked-by: Jason Baron
>
On Tue, Oct 9, 2018 at 1:21 PM Rasmus Villemoes
wrote:
>
> dynamic debug may be implemented via static keys, but ACPI is missing
> out on that runtime benefit since it open-codes one possible definition
> of DYNAMIC_DEBUG_BRANCH.
>
> Cc: linux-a...@vger.kernel.org
> Acked-by: Jason Baron
>
Output of the PWM block on i.MX SoCs is always low when the block is
disabled. This can cause issues when inverted PWM polarity is needed.
With inverted polarity a duty cycle = 0% corresponds to high level on
the output. Now, when PWM is disabled its output instantly goes low
which corresponds to
Normally the PWM output is held LOW when PWM is disabled. This can cause
problems when inverted PWM signal polarity is needed. With this behavior
the connected circuit is fed by 100% duty cycle instead of being shut-off.
Allow users to define a "gpio" and a "pwm" pinctrl states. The pwm pinctrl
Output of the PWM block on i.MX SoCs is always low when the block is
disabled. This can cause issues when inverted PWM polarity is needed.
With inverted polarity a duty cycle = 0% corresponds to high level on
the output. Now, when PWM is disabled its output instantly goes low
which corresponds to
Normally the PWM output is held LOW when PWM is disabled. This can cause
problems when inverted PWM signal polarity is needed. With this behavior
the connected circuit is fed by 100% duty cycle instead of being shut-off.
Allow users to define a "gpio" and a "pwm" pinctrl states. The pwm pinctrl
On Wed, Oct 10, 2018 at 11:13 AM, Michal Hocko wrote:
> On Wed 10-10-18 09:55:57, Dmitry Vyukov wrote:
>> On Wed, Oct 10, 2018 at 6:11 AM, 'David Rientjes' via syzkaller-bugs
>> wrote:
>> > On Wed, 10 Oct 2018, Tetsuo Handa wrote:
>> >
>> >> syzbot is hitting RCU stall due to memcg-OOM event.
>>
This is an attempt to deal with i.MX SoC PWM HW limitation.
When a pad is configured as a PWM output the output level is always 0V
if the PWM block is disabled. This can cause problems when inverted PWM
signal is needed to drive the connected circuit. With inverted output
duty cycle = 0%
On Wed, Oct 10, 2018 at 11:13 AM, Michal Hocko wrote:
> On Wed 10-10-18 09:55:57, Dmitry Vyukov wrote:
>> On Wed, Oct 10, 2018 at 6:11 AM, 'David Rientjes' via syzkaller-bugs
>> wrote:
>> > On Wed, 10 Oct 2018, Tetsuo Handa wrote:
>> >
>> >> syzbot is hitting RCU stall due to memcg-OOM event.
>>
This is an attempt to deal with i.MX SoC PWM HW limitation.
When a pad is configured as a PWM output the output level is always 0V
if the PWM block is disabled. This can cause problems when inverted PWM
signal is needed to drive the connected circuit. With inverted output
duty cycle = 0%
On 2018-10-10 10:25:42 [+0200], Dmitry Vyukov wrote:
> > That loop should behave like your on_each_cpu() except it does not
> > involve the remote CPU.
>
>
> The problem is that it can squeeze in between:
>
> + spin_unlock(>lock);
>
> spin_lock(_lock);
>
> as far
On 2018-10-10 10:25:42 [+0200], Dmitry Vyukov wrote:
> > That loop should behave like your on_each_cpu() except it does not
> > involve the remote CPU.
>
>
> The problem is that it can squeeze in between:
>
> + spin_unlock(>lock);
>
> spin_lock(_lock);
>
> as far
On Wed, Oct 10, 2018 at 06:45:17AM +, Chunhui Li (李春辉) wrote:
> Hi Mark,
>
> kasan detect out-of-bounds in stacktrace.c line 70, it's already over
> READ_ONCE_NOCHECK, but still crash
> kernel-4.9/arch/arm64/kernel/stacktrace.c
> 69frame->sp = fp + 0x10;
> 70frame->fp =
On Wed, Oct 10, 2018 at 06:45:17AM +, Chunhui Li (李春辉) wrote:
> Hi Mark,
>
> kasan detect out-of-bounds in stacktrace.c line 70, it's already over
> READ_ONCE_NOCHECK, but still crash
> kernel-4.9/arch/arm64/kernel/stacktrace.c
> 69frame->sp = fp + 0x10;
> 70frame->fp =
On Tue, 9 Oct 2018 at 17:34, Lukasz Luba wrote:
>
> PROVE_LOCKING enables LOCKDEP, which causes big overhead on cache and
> bus transactions.
>
> On some ARM big.LITTLE architecutres (Exynos 5433) the overhead is really big.
> The overhead can be measures using hackbench test which will speed up
On Tue, 9 Oct 2018 at 17:34, Lukasz Luba wrote:
>
> PROVE_LOCKING enables LOCKDEP, which causes big overhead on cache and
> bus transactions.
>
> On some ARM big.LITTLE architecutres (Exynos 5433) the overhead is really big.
> The overhead can be measures using hackbench test which will speed up
From: Jiada Wang
Currently ssi driver only requests dma channel for SSI_0, with
naming of 'rxu/txu', which is used to transfer data to/from busif0.
But for GEN2/GEN3, there are also busif1 ~ busif7, which need to
be used when SSI works in TDM Split/Ex-Split mode.
This patch adds support to
From: Jiada Wang
Currently ssi driver only requests dma channel for SSI_0, with
naming of 'rxu/txu', which is used to transfer data to/from busif0.
But for GEN2/GEN3, there are also busif1 ~ busif7, which need to
be used when SSI works in TDM Split/Ex-Split mode.
This patch adds support to
On Tue, Oct 09, 2018 at 03:28:15PM -0700, Dennis Zhou wrote:
> Hi Greg,
>
> The new percpu allocator introduced in 4.14 had a missing free for the
> percpu metadata. This caused a memory leak when percpu memory is being
> churned resulting in the allocation and deallocation of percpu memory
>
On Tue, Oct 09, 2018 at 09:23:18PM -0700, Benson Leung wrote:
> Hi Greg,
>
> Sorry for the late in the cycle request, but this one is fairly urgent.
>
> Please pull thi fix to chrome platform. A patch that landed
> for 4.19 broke cros_ec based chromebooks' keyboards, and this fixes them.
>
>
On Tue, Oct 09, 2018 at 03:28:15PM -0700, Dennis Zhou wrote:
> Hi Greg,
>
> The new percpu allocator introduced in 4.14 had a missing free for the
> percpu metadata. This caused a memory leak when percpu memory is being
> churned resulting in the allocation and deallocation of percpu memory
>
On Tue, Oct 09, 2018 at 09:23:18PM -0700, Benson Leung wrote:
> Hi Greg,
>
> Sorry for the late in the cycle request, but this one is fairly urgent.
>
> Please pull thi fix to chrome platform. A patch that landed
> for 4.19 broke cros_ec based chromebooks' keyboards, and this fixes them.
>
>
On Wed 10-10-18 09:55:57, Dmitry Vyukov wrote:
> On Wed, Oct 10, 2018 at 6:11 AM, 'David Rientjes' via syzkaller-bugs
> wrote:
> > On Wed, 10 Oct 2018, Tetsuo Handa wrote:
> >
> >> syzbot is hitting RCU stall due to memcg-OOM event.
> >>
On Wed 10-10-18 09:55:57, Dmitry Vyukov wrote:
> On Wed, Oct 10, 2018 at 6:11 AM, 'David Rientjes' via syzkaller-bugs
> wrote:
> > On Wed, 10 Oct 2018, Tetsuo Handa wrote:
> >
> >> syzbot is hitting RCU stall due to memcg-OOM event.
> >>
diff --git a/Makefile b/Makefile
index cc0e65a8d7bf..7fc373c011c0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 74
+SUBLEVEL = 75
EXTRAVERSION =
NAME = Petit Gorille
diff --git a/arch/arc/include/asm/atomic.h
I'm announcing the release of the 4.18.13 kernel.
All users of the 4.18 kernel series must upgrade.
The updated 4.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.18.y
and can be browsed at the normal kernel.org git web
diff --git a/Makefile b/Makefile
index cc0e65a8d7bf..7fc373c011c0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 74
+SUBLEVEL = 75
EXTRAVERSION =
NAME = Petit Gorille
diff --git a/arch/arc/include/asm/atomic.h
I'm announcing the release of the 4.18.13 kernel.
All users of the 4.18 kernel series must upgrade.
The updated 4.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.18.y
and can be browsed at the normal kernel.org git web
diff --git a/Makefile b/Makefile
index 73c4e9a8c127..a46c9788ca67 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 131
+SUBLEVEL = 132
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
I'm announcing the release of the 4.9.132 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 4.9.132 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Makefile b/Makefile
index 73c4e9a8c127..a46c9788ca67 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 131
+SUBLEVEL = 132
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
I'm announcing the release of the 4.14.75 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.14.y
and can be browsed at the normal kernel.org git web
I'm announcing the release of the 4.14.75 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.14.y
and can be browsed at the normal kernel.org git web
diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index cfd31d94c872..f8bf14055c2f 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -32,7 +32,7 @@ Supported chips:
Datasheet: Publicly available at the Texas Instruments website
diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index cfd31d94c872..f8bf14055c2f 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -32,7 +32,7 @@ Supported chips:
Datasheet: Publicly available at the Texas Instruments website
I'm announcing the release of the 4.4.160 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 4.4.160 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
On Thu, Oct 4, 2018 at 1:40 PM wrote:
> From: Sean Wang
>
> Add all source files under drivers/pinctrl/mediatek for the entry and
> change the address to a permanent one since I have a personal leave
> over the next few months and the address would be suspended for a while.
>
> Cc: Linus
On Thu, Oct 4, 2018 at 1:40 PM wrote:
> From: Sean Wang
>
> Add all source files under drivers/pinctrl/mediatek for the entry and
> change the address to a permanent one since I have a personal leave
> over the next few months and the address would be suspended for a while.
>
> Cc: Linus
On Tue 09-10-18 21:11:48, David Rientjes wrote:
> On Wed, 10 Oct 2018, Tetsuo Handa wrote:
>
> > syzbot is hitting RCU stall due to memcg-OOM event.
> > https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
> >
> > What should we do if memcg-OOM found no killable task
On Tue 09-10-18 21:11:48, David Rientjes wrote:
> On Wed, 10 Oct 2018, Tetsuo Handa wrote:
>
> > syzbot is hitting RCU stall due to memcg-OOM event.
> > https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
> >
> > What should we do if memcg-OOM found no killable task
From: Huibin Hong
The rxconf and txconf structs are allocated on the
stack, so make sure we zero them before filling out
the relevant fields.
Signed-off-by: Huibin Hong
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Hi all,
The first three patches in this series enable spi dma on rk3399,
while the remaining patches are meant to be decreasingly obvious
cleanups to the rockchip spi driver.
Unfortunately I only have rk3399-gru-kevin hardware to test
this on, so it would be nice if someone would test this on
From: Huibin Hong
The rxconf and txconf structs are allocated on the
stack, so make sure we zero them before filling out
the relevant fields.
Signed-off-by: Huibin Hong
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Hi all,
The first three patches in this series enable spi dma on rk3399,
while the remaining patches are meant to be decreasingly obvious
cleanups to the rockchip spi driver.
Unfortunately I only have rk3399-gru-kevin hardware to test
this on, so it would be nice if someone would test this on
Add spi dma channels as specified by the rk3399 TRM.
Signed-off-by: Emil Renner Berthing
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index
The driver data has a u32 field use_dma which is
only ever used as a boolean, so change its type
to reflect that.
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-rockchip.c
Let the dma/non-dma code paths handle the spi enable
flag themselves. This removes some logic to determine
if the flag should be turned on before or after dma
and also don't leave the spi enabled if the dma path
fails.
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 28
The dma direction for the tx and rx dma channels never
change, so just use the constants directly rather
than storing them in device data.
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git
We no longer need the dma_caps since the dma driver
already clamps the burst length to the hardware limit,
so don't request and store dma_caps in device data.
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 2 --
1 file changed, 2 deletions(-)
diff --git
From: Huibin Hong
Signal tx dma when spi fifo is less than half full,
and limit tx bursts to half the fifo length.
Clamp rx burst length to 1 to avoid alignment issues.
Signed-off-by: Huibin Hong
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 12 +++-
1 file
Add spi dma channels as specified by the rk3399 TRM.
Signed-off-by: Emil Renner Berthing
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index
The driver data has a u32 field use_dma which is
only ever used as a boolean, so change its type
to reflect that.
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-rockchip.c
Let the dma/non-dma code paths handle the spi enable
flag themselves. This removes some logic to determine
if the flag should be turned on before or after dma
and also don't leave the spi enabled if the dma path
fails.
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 28
The dma direction for the tx and rx dma channels never
change, so just use the constants directly rather
than storing them in device data.
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git
We no longer need the dma_caps since the dma driver
already clamps the burst length to the hardware limit,
so don't request and store dma_caps in device data.
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 2 --
1 file changed, 2 deletions(-)
diff --git
From: Huibin Hong
Signal tx dma when spi fifo is less than half full,
and limit tx bursts to half the fifo length.
Clamp rx burst length to 1 to avoid alignment issues.
Signed-off-by: Huibin Hong
Signed-off-by: Emil Renner Berthing
---
drivers/spi/spi-rockchip.c | 12 +++-
1 file
On Wed 10-10-18 09:12:45, Tetsuo Handa wrote:
> syzbot is hitting RCU stall due to memcg-OOM event.
> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
This is really interesting. If we do not have any eligible oom victim we
simply force the charge (allow to proceed
On Wed 10-10-18 09:12:45, Tetsuo Handa wrote:
> syzbot is hitting RCU stall due to memcg-OOM event.
> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
This is really interesting. If we do not have any eligible oom victim we
simply force the charge (allow to proceed
On Wed, Oct 10, 2018 at 04:41:16PM +0800, Chao Fan wrote:
> ***Background:
> People reported that kaslr may randomly chooses some positions
> which are located in movable memory regions. This will break memory
> hotplug feature and make the movable memory chosen by KASLR can't be
> removed.
>
>
On 09/10/18 18:07, Lina Iyer wrote:
On Tue, Oct 02 2018 at 11:06 -0600, Lina Iyer wrote:
Marc,
I am exploring an option where we don't do this enable/disable every
suspend/resume and in that process, I was able to just use the PDC
interrupt instead of the TLMM for triggering the GPIO. The PDC
On Wed, Oct 10, 2018 at 04:41:16PM +0800, Chao Fan wrote:
> ***Background:
> People reported that kaslr may randomly chooses some positions
> which are located in movable memory regions. This will break memory
> hotplug feature and make the movable memory chosen by KASLR can't be
> removed.
>
>
On 09/10/18 18:07, Lina Iyer wrote:
On Tue, Oct 02 2018 at 11:06 -0600, Lina Iyer wrote:
Marc,
I am exploring an option where we don't do this enable/disable every
suspend/resume and in that process, I was able to just use the PDC
interrupt instead of the TLMM for triggering the GPIO. The PDC
On Tue 09-10-18 17:42:09, John Hubbard wrote:
> On 10/8/18 5:14 PM, Andrew Morton wrote:
> > Also, maintainability. What happens if someone now uses put_page() by
> > mistake? Kernel fails in some mysterious fashion? How can we prevent
> > this from occurring as code evolves? Is there a cheap
On Tue 09-10-18 17:42:09, John Hubbard wrote:
> On 10/8/18 5:14 PM, Andrew Morton wrote:
> > Also, maintainability. What happens if someone now uses put_page() by
> > mistake? Kernel fails in some mysterious fashion? How can we prevent
> > this from occurring as code evolves? Is there a cheap
Sorry, I forgot that editing r8169.c and rebuilding would result in rc7+, so I
tested the wrong kernel/module to get the
results I provided below. That, however, may make the results more interesting
because they happened with a virgin rc7
kernel/module.
I'll test your proposals properly later.
Sorry, I forgot that editing r8169.c and rebuilding would result in rc7+, so I
tested the wrong kernel/module to get the
results I provided below. That, however, may make the results more interesting
because they happened with a virgin rc7
kernel/module.
I'll test your proposals properly later.
On Wed, 10 Oct 2018 at 10:29, Quentin Perret wrote:
>
> Hi Thara,
>
> On Wednesday 10 Oct 2018 at 08:17:51 (+0200), Ingo Molnar wrote:
> >
> > * Thara Gopinath wrote:
> >
> > > Thermal governors can respond to an overheat event for a cpu by
> > > capping the cpu's maximum possible frequency.
On Wed, 10 Oct 2018 at 10:29, Quentin Perret wrote:
>
> Hi Thara,
>
> On Wednesday 10 Oct 2018 at 08:17:51 (+0200), Ingo Molnar wrote:
> >
> > * Thara Gopinath wrote:
> >
> > > Thermal governors can respond to an overheat event for a cpu by
> > > capping the cpu's maximum possible frequency.
On Tue 09-10-18 10:34:55, Dan Williams wrote:
> On Tue, Oct 9, 2018 at 4:28 AM Michal Hocko wrote:
> >
> > On Thu 04-10-18 09:44:35, Dan Williams wrote:
> > > Hi Michal,
> > >
> > > On Thu, Oct 4, 2018 at 12:53 AM Michal Hocko wrote:
> > > >
> > > > On Wed 03-10-18 19:15:18, Dan Williams wrote:
On Tue 09-10-18 10:34:55, Dan Williams wrote:
> On Tue, Oct 9, 2018 at 4:28 AM Michal Hocko wrote:
> >
> > On Thu 04-10-18 09:44:35, Dan Williams wrote:
> > > Hi Michal,
> > >
> > > On Thu, Oct 4, 2018 at 12:53 AM Michal Hocko wrote:
> > > >
> > > > On Wed 03-10-18 19:15:18, Dan Williams wrote:
> +++ b/mmc_cmds.c
> @@ -1758,8 +1758,15 @@ int do_read_extcsd(int nargs, char **argv)
> }
>
> if (ext_csd_rev >= 7) {
> - printf("eMMC Firmware Version: %s\n",
> - (char*)_csd[EXT_CSD_FIRMWARE_VERSION]);
> + printf("Firmware Version:
>
> +++ b/mmc_cmds.c
> @@ -1758,8 +1758,15 @@ int do_read_extcsd(int nargs, char **argv)
> }
>
> if (ext_csd_rev >= 7) {
> - printf("eMMC Firmware Version: %s\n",
> - (char*)_csd[EXT_CSD_FIRMWARE_VERSION]);
> + printf("Firmware Version:
>
Hi Longman,
Thanks for the patches. I have applied them and run on ARM.
In context switch test, there is ~2% improvement
(but still ~15us instead of 5-6us).
In dhrystone: test results are the same.
There is also 2% improvement in boot time.
You can add me on CC list if you have some patches
Hi Longman,
Thanks for the patches. I have applied them and run on ARM.
In context switch test, there is ~2% improvement
(but still ~15us instead of 5-6us).
In dhrystone: test results are the same.
There is also 2% improvement in boot time.
You can add me on CC list if you have some patches
Looks fine.
Thanks,
Avri
> eMMC 5.0 introduced OPTIMAL_READ_SIZE, OPTIMAL_WRITE_SIZE and
> OPTIMAL
> TRIM_UNIT_SIZE fields in the extcsd
>
> Interpret these fields when reading out the extcsd with human-readable
> results
>
> Signed-off-by: James Nuss
Reviewed-by: Avri Altman
Looks fine.
Thanks,
Avri
> eMMC 5.0 introduced OPTIMAL_READ_SIZE, OPTIMAL_WRITE_SIZE and
> OPTIMAL
> TRIM_UNIT_SIZE fields in the extcsd
>
> Interpret these fields when reading out the extcsd with human-readable
> results
>
> Signed-off-by: James Nuss
Reviewed-by: Avri Altman
max98988 only builds with I2C support enabled, otherwise we get a build error:
sound/soc/codecs/max98088.c:1789:1: error: data definition has no type or
storage class [-Werror]
module_i2c_driver(max98088_i2c_driver);
^
sound/soc/codecs/max98088.c:1789:1: error: type defaults to
max98988 only builds with I2C support enabled, otherwise we get a build error:
sound/soc/codecs/max98088.c:1789:1: error: data definition has no type or
storage class [-Werror]
module_i2c_driver(max98088_i2c_driver);
^
sound/soc/codecs/max98088.c:1789:1: error: type defaults to
Hi Gustavo,
On Wed, Oct 10, 2018 at 10:31:39AM +0200, Gustavo A. R. Silva wrote:
> In case memory resources for *fw* were successfully allocated,
> release them before return.
>
> Addresses-Coverity-ID: 1473968 ("Resource leak")
> Fixes: 00d70d8e0e78 ("net: phy: mscc: add support for VSC8574
Hi Gustavo,
On Wed, Oct 10, 2018 at 10:31:39AM +0200, Gustavo A. R. Silva wrote:
> In case memory resources for *fw* were successfully allocated,
> release them before return.
>
> Addresses-Coverity-ID: 1473968 ("Resource leak")
> Fixes: 00d70d8e0e78 ("net: phy: mscc: add support for VSC8574
On Wed, Oct 10, 2018 at 03:23:09AM +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> Short of reverting commit 00d909a107 for v4.19, target-core needs a
> wait_event_t marco can be executed using TASK_UNINTERRUPTIBLE to
> function correctly with existing fabric drivers that
On Wed, Oct 10, 2018 at 03:23:09AM +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> Short of reverting commit 00d909a107 for v4.19, target-core needs a
> wait_event_t marco can be executed using TASK_UNINTERRUPTIBLE to
> function correctly with existing fabric drivers that
In case memory resources for *fw* were successfully allocated,
release them before return.
Addresses-Coverity-ID: 1473968 ("Resource leak")
Fixes: 00d70d8e0e78 ("net: phy: mscc: add support for VSC8574 PHY")
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
- Jump to out label so all
In case memory resources for *fw* were successfully allocated,
release them before return.
Addresses-Coverity-ID: 1473968 ("Resource leak")
Fixes: 00d70d8e0e78 ("net: phy: mscc: add support for VSC8574 PHY")
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
- Jump to out label so all
1201 - 1300 of 1504 matches
Mail list logo
