On Fri, 22 Jun 2018 at 13:37, Peter Zijlstra wrote:
>
> On Fri, Jun 22, 2018 at 08:58:53AM +0100, Quentin Perret wrote:
> > Say we have 50% of the capacity stolen by RT, and a 25% CFS task
> > running. If we re-scale, we'll end up with a 50% request for CFS
> > (util==512 for your code above).
On Fri 22-06-18 19:40:54, 禹舟键 wrote:
> Hi Michal
> > You misunderstood my suggestion. Let me be more specific. Please
> > separate the whole new oom_constraint including its _usage_.
>
> Sorry for misunderstanding your words. I think you want me to separate
> enum oom_constraint and static const
On Fri 22-06-18 19:40:54, 禹舟键 wrote:
> Hi Michal
> > You misunderstood my suggestion. Let me be more specific. Please
> > separate the whole new oom_constraint including its _usage_.
>
> Sorry for misunderstanding your words. I think you want me to separate
> enum oom_constraint and static const
On Fri, Jun 22, 2018 at 02:07:39PM +0200, Christoph Hellwig wrote:
> On Fri, Jun 22, 2018 at 12:56:13PM +0100, Al Viro wrote:
> > So mark that in ->f_mode - I strongly suspect that
> > sk_can_busy_loop(sock->sk) can't change while an opened file is there.
> > And lift that (conditional on new
On Fri, Jun 22, 2018 at 02:07:39PM +0200, Christoph Hellwig wrote:
> On Fri, Jun 22, 2018 at 12:56:13PM +0100, Al Viro wrote:
> > So mark that in ->f_mode - I strongly suspect that
> > sk_can_busy_loop(sock->sk) can't change while an opened file is there.
> > And lift that (conditional on new
On 06/21/18 at 05:01pm, Ingo Molnar wrote:
>
> * Baoquan He wrote:
>
> > +/* Store the number of 1GB huge pages which user specified.*/
> > +static unsigned long max_gb_huge_pages;
> > +
> > +static int parse_gb_huge_pages(char *param, char* val)
> > +{
> > + char *p;
> > + u64 mem_size;
>
On 06/21/18 at 05:01pm, Ingo Molnar wrote:
>
> * Baoquan He wrote:
>
> > +/* Store the number of 1GB huge pages which user specified.*/
> > +static unsigned long max_gb_huge_pages;
> > +
> > +static int parse_gb_huge_pages(char *param, char* val)
> > +{
> > + char *p;
> > + u64 mem_size;
>
On Fri, 22 Jun 2018 at 13:41, Peter Zijlstra wrote:
>
> On Fri, Jun 22, 2018 at 10:10:32AM +0200, Vincent Guittot wrote:
> > On Thu, 21 Jun 2018 at 20:57, Peter Zijlstra wrote:
> > >
> > > > So this (and the dl etc. equivalents) result in exactly the problems
> > > > complained about last time,
On Fri, 22 Jun 2018 at 13:41, Peter Zijlstra wrote:
>
> On Fri, Jun 22, 2018 at 10:10:32AM +0200, Vincent Guittot wrote:
> > On Thu, 21 Jun 2018 at 20:57, Peter Zijlstra wrote:
> > >
> > > > So this (and the dl etc. equivalents) result in exactly the problems
> > > > complained about last time,
On Fri, 22 Jun 2018, Thomas Gleixner wrote:
> The whole thing is simply:
>
> handle_ac()
> {
> if (user_mode(regs)) {
>do_trap(AC, SIGBUS, ...);
> } else {
> disable_ac_on_local_cpu();
> WARN_ONCE(1);
> }
> }
>
> That wants #AC
On Fri, 22 Jun 2018, Thomas Gleixner wrote:
> The whole thing is simply:
>
> handle_ac()
> {
> if (user_mode(regs)) {
>do_trap(AC, SIGBUS, ...);
> } else {
> disable_ac_on_local_cpu();
> WARN_ONCE(1);
> }
> }
>
> That wants #AC
On Fri, Jun 22, 2018 at 12:56:13PM +0100, Al Viro wrote:
> So mark that in ->f_mode - I strongly suspect that
> sk_can_busy_loop(sock->sk) can't change while an opened file is there.
> And lift that (conditional on new FMODE_BUSY_LOOP) into do_poll()
> and do_select() - we *already* have
On Fri, Jun 22, 2018 at 12:56:13PM +0100, Al Viro wrote:
> So mark that in ->f_mode - I strongly suspect that
> sk_can_busy_loop(sock->sk) can't change while an opened file is there.
> And lift that (conditional on new FMODE_BUSY_LOOP) into do_poll()
> and do_select() - we *already* have
On Fri, Jun 22, 2018 at 01:53:00PM +0200, Christoph Hellwig wrote:
> > Now, ->sk_wq is modified only in sock_init_data() and sock_graft();
> > the latter, IIRC, is ->accept() helper. Do we ever call either of
> > those on a sock of already opened file? IOW, is there any real
> > reason for
On Fri, Jun 22, 2018 at 01:53:00PM +0200, Christoph Hellwig wrote:
> > Now, ->sk_wq is modified only in sock_init_data() and sock_graft();
> > the latter, IIRC, is ->accept() helper. Do we ever call either of
> > those on a sock of already opened file? IOW, is there any real
> > reason for
From: Zhenzhong Duan
Free useless ucode_patch entry when it's replaced.
Signed-off-by: Zhenzhong Duan
Cc: Srinivas REDDY Eeda
Cc: x86-ml
Link: http://lkml.kernel.org/r/888102f0-fd22-459d-b090-a1bd8a00cb2b@default
[ Drop the memfree_patch() two-liner. ]
Signed-off-by: Borislav Petkov
---
From: Zhenzhong Duan
Free useless ucode_patch entry when it's replaced.
Signed-off-by: Zhenzhong Duan
Cc: Srinivas REDDY Eeda
Cc: x86-ml
Link: http://lkml.kernel.org/r/888102f0-fd22-459d-b090-a1bd8a00cb2b@default
[ Drop the memfree_patch() two-liner. ]
Signed-off-by: Borislav Petkov
---
On Fri, Jun 22, 2018 at 01:37:13PM +0200, Peter Zijlstra wrote:
> I suppose we can make it more complicated, something like:
>
> u u
> f := u + (--- - u) * (---)^n
> 1-r 1-r
>
> Where: u := cfs util
>r := \Sum !cfs util
>f := frequency
On Fri, Jun 22, 2018 at 01:37:13PM +0200, Peter Zijlstra wrote:
> I suppose we can make it more complicated, something like:
>
> u u
> f := u + (--- - u) * (---)^n
> 1-r 1-r
>
> Where: u := cfs util
>r := \Sum !cfs util
>f := frequency
On Fri, Jun 22, 2018 at 12:01:17PM +0100, Al Viro wrote:
> For fuck sake, if you want vfs_poll() inlined, *make* *it* *inlined*.
That is not going to help with de-virtualizing _qproc, which was
the whole idea of that change. At least not without a compiler
way smarter than gcc.
But if you want
On Fri, Jun 22, 2018 at 12:01:17PM +0100, Al Viro wrote:
> For fuck sake, if you want vfs_poll() inlined, *make* *it* *inlined*.
That is not going to help with de-virtualizing _qproc, which was
the whole idea of that change. At least not without a compiler
way smarter than gcc.
But if you want
Hi Masahiro,
On Tue, 19 Jun 2018 13:28:11 +0200
Boris Brezillon wrote:
> Hi Masahiro,
>
> On Fri, 15 Jun 2018 10:18:50 +0900
> Masahiro Yamada wrote:
>
> > According to the Denali User's Guide, this IP needs three clocks:
> >
> > - clk: controller core clock
> >
> > - clk_x: bus
Hi Masahiro,
On Tue, 19 Jun 2018 13:28:11 +0200
Boris Brezillon wrote:
> Hi Masahiro,
>
> On Fri, 15 Jun 2018 10:18:50 +0900
> Masahiro Yamada wrote:
>
> > According to the Denali User's Guide, this IP needs three clocks:
> >
> > - clk: controller core clock
> >
> > - clk_x: bus
The drivers gets probed from a mfd devices. So the driver runs
probe although no DT node exists. This leads to a NULL pointer
dereference in the probe function. Check if a node exists and
error out in case none is present.
Fixes: 3e9f0b3e2b27 ("input: Add MediaTek PMIC keys support")
The drivers gets probed from a mfd devices. So the driver runs
probe although no DT node exists. This leads to a NULL pointer
dereference in the probe function. Check if a node exists and
error out in case none is present.
Fixes: 3e9f0b3e2b27 ("input: Add MediaTek PMIC keys support")
Hi Russell,
Thanks for your comments!
On Fri, Jun 22, 2018 at 11:23 AM Russell King - ARM Linux
wrote:
> On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote:
> > "ARM multiplatform" has actually two meanings:
> > 1. It groups platforms that follow the "ARM multiplatform"
Hi Russell,
Thanks for your comments!
On Fri, Jun 22, 2018 at 11:23 AM Russell King - ARM Linux
wrote:
> On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote:
> > "ARM multiplatform" has actually two meanings:
> > 1. It groups platforms that follow the "ARM multiplatform"
On Fri, Jun 22, 2018 at 10:10:32AM +0200, Vincent Guittot wrote:
> On Thu, 21 Jun 2018 at 20:57, Peter Zijlstra wrote:
> >
> > > So this (and the dl etc. equivalents) result in exactly the problems
> > > complained about last time, no?
> > >
> > > What I proposed was something along the lines of:
On Fri, Jun 22, 2018 at 10:10:32AM +0200, Vincent Guittot wrote:
> On Thu, 21 Jun 2018 at 20:57, Peter Zijlstra wrote:
> >
> > > So this (and the dl etc. equivalents) result in exactly the problems
> > > complained about last time, no?
> > >
> > > What I proposed was something along the lines of:
On 06/21/2018 11:25 PM, Jason Gunthorpe wrote:
On Thu, Jun 21, 2018 at 04:59:55PM -0400, Stefan Berger wrote:
On 06/21/2018 04:53 PM, Mimi Zohar wrote:
On Wed, 2018-06-20 at 16:42 -0400, Stefan Berger wrote:
Rather than accessing the TPM functions using a NULL pointer, which
causes a lookup
On 06/21/2018 11:25 PM, Jason Gunthorpe wrote:
On Thu, Jun 21, 2018 at 04:59:55PM -0400, Stefan Berger wrote:
On 06/21/2018 04:53 PM, Mimi Zohar wrote:
On Wed, 2018-06-20 at 16:42 -0400, Stefan Berger wrote:
Rather than accessing the TPM functions using a NULL pointer, which
causes a lookup
Hi Michal
> You misunderstood my suggestion. Let me be more specific. Please
> separate the whole new oom_constraint including its _usage_.
Sorry for misunderstanding your words. I think you want me to separate
enum oom_constraint and static const char * const
oom_constraint_text[] to two parts,
Hi Michal
> You misunderstood my suggestion. Let me be more specific. Please
> separate the whole new oom_constraint including its _usage_.
Sorry for misunderstanding your words. I think you want me to separate
enum oom_constraint and static const char * const
oom_constraint_text[] to two parts,
On Fri, Jun 22, 2018 at 08:58:53AM +0100, Quentin Perret wrote:
> Say we have 50% of the capacity stolen by RT, and a 25% CFS task
> running. If we re-scale, we'll end up with a 50% request for CFS
> (util==512 for your code above). But if we want to see a little bit
> of idle time in the system,
On Fri, Jun 22, 2018 at 08:58:53AM +0100, Quentin Perret wrote:
> Say we have 50% of the capacity stolen by RT, and a 25% CFS task
> running. If we re-scale, we'll end up with a 50% request for CFS
> (util==512 for your code above). But if we want to see a little bit
> of idle time in the system,
On Fri, 22 Jun 2018 09:04:25 +0200
Geert Uytterhoeven wrote:
> With gcc 4.1.2 when compiling for 32-bit:
>
> drivers/mtd/devices/mtd_dataflash.c:736: warning: integer constant is too
> large for ‘long’ type
> drivers/mtd/devices/mtd_dataflash.c:737: warning: integer constant is too
>
On Fri, 22 Jun 2018 09:04:25 +0200
Geert Uytterhoeven wrote:
> With gcc 4.1.2 when compiling for 32-bit:
>
> drivers/mtd/devices/mtd_dataflash.c:736: warning: integer constant is too
> large for ‘long’ type
> drivers/mtd/devices/mtd_dataflash.c:737: warning: integer constant is too
>
Function irq_desc_get_msi_desc() is not referenced in the kernel (and does
not seem to have been referenced since e39758e0ea76, 3 years ago), so
delete it.
Signed-off-by: John Garry
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index 25b33b6..dd1e40d 100644
---
Function irq_desc_get_msi_desc() is not referenced in the kernel (and does
not seem to have been referenced since e39758e0ea76, 3 years ago), so
delete it.
Signed-off-by: John Garry
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index 25b33b6..dd1e40d 100644
---
On Mon, 18 Jun 2018 15:57:57 +0200
Miquel Raynal wrote:
> Hi Boris,
>
> On Wed, 13 Jun 2018 14:32:36 +0530, Abhishek Sahu
> wrote:
>
> > Positive return value from read_oob() is making false BAD
> > blocks. For some of the NAND controllers, OOB bytes will be
> > protected with ECC and
On Mon, 18 Jun 2018 15:57:57 +0200
Miquel Raynal wrote:
> Hi Boris,
>
> On Wed, 13 Jun 2018 14:32:36 +0530, Abhishek Sahu
> wrote:
>
> > Positive return value from read_oob() is making false BAD
> > blocks. For some of the NAND controllers, OOB bytes will be
> > protected with ECC and
On Tue, 2018-05-22 at 18:34 +0200, Jerome Brunet wrote:
> The purpose of this patchset is to add support for the clock controller
> dedicated to the audio subsystem found on A113 based SoCs
>
> The series depends on the CLK_MUX_ROUND_CLOSEST fixes [merged in clk-next]
> and the duty cycle support
On Tue, 2018-05-22 at 18:34 +0200, Jerome Brunet wrote:
> The purpose of this patchset is to add support for the clock controller
> dedicated to the audio subsystem found on A113 based SoCs
>
> The series depends on the CLK_MUX_ROUND_CLOSEST fixes [merged in clk-next]
> and the duty cycle support
> > > I also just realised that this prevents Power from using ctrl+isync to
> > > implement acquire, should they wish to do so.
> >
> > They in fact do so on chips lacking LWSYNC, see how PPC_ACQUIRE_BARRIER
> > (as used by atomic_*_acquire) turns into ISYNC (note however that they
> > do not
> > > I also just realised that this prevents Power from using ctrl+isync to
> > > implement acquire, should they wish to do so.
> >
> > They in fact do so on chips lacking LWSYNC, see how PPC_ACQUIRE_BARRIER
> > (as used by atomic_*_acquire) turns into ISYNC (note however that they
> > do not
Gustavo A. R. Silva wrote:
> Release resources allocated for *ctx* before return.
I've folded that into the original patch, thanks.
David
Gustavo A. R. Silva wrote:
> Release resources allocated for *ctx* before return.
I've folded that into the original patch, thanks.
David
From: Oscar Salvador
link_mem_sections() and walk_memory_range() share most of the code,
so we can use convert link_mem_sections() into a dummy function that calls
walk_memory_range() with a callback to register_mem_sect_under_node().
This patch converts register_mem_sect_under_node() in order
From: Oscar Salvador
link_mem_sections() and walk_memory_range() share most of the code,
so we can use convert link_mem_sections() into a dummy function that calls
walk_memory_range() with a callback to register_mem_sect_under_node().
This patch converts register_mem_sect_under_node() in order
From: Oscar Salvador
Callers of register_mem_sect_under_node() are always passing a valid
memory_block (not NULL), so we can safely drop the check for NULL.
In the same way, register_mem_sect_under_node() is only called in case
the node is online, so we can safely remove that check as well.
From: Oscar Salvador
Callers of register_mem_sect_under_node() are always passing a valid
memory_block (not NULL), so we can safely drop the check for NULL.
In the same way, register_mem_sect_under_node() is only called in case
the node is online, so we can safely remove that check as well.
From: Oscar Salvador
add_memory_resource() contains code to allocate a new node in case
it is necessary.
Since try_online_node() also hast some code for this purpose,
let us make use of that and remove duplicate code.
This introduces __try_online_node(), which is called by
add_memory_resource()
From: Oscar Salvador
When hotpluging memory, it is possible that two calls are being made
to register_mem_sect_under_node().
One comes from __add_section()->hotplug_memory_register()
and the other from add_memory_resource()->link_mem_sections() if
we had to register a new node.
In case we had
From: Oscar Salvador
add_memory_resource() contains code to allocate a new node in case
it is necessary.
Since try_online_node() also hast some code for this purpose,
let us make use of that and remove duplicate code.
This introduces __try_online_node(), which is called by
add_memory_resource()
From: Oscar Salvador
When hotpluging memory, it is possible that two calls are being made
to register_mem_sect_under_node().
One comes from __add_section()->hotplug_memory_register()
and the other from add_memory_resource()->link_mem_sections() if
we had to register a new node.
In case we had
From: Oscar Salvador
Hi,
I this is a small cleanup for the memhotplug's code.
A lot more could be done, but it is better to start somewhere.
I tried to unify/remove duplicated code.
The following is what this patchset does:
1) add_memory_resource() has code to allocate a node in case it was
From: Oscar Salvador
Hi,
I this is a small cleanup for the memhotplug's code.
A lot more could be done, but it is better to start somewhere.
I tried to unify/remove duplicated code.
The following is what this patchset does:
1) add_memory_resource() has code to allocate a node in case it was
Hi Wei,
Thanks for giving that a spin.
On Fri, Jun 22, 2018 at 06:45:15PM +0800, Wei Xu wrote:
> On 2018/6/22 17:23, Will Deacon wrote:
> >On Fri, Jun 22, 2018 at 09:33:04AM +0100, Wei Xu wrote:
> >>On 2018/6/21 11:54, Will Deacon wrote:
> >>>On Thu, Jun 21, 2018 at 11:14:28AM +0100, Wei Xu
Hi Wei,
Thanks for giving that a spin.
On Fri, Jun 22, 2018 at 06:45:15PM +0800, Wei Xu wrote:
> On 2018/6/22 17:23, Will Deacon wrote:
> >On Fri, Jun 22, 2018 at 09:33:04AM +0100, Wei Xu wrote:
> >>On 2018/6/21 11:54, Will Deacon wrote:
> >>>On Thu, Jun 21, 2018 at 11:14:28AM +0100, Wei Xu
> -Original Message-
> From: Abel Vesa
> Sent: Wednesday, June 20, 2018 8:24 PM
> To: Lucas Stach ; A.s. Dong
>
> Cc: linux-g...@vger.kernel.org; dl-linux-imx ; Shawn
> Guo ; Pengutronix Kernel Team
> ; Linus Walleij ; Rob
> Herring ; Mark Rutland ;
> devicet...@vger.kernel.org;
> -Original Message-
> From: Abel Vesa
> Sent: Wednesday, June 20, 2018 8:24 PM
> To: Lucas Stach ; A.s. Dong
>
> Cc: linux-g...@vger.kernel.org; dl-linux-imx ; Shawn
> Guo ; Pengutronix Kernel Team
> ; Linus Walleij ; Rob
> Herring ; Mark Rutland ;
> devicet...@vger.kernel.org;
- Rebase to v4.18-rc1 (applies to next-20180622, too),
v3:
- Add Acked-by,
- Rebase to v4.17-rc1,
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/iio/adc/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iio/adc/Kconfig b/drive
- Rebase to v4.18-rc1 (applies to next-20180622, too),
v3:
- Add Acked-by,
- Rebase to v4.17-rc1,
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/iio/adc/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iio/adc/Kconfig b/drive
1 (applies to next-20180622, too),
v3:
- Rebase to v4.17-rc1,
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/firewire/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig
index 145974
1 (applies to next-20180622, too),
v3:
- Rebase to v4.17-rc1,
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/firewire/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig
index 145974
1 (applies to next-20180622, too),
v3:
- Rebase to v4.17-rc1,
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/ata/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 2b16e7c8fff35764..39b181d6bd0d8
1 (applies to next-20180622, too),
v3:
- Rebase to v4.17-rc1,
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/ata/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 2b16e7c8fff35764..39b181d6bd0d8
On 22/06/2018 10:52:49+0100, Marc Zyngier wrote:
> The ls-scfs-msi driver is not dealing with the effective affinity
> as it should. Let's fix that, and make it clear that the effective
> affinity is restricted to a single CPU. Also prevent the driver from
> messing with the internals of the
On 22/06/2018 10:52:49+0100, Marc Zyngier wrote:
> The ls-scfs-msi driver is not dealing with the effective affinity
> as it should. Let's fix that, and make it clear that the effective
> affinity is restricted to a single CPU. Also prevent the driver from
> messing with the internals of the
On Fri, Jun 22, 2018 at 12:00:14PM +0200, Christoph Hellwig wrote:
> And a version with select() also covered:
For fuck sake, if you want vfs_poll() inlined, *make* *it* *inlined*.
Is there any reason for not doing that other than EXPORT_SYMBOL_GPL
fetish? Because if there isn't, I would like to
Hi Abel,
The patch mostly looks good to me.
Only a few minor comments.
> -Original Message-
> From: Abel Vesa
> Sent: Wednesday, June 20, 2018 8:24 PM
> To: Lucas Stach ; A.s. Dong
>
> Cc: linux-g...@vger.kernel.org; dl-linux-imx ; Shawn
> Guo ; Pengutronix Kernel Team
> ; Linus Walleij
On Fri, Jun 22, 2018 at 12:00:14PM +0200, Christoph Hellwig wrote:
> And a version with select() also covered:
For fuck sake, if you want vfs_poll() inlined, *make* *it* *inlined*.
Is there any reason for not doing that other than EXPORT_SYMBOL_GPL
fetish? Because if there isn't, I would like to
Hi Abel,
The patch mostly looks good to me.
Only a few minor comments.
> -Original Message-
> From: Abel Vesa
> Sent: Wednesday, June 20, 2018 8:24 PM
> To: Lucas Stach ; A.s. Dong
>
> Cc: linux-g...@vger.kernel.org; dl-linux-imx ; Shawn
> Guo ; Pengutronix Kernel Team
> ; Linus Walleij
On Fri, 2018-06-22 at 13:40 +0300, Dan Carpenter wrote:
> On Thu, Jun 21, 2018 at 08:22:30PM +0200, Michael Straube wrote:
> > Fix checkpatch error 'do not use assignment in if condition'.
[]
> > diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> >
On Fri, 2018-06-22 at 13:40 +0300, Dan Carpenter wrote:
> On Thu, Jun 21, 2018 at 08:22:30PM +0200, Michael Straube wrote:
> > Fix checkpatch error 'do not use assignment in if condition'.
[]
> > diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> >
On Fri, Jun 22, 2018 at 03:54:22AM -0700, Joe Perches wrote:
> On Fri, 2018-06-22 at 13:40 +0300, Dan Carpenter wrote:
> > On Thu, Jun 21, 2018 at 08:22:30PM +0200, Michael Straube wrote:
> > > Fix checkpatch error 'do not use assignment in if condition'.
> []
> > > diff --git
On Fri, Jun 22, 2018 at 03:54:22AM -0700, Joe Perches wrote:
> On Fri, 2018-06-22 at 13:40 +0300, Dan Carpenter wrote:
> > On Thu, Jun 21, 2018 at 08:22:30PM +0200, Michael Straube wrote:
> > > Fix checkpatch error 'do not use assignment in if condition'.
> []
> > > diff --git
On Fri, 22 Jun 2018 12:41:14 +0200,
Robert Jarzmik wrote:
>
> Takashi Iwai writes:
>
> >> Special review query: review the "return of_node_get(node)", which
> >> assumes that upon device removal, of_put_node(dev.of_node) will be
> >> called...
> >
> > Is it really done automagically? I
On Fri, 22 Jun 2018 12:41:14 +0200,
Robert Jarzmik wrote:
>
> Takashi Iwai writes:
>
> >> Special review query: review the "return of_node_get(node)", which
> >> assumes that upon device removal, of_put_node(dev.of_node) will be
> >> called...
> >
> > Is it really done automagically? I
Add a driver for Cadence I3C GPIO expander.
Signed-off-by: Boris Brezillon
---
Hi Linus,
I intentionally did not report your Acked-by because of the scract
buffer changes I added in this version (needed to follow the
"buffer should be DMA-able" rule)
Feel free to add it back if you're okay
Add a driver for Cadence I3C GPIO expander.
Signed-off-by: Boris Brezillon
---
Hi Linus,
I intentionally did not report your Acked-by because of the scract
buffer changes I added in this version (needed to follow the
"buffer should be DMA-able" rule)
Feel free to add it back if you're okay
On Fri, Jun 22, 2018 at 12:07 PM, Geert Uytterhoeven
wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Miguel Ojeda
Thanks,
Miguel
> ---
> v3:
> - Upd
On Fri, Jun 22, 2018 at 12:07 PM, Geert Uytterhoeven
wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Miguel Ojeda
Thanks,
Miguel
> ---
> v3:
> - Upd
On Sun, 27 May 2018, Fenghua Yu wrote:
> +static void wait_for_reexecution(void)
> +{
> + while (time_before(jiffies, disable_split_lock_jiffies +
> +reenable_split_lock_delay))
> + cpu_relax();
> +}
> +
> +/*
> + * TEST_CTL MSR is shared among threads on
On Sun, 27 May 2018, Fenghua Yu wrote:
> +static void wait_for_reexecution(void)
> +{
> + while (time_before(jiffies, disable_split_lock_jiffies +
> +reenable_split_lock_delay))
> + cpu_relax();
> +}
> +
> +/*
> + * TEST_CTL MSR is shared among threads on
I liked the patch, but just go over the 80 character limit instead of
adding a "key" variable. It's better that it generate a checkpatch
warning and forces someone to rename the variable...
regards,
dan carpenter
I liked the patch, but just go over the 80 character limit instead of
adding a "key" variable. It's better that it generate a checkpatch
warning and forces someone to rename the variable...
regards,
dan carpenter
Hi Will,
On 2018/6/22 17:23, Will Deacon wrote:
Hi Wei,
On Fri, Jun 22, 2018 at 09:33:04AM +0100, Wei Xu wrote:
On 2018/6/21 11:54, Will Deacon wrote:
On Thu, Jun 21, 2018 at 11:14:28AM +0100, Wei Xu wrote:
On 2018/6/21 10:18, Will Deacon wrote:
Wei -- does the diff below help at all? Make
Hi Will,
On 2018/6/22 17:23, Will Deacon wrote:
Hi Wei,
On Fri, Jun 22, 2018 at 09:33:04AM +0100, Wei Xu wrote:
On 2018/6/21 11:54, Will Deacon wrote:
On Thu, Jun 21, 2018 at 11:14:28AM +0100, Wei Xu wrote:
On 2018/6/21 10:18, Will Deacon wrote:
Wei -- does the diff below help at all? Make
When delivering a signal to a task that is using rseq, we call into
__rseq_handle_notify_resume() so that the registers pushed in the
sigframe are updated to reflect the state of the restartable sequence
(for example, ensuring that the signal returns to the abort handler if
necessary).
However,
Add "vqmmc-supply" property for mmc0/mmc1 to indicate the supply connected
to the IO lines. Also add dt node for ldo1 regulator required for mmc1
vqmmc-supply.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 10 ++
1 file changed, 10 insertions(+)
When delivering a signal to a task that is using rseq, we call into
__rseq_handle_notify_resume() so that the registers pushed in the
sigframe are updated to reflect the state of the restartable sequence
(for example, ensuring that the signal returns to the abort handler if
necessary).
However,
Add "vqmmc-supply" property for mmc0/mmc1 to indicate the supply connected
to the IO lines. Also add dt node for ldo1 regulator required for mmc1
vqmmc-supply.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 10 ++
1 file changed, 10 insertions(+)
On Fri 22-06-18 17:33:12, 禹舟键 wrote:
> Hi Michal
> > diff --git a/include/linux/oom.h b/include/linux/oom.h
> > index 6adac113e96d..5bed78d4bfb8 100644
> > --- a/include/linux/oom.h
> > +++ b/include/linux/oom.h
> > @@ -15,6 +15,20 @@ struct notifier_block;
> > struct mem_cgroup;
> > struct
On Fri 22-06-18 17:33:12, 禹舟键 wrote:
> Hi Michal
> > diff --git a/include/linux/oom.h b/include/linux/oom.h
> > index 6adac113e96d..5bed78d4bfb8 100644
> > --- a/include/linux/oom.h
> > +++ b/include/linux/oom.h
> > @@ -15,6 +15,20 @@ struct notifier_block;
> > struct mem_cgroup;
> > struct
On Wed, 2018-06-20 at 10:31 +0200, Neil Armstrong wrote:
> On 19/06/2018 18:00, Jerome Brunet wrote:
> > The legacy method to access the hhi register space is not longer used.
> > We can safely drop it now.
> >
> > Signed-off-by: Jerome Brunet
> > ---
> > drivers/clk/meson/axg.c | 37
On Wed, 2018-06-20 at 10:31 +0200, Neil Armstrong wrote:
> On 19/06/2018 18:00, Jerome Brunet wrote:
> > The legacy method to access the hhi register space is not longer used.
> > We can safely drop it now.
> >
> > Signed-off-by: Jerome Brunet
> > ---
> > drivers/clk/meson/axg.c | 37
On Wed, 2018-06-20 at 10:31 +0200, Neil Armstrong wrote:
> On 19/06/2018 17:47, Jerome Brunet wrote:
> > The audio divider is one based. This offset was mistakenly dropped from
> > recalc_rate() when migrating to clk_regmap.
> >
> > Fixes: 88a4e1283681 ("clk: meson: migrate the audio divider
On Wed, 2018-06-20 at 10:31 +0200, Neil Armstrong wrote:
> On 19/06/2018 17:47, Jerome Brunet wrote:
> > The audio divider is one based. This offset was mistakenly dropped from
> > recalc_rate() when migrating to clk_regmap.
> >
> > Fixes: 88a4e1283681 ("clk: meson: migrate the audio divider
Takashi Iwai writes:
>> Special review query: review the "return of_node_get(node)", which
>> assumes that upon device removal, of_put_node(dev.of_node) will be
>> called...
>
> Is it really done automagically? I couldn't spot it.
Neither could I ...
I based this on
901 - 1000 of 1351 matches
Mail list logo
