Re: linux-next: manual merge of the tip tree with the openrisc tree
On Mon, Feb 20, 2017 at 12:28:44PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 20, 2017 at 12:18:05PM +0100, Peter Zijlstra wrote:
> > On Sun, Feb 19, 2017 at 04:26:54PM +0900, Stafford Horne wrote:
> > > On Fri, Feb 17, 2017 at 12:43:21PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of the tip tree got a conflict in:
> > > >
> > > > arch/openrisc/include/asm/Kbuild
> > > >
> > > > between commit:
> > > >
> > > > 157e82f58007 ("openrisc: add cmpxchg and xchg implementations")
> >
> > *groan* branch delay slots...
> >
> >
> > It it typically recommended to implement 1 and 2 byte versions as well.
> > If the architecture doesn't support these natively, you can easily
> > implement them with the 4 byte ll/sc and simply retain the other bits.
>
> While there; I spotted commit 8ffa662370f0 ("openrisc: add optimized
> atomic operations") which doesn't make any kind of sense to me.
>
> Have you actually read the asm-generic/atomic.h file you're including?
>
Hi Peter,
For 8ffa662370f0 ("openrisc: add optimized atomic operations")
As discussed on IRC, you are referring to the fact that this patch only
implements a few of the atomic operations. I initially thought there
was a reason for that (when doing the first review of Stefan's patch and
discussing with him). However, the issue is that this patch is against
the code before the atomic.h rewrite (3 years back).
This needs to be fixed by implementing all of the methods.
For 157e82f58007 ("openrisc: add cmpxchg and xchg implementations")
Also as discussed 1 and 2 byte ops are not currently used, however they
will become required when using qspinlock. Some example code exists
which could be borrowed for handling to bitmasking and alignment
complications. i.e.
arch/sh/include/asm/cmpxchg-xchg.h
These will be added. Possibly it would also be good to try and move
this generic 1 and 2 byte implementation code into include/asm?
I am not sure if I will have time to get these done before the merge
window. Ill see if I can get the time to work on them, if not I will
pull the "atomic operations" patch as its really just preparation for
the SMP work.
Also, going forward I will Cc you on any atomic or barrier related
patches.
-Stafford
Re: linux-next: manual merge of the tip tree with the openrisc tree
On Mon, Feb 20, 2017 at 12:28:44PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 20, 2017 at 12:18:05PM +0100, Peter Zijlstra wrote:
> > On Sun, Feb 19, 2017 at 04:26:54PM +0900, Stafford Horne wrote:
> > > On Fri, Feb 17, 2017 at 12:43:21PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of the tip tree got a conflict in:
> > > >
> > > > arch/openrisc/include/asm/Kbuild
> > > >
> > > > between commit:
> > > >
> > > > 157e82f58007 ("openrisc: add cmpxchg and xchg implementations")
> >
> > *groan* branch delay slots...
> >
> >
> > It it typically recommended to implement 1 and 2 byte versions as well.
> > If the architecture doesn't support these natively, you can easily
> > implement them with the 4 byte ll/sc and simply retain the other bits.
>
> While there; I spotted commit 8ffa662370f0 ("openrisc: add optimized
> atomic operations") which doesn't make any kind of sense to me.
>
> Have you actually read the asm-generic/atomic.h file you're including?
>
Hi Peter,
For 8ffa662370f0 ("openrisc: add optimized atomic operations")
As discussed on IRC, you are referring to the fact that this patch only
implements a few of the atomic operations. I initially thought there
was a reason for that (when doing the first review of Stefan's patch and
discussing with him). However, the issue is that this patch is against
the code before the atomic.h rewrite (3 years back).
This needs to be fixed by implementing all of the methods.
For 157e82f58007 ("openrisc: add cmpxchg and xchg implementations")
Also as discussed 1 and 2 byte ops are not currently used, however they
will become required when using qspinlock. Some example code exists
which could be borrowed for handling to bitmasking and alignment
complications. i.e.
arch/sh/include/asm/cmpxchg-xchg.h
These will be added. Possibly it would also be good to try and move
this generic 1 and 2 byte implementation code into include/asm?
I am not sure if I will have time to get these done before the merge
window. Ill see if I can get the time to work on them, if not I will
pull the "atomic operations" patch as its really just preparation for
the SMP work.
Also, going forward I will Cc you on any atomic or barrier related
patches.
-Stafford
Re: linux-next: manual merge of the tip tree with the openrisc tree
On Sun, Feb 19, 2017 at 04:26:54PM +0900, Stafford Horne wrote:
> On Fri, Feb 17, 2017 at 12:43:21PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > arch/openrisc/include/asm/Kbuild
> >
> > between commit:
> >
> > 157e82f58007 ("openrisc: add cmpxchg and xchg implementations")
*groan* branch delay slots...
It it typically recommended to implement 1 and 2 byte versions as well.
If the architecture doesn't support these natively, you can easily
implement them with the 4 byte ll/sc and simply retain the other bits.
Re: linux-next: manual merge of the tip tree with the openrisc tree
On Sun, Feb 19, 2017 at 04:26:54PM +0900, Stafford Horne wrote:
> On Fri, Feb 17, 2017 at 12:43:21PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > arch/openrisc/include/asm/Kbuild
> >
> > between commit:
> >
> > 157e82f58007 ("openrisc: add cmpxchg and xchg implementations")
*groan* branch delay slots...
It it typically recommended to implement 1 and 2 byte versions as well.
If the architecture doesn't support these natively, you can easily
implement them with the 4 byte ll/sc and simply retain the other bits.
Re: linux-next: manual merge of the tip tree with the openrisc tree
On Mon, Feb 20, 2017 at 12:18:05PM +0100, Peter Zijlstra wrote:
> On Sun, Feb 19, 2017 at 04:26:54PM +0900, Stafford Horne wrote:
> > On Fri, Feb 17, 2017 at 12:43:21PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the tip tree got a conflict in:
> > >
> > > arch/openrisc/include/asm/Kbuild
> > >
> > > between commit:
> > >
> > > 157e82f58007 ("openrisc: add cmpxchg and xchg implementations")
>
> *groan* branch delay slots...
>
>
> It it typically recommended to implement 1 and 2 byte versions as well.
> If the architecture doesn't support these natively, you can easily
> implement them with the 4 byte ll/sc and simply retain the other bits.
While there; I spotted commit 8ffa662370f0 ("openrisc: add optimized
atomic operations") which doesn't make any kind of sense to me.
Have you actually read the asm-generic/atomic.h file you're including?
Re: linux-next: manual merge of the tip tree with the openrisc tree
On Mon, Feb 20, 2017 at 12:18:05PM +0100, Peter Zijlstra wrote:
> On Sun, Feb 19, 2017 at 04:26:54PM +0900, Stafford Horne wrote:
> > On Fri, Feb 17, 2017 at 12:43:21PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the tip tree got a conflict in:
> > >
> > > arch/openrisc/include/asm/Kbuild
> > >
> > > between commit:
> > >
> > > 157e82f58007 ("openrisc: add cmpxchg and xchg implementations")
>
> *groan* branch delay slots...
>
>
> It it typically recommended to implement 1 and 2 byte versions as well.
> If the architecture doesn't support these natively, you can easily
> implement them with the 4 byte ll/sc and simply retain the other bits.
While there; I spotted commit 8ffa662370f0 ("openrisc: add optimized
atomic operations") which doesn't make any kind of sense to me.
Have you actually read the asm-generic/atomic.h file you're including?
Re: linux-next: manual merge of the tip tree with the openrisc tree
On Fri, Feb 17, 2017 at 12:43:21PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/openrisc/include/asm/Kbuild
>
> between commit:
>
> 157e82f58007 ("openrisc: add cmpxchg and xchg implementations")
>
> from the openrisc tree and commit:
>
> b672592f0221 ("sched/cputime: Remove generic asm headers")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thank you, the below looks good. I dont think there is much that can be
done other than sorting the conflict during merge.
I will mention this to linus. Hopefully this will be next week.
-Stafford
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/openrisc/include/asm/Kbuild
> index a669c141436e,ef8d1ccc3e45..
> --- a/arch/openrisc/include/asm/Kbuild
> +++ b/arch/openrisc/include/asm/Kbuild
> @@@ -9,7 -10,8 +9,6 @@@ generic-y += bugs.
> generic-y += cacheflush.h
> generic-y += checksum.h
> generic-y += clkdev.h
> - generic-y += cputime.h
> -generic-y += cmpxchg-local.h
> -generic-y += cmpxchg.h
> generic-y += current.h
> generic-y += device.h
> generic-y += div64.h
Re: linux-next: manual merge of the tip tree with the openrisc tree
On Fri, Feb 17, 2017 at 12:43:21PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/openrisc/include/asm/Kbuild
>
> between commit:
>
> 157e82f58007 ("openrisc: add cmpxchg and xchg implementations")
>
> from the openrisc tree and commit:
>
> b672592f0221 ("sched/cputime: Remove generic asm headers")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thank you, the below looks good. I dont think there is much that can be
done other than sorting the conflict during merge.
I will mention this to linus. Hopefully this will be next week.
-Stafford
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/openrisc/include/asm/Kbuild
> index a669c141436e,ef8d1ccc3e45..
> --- a/arch/openrisc/include/asm/Kbuild
> +++ b/arch/openrisc/include/asm/Kbuild
> @@@ -9,7 -10,8 +9,6 @@@ generic-y += bugs.
> generic-y += cacheflush.h
> generic-y += checksum.h
> generic-y += clkdev.h
> - generic-y += cputime.h
> -generic-y += cmpxchg-local.h
> -generic-y += cmpxchg.h
> generic-y += current.h
> generic-y += device.h
> generic-y += div64.h
