Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-21 Thread Leizhen (ThunderTown) 


On 2016/6/20 14:39, Leizhen (ThunderTown) wrote:
> 
> 
> On 2016/6/14 22:22, Catalin Marinas wrote:
>> On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote:
>>> On 2016/6/7 21:58, Will Deacon wrote:
 On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
> v3 -> v4:
> 1. Packed three patches of Kefeng Wang, patch6-8.
> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
>
> v2 -> v3:
> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to 
> make the
>patches looks more well. The final code have no change. 
>
> v1 -> v2:
> 1. Base on https://lkml.org/lkml/2016/5/24/679

 If you want bug fixes to land in 4.7, you'll need to base them on a
 mainline kernel.
>>>
>>> I heared that David Daney's acpi numa patch series was accepted and
>>> put into next branch(Linux 4.8).
>>> Otherwise I will suggest him sending his patch6-7 to mainline first.
>>> So that, only a very small conflict will be exist.
>>>
>>> I also tested that:
>>> 1. git am David Daney's patch6-7, then git am all of my patches on a
>>> branch, named branch A.
>>> 2. git am David Daney's patch6-7 on another branch, named branch B.
>>> 3. when I git merge B into branch A, it's still conflict. So I guess
>>> git merge is based on source code, rather than patches.
>>>
>>> So at present, unless the maintainers are willing to resolve the
>>> conflict, otherwise I update my patches will not work.
>>
>> It usually depends on how complex the conflict is and whether your
>> patches functionally depend on the other patches. I have no idea what
>> the dependency is here since I haven't tried applying them to mainline.
>>
>>> Fortunately, these patches are not particularly urgent. So I think I
>>> can wait until Linux 4.8 start, then send these patches again. But I'm
>>> not sure whether these patches can be merged into Linux 4.8, I really
>>> hope.
>>
>> If there are fixes to the arm64 ACPI NUMA patches that Rafael queued
>> into linux-next, they should be sent to him and potentially being queued
>> on top ahead of the 4.8 merging window or shortly after 4.8-rc1.
>> Non-ACPI NUMA patches (as I can see, most of these patches are DT
>> specific) could be merged independently.
>>
>> So how many patches do you have in each category below:
>>
>> 1. NUMA fixes against current mainline (4.7-rc3)
>> 2. NUMA fixes against the arm64 ACPI NUMA patches queued by Rafael
> My patches have not fixed any bugs for ACPI NUMA, but just based on it.
> There are only three related patches:
> [PATCH v7 06_15] arm64, numa  rework numa_add_memblk()
> [PATCH v7 07_15] arm64, numa  Cleanup NUMA disabled messages.
> [PATCH v7 14_15] arm64, acpi, numa  NUMA support based on SRAT and SLIT
> 
> arch/arm64/mm/numa.c  |  28 --
> drivers/of/of_numa.c  |   4 +-
> 
> My patches 1-5, 8, 11 will confict with it.
> 
>> 3. New functionality or clean-up. Are these against mainline or ACPI
>>NUMA patches?
> Hi, Catalin
> I'm sorry to reply this email too late. Because I have been thinking if
> there are any other solutions.
> 
> I try to adjust the sequence of my patches as below:
> 1. New functionality  //queued in your branch  (my patches 9-14, and 
> 6, 6 is clean-up)
> 2. 4.8-rc1//apci numa series and my new functionality had 
> been merged
> 3. bug fixes  //other 4.8-rc versions  (my patches 1-5)
> 4. clean-up (pr_fmt)  //queued in 4.9  (my patches 7-8)

Hi, Catalin
  What about your opinion? Are you agree?

> 
> And there only one confliction exist:
> ++<<< HEAD
>  +static u8 numa_distance[MAX_NUMNODES][MAX_NUMNODES];
> //choose this
>  +static int numa_off;
> ++===
> + static int numa_distance_cnt;
> + static u8 *numa_distance;
> + static bool numa_off;   
> //choose this
> ++>>> acpi
> 
>>

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-21 Thread Leizhen (ThunderTown) 


On 2016/6/20 14:39, Leizhen (ThunderTown) wrote:
> 
> 
> On 2016/6/14 22:22, Catalin Marinas wrote:
>> On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote:
>>> On 2016/6/7 21:58, Will Deacon wrote:
 On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
