On Wed, Oct 10, 2018 at 03:10:11PM +0200, Jann Horn wrote:
> On Wed, Oct 10, 2018 at 2:54 PM Christian Brauner
> wrote:
> > On Tue, Oct 09, 2018 at 06:26:47PM +0200, Jann Horn wrote:
> > > On Tue, Oct 9, 2018 at 6:20 PM Christian Brauner
> > > wrote:
> > > > On Tue, Oct 09, 2018 at 05:26:26PM
Linus (aka Greg),
It was reported that trace_printk() was not reporting properly
values that came after a dereference pointer.
trace_printk() utilizes vbin_printf() and bstr_printf() to keep the
overhead of tracing down. vbin_printf() does not do any conversions
and just stors the string
On Wed, Oct 10, 2018 at 03:10:11PM +0200, Jann Horn wrote:
> On Wed, Oct 10, 2018 at 2:54 PM Christian Brauner
> wrote:
> > On Tue, Oct 09, 2018 at 06:26:47PM +0200, Jann Horn wrote:
> > > On Tue, Oct 9, 2018 at 6:20 PM Christian Brauner
> > > wrote:
> > > > On Tue, Oct 09, 2018 at 05:26:26PM
Linus (aka Greg),
It was reported that trace_printk() was not reporting properly
values that came after a dereference pointer.
trace_printk() utilizes vbin_printf() and bstr_printf() to keep the
overhead of tracing down. vbin_printf() does not do any conversions
and just stors the string
On Wed, Oct 10, 2018 at 3:10 PM, Tetsuo Handa
wrote:
>>> Just flooding out of memory messages can trigger RCU stall problems.
>>> For example, a severe skbuff_head_cache or kmalloc-512 leak bug is
>>> causing
>>
>> [...]
>>
>> Quite some of them, indeed! I guess we
On Wed, Oct 10, 2018 at 3:10 PM, Tetsuo Handa
wrote:
>>> Just flooding out of memory messages can trigger RCU stall problems.
>>> For example, a severe skbuff_head_cache or kmalloc-512 leak bug is
>>> causing
>>
>> [...]
>>
>> Quite some of them, indeed! I guess we
Add touchscreen platform data for the Onda V80 Plus v3 tablet.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/touchscreen_dmi.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c
b/drivers/platform/x86/touchscreen_dmi.c
Add touchscreen platform data for the Onda V80 Plus v3 tablet.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/touchscreen_dmi.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c
b/drivers/platform/x86/touchscreen_dmi.c
On Wed, Oct 10, 2018 at 03:01:29PM +0200, Andreas Schwab wrote:
> On Okt 09 2018, Atish Patra wrote:
>
> > +static void sifive_set_ie(struct sifive_gpio *chip, unsigned int offset)
> > +{
> > + unsigned long flags;
> > + unsigned int trigger;
> > +
> > + raw_spin_lock_irqsave(>lock,
On Wed, Oct 10, 2018 at 03:01:29PM +0200, Andreas Schwab wrote:
> On Okt 09 2018, Atish Patra wrote:
>
> > +static void sifive_set_ie(struct sifive_gpio *chip, unsigned int offset)
> > +{
> > + unsigned long flags;
> > + unsigned int trigger;
> > +
> > + raw_spin_lock_irqsave(>lock,
Thanks for getting these drivers submitted upstream!
I don't really know anything about PWM, so just some random nitpicking
below..
> + iowrite32(frac, pwm->regs + REG_PWMCMP0 + (dev->hwpwm * SIZE_PWMCMP));
* already has a higher precedence than +, so no need for the inner
braces.
> +
Thanks for getting these drivers submitted upstream!
I don't really know anything about PWM, so just some random nitpicking
below..
> + iowrite32(frac, pwm->regs + REG_PWMCMP0 + (dev->hwpwm * SIZE_PWMCMP));
* already has a higher precedence than +, so no need for the inner
braces.
> +
On Wednesday 10 Oct 2018 at 14:50:33 (+0200), Juri Lelli wrote:
> On 10/10/18 14:34, Vincent Guittot wrote:
> > Hi Juri,
> >
> > On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> > >
> > > On 10/10/18 14:04, Vincent Guittot wrote:
> > >
> > > [...]
> > >
> > > > The problem was the same with
On Wednesday 10 Oct 2018 at 14:50:33 (+0200), Juri Lelli wrote:
> On 10/10/18 14:34, Vincent Guittot wrote:
> > Hi Juri,
> >
> > On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> > >
> > > On 10/10/18 14:04, Vincent Guittot wrote:
> > >
> > > [...]
> > >
> > > > The problem was the same with
On 2018/10/10 21:36, Dmitry Vyukov wrote:
> On Wed, Oct 10, 2018 at 2:29 PM, Dmitry Vyukov wrote:
>> On Wed, Oct 10, 2018 at 2:25 PM, Michal Hocko wrote:
>>> On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote:
On (10/10/18 13:35), Michal Hocko wrote:
>> Just flooding out of memory
On 2018/10/10 21:36, Dmitry Vyukov wrote:
> On Wed, Oct 10, 2018 at 2:29 PM, Dmitry Vyukov wrote:
>> On Wed, Oct 10, 2018 at 2:25 PM, Michal Hocko wrote:
>>> On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote:
On (10/10/18 13:35), Michal Hocko wrote:
>> Just flooding out of memory
On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote:
>
> On 10/10/18 14:34, Vincent Guittot wrote:
> > Hi Juri,
> >
> > On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> > >
> > > On 10/10/18 14:04, Vincent Guittot wrote:
> > >
> > > [...]
> > >
> > > > The problem was the same with RT, the cfs
On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote:
>
> On 10/10/18 14:34, Vincent Guittot wrote:
> > Hi Juri,
> >
> > On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> > >
> > > On 10/10/18 14:04, Vincent Guittot wrote:
> > >
> > > [...]
> > >
> > > > The problem was the same with RT, the cfs
On 10/10/2018 14:02, David Howells wrote:
The attached change seems to fix the lazy-umount problem.
David
---
diff --git a/fs/namespace.c b/fs/namespace.c
index 5adeeea2a4d9..d43f0fa152e9 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2472,7 +2472,7 @@ static int do_move_mount(struct path
On 10/10/2018 14:02, David Howells wrote:
The attached change seems to fix the lazy-umount problem.
David
---
diff --git a/fs/namespace.c b/fs/namespace.c
index 5adeeea2a4d9..d43f0fa152e9 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2472,7 +2472,7 @@ static int do_move_mount(struct path
On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
> This patchset doesn't touch cpu_capacity_orig and doesn't need to as
> it assume that the max capacity is unchanged but some capacity is
> momentary stolen by thermal.
> If you want to reflect immediately all thermal capping
On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
> This patchset doesn't touch cpu_capacity_orig and doesn't need to as
> it assume that the max capacity is unchanged but some capacity is
> momentary stolen by thermal.
> If you want to reflect immediately all thermal capping
On Tue, Oct 9, 2018 at 1:30 PM, Leon Romanovsky wrote:
> On Mon, Oct 08, 2018 at 01:45:13PM -0600, Jason Gunthorpe wrote:
>> On Mon, Oct 08, 2018 at 06:15:22PM +0200, Dmitry Vyukov wrote:
>> > On Mon, Oct 8, 2018 at 6:12 PM, syzbot
>> > wrote:
>> > > Hello,
>> > >
>> > > syzbot found the
On Tue, Oct 9, 2018 at 1:30 PM, Leon Romanovsky wrote:
> On Mon, Oct 08, 2018 at 01:45:13PM -0600, Jason Gunthorpe wrote:
>> On Mon, Oct 08, 2018 at 06:15:22PM +0200, Dmitry Vyukov wrote:
>> > On Mon, Oct 8, 2018 at 6:12 PM, syzbot
>> > wrote:
>> > > Hello,
>> > >
>> > > syzbot found the
On Okt 09 2018, Atish Patra wrote:
> +static void sifive_set_ie(struct sifive_gpio *chip, unsigned int offset)
> +{
> + unsigned long flags;
> + unsigned int trigger;
> +
> + raw_spin_lock_irqsave(>lock, flags);
> + trigger = (chip->enabled & BIT(offset)) ? chip->trigger[offset]
On Okt 09 2018, Atish Patra wrote:
> +static void sifive_set_ie(struct sifive_gpio *chip, unsigned int offset)
> +{
> + unsigned long flags;
> + unsigned int trigger;
> +
> + raw_spin_lock_irqsave(>lock, flags);
> + trigger = (chip->enabled & BIT(offset)) ? chip->trigger[offset]
The attached change seems to fix the lazy-umount problem.
David
---
diff --git a/fs/namespace.c b/fs/namespace.c
index 5adeeea2a4d9..d43f0fa152e9 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2472,7 +2472,7 @@ static int do_move_mount(struct path *old_path, struct
path *new_path)
The attached change seems to fix the lazy-umount problem.
David
---
diff --git a/fs/namespace.c b/fs/namespace.c
index 5adeeea2a4d9..d43f0fa152e9 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2472,7 +2472,7 @@ static int do_move_mount(struct path *old_path, struct
path *new_path)
On Tue, Oct 9, 2018 at 7:14 PM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:ae16eea39a86 Add linux-next specific files for 20181008
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16a493b940
> kernel config:
On Tue, Oct 9, 2018 at 7:14 PM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:ae16eea39a86 Add linux-next specific files for 20181008
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16a493b940
> kernel config:
Em Wed, Oct 10, 2018 at 10:03:39AM +0200, Jiri Olsa escreveu:
> On Tue, Oct 09, 2018 at 02:18:39PM -0700, Andi Kleen wrote:
> > On Tue, Oct 09, 2018 at 12:01:44PM +0200, Jiri Olsa wrote:
> > > On Wed, Oct 03, 2018 at 07:45:50AM -0700, Andi Kleen wrote:
> > > > > note there's couple of changes that
Em Wed, Oct 10, 2018 at 10:03:39AM +0200, Jiri Olsa escreveu:
> On Tue, Oct 09, 2018 at 02:18:39PM -0700, Andi Kleen wrote:
> > On Tue, Oct 09, 2018 at 12:01:44PM +0200, Jiri Olsa wrote:
> > > On Wed, Oct 03, 2018 at 07:45:50AM -0700, Andi Kleen wrote:
> > > > > note there's couple of changes that
Em Wed, Oct 10, 2018 at 09:55:06AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Oct 09, 2018 at 08:52:26PM -0700, Benjamin Peterson escreveu:
> > Hi Arnaldo,
> > Did you get a chance to look at this again?
>
> Thanks, for pinging me about it, will check.
So, this is already upstream, I'll
Em Wed, Oct 10, 2018 at 09:55:06AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Oct 09, 2018 at 08:52:26PM -0700, Benjamin Peterson escreveu:
> > Hi Arnaldo,
> > Did you get a chance to look at this again?
>
> Thanks, for pinging me about it, will check.
So, this is already upstream, I'll
Em Tue, Oct 09, 2018 at 08:52:26PM -0700, Benjamin Peterson escreveu:
> Hi Arnaldo,
> Did you get a chance to look at this again?
Thanks, for pinging me about it, will check.
- Arnaldo
> On Thu, Aug 30, 2018, at 14:50, Benjamin Peterson wrote:
> > Thanks for the review.
> >
> > On Thu, Aug
Em Tue, Oct 09, 2018 at 08:52:26PM -0700, Benjamin Peterson escreveu:
> Hi Arnaldo,
> Did you get a chance to look at this again?
Thanks, for pinging me about it, will check.
- Arnaldo
> On Thu, Aug 30, 2018, at 14:50, Benjamin Peterson wrote:
> > Thanks for the review.
> >
> > On Thu, Aug
Hi Lukasz,
On Tue, Oct 9, 2018 at 12:36 PM 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 which will
Hi Lukasz,
On Tue, Oct 9, 2018 at 12:36 PM 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 which will
Em Wed, Oct 10, 2018 at 12:20:04AM +0200, Jiri Olsa escreveu:
> On Tue, Oct 09, 2018 at 04:47:31PM -0500, Anthony LaTorre wrote:
> > I can try building perf from the latest sources. I've attached the
> > perf.data and perf.data.tar.bz2 from the test program I sent earlier.
>
> cool, reproduced..
Em Wed, Oct 10, 2018 at 12:20:04AM +0200, Jiri Olsa escreveu:
> On Tue, Oct 09, 2018 at 04:47:31PM -0500, Anthony LaTorre wrote:
> > I can try building perf from the latest sources. I've attached the
> > perf.data and perf.data.tar.bz2 from the test program I sent earlier.
>
> cool, reproduced..
On 10/10/18 14:34, Vincent Guittot wrote:
> Hi Juri,
>
> On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> >
> > On 10/10/18 14:04, Vincent Guittot wrote:
> >
> > [...]
> >
> > > The problem was the same with RT, the cfs utilization was lower than
> > > reality because RT steals soem cycle to
On 10/10/18 14:34, Vincent Guittot wrote:
> Hi Juri,
>
> On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> >
> > On 10/10/18 14:04, Vincent Guittot wrote:
> >
> > [...]
> >
> > > The problem was the same with RT, the cfs utilization was lower than
> > > reality because RT steals soem cycle to
Alan Jenkins wrote:
> +pr_info("mnt_flags=%x umount=%x\n",
> + (unsigned) old->mnt.mnt_flags,
> + (unsigned) !!(old->mnt.mnt_flags & MNT_UMOUNT);
> +
Note that this doesn't actually compile, for want of a bracket.
David
Alan Jenkins wrote:
> +pr_info("mnt_flags=%x umount=%x\n",
> + (unsigned) old->mnt.mnt_flags,
> + (unsigned) !!(old->mnt.mnt_flags & MNT_UMOUNT);
> +
Note that this doesn't actually compile, for want of a bracket.
David
On Wed, Oct 10, 2018 at 02:12:01PM +0200, Linus Walleij wrote:
> On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
> wrote:
> > On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> > > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
> > > wrote:
> > >
> > > > Sigh, sorry, I caught
On Wed, Oct 10, 2018 at 02:12:01PM +0200, Linus Walleij wrote:
> On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
> wrote:
> > On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> > > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
> > > wrote:
> > >
> > > > Sigh, sorry, I caught
On 10 Oct 2018, at 0:05, Anshuman Khandual wrote:
> On 10/09/2018 07:28 PM, Zi Yan wrote:
>> cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE for x86
>> PMD migration entry check)
>>
>> On 8 Oct 2018, at 23:58, Anshuman Khandual wrote:
>>
>>> A normal mapped THP page at PMD
On 10 Oct 2018, at 0:05, Anshuman Khandual wrote:
> On 10/09/2018 07:28 PM, Zi Yan wrote:
>> cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE for x86
>> PMD migration entry check)
>>
>> On 8 Oct 2018, at 23:58, Anshuman Khandual wrote:
>>
>>> A normal mapped THP page at PMD
On 10/10/2018 13:31, David Howells wrote:
Alan Jenkins wrote:
# mount --move . /mnt
is this calling move_mount(2) on your system?
David
No. That was an unpatched mount program, from util-linux.
Alan
On 10/10/2018 13:31, David Howells wrote:
Alan Jenkins wrote:
# mount --move . /mnt
is this calling move_mount(2) on your system?
David
No. That was an unpatched mount program, from util-linux.
Alan
On 10/10/18 13:56, Henrik Austad wrote:
> On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> > Hi all,
>
> Hi, nice series, I have a lot of details to grok, but I like the idea of PE
>
> > Proxy Execution (also goes under several other names) isn't a new
> > concept, it has been
On 10/10/18 13:56, Henrik Austad wrote:
> On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> > Hi all,
>
> Hi, nice series, I have a lot of details to grok, but I like the idea of PE
>
> > Proxy Execution (also goes under several other names) isn't a new
> > concept, it has been
On Wed, Oct 10, 2018 at 2:29 PM, Dmitry Vyukov wrote:
> On Wed, Oct 10, 2018 at 2:25 PM, Michal Hocko wrote:
>> On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote:
>>> On (10/10/18 13:35), Michal Hocko wrote:
>>> > > Just flooding out of memory messages can trigger RCU stall problems.
>>> > >
On Wed, Oct 10, 2018 at 2:29 PM, Dmitry Vyukov wrote:
> On Wed, Oct 10, 2018 at 2:25 PM, Michal Hocko wrote:
>> On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote:
>>> On (10/10/18 13:35), Michal Hocko wrote:
>>> > > Just flooding out of memory messages can trigger RCU stall problems.
>>> > >
Alan Jenkins wrote:
> + * Copyright (C) 2017 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
Do you want to update that and I can take them into my patchset?
David
Alan Jenkins wrote:
> + * Copyright (C) 2017 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
Do you want to update that and I can take them into my patchset?
David
Hi Atish,
thanks for your patch!
On Tue, Oct 9, 2018 at 8:51 PM Atish Patra wrote:
> From: "Wesley W. Terpstra"
>
> Adds the GPIO driver for SiFive RISC-V SoCs.
>
> Signed-off-by: Wesley W. Terpstra
> [Atish: Various fixes and code cleanup]
> Signed-off-by: Atish Patra
(...)
> +config
Hi Atish,
thanks for your patch!
On Tue, Oct 9, 2018 at 8:51 PM Atish Patra wrote:
> From: "Wesley W. Terpstra"
>
> Adds the GPIO driver for SiFive RISC-V SoCs.
>
> Signed-off-by: Wesley W. Terpstra
> [Atish: Various fixes and code cleanup]
> Signed-off-by: Atish Patra
(...)
> +config
Hi Juri,
On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
>
> On 10/10/18 14:04, Vincent Guittot wrote:
>
> [...]
>
> > The problem was the same with RT, the cfs utilization was lower than
> > reality because RT steals soem cycle to CFS
> > So schedutil was selecting a lower frequency when cfs
Hi Juri,
On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
>
> On 10/10/18 14:04, Vincent Guittot wrote:
>
> [...]
>
> > The problem was the same with RT, the cfs utilization was lower than
> > reality because RT steals soem cycle to CFS
> > So schedutil was selecting a lower frequency when cfs
syzbot has found a reproducer for the following crash on:
HEAD commit:3d647e62686f Merge tag 's390-4.19-4' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15fc834e40
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:3d647e62686f Merge tag 's390-4.19-4' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15fc834e40
kernel config:
Alan Jenkins wrote:
> # mount --move . /mnt
is this calling move_mount(2) on your system?
David
Alan Jenkins wrote:
> # mount --move . /mnt
is this calling move_mount(2) on your system?
David
On Wed, Oct 10, 2018 at 2:25 PM, Michal Hocko wrote:
> On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote:
>> On (10/10/18 13:35), Michal Hocko wrote:
>> > > Just flooding out of memory messages can trigger RCU stall problems.
>> > > For example, a severe skbuff_head_cache or kmalloc-512 leak bug
On Wed, Oct 10, 2018 at 2:25 PM, Michal Hocko wrote:
> On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote:
>> On (10/10/18 13:35), Michal Hocko wrote:
>> > > Just flooding out of memory messages can trigger RCU stall problems.
>> > > For example, a severe skbuff_head_cache or kmalloc-512 leak bug
On 10/10/18 13:23, Peter Zijlstra wrote:
> On Wed, Oct 10, 2018 at 01:16:29PM +0200, luca abeni wrote:
> > On Wed, 10 Oct 2018 12:57:10 +0200
> > Peter Zijlstra wrote:
> >
> > > On Wed, Oct 10, 2018 at 12:34:17PM +0200, luca abeni wrote:
> > > > So, I would propose to make the proxy() function
On 10/10/18 13:23, Peter Zijlstra wrote:
> On Wed, Oct 10, 2018 at 01:16:29PM +0200, luca abeni wrote:
> > On Wed, 10 Oct 2018 12:57:10 +0200
> > Peter Zijlstra wrote:
> >
> > > On Wed, Oct 10, 2018 at 12:34:17PM +0200, luca abeni wrote:
> > > > So, I would propose to make the proxy() function
On Wed, Oct 10, 2018 at 11:58:40AM +, Woodhouse, David wrote:
> On Wed, 2018-10-10 at 12:27 +0100, Mark Brown wrote:
> > If this is a modified IP with additional features then it should be
> > given a new compatible string rather than having a property - it's not
> > just configuration of the
On Wed, Oct 10, 2018 at 11:58:40AM +, Woodhouse, David wrote:
> On Wed, 2018-10-10 at 12:27 +0100, Mark Brown wrote:
> > If this is a modified IP with additional features then it should be
> > given a new compatible string rather than having a property - it's not
> > just configuration of the
On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote:
> On (10/10/18 13:35), Michal Hocko wrote:
> > > Just flooding out of memory messages can trigger RCU stall problems.
> > > For example, a severe skbuff_head_cache or kmalloc-512 leak bug is causing
> >
> > [...]
> >
> > Quite some of them,
On Wed, Oct 10, 2018 at 01:56:39PM +0200, Henrik Austad wrote:
> On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> > Hi all,
>
> Hi, nice series, I have a lot of details to grok, but I like the idea of PE
>
> > Proxy Execution (also goes under several other names) isn't a new
> >
On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote:
> On (10/10/18 13:35), Michal Hocko wrote:
> > > Just flooding out of memory messages can trigger RCU stall problems.
> > > For example, a severe skbuff_head_cache or kmalloc-512 leak bug is causing
> >
> > [...]
> >
> > Quite some of them,
On Wed, Oct 10, 2018 at 01:56:39PM +0200, Henrik Austad wrote:
> On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> > Hi all,
>
> Hi, nice series, I have a lot of details to grok, but I like the idea of PE
>
> > Proxy Execution (also goes under several other names) isn't a new
> >
On 10/10/18 14:04, Vincent Guittot wrote:
[...]
> The problem was the same with RT, the cfs utilization was lower than
> reality because RT steals soem cycle to CFS
> So schedutil was selecting a lower frequency when cfs was running
> whereas the CPU was fully used.
> The same can happen with
On 10/10/18 14:04, Vincent Guittot wrote:
[...]
> The problem was the same with RT, the cfs utilization was lower than
> reality because RT steals soem cycle to CFS
> So schedutil was selecting a lower frequency when cfs was running
> whereas the CPU was fully used.
> The same can happen with
From: Rafael J. Wysocki
After some recent menu governor changes, the promotion of the
"polling" state to a physical one is mostly controlled by the
latency limit (resulting from the "interactivity" factor) and
not by the time to the closest timer event, so it should be
sufficient to check the
From: Rafael J. Wysocki
After some recent menu governor changes, the promotion of the
"polling" state to a physical one is mostly controlled by the
latency limit (resulting from the "interactivity" factor) and
not by the time to the closest timer event, so it should be
sufficient to check the
Am 10.10.2018 um 14:09 schrieb Russell King - ARM Linux:
> On Wed, Oct 10, 2018 at 02:04:14PM +0200, Stefan Wahren wrote:
>> Hi,
>>
>> Am 10.10.2018 um 13:19 schrieb Rob Herring:
>>> On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
>>> wrote:
Hi,
I see a bunch of vendor (or
Am 10.10.2018 um 14:09 schrieb Russell King - ARM Linux:
> On Wed, Oct 10, 2018 at 02:04:14PM +0200, Stefan Wahren wrote:
>> Hi,
>>
>> Am 10.10.2018 um 13:19 schrieb Rob Herring:
>>> On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
>>> wrote:
Hi,
I see a bunch of vendor (or
On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
wrote:
> On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
> > wrote:
> >
> > > Sigh, sorry, I caught this after I sent my initial all good email but
> > > this commit breaks NFC
On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
wrote:
> On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
> > wrote:
> >
> > > Sigh, sorry, I caught this after I sent my initial all good email but
> > > this commit breaks NFC
On Wed, Oct 10, 2018 at 02:04:14PM +0200, Stefan Wahren wrote:
> Hi,
>
> Am 10.10.2018 um 13:19 schrieb Rob Herring:
> > On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
> > wrote:
> >> Hi,
> >>
> >>
> >> I see a bunch of vendor (or SoC) names in
> >> Documentation/device/bindings/arm/
> >>
> >>
On Wed, Oct 10, 2018 at 02:04:14PM +0200, Stefan Wahren wrote:
> Hi,
>
> Am 10.10.2018 um 13:19 schrieb Rob Herring:
> > On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
> > wrote:
> >> Hi,
> >>
> >>
> >> I see a bunch of vendor (or SoC) names in
> >> Documentation/device/bindings/arm/
> >>
> >>
On Wed, Oct 10, 2018 at 08:07:52PM +0900, Masahiro Yamada wrote:
> Hi,
>
>
> I see a bunch of vendor (or SoC) names in
> Documentation/device/bindings/arm/
>
> ./Documentation/devicetree/bindings/arm/altera
> ./Documentation/devicetree/bindings/arm/amlogic
>
From: Laurentiu Tudor
This allows for the SMMU device to be probed by the SMMU kernel driver.
Signed-off-by: Laurentiu Tudor
---
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 42 +++
1 file changed, 42 insertions(+)
diff --git
On Wed, Oct 10, 2018 at 08:07:52PM +0900, Masahiro Yamada wrote:
> Hi,
>
>
> I see a bunch of vendor (or SoC) names in
> Documentation/device/bindings/arm/
>
> ./Documentation/devicetree/bindings/arm/altera
> ./Documentation/devicetree/bindings/arm/amlogic
>
From: Laurentiu Tudor
This allows for the SMMU device to be probed by the SMMU kernel driver.
Signed-off-by: Laurentiu Tudor
---
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 42 +++
1 file changed, 42 insertions(+)
diff --git
Hi Arnd,
On 18-10-10 10:37, Arnd Bergmann wrote:
> 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);
>
On Mon, Oct 8, 2018 at 6:32 PM Stephen Boyd wrote:
> gpiochip_set_cascaded_irqchip() is passed 'parent_irq' as an argument
> and then the address of that argument is assigned to the gpio chips
> gpio_irq_chip 'parents' pointer shortly thereafter. This can't ever
> work, because we've just
Hi Arnd,
On 18-10-10 10:37, Arnd Bergmann wrote:
> 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);
>
On Mon, Oct 8, 2018 at 6:32 PM Stephen Boyd wrote:
> gpiochip_set_cascaded_irqchip() is passed 'parent_irq' as an argument
> and then the address of that argument is assigned to the gpio chips
> gpio_irq_chip 'parents' pointer shortly thereafter. This can't ever
> work, because we've just
On Wed, 10 Oct 2018 at 12:36, Quentin Perret wrote:
>
> On Wednesday 10 Oct 2018 at 12:14:32 (+0200), Vincent Guittot wrote:
> > On Wed, 10 Oct 2018 at 11:55, Quentin Perret wrote:
> > >
> > > Hi Vincent,
> > >
> > > On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> > > >
On Wed, 10 Oct 2018 at 12:36, Quentin Perret wrote:
>
> On Wednesday 10 Oct 2018 at 12:14:32 (+0200), Vincent Guittot wrote:
> > On Wed, 10 Oct 2018 at 11:55, Quentin Perret wrote:
> > >
> > > Hi Vincent,
> > >
> > > On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> > > >
Hi,
Am 10.10.2018 um 13:19 schrieb Rob Herring:
> On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
> wrote:
>> Hi,
>>
>>
>> I see a bunch of vendor (or SoC) names in
>> Documentation/device/bindings/arm/
>>
>> ./Documentation/devicetree/bindings/arm/altera
>>
Hi,
Am 10.10.2018 um 13:19 schrieb Rob Herring:
> On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
> wrote:
>> Hi,
>>
>>
>> I see a bunch of vendor (or SoC) names in
>> Documentation/device/bindings/arm/
>>
>> ./Documentation/devicetree/bindings/arm/altera
>>
Hi.
When I wrote my DMA engine driver,
I had difficulty in understanding
what to set to the struct dma_device members.
For example, src_addr_widths.
I see two driver groups regarding this.
[A] BIT(DMA_SLAVE_BUSWIDTH_*_BYTES) are OR'ed
For example, st_fdma.c
Hi.
When I wrote my DMA engine driver,
I had difficulty in understanding
what to set to the struct dma_device members.
For example, src_addr_widths.
I see two driver groups regarding this.
[A] BIT(DMA_SLAVE_BUSWIDTH_*_BYTES) are OR'ed
For example, st_fdma.c
Hi Greg,
Please pull this one DT fix for 4.19.
Note I didn't tag this for stable as I cherry-picked it from my 4.20
branch and wanted to not touch the commit msg at all. Maybe that
doesn't matter.
Rob
The following changes since commit e54192b48da75f025ae4b277925eaf6aca1d13bd:
of: fix
Hi Greg,
Please pull this one DT fix for 4.19.
Note I didn't tag this for stable as I cherry-picked it from my 4.20
branch and wanted to not touch the commit msg at all. Maybe that
doesn't matter.
Rob
The following changes since commit e54192b48da75f025ae4b277925eaf6aca1d13bd:
of: fix
1001 - 1100 of 1504 matches
Mail list logo
