On Thu, Jun 28, 2018 at 06:36:38PM +0200, Sebastian Reichel wrote:
> Add information about 3V3 power rail to avoid kernel warnings,
> that dummy regulators have been added.
>
> Signed-off-by: Sebastian Reichel
I changed subject prefix to 'ARM: dts: imx53-ppd: ...', and applied
both.
Shawn
On Thu, Jun 28, 2018 at 06:36:38PM +0200, Sebastian Reichel wrote:
> Add information about 3V3 power rail to avoid kernel warnings,
> that dummy regulators have been added.
>
> Signed-off-by: Sebastian Reichel
I changed subject prefix to 'ARM: dts: imx53-ppd: ...', and applied
both.
Shawn
Hi Peter,
Thanks for the feedback. I'll make sure to incorporate it into my next
patch, and send that soon.
Thanks,
Isaac Manjarres
On 2018-07-02 05:15, Peter Zijlstra wrote:
On Fri, Jun 29, 2018 at 01:55:12PM -0700, Isaac J. Manjarres wrote:
When cpu_stop_queue_two_works() begins to wake the
Hi Peter,
Thanks for the feedback. I'll make sure to incorporate it into my next
patch, and send that soon.
Thanks,
Isaac Manjarres
On 2018-07-02 05:15, Peter Zijlstra wrote:
On Fri, Jun 29, 2018 at 01:55:12PM -0700, Isaac J. Manjarres wrote:
When cpu_stop_queue_two_works() begins to wake the
On Tue, Jul 3, 2018 at 3:34 AM, Ian Kent wrote:
> On Mon, 2018-07-02 at 14:15 +0200, Dmitry Vyukov wrote:
>> On Mon, Jul 2, 2018 at 1:55 PM, tomas wrote:
>> > Yes, thanks. Please use my full name, Tomas Bortoli.
>>
>>
>> Please also include:
>>
>> Reported-by:
On Tue, Jul 3, 2018 at 3:34 AM, Ian Kent wrote:
> On Mon, 2018-07-02 at 14:15 +0200, Dmitry Vyukov wrote:
>> On Mon, Jul 2, 2018 at 1:55 PM, tomas wrote:
>> > Yes, thanks. Please use my full name, Tomas Bortoli.
>>
>>
>> Please also include:
>>
>> Reported-by:
On Wed, Jun 27, 2018 at 09:37:13PM -0700, Andrey Smirnov wrote:
> Pinctrl_usbh1reg defines pinmux setting for reset GPIO used by
> usbh1phy, but is not referenced by that node. Fix that.
>
> Cc: Fabio Estevam
> Cc: Shawn Guo
> Cc: linux-arm-ker...@lists.infradead.org
> Cc:
On Wed, Jun 27, 2018 at 09:37:13PM -0700, Andrey Smirnov wrote:
> Pinctrl_usbh1reg defines pinmux setting for reset GPIO used by
> usbh1phy, but is not referenced by that node. Fix that.
>
> Cc: Fabio Estevam
> Cc: Shawn Guo
> Cc: linux-arm-ker...@lists.infradead.org
> Cc:
Hi,
Just gently ping.
May this patch be reviewed and merged?
Thanks,
Jian-Hong Pan
2018-05-25 17:54 GMT+08:00 Jian-Hong Pan :
> Without this patch we cannot turn on the Bluethooth adapter on HP
> 14-bs007la.
>
> T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 1.10
Hi,
Just gently ping.
May this patch be reviewed and merged?
Thanks,
Jian-Hong Pan
2018-05-25 17:54 GMT+08:00 Jian-Hong Pan :
> Without this patch we cannot turn on the Bluethooth adapter on HP
> 14-bs007la.
>
> T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 1.10
Rafael,
On 20 June 2018 at 19:22, Ulf Hansson wrote:
> Changes in v8:
> - Added some tags for reviews and acks.
> - Cleanup timer patch (patch6) according to comments from Rafael.
> - Rebased series on top of v4.18rc1 - it applied cleanly, except for patch 5.
> - While adopting patch 5 to
Rafael,
On 20 June 2018 at 19:22, Ulf Hansson wrote:
> Changes in v8:
> - Added some tags for reviews and acks.
> - Cleanup timer patch (patch6) according to comments from Rafael.
> - Rebased series on top of v4.18rc1 - it applied cleanly, except for patch 5.
> - While adopting patch 5 to
Although we can rely on cpuacct to present the cpu usage of task
group, it is hard to tell how intense the competition is between
these groups on cpu resources.
Monitoring the wait time of each process or sched_debug could cost
too much, and there is no good way to accurately represent the
Although we can rely on cpuacct to present the cpu usage of task
group, it is hard to tell how intense the competition is between
these groups on cpu resources.
Monitoring the wait time of each process or sched_debug could cost
too much, and there is no good way to accurately represent the
On Mon, Jul 2, 2018 at 7:18 PM, Olof Johansson wrote:
> Hi Jens,
>
>
> On Mon, Jul 2, 2018 at 5:10 AM, Jens Wiklander
> wrote:
>> Hello arm-soc maintainers,
>>
>> Please pull these small tee driver enhancements. There's a new config
>> option for the OP-TEE driver, OPTEE_SHM_NUM_PRIV_PAGES. Also
On Mon, Jul 2, 2018 at 7:18 PM, Olof Johansson wrote:
> Hi Jens,
>
>
> On Mon, Jul 2, 2018 at 5:10 AM, Jens Wiklander
> wrote:
>> Hello arm-soc maintainers,
>>
>> Please pull these small tee driver enhancements. There's a new config
>> option for the OP-TEE driver, OPTEE_SHM_NUM_PRIV_PAGES. Also
On Mon, Jul 02, 2018 at 02:12:52AM +, Robin Gong wrote:
> But in fact, the original dts is not correct without 'regulator-always-
> on'since SW4 is the critical DDR power rail, although, it's kept on in
> the previous kernel by no switches enable/disable interfaces provided
> in pfuze driver.
On Mon, Jul 02, 2018 at 02:12:52AM +, Robin Gong wrote:
> But in fact, the original dts is not correct without 'regulator-always-
> on'since SW4 is the critical DDR power rail, although, it's kept on in
> the previous kernel by no switches enable/disable interfaces provided
> in pfuze driver.
From: Wentao Wang
Add FITRIM ioctl for FAT file system
[hirof...@mail.parknet.co.jp: bug fixes, coding style fixes, add signal check]
Signed-off-by: Wentao Wang
Signed-off-by: OGAWA Hirofumi
---
fs/fat/fat.h|1
fs/fat/fatent.c | 102
From: Wentao Wang
Add FITRIM ioctl for FAT file system
[hirof...@mail.parknet.co.jp: bug fixes, coding style fixes, add signal check]
Signed-off-by: Wentao Wang
Signed-off-by: OGAWA Hirofumi
---
fs/fat/fat.h|1
fs/fat/fatent.c | 102
On 3 July 2018 at 04:25, Fabio Estevam wrote:
> On Mon, Jul 2, 2018 at 11:13 PM, Anson Huang wrote:
>
>> I think either way is OK, since flexible array is used in kernel code quite
>> commonly,
>> so I prefer to make code change as small as possible, the original patch can
>> also prevent
>>
On 3 July 2018 at 04:25, Fabio Estevam wrote:
> On Mon, Jul 2, 2018 at 11:13 PM, Anson Huang wrote:
>
>> I think either way is OK, since flexible array is used in kernel code quite
>> commonly,
>> so I prefer to make code change as small as possible, the original patch can
>> also prevent
>>
Matthew Wilcox writes:
> On Fri, Jun 22, 2018 at 11:51:38AM +0800, Huang, Ying wrote:
>> +++ b/mm/swap_state.c
>> @@ -426,33 +447,37 @@ struct page *__read_swap_cache_async(swp_entry_t
>> entry, gfp_t gfp_mask,
>> /*
>> * call radix_tree_preload() while we can wait.
Matthew Wilcox writes:
> On Fri, Jun 22, 2018 at 11:51:38AM +0800, Huang, Ying wrote:
>> +++ b/mm/swap_state.c
>> @@ -426,33 +447,37 @@ struct page *__read_swap_cache_async(swp_entry_t
>> entry, gfp_t gfp_mask,
>> /*
>> * call radix_tree_preload() while we can wait.
From: "Gautham R. Shenoy"
In the situations where snooze is the only cpuidle state due to
firmware not exposing any platform idle states, the idle CPUs will
remain in snooze for a long time with interrupts disabled causing the
Hard-lockup detector to complain.
watchdog: CPU 51 detected hard
From: "Gautham R. Shenoy"
In the situations where snooze is the only cpuidle state due to
firmware not exposing any platform idle states, the idle CPUs will
remain in snooze for a long time with interrupts disabled causing the
Hard-lockup detector to complain.
watchdog: CPU 51 detected hard
On Tue, 2018-07-03 at 12:39 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2018-07-02 at 19:26 -0700, Linus Torvalds wrote:
> > On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds
> > wrote:
> > >
> > > It's whitespace-damaged on purpose. It's probably broken shit. DO NOT
> > > USE UNDER ANY
On 07/02/2018 11:06 PM, Andrew Morton wrote:
> On Mon, 2 Jul 2018 09:50:49 +0200 Christian Borntraeger
> wrote:
>
>> KVM guests on s390 can notify the host of unused pages. This can result
>> in pte_unused callbacks to be true for KVM guest memory.
>>
>> If a page is unused (checked with
On 07/02/2018 11:06 PM, Andrew Morton wrote:
> On Mon, 2 Jul 2018 09:50:49 +0200 Christian Borntraeger
> wrote:
>
>> KVM guests on s390 can notify the host of unused pages. This can result
>> in pte_unused callbacks to be true for KVM guest memory.
>>
>> If a page is unused (checked with
On Tue, 2018-07-03 at 12:39 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2018-07-02 at 19:26 -0700, Linus Torvalds wrote:
> > On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds
> > wrote:
> > >
> > > It's whitespace-damaged on purpose. It's probably broken shit. DO NOT
> > > USE UNDER ANY
Replaces instances of "unsigned" with "unsigned int"; fixes comma and tab
spacing.
Signed-off-by: Peter Vernia
---
drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 35 +
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git
Replaces instances of "unsigned" with "unsigned int"; fixes comma and tab
spacing.
Signed-off-by: Peter Vernia
---
drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 35 +
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git
Hi all,
Changes since 20180702:
The net-next tree gained a build failure due to an interaction with Linus'
tree for which I applied a merge fix patch.
The akpm-current tree still had its build failure for which I reverted
a commit.
Non-merge commits (relative to Linus' tree): 3320
3593 files
Hi all,
Changes since 20180702:
The net-next tree gained a build failure due to an interaction with Linus'
tree for which I applied a merge fix patch.
The akpm-current tree still had its build failure for which I reverted
a commit.
Non-merge commits (relative to Linus' tree): 3320
3593 files
On Monday 02 July 2018 10:00 PM, Eduardo Valentin wrote:
> Keerthy,
>
> On Fri, Jun 29, 2018 at 06:10:26PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi,
>>
>> On Wednesday, May 02, 2018 03:20:35 PM Bartlomiej Zolnierkiewicz wrote:
>>> Majority of this code (i.e. functions from
On Monday 02 July 2018 10:00 PM, Eduardo Valentin wrote:
> Keerthy,
>
> On Fri, Jun 29, 2018 at 06:10:26PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi,
>>
>> On Wednesday, May 02, 2018 03:20:35 PM Bartlomiej Zolnierkiewicz wrote:
>>> Majority of this code (i.e. functions from
> The subject is over 72 characters or whatever the limit is and there
> isn't a commit message.
Dan, thanks for your help, I realize where I went wrong now. I will re-submit
the patch fresh to fix the message subject.
--Peter
> The subject is over 72 characters or whatever the limit is and there
> isn't a commit message.
Dan, thanks for your help, I realize where I went wrong now. I will re-submit
the patch fresh to fix the message subject.
--Peter
On Mon, Jul 2, 2018 at 9:43 PM Seung-Woo Kim wrote:
>
> I think the commit itself is required. Simple, but not reliable,
> workaround fix is like below:
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index a34d401..7c751f2 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1879,6 +1879,8 @@ void
On Mon, Jul 2, 2018 at 9:43 PM Seung-Woo Kim wrote:
>
> I think the commit itself is required. Simple, but not reliable,
> workaround fix is like below:
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index a34d401..7c751f2 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1879,6 +1879,8 @@ void
On Monday 02 July 2018 08:57 PM, David Lechner wrote:
> On 07/02/2018 07:08 AM, Sekhar Nori wrote:
>> Hi Bjorn,
>>
>> On Thursday 21 June 2018 05:11 PM, Bartosz Golaszewski wrote:
>>> 2018-06-21 12:52 GMT+02:00 Sekhar Nori :
Hi Bartosz,
On Thursday 21 June 2018 01:07 PM, Bartosz
On Monday 02 July 2018 08:57 PM, David Lechner wrote:
> On 07/02/2018 07:08 AM, Sekhar Nori wrote:
>> Hi Bjorn,
>>
>> On Thursday 21 June 2018 05:11 PM, Bartosz Golaszewski wrote:
>>> 2018-06-21 12:52 GMT+02:00 Sekhar Nori :
Hi Bartosz,
On Thursday 21 June 2018 01:07 PM, Bartosz
On 2018년 07월 03일 13:36, Greg KH wrote:
> On Tue, Jul 03, 2018 at 12:24:59PM +0900, Seung-Woo Kim wrote:
>> Hello,
>>
>> On 2018년 05월 30일 16:32, Greg KH wrote:
>>> I'm announcing the release of the 3.18.111 kernel.
>>>
>>> All users of the 3.18 kernel series must upgrade.
>>>
>>> The updated
On 2018년 07월 03일 13:36, Greg KH wrote:
> On Tue, Jul 03, 2018 at 12:24:59PM +0900, Seung-Woo Kim wrote:
>> Hello,
>>
>> On 2018년 05월 30일 16:32, Greg KH wrote:
>>> I'm announcing the release of the 3.18.111 kernel.
>>>
>>> All users of the 3.18 kernel series must upgrade.
>>>
>>> The updated
On Tue, Jul 03, 2018 at 12:11:19PM +0800, Yang Shi wrote:
> direct reclaim doesn't write out filesystem page, only kswapd could do
> this. So, if it is called from direct relaim, it is definitely a bug.
>
> And, Mel Gorman mentioned "Ultimately, this will be a BUG_ON." in commit
>
On Tue, Jul 03, 2018 at 12:11:19PM +0800, Yang Shi wrote:
> direct reclaim doesn't write out filesystem page, only kswapd could do
> this. So, if it is called from direct relaim, it is definitely a bug.
>
> And, Mel Gorman mentioned "Ultimately, this will be a BUG_ON." in commit
>
On Tue, Jul 03, 2018 at 12:24:59PM +0900, Seung-Woo Kim wrote:
> Hello,
>
> On 2018년 05월 30일 16:32, Greg KH wrote:
> > I'm announcing the release of the 3.18.111 kernel.
> >
> > All users of the 3.18 kernel series must upgrade.
> >
> > The updated 3.18.y git tree can be found at:
> >
On Tue, Jul 03, 2018 at 12:24:59PM +0900, Seung-Woo Kim wrote:
> Hello,
>
> On 2018년 05월 30일 16:32, Greg KH wrote:
> > I'm announcing the release of the 3.18.111 kernel.
> >
> > All users of the 3.18 kernel series must upgrade.
> >
> > The updated 3.18.y git tree can be found at:
> >
On 07/02/2018 05:08 PM, Christopher Lameter wrote:
> On Mon, 2 Jul 2018, John Hubbard wrote:
>
>>>
>>> These two are just wrong. You cannot make any page reference for
>>> PageDmaPinned() account against a pin count. First, it is just conceptually
>>> wrong as these references need not be long
On 07/02/2018 05:08 PM, Christopher Lameter wrote:
> On Mon, 2 Jul 2018, John Hubbard wrote:
>
>>>
>>> These two are just wrong. You cannot make any page reference for
>>> PageDmaPinned() account against a pin count. First, it is just conceptually
>>> wrong as these references need not be long
Cc-ing Linus, Tejun, Andrew
[I'll keep the entire lockdep report]
On (07/02/18 19:26), Tetsuo Handa wrote:
[..]
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606834] swapper/0/0 is trying
> to acquire lock:
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606835] 316e1432
>
Cc-ing Linus, Tejun, Andrew
[I'll keep the entire lockdep report]
On (07/02/18 19:26), Tetsuo Handa wrote:
[..]
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606834] swapper/0/0 is trying
> to acquire lock:
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606835] 316e1432
>
Hi Linus,
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: Monday, July 2, 2018 7:18 PM
> To: Naga Sureshkumar Relli
> Cc: Boris Brezillon ; Richard Weinberger
> ;
> David Woodhouse ; Brian Norris
> ; Mark Vasut ; Florian
> Fainelli
> ; Markus Mayer
Hi Linus,
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: Monday, July 2, 2018 7:18 PM
> To: Naga Sureshkumar Relli
> Cc: Boris Brezillon ; Richard Weinberger
> ;
> David Woodhouse ; Brian Norris
> ; Mark Vasut ; Florian
> Fainelli
> ; Markus Mayer
On 02-07-18, 16:27, Olof Johansson wrote:
> On Mon, Jul 02, 2018 at 02:25:40PM -0600, Rob Herring wrote:
> > On Fri, May 25, 2018 at 4:32 AM Viresh Kumar
> > wrote:
> > >
> > > The OPP properties, like "operating-points", should either be present
> > > for all the CPUs of a cluster or none. If
On 02-07-18, 16:27, Olof Johansson wrote:
> On Mon, Jul 02, 2018 at 02:25:40PM -0600, Rob Herring wrote:
> > On Fri, May 25, 2018 at 4:32 AM Viresh Kumar
> > wrote:
> > >
> > > The OPP properties, like "operating-points", should either be present
> > > for all the CPUs of a cluster or none. If
direct reclaim doesn't write out filesystem page, only kswapd could do
it. So, if the call comes from direct reclaim, it is definitely a bug.
And, Mel Gormane also mentioned "Ultimately, this will be a BUG_ON." In
commit 94054fa3fca1fd78db02cb3d68d5627120f0a1d4 ("xfs: warn if direct
reclaim tries
direct reclaim doesn't write out filesystem page, only kswapd could do
it. So, if the call comes from direct reclaim, it is definitely a bug.
And, Mel Gormane also mentioned "Ultimately, this will be a BUG_ON." In
commit 94054fa3fca1fd78db02cb3d68d5627120f0a1d4 ("xfs: warn if direct
reclaim tries
direct reclaim doesn't write out filesystem page, only kswapd could do
this. So, if it is called from direct relaim, it is definitely a bug.
And, Mel Gorman mentioned "Ultimately, this will be a BUG_ON." in commit
94054fa3fca1fd78db02cb3d68d5627120f0a1d4 ("xfs: warn if direct reclaim
tries to
direct reclaim doesn't write out filesystem page, only kswapd could do
this. So, if it is called from direct relaim, it is definitely a bug.
And, Mel Gorman mentioned "Ultimately, this will be a BUG_ON." in commit
94054fa3fca1fd78db02cb3d68d5627120f0a1d4 ("xfs: warn if direct reclaim
tries to
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev
head: 3981406d6621b8a72a873bdc88d0a95d2e928c9e
commit: 3981406d6621b8a72a873bdc88d0a95d2e928c9e [117/117] rcu: Define
RCU-sched API in terms of RCU for Tree RCU PREEMPT builds
config:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev
head: 3981406d6621b8a72a873bdc88d0a95d2e928c9e
commit: 3981406d6621b8a72a873bdc88d0a95d2e928c9e [117/117] rcu: Define
RCU-sched API in terms of RCU for Tree RCU PREEMPT builds
config:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev
head: 3981406d6621b8a72a873bdc88d0a95d2e928c9e
commit: 3981406d6621b8a72a873bdc88d0a95d2e928c9e [117/117] rcu: Define
RCU-sched API in terms of RCU for Tree RCU PREEMPT builds
config:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev
head: 3981406d6621b8a72a873bdc88d0a95d2e928c9e
commit: 3981406d6621b8a72a873bdc88d0a95d2e928c9e [117/117] rcu: Define
RCU-sched API in terms of RCU for Tree RCU PREEMPT builds
config:
On Mon, Jul 02, 2018 at 02:05:40PM -0700, Tejun Heo wrote:
> Hello, Paul.
>
> Sorry about the late reply.
>
> On Wed, Jun 20, 2018 at 12:29:01PM -0700, Paul E. McKenney wrote:
> > I have hit this WARN_ON_ONCE() in process_one_work:
> >
> > WARN_ON_ONCE(!(pool->flags & POOL_DISASSOCIATED) &&
On Mon, Jul 02, 2018 at 02:05:40PM -0700, Tejun Heo wrote:
> Hello, Paul.
>
> Sorry about the late reply.
>
> On Wed, Jun 20, 2018 at 12:29:01PM -0700, Paul E. McKenney wrote:
> > I have hit this WARN_ON_ONCE() in process_one_work:
> >
> > WARN_ON_ONCE(!(pool->flags & POOL_DISASSOCIATED) &&
On Sun, Jul 1, 2018 at 11:36 AM Guo Ren wrote:
>
> Signed-off-by: Guo Ren
> ---
[...]
> +config CSKY_BUILTIN_DTB
> + bool "Use kernel builtin dtb"
> +
> +config CSKY_BUILTIN_DTB_NAME
> + string "kernel builtin dtb name"
> + depends on CSKY_BUILTIN_DTB
> +endmenu
These
On Sun, Jul 1, 2018 at 11:36 AM Guo Ren wrote:
>
> Signed-off-by: Guo Ren
> ---
[...]
> +config CSKY_BUILTIN_DTB
> + bool "Use kernel builtin dtb"
> +
> +config CSKY_BUILTIN_DTB_NAME
> + string "kernel builtin dtb name"
> + depends on CSKY_BUILTIN_DTB
> +endmenu
These
On 2018-07-01 23:39, Miquel Raynal wrote:
Hi Abhishek,
Abhishek Sahu wrote on Wed, 20 Jun 2018
12:57:27 +0530:
* v4:
1. Added patch to make other ECC configurations function static.
2. Clubbed the DT update patches.
3. Removed the bad block related patch. Discussion is going on
related
On 2018-07-01 23:39, Miquel Raynal wrote:
Hi Abhishek,
Abhishek Sahu wrote on Wed, 20 Jun 2018
12:57:27 +0530:
* v4:
1. Added patch to make other ECC configurations function static.
2. Clubbed the DT update patches.
3. Removed the bad block related patch. Discussion is going on
related
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev
head: 673d4e1483611783d502fe63317483b294f1bba0
commit: 673d4e1483611783d502fe63317483b294f1bba0 [117/117] rcu: Define
RCU-sched API in terms of RCU for Tree RCU PREEMPT builds
config: powerpc-defconfig (attached
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev
head: 673d4e1483611783d502fe63317483b294f1bba0
commit: 673d4e1483611783d502fe63317483b294f1bba0 [117/117] rcu: Define
RCU-sched API in terms of RCU for Tree RCU PREEMPT builds
config: powerpc-defconfig (attached
On Sun, Jul 1, 2018 at 11:35 AM Guo Ren wrote:
>
Commit message needed.
> Signed-off-by: Guo Ren
> ---
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-csky-v1.c | 126
> drivers/irqchip/irq-csky-v2.c | 191
>
On Sun, Jul 1, 2018 at 11:35 AM Guo Ren wrote:
>
Commit message needed.
> Signed-off-by: Guo Ren
> ---
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-csky-v1.c | 126
> drivers/irqchip/irq-csky-v2.c | 191
>
Hello,
On 2018년 05월 30일 16:32, Greg KH wrote:
> I'm announcing the release of the 3.18.111 kernel.
>
> All users of the 3.18 kernel series must upgrade.
>
> The updated 3.18.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> linux-3.18.y
Hello,
On 2018년 05월 30일 16:32, Greg KH wrote:
> I'm announcing the release of the 3.18.111 kernel.
>
> All users of the 3.18 kernel series must upgrade.
>
> The updated 3.18.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> linux-3.18.y
On Sun, Jul 1, 2018 at 11:34 AM Guo Ren wrote:
>
Needs a commit msg. Perhaps some overview of what's in each config.
> Signed-off-by: Guo Ren
> ---
> arch/csky/configs/gx66xx_defconfig | 549
> +
> arch/csky/configs/qemu_ck807_defconfig | 541
On Sun, Jul 1, 2018 at 11:34 AM Guo Ren wrote:
>
Needs a commit msg. Perhaps some overview of what's in each config.
> Signed-off-by: Guo Ren
> ---
> arch/csky/configs/gx66xx_defconfig | 549
> +
> arch/csky/configs/qemu_ck807_defconfig | 541
Can you put it into memblock.c
> Do you think it looks ok if I add the inline prefix?
I would say no, this function is a too complex, and is not in some
critical path to be always inlined.
I would put it into memblock.c, and have #ifdef
CONFIG_HAVE_MEMBLOCK_PFN_VALID around it.
Thank you,
Can you put it into memblock.c
> Do you think it looks ok if I add the inline prefix?
I would say no, this function is a too complex, and is not in some
critical path to be always inlined.
I would put it into memblock.c, and have #ifdef
CONFIG_HAVE_MEMBLOCK_PFN_VALID around it.
Thank you,
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 9a93848fe787a53aec404e4e00d8f7f9bbdaebb4
Author: Peter Zijlstra
AuthorDate: Thu Feb 2 14:43:51 2017 +0100
Commit: Ingo
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 9a93848fe787a53aec404e4e00d8f7f9bbdaebb4
Author: Peter Zijlstra
AuthorDate: Thu Feb 2 14:43:51 2017 +0100
Commit: Ingo
On 一, 2018-07-02 at 18:47 +0530, Vinod wrote:
> On 02-07-18, 02:32, Robin Gong wrote:
> >
> > Hi Vinod,
> > Do you have any comment for this patchset? Lucas and Sascha
> > acked it and tty patch already merged in.
> I was actually waiting for ACK/action on patch 1 :)
>
> I have reviewed the
On 一, 2018-07-02 at 18:47 +0530, Vinod wrote:
> On 02-07-18, 02:32, Robin Gong wrote:
> >
> > Hi Vinod,
> > Do you have any comment for this patchset? Lucas and Sascha
> > acked it and tty patch already merged in.
> I was actually waiting for ACK/action on patch 1 :)
>
> I have reviewed the
On Mon, Jul 02, 2018 at 06:29:15AM -0700, Christoph Hellwig wrote:
> This commit is missing an explanation.
The patch is for abiv1 & abiv2 CPU series' MMU support.
- abiv1 CPU (CK610) is VIPT cache and it doesn't support highmem.
- abiv2 CPUs are all PIPT cache and they could support highmem.
On Mon, Jul 02, 2018 at 06:29:15AM -0700, Christoph Hellwig wrote:
> This commit is missing an explanation.
The patch is for abiv1 & abiv2 CPU series' MMU support.
- abiv1 CPU (CK610) is VIPT cache and it doesn't support highmem.
- abiv2 CPUs are all PIPT cache and they could support highmem.
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit ee410f15b1418f2f4428e79980674c979081bcb7
Author: Thierry Escande
AuthorDate: Thu Jun 14 15:28:15 2018 -0700
Commit:
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit ee410f15b1418f2f4428e79980674c979081bcb7
Author: Thierry Escande
AuthorDate: Thu Jun 14 15:28:15 2018 -0700
Commit:
On Tue, 3 Jul 2018 10:22:57 +0800 Jisheng Zhang wrote:
> Hi,
>
> On Mon, 2 Jul 2018 14:51:03 +0300 Andy Shevchenko wrote:
>
> > On Mon, 2018-07-02 at 13:18 +0300, Andy Shevchenko wrote:
> > > On Mon, 2018-07-02 at 18:04 +0800, Jisheng Zhang wrote:
> > > > For Synopsys DesignWare 8250 uart
On Tue, 3 Jul 2018 10:22:57 +0800 Jisheng Zhang wrote:
> Hi,
>
> On Mon, 2 Jul 2018 14:51:03 +0300 Andy Shevchenko wrote:
>
> > On Mon, 2018-07-02 at 13:18 +0300, Andy Shevchenko wrote:
> > > On Mon, 2018-07-02 at 18:04 +0800, Jisheng Zhang wrote:
> > > > For Synopsys DesignWare 8250 uart
On Mon, Jul 02, 2018 at 01:13:40PM -0500, David Lechner wrote:
>On 06/21/2018 04:06 PM, William Breathitt Gray wrote:
>> I decided to strip down these devices to arrive at the core essence of
>> what constitutes a "counter device" and therefore design a "generic
>> counter" abstraction to better
On Mon, Jul 02, 2018 at 01:13:40PM -0500, David Lechner wrote:
>On 06/21/2018 04:06 PM, William Breathitt Gray wrote:
>> I decided to strip down these devices to arrive at the core essence of
>> what constitutes a "counter device" and therefore design a "generic
>> counter" abstraction to better
On Mon, Jul 2, 2018 at 7:30 PM Mathieu Desnoyers
wrote:
>
>
> Is it really ? Last time we had this discussion, not all architectures
> guaranteed that reading a 64-bit integer would happen in two atomic
> 32-bit sub-parts.
All architectures that matter do.
Please don't overdesign this, or try
On Mon, Jul 2, 2018 at 7:30 PM Mathieu Desnoyers
wrote:
>
>
> Is it really ? Last time we had this discussion, not all architectures
> guaranteed that reading a 64-bit integer would happen in two atomic
> 32-bit sub-parts.
All architectures that matter do.
Please don't overdesign this, or try
Hi Robert,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18-rc3 next-20180702]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Robert,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18-rc3 next-20180702]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Tianyu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.18-rc3 next-20180702]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Mon, 2018-07-02 at 19:26 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds
> wrote:
> >
> > It's whitespace-damaged on purpose. It's probably broken shit. DO NOT
> > USE UNDER ANY CIRCUMSTANCES. Think of it more as a "something like
> > this might work, but
Hi Tianyu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.18-rc3 next-20180702]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Mon, 2018-07-02 at 19:26 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds
> wrote:
> >
> > It's whitespace-damaged on purpose. It's probably broken shit. DO NOT
> > USE UNDER ANY CIRCUMSTANCES. Think of it more as a "something like
> > this might work, but
1 - 100 of 1656 matches
Mail list logo