> v3 -> v4:
> 1. Packed three patches of Kefeng Wang, patch6-8.
> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
>
> v2 -> v3:
> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to 
> make the
>patches looks more well. The final code have no change. 
>
> v1 -> v2:
> 1. Base on https://lkml.org/lkml/2016/5/24/679

 If you want bug fixes to land in 4.7, you'll need to base them on a
 mainline kernel.
>>>
>>> I heared that David Daney's acpi numa patch series was accepted and
>>> put into next branch(Linux 4.8).
>>> Otherwise I will suggest him sending his patch6-7 to mainline first.
>>> So that, only a very small conflict will be exist.
>>>
>>> I also tested that:
>>> 1. git am David Daney's patch6-7, then git am all of my patches on a
>>> branch, named branch A.
>>> 2. git am David Daney's patch6-7 on another branch, named branch B.
>>> 3. when I git merge B into branch A, it's still conflict. So I guess
>>> git merge is based on source code, rather than patches.
>>>
>>> So at present, unless the maintainers are willing to resolve the
>>> conflict, otherwise I update my patches will not work.
>>
>> It usually depends on how complex the conflict is and whether your
>> patches functionally depend on the other patches. I have no idea what
>> the dependency is here since I haven't tried applying them to mainline.
>>
>>> Fortunately, these patches are not particularly urgent. So I think I
>>> can wait until Linux 4.8 start, then send these patches again. But I'm
>>> not sure whether these patches can be merged into Linux 4.8, I really
>>> hope.
>>
>> If there are fixes to the arm64 ACPI NUMA patches that Rafael queued
>> into linux-next, they should be sent to him and potentially being queued
>> on top ahead of the 4.8 merging window or shortly after 4.8-rc1.
>> Non-ACPI NUMA patches (as I can see, most of these patches are DT
>> specific) could be merged independently.
>>
>> So how many patches do you have in each category below:
>>
>> 1. NUMA fixes against current mainline (4.7-rc3)
>> 2. NUMA fixes against the arm64 ACPI NUMA patches queued by Rafael
> My patches have not fixed any bugs for ACPI NUMA, but just based on it.
> There are only three related patches:
> [PATCH v7 06_15] arm64, numa  rework numa_add_memblk()
> [PATCH v7 07_15] arm64, numa  Cleanup NUMA disabled messages.
> [PATCH v7 14_15] arm64, acpi, numa  NUMA support based on SRAT and SLIT
> 
> arch/arm64/mm/numa.c  |  28 --
> drivers/of/of_numa.c  |   4 +-
> 
> My patches 1-5, 8, 11 will confict with it.
> 
>> 3. New functionality or clean-up. Are these against mainline or ACPI
>>NUMA patches?
> Hi, Catalin
> I'm sorry to reply this email too late. Because I have been thinking if
> there are any other solutions.
> 
> I try to adjust the sequence of my patches as below:
> 1. New functionality  //queued in your branch  (my patches 9-14, and 
> 6, 6 is clean-up)
> 2. 4.8-rc1//apci numa series and my new functionality had 
> been merged
> 3. bug fixes  //other 4.8-rc versions  (my patches 1-5)
> 4. clean-up (pr_fmt)  //queued in 4.9  (my patches 7-8)

Hi, Catalin
  What about your opinion? Are you agree?

> 
> And there only one confliction exist:
> ++<<< HEAD
>  +static u8 numa_distance[MAX_NUMNODES][MAX_NUMNODES];
> //choose this
>  +static int numa_off;
> ++===
> + static int numa_distance_cnt;
> + static u8 *numa_distance;
> + static bool numa_off;   
> //choose this
> ++>>> acpi
> 
>>

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-20 Thread Leizhen (ThunderTown) 


On 2016/6/14 22:22, Catalin Marinas wrote:
> On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/6/7 21:58, Will Deacon wrote:
>>> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
 v3 -> v4:
 1. Packed three patches of Kefeng Wang, patch6-8.
 2. Add 6 new patches(9-15) to enhance the numa on arm64.

 v2 -> v3:
 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to 
 make the
patches looks more well. The final code have no change. 

 v1 -> v2:
 1. Base on https://lkml.org/lkml/2016/5/24/679
>>>
>>> If you want bug fixes to land in 4.7, you'll need to base them on a
>>> mainline kernel.
>>
>> I heared that David Daney's acpi numa patch series was accepted and
>> put into next branch(Linux 4.8).
>> Otherwise I will suggest him sending his patch6-7 to mainline first.
>> So that, only a very small conflict will be exist.
>>
>> I also tested that:
>> 1. git am David Daney's patch6-7, then git am all of my patches on a
>> branch, named branch A.
>> 2. git am David Daney's patch6-7 on another branch, named branch B.
>> 3. when I git merge B into branch A, it's still conflict. So I guess
>> git merge is based on source code, rather than patches.
>>
>> So at present, unless the maintainers are willing to resolve the
>> conflict, otherwise I update my patches will not work.
> 
> It usually depends on how complex the conflict is and whether your
> patches functionally depend on the other patches. I have no idea what
> the dependency is here since I haven't tried applying them to mainline.
> 
>> Fortunately, these patches are not particularly urgent. So I think I
>> can wait until Linux 4.8 start, then send these patches again. But I'm
>> not sure whether these patches can be merged into Linux 4.8, I really
>> hope.
> 
> If there are fixes to the arm64 ACPI NUMA patches that Rafael queued
> into linux-next, they should be sent to him and potentially being queued
> on top ahead of the 4.8 merging window or shortly after 4.8-rc1.
> Non-ACPI NUMA patches (as I can see, most of these patches are DT
> specific) could be merged independently.
> 
> So how many patches do you have in each category below:
> 
> 1. NUMA fixes against current mainline (4.7-rc3)
> 2. NUMA fixes against the arm64 ACPI NUMA patches queued by Rafael
My patches have not fixed any bugs for ACPI NUMA, but just based on it.
There are only three related patches:
[PATCH v7 06_15] arm64, numa  rework numa_add_memblk()
[PATCH v7 07_15] arm64, numa  Cleanup NUMA disabled messages.
[PATCH v7 14_15] arm64, acpi, numa  NUMA support based on SRAT and SLIT

arch/arm64/mm/numa.c  |  28 --
drivers/of/of_numa.c  |   4 +-

My patches 1-5, 8, 11 will confict with it.

> 3. New functionality or clean-up. Are these against mainline or ACPI
>NUMA patches?
Hi, Catalin
I'm sorry to reply this email too late. Because I have been thinking if
there are any other solutions.

I try to adjust the sequence of my patches as below:
1. New functionality//queued in your branch  (my patches 9-14, and 
6, 6 is clean-up)
2. 4.8-rc1  //apci numa series and my new functionality had 
been merged
3. bug fixes//other 4.8-rc versions  (my patches 1-5)
4. clean-up (pr_fmt)//queued in 4.9  (my patches 7-8)

And there only one confliction exist:
++<<< HEAD
 +static u8 numa_distance[MAX_NUMNODES][MAX_NUMNODES];  
//choose this
 +static int numa_off;
++===
+ static int numa_distance_cnt;
+ static u8 *numa_distance;
+ static bool numa_off; 
//choose this
++>>> acpi

>

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-20 Thread Leizhen (ThunderTown) 


On 2016/6/14 22:22, Catalin Marinas wrote:
> On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/6/7 21:58, Will Deacon wrote:
>>> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
 v3 -> v4:
 1. Packed three patches of Kefeng Wang, patch6-8.
 2. Add 6 new patches(9-15) to enhance the numa on arm64.

 v2 -> v3:
 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to 
 make the
patches looks more well. The final code have no change. 

 v1 -> v2:
 1. Base on https://lkml.org/lkml/2016/5/24/679
>>>
>>> If you want bug fixes to land in 4.7, you'll need to base them on a
>>> mainline kernel.
>>
>> I heared that David Daney's acpi numa patch series was accepted and
>> put into next branch(Linux 4.8).
>> Otherwise I will suggest him sending his patch6-7 to mainline first.
>> So that, only a very small conflict will be exist.
>>
>> I also tested that:
>> 1. git am David Daney's patch6-7, then git am all of my patches on a
>> branch, named branch A.
>> 2. git am David Daney's patch6-7 on another branch, named branch B.
>> 3. when I git merge B into branch A, it's still conflict. So I guess
>> git merge is based on source code, rather than patches.
>>
>> So at present, unless the maintainers are willing to resolve the
>> conflict, otherwise I update my patches will not work.
> 
> It usually depends on how complex the conflict is and whether your
> patches functionally depend on the other patches. I have no idea what
> the dependency is here since I haven't tried applying them to mainline.
> 
>> Fortunately, these patches are not particularly urgent. So I think I
>> can wait until Linux 4.8 start, then send these patches again. But I'm
>> not sure whether these patches can be merged into Linux 4.8, I really
>> hope.
> 
> If there are fixes to the arm64 ACPI NUMA patches that Rafael queued
> into linux-next, they should be sent to him and potentially being queued
> on top ahead of the 4.8 merging window or shortly after 4.8-rc1.
> Non-ACPI NUMA patches (as I can see, most of these patches are DT
> specific) could be merged independently.
> 
> So how many patches do you have in each category below:
> 
> 1. NUMA fixes against current mainline (4.7-rc3)
> 2. NUMA fixes against the arm64 ACPI NUMA patches queued by Rafael
My patches have not fixed any bugs for ACPI NUMA, but just based on it.
There are only three related patches:
[PATCH v7 06_15] arm64, numa  rework numa_add_memblk()
[PATCH v7 07_15] arm64, numa  Cleanup NUMA disabled messages.
[PATCH v7 14_15] arm64, acpi, numa  NUMA support based on SRAT and SLIT

arch/arm64/mm/numa.c  |  28 --
drivers/of/of_numa.c  |   4 +-

My patches 1-5, 8, 11 will confict with it.

> 3. New functionality or clean-up. Are these against mainline or ACPI
>NUMA patches?
Hi, Catalin
I'm sorry to reply this email too late. Because I have been thinking if
there are any other solutions.

I try to adjust the sequence of my patches as below:
1. New functionality//queued in your branch  (my patches 9-14, and 
6, 6 is clean-up)
2. 4.8-rc1  //apci numa series and my new functionality had 
been merged
3. bug fixes//other 4.8-rc versions  (my patches 1-5)
4. clean-up (pr_fmt)//queued in 4.9  (my patches 7-8)

And there only one confliction exist:
++<<< HEAD
 +static u8 numa_distance[MAX_NUMNODES][MAX_NUMNODES];  
//choose this
 +static int numa_off;
++===
+ static int numa_distance_cnt;
+ static u8 *numa_distance;
+ static bool numa_off; 
//choose this
++>>> acpi

>

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-14 Thread Catalin Marinas 
On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote:
> On 2016/6/7 21:58, Will Deacon wrote:
> > On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
> >> v3 -> v4:
> >> 1. Packed three patches of Kefeng Wang, patch6-8.
> >> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
> >>
> >> v2 -> v3:
> >> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to 
> >> make the
> >>patches looks more well. The final code have no change. 
> >>
> >> v1 -> v2:
> >> 1. Base on https://lkml.org/lkml/2016/5/24/679
> > 
> > If you want bug fixes to land in 4.7, you'll need to base them on a
> > mainline kernel.
> 
> I heared that David Daney's acpi numa patch series was accepted and
> put into next branch(Linux 4.8).
> Otherwise I will suggest him sending his patch6-7 to mainline first.
> So that, only a very small conflict will be exist.
> 
> I also tested that:
> 1. git am David Daney's patch6-7, then git am all of my patches on a
> branch, named branch A.
> 2. git am David Daney's patch6-7 on another branch, named branch B.
> 3. when I git merge B into branch A, it's still conflict. So I guess
> git merge is based on source code, rather than patches.
> 
> So at present, unless the maintainers are willing to resolve the
> conflict, otherwise I update my patches will not work.

It usually depends on how complex the conflict is and whether your
patches functionally depend on the other patches. I have no idea what
the dependency is here since I haven't tried applying them to mainline.

> Fortunately, these patches are not particularly urgent. So I think I
> can wait until Linux 4.8 start, then send these patches again. But I'm
> not sure whether these patches can be merged into Linux 4.8, I really
> hope.

If there are fixes to the arm64 ACPI NUMA patches that Rafael queued
into linux-next, they should be sent to him and potentially being queued
on top ahead of the 4.8 merging window or shortly after 4.8-rc1.
Non-ACPI NUMA patches (as I can see, most of these patches are DT
specific) could be merged independently.

So how many patches do you have in each category below:

1. NUMA fixes against current mainline (4.7-rc3)
2. NUMA fixes against the arm64 ACPI NUMA patches queued by Rafael
3. New functionality or clean-up. Are these against mainline or ACPI
   NUMA patches?

-- 
Catalin

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-14 Thread Catalin Marinas 
On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote:
> On 2016/6/7 21:58, Will Deacon wrote:
> > On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
> >> v3 -> v4:
> >> 1. Packed three patches of Kefeng Wang, patch6-8.
> >> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
> >>
> >> v2 -> v3:
> >> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to 
> >> make the
> >>patches looks more well. The final code have no change. 
> >>
> >> v1 -> v2:
> >> 1. Base on https://lkml.org/lkml/2016/5/24/679
> > 
> > If you want bug fixes to land in 4.7, you'll need to base them on a
> > mainline kernel.
> 
> I heared that David Daney's acpi numa patch series was accepted and
> put into next branch(Linux 4.8).
> Otherwise I will suggest him sending his patch6-7 to mainline first.
> So that, only a very small conflict will be exist.
> 
> I also tested that:
> 1. git am David Daney's patch6-7, then git am all of my patches on a
> branch, named branch A.
> 2. git am David Daney's patch6-7 on another branch, named branch B.
> 3. when I git merge B into branch A, it's still conflict. So I guess
> git merge is based on source code, rather than patches.
> 
> So at present, unless the maintainers are willing to resolve the
> conflict, otherwise I update my patches will not work.

It usually depends on how complex the conflict is and whether your
patches functionally depend on the other patches. I have no idea what
the dependency is here since I haven't tried applying them to mainline.

> Fortunately, these patches are not particularly urgent. So I think I
> can wait until Linux 4.8 start, then send these patches again. But I'm
> not sure whether these patches can be merged into Linux 4.8, I really
> hope.

If there are fixes to the arm64 ACPI NUMA patches that Rafael queued
into linux-next, they should be sent to him and potentially being queued
on top ahead of the 4.8 merging window or shortly after 4.8-rc1.
Non-ACPI NUMA patches (as I can see, most of these patches are DT
specific) could be merged independently.

So how many patches do you have in each category below:

1. NUMA fixes against current mainline (4.7-rc3)
2. NUMA fixes against the arm64 ACPI NUMA patches queued by Rafael
3. New functionality or clean-up. Are these against mainline or ACPI
   NUMA patches?

-- 
Catalin

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-14 Thread Hanjun Guo 
On 2016/6/13 18:12, Will Deacon wrote:
> On Sun, Jun 12, 2016 at 03:09:46PM +0800, Hanjun Guo wrote:
>> On 2016/6/7 21:58, Will Deacon wrote:
>>> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
 v3 -> v4:
 1. Packed three patches of Kefeng Wang, patch6-8.
 2. Add 6 new patches(9-15) to enhance the numa on arm64.

 v2 -> v3:
 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to 
 make the
patches looks more well. The final code have no change. 

 v1 -> v2:
 1. Base on https://lkml.org/lkml/2016/5/24/679
>>> If you want bug fixes to land in 4.7, you'll need to base them on a
>>> mainline kernel.
>>>
>> Rafael queued ARM64 ACPI NUMA support for 4.8, and this patch set is based
>> on that with no urgent bugfixes, can this patch set be queued for 4.8?
> Up to Catalin, since he's handling the 4.8 merge window. It would be really
> nice if you could give us the heads up about dependencies like this in the
> future, preferably *before* the base part has already been merged. That way,
> it's easier to create shared topic branches and gives us more options if
> we think that conflicts are likely to occur.

Understood the maintenance difficulty will have, will do that next time.
Much appreciate if it can be merged for 4.8.

Thanks
Hanjun

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-14 Thread Hanjun Guo 
On 2016/6/13 18:12, Will Deacon wrote:
> On Sun, Jun 12, 2016 at 03:09:46PM +0800, Hanjun Guo wrote:
>> On 2016/6/7 21:58, Will Deacon wrote:
>>> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
 v3 -> v4:
 1. Packed three patches of Kefeng Wang, patch6-8.
 2. Add 6 new patches(9-15) to enhance the numa on arm64.

 v2 -> v3:
 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to 
 make the
patches looks more well. The final code have no change. 

 v1 -> v2:
 1. Base on https://lkml.org/lkml/2016/5/24/679
>>> If you want bug fixes to land in 4.7, you'll need to base them on a
>>> mainline kernel.
>>>
>> Rafael queued ARM64 ACPI NUMA support for 4.8, and this patch set is based
>> on that with no urgent bugfixes, can this patch set be queued for 4.8?
> Up to Catalin, since he's handling the 4.8 merge window. It would be really
> nice if you could give us the heads up about dependencies like this in the
> future, preferably *before* the base part has already been merged. That way,
> it's easier to create shared topic branches and gives us more options if
> we think that conflicts are likely to occur.

Understood the maintenance difficulty will have, will do that next time.
Much appreciate if it can be merged for 4.8.

Thanks
Hanjun

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-13 Thread Will Deacon 
On Sun, Jun 12, 2016 at 03:09:46PM +0800, Hanjun Guo wrote:
> On 2016/6/7 21:58, Will Deacon wrote:
> > On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
> >> v3 -> v4:
> >> 1. Packed three patches of Kefeng Wang, patch6-8.
> >> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
> >>
> >> v2 -> v3:
> >> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to 
> >> make the
> >>patches looks more well. The final code have no change. 
> >>
> >> v1 -> v2:
> >> 1. Base on https://lkml.org/lkml/2016/5/24/679
> > If you want bug fixes to land in 4.7, you'll need to base them on a
> > mainline kernel.
> >
> 
> Rafael queued ARM64 ACPI NUMA support for 4.8, and this patch set is based
> on that with no urgent bugfixes, can this patch set be queued for 4.8?

Up to Catalin, since he's handling the 4.8 merge window. It would be really
nice if you could give us the heads up about dependencies like this in the
future, preferably *before* the base part has already been merged. That way,
it's easier to create shared topic branches and gives us more options if
we think that conflicts are likely to occur.

Will

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-13 Thread Will Deacon 
On Sun, Jun 12, 2016 at 03:09:46PM +0800, Hanjun Guo wrote:
> On 2016/6/7 21:58, Will Deacon wrote:
> > On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
> >> v3 -> v4:
> >> 1. Packed three patches of Kefeng Wang, patch6-8.
> >> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
> >>
> >> v2 -> v3:
> >> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to 
> >> make the
> >>patches looks more well. The final code have no change. 
> >>
> >> v1 -> v2:
> >> 1. Base on https://lkml.org/lkml/2016/5/24/679
> > If you want bug fixes to land in 4.7, you'll need to base them on a
> > mainline kernel.
> >
> 
> Rafael queued ARM64 ACPI NUMA support for 4.8, and this patch set is based
> on that with no urgent bugfixes, can this patch set be queued for 4.8?

Up to Catalin, since he's handling the 4.8 merge window. It would be really
nice if you could give us the heads up about dependencies like this in the
future, preferably *before* the base part has already been merged. That way,
it's easier to create shared topic branches and gives us more options if
we think that conflicts are likely to occur.

Will

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-12 Thread Hanjun Guo 
Hi Will,

On 2016/6/7 21:58, Will Deacon wrote:
> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
>> v3 -> v4:
>> 1. Packed three patches of Kefeng Wang, patch6-8.
>> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
>>
>> v2 -> v3:
>> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make 
>> the
>>patches looks more well. The final code have no change. 
>>
>> v1 -> v2:
>> 1. Base on https://lkml.org/lkml/2016/5/24/679
> If you want bug fixes to land in 4.7, you'll need to base them on a
> mainline kernel.
>

Rafael queued ARM64 ACPI NUMA support for 4.8, and this patch set is based
on that with no urgent bugfixes, can this patch set be queued for 4.8?

Thanks
Hanjun

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-12 Thread Hanjun Guo 
Hi Will,

On 2016/6/7 21:58, Will Deacon wrote:
> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
>> v3 -> v4:
>> 1. Packed three patches of Kefeng Wang, patch6-8.
>> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
>>
>> v2 -> v3:
>> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make 
>> the
>>patches looks more well. The final code have no change. 
>>
>> v1 -> v2:
>> 1. Base on https://lkml.org/lkml/2016/5/24/679
> If you want bug fixes to land in 4.7, you'll need to base them on a
> mainline kernel.
>

Rafael queued ARM64 ACPI NUMA support for 4.8, and this patch set is based
on that with no urgent bugfixes, can this patch set be queued for 4.8?

Thanks
Hanjun

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-08 Thread Leizhen (ThunderTown) 


On 2016/6/7 21:58, Will Deacon wrote:
> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
>> v3 -> v4:
>> 1. Packed three patches of Kefeng Wang, patch6-8.
>> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
>>
>> v2 -> v3:
>> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make 
>> the
>>patches looks more well. The final code have no change. 
>>
>> v1 -> v2:
>> 1. Base on https://lkml.org/lkml/2016/5/24/679
> 
> If you want bug fixes to land in 4.7, you'll need to base them on a
> mainline kernel.

I heared that David Daney's acpi numa patch series was accepted and put into 
next branch(Linux 4.8).
Otherwise I will suggest him sending his patch6-7 to mainline first. So that, 
only a very small conflict
will be exist.

I also tested that:
1. git am David Daney's patch6-7, then git am all of my patches on a branch, 
named branch A.
2. git am David Daney's patch6-7 on another branch, named branch B.
3. when I git merge B into branch A, it's still conflict. So I guess git merge 
is based on source code, rather than patches.

So at present, unless the maintainers are willing to resolve the conflict, 
otherwise I update my patches will not work.

Fortunately, these patches are not particularly urgent. So I think I can wait 
until Linux 4.8 start, then send these patches again.
But I'm not sure whether these patches can be merged into Linux 4.8, I really 
hope.

> 
> Will
> 
> .
>

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-08 Thread Leizhen (ThunderTown) 


On 2016/6/7 21:58, Will Deacon wrote:
> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
>> v3 -> v4:
>> 1. Packed three patches of Kefeng Wang, patch6-8.
>> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
>>
>> v2 -> v3:
>> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make 
>> the
>>patches looks more well. The final code have no change. 
>>
>> v1 -> v2:
>> 1. Base on https://lkml.org/lkml/2016/5/24/679
> 
> If you want bug fixes to land in 4.7, you'll need to base them on a
> mainline kernel.

I heared that David Daney's acpi numa patch series was accepted and put into 
next branch(Linux 4.8).
Otherwise I will suggest him sending his patch6-7 to mainline first. So that, 
only a very small conflict
will be exist.

I also tested that:
1. git am David Daney's patch6-7, then git am all of my patches on a branch, 
named branch A.
2. git am David Daney's patch6-7 on another branch, named branch B.
3. when I git merge B into branch A, it's still conflict. So I guess git merge 
is based on source code, rather than patches.

So at present, unless the maintainers are willing to resolve the conflict, 
otherwise I update my patches will not work.

Fortunately, these patches are not particularly urgent. So I think I can wait 
until Linux 4.8 start, then send these patches again.
But I'm not sure whether these patches can be merged into Linux 4.8, I really 
hope.

> 
> Will
> 
> .
>

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-07 Thread Rob Herring 
On Tue, Jun 7, 2016 at 3:08 AM, Zhen Lei  wrote:
> v3 -> v4:
> 1. Packed three patches of Kefeng Wang, patch6-8.
> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
>
> v2 -> v3:
> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make 
> the
>patches looks more well. The final code have no change.
>
> v1 -> v2:
> 1. Base on https://lkml.org/lkml/2016/5/24/679
> 2. Rewrote of_numa_parse_memory_nodes according to Rob Herring's advice. So 
> that it looks more clear.
> 3. Rewrote patch 5 because some scenes were not considered before.
>
> Kefeng Wang (3):
>   of_numa: Use of_get_next_parent to simplify code
>   of_numa: Use pr_fmt()
>   arm64: numa: Use pr_fmt()
>
> Zhen Lei (11):
>   of/numa: remove a duplicated pr_debug information
>   of/numa: fix a memory@ node can only contains one memory block
>   arm64/numa: add nid check for memory block
>   of/numa: remove a duplicated warning
>   arm64/numa: avoid inconsistent information to be printed
>   arm64/numa: support HAVE_SETUP_PER_CPU_AREA
>   arm64/numa: define numa_distance as array to simplify code
>   arm64/numa: support HAVE_MEMORYLESS_NODES
>   arm64/numa: remove some useless code
>   of/numa: remove the constraint on the distances of node pairs
>   Documentation: remove the constraint on the distances of node pairs
>
>  Documentation/devicetree/bindings/numa.txt |   1 -
>  arch/arm64/Kconfig |  12 ++
>  arch/arm64/include/asm/numa.h  |   1 -
>  arch/arm64/kernel/smp.c|   1 +
>  arch/arm64/mm/numa.c   | 228 
> -
>  drivers/of/of_numa.c   |  87 +--
>  6 files changed, 180 insertions(+), 150 deletions(-)

For patches 1, 2, 4, 6, 7, and 13:

Acked-by: Rob Herring 

Rob

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-07 Thread Rob Herring 
On Tue, Jun 7, 2016 at 3:08 AM, Zhen Lei  wrote:
> v3 -> v4:
> 1. Packed three patches of Kefeng Wang, patch6-8.
> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
>
> v2 -> v3:
> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make 
> the
>patches looks more well. The final code have no change.
>
> v1 -> v2:
> 1. Base on https://lkml.org/lkml/2016/5/24/679
> 2. Rewrote of_numa_parse_memory_nodes according to Rob Herring's advice. So 
> that it looks more clear.
> 3. Rewrote patch 5 because some scenes were not considered before.
>
> Kefeng Wang (3):
>   of_numa: Use of_get_next_parent to simplify code
>   of_numa: Use pr_fmt()
>   arm64: numa: Use pr_fmt()
>
> Zhen Lei (11):
>   of/numa: remove a duplicated pr_debug information
>   of/numa: fix a memory@ node can only contains one memory block
>   arm64/numa: add nid check for memory block
>   of/numa: remove a duplicated warning
>   arm64/numa: avoid inconsistent information to be printed
>   arm64/numa: support HAVE_SETUP_PER_CPU_AREA
>   arm64/numa: define numa_distance as array to simplify code
>   arm64/numa: support HAVE_MEMORYLESS_NODES
>   arm64/numa: remove some useless code
>   of/numa: remove the constraint on the distances of node pairs
>   Documentation: remove the constraint on the distances of node pairs
>
>  Documentation/devicetree/bindings/numa.txt |   1 -
>  arch/arm64/Kconfig |  12 ++
>  arch/arm64/include/asm/numa.h  |   1 -
>  arch/arm64/kernel/smp.c|   1 +
>  arch/arm64/mm/numa.c   | 228 
> -
>  drivers/of/of_numa.c   |  87 +--
>  6 files changed, 180 insertions(+), 150 deletions(-)

For patches 1, 2, 4, 6, 7, and 13:

Acked-by: Rob Herring 

Rob

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-07 Thread Will Deacon 
On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
> v3 -> v4:
> 1. Packed three patches of Kefeng Wang, patch6-8.
> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
> 
> v2 -> v3:
> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make 
> the
>patches looks more well. The final code have no change. 
> 
> v1 -> v2:
> 1. Base on https://lkml.org/lkml/2016/5/24/679

If you want bug fixes to land in 4.7, you'll need to base them on a
mainline kernel.

Will

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-07 Thread Will Deacon 
On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
> v3 -> v4:
> 1. Packed three patches of Kefeng Wang, patch6-8.
> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
> 
> v2 -> v3:
> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make 
> the
>patches looks more well. The final code have no change. 
> 
> v1 -> v2:
> 1. Base on https://lkml.org/lkml/2016/5/24/679

If you want bug fixes to land in 4.7, you'll need to base them on a
mainline kernel.

Will