linux-next: manual merge of the openrisc tree with Linus' tree

linux-next: manual merge of the openrisc tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

Hi Jonas,

Today's linux-next merge of the openrisc tree got a conflict in
arch/openrisc/kernel/signal.c between commit d7cb66670905 ("openrisc:
don't use pt_regs in struct sigcontext") from Linus' tree and commit
ddf54eaa745b ("openrisc: don't use pt_regs in struct sigcontext") from
the openrisc tree.

Two slightly differentl versions of the same change.  I used the version
in Linus' tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

linux-next: manual merge of the openrisc tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

Hi all,

Today's linux-next merge of the openrisc tree got a conflict in:

  drivers/soc/litex/litex_soc_ctrl.c

between commit:

  e6dc077b7dff ("soc: litex: Fix compile warning when device tree is not configured")

from Linus' tree and commit:

  3706f9f76a4f ("drivers/soc/litex: Add restart handler")

from the openrisc 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/soc/litex/litex_soc_ctrl.c
index 9b0766384570,a7dd5be9fd5b..000000000000
--- a/drivers/soc/litex/litex_soc_ctrl.c
+++ b/drivers/soc/litex/litex_soc_ctrl.c
@@@ -138,9 -71,19 +71,20 @@@ static int litex_check_csr_access(void 
  
  struct litex_soc_ctrl_device {
  	void __iomem *base;
+ 	struct notifier_block reset_nb;
  };
  
+ static int litex_reset_handler(struct notifier_block *this, unsigned long mode,
+ 			       void *cmd)
+ {
+ 	struct litex_soc_ctrl_device *soc_ctrl_dev =
+ 		container_of(this, struct litex_soc_ctrl_device, reset_nb);
+ 
+ 	litex_write32(soc_ctrl_dev->base + RESET_REG_OFF, RESET_REG_VALUE);
+ 	return NOTIFY_DONE;
+ }
+ 
 +#ifdef CONFIG_OF
  static const struct of_device_id litex_soc_ctrl_of_match[] = {
  	{.compatible = "litex,soc-controller"},
  	{},

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the openrisc tree with Linus' tree

[Stafford Horne]

On Mon, Jan 25, 2021 at 09:05:06AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the openrisc tree got a conflict in:
> 
>   drivers/soc/litex/litex_soc_ctrl.c
> 
> between commit:
> 
>   e6dc077b7dff ("soc: litex: Fix compile warning when device tree is not configured")
> 
> from Linus' tree and commit:
> 
>   3706f9f76a4f ("drivers/soc/litex: Add restart handler")
> 
> from the openrisc 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.

Hi Stephen,

Thank's I knew about this conflict but I was not sure the best way to handle, I
was/am going to rebase the openrisc/for-next branch onto 5.11-rc5 once released.
I will resolve the conflict during the rebase so you should be able to drop the
conflict patch after that.

The issue is I had a fix that went straight to 5.11.  Should I usually put these
kind of fixes on my for-next and my fixes branches in parallel, that way I can
resolve conflicts on for-next before hand?

I don't usually do that as in my mind for next is for 5.12 and fixes for 5.11 go
straight to 5.11.  Also, I don't like putting the same patch in 2 queues.  But
if I got any advice on how to avoid this in the future it would be appreciated.

Thank you,

-Stafford

Re: linux-next: manual merge of the openrisc tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

Hi Stafford,

On Mon, 25 Jan 2021 10:04:46 +0900 Stafford Horne <shorne@gmail.com> wrote:
>
> Thank's I knew about this conflict but I was not sure the best way to handle, I
> was/am going to rebase the openrisc/for-next branch onto 5.11-rc5 once released.
> I will resolve the conflict during the rebase so you should be able to drop the
> conflict patch after that.

Its a pretty trivial conflict, so I wouldn't do the rebase just for this.

> The issue is I had a fix that went straight to 5.11.  Should I usually put these
> kind of fixes on my for-next and my fixes branches in parallel, that way I can
> resolve conflicts on for-next before hand?

I notice that the version in Linus' tree was merged from a separate
branch.  The easiest that to do is for you to merge that same branch
into your for-next branch - that way you only get your own changes, not
any other stuff that might be in Linus' tree.

> I don't usually do that as in my mind for next is for 5.12 and fixes for 5.11 go
> straight to 5.11.  Also, I don't like putting the same patch in 2 queues.  But
> if I got any advice on how to avoid this in the future it would be appreciated.

Like I said, just merge your fixes branch into you for-next branch
when/if you think the fixes are important for further development, or
the conflicts become to great.

I can also add you fixes branch to linux-next if you like (I already
have 86 other "fixes" branches).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the openrisc tree with Linus' tree

[Stafford Horne]

On Mon, Jan 25, 2021 at 12:47:46PM +1100, Stephen Rothwell wrote:
> Hi Stafford,
> 
> On Mon, 25 Jan 2021 10:04:46 +0900 Stafford Horne <shorne@gmail.com> wrote:
> >
> > Thank's I knew about this conflict but I was not sure the best way to handle, I
> > was/am going to rebase the openrisc/for-next branch onto 5.11-rc5 once released.
> > I will resolve the conflict during the rebase so you should be able to drop the
> > conflict patch after that.
> 
> Its a pretty trivial conflict, so I wouldn't do the rebase just for this.

Alright, I will not rebase.

> > The issue is I had a fix that went straight to 5.11.  Should I usually put these
> > kind of fixes on my for-next and my fixes branches in parallel, that way I can
> > resolve conflicts on for-next before hand?
> 
> I notice that the version in Linus' tree was merged from a separate
> branch.  The easiest that to do is for you to merge that same branch
> into your for-next branch - that way you only get your own changes, not
> any other stuff that might be in Linus' tree.
> 
> > I don't usually do that as in my mind for next is for 5.12 and fixes for 5.11 go
> > straight to 5.11.  Also, I don't like putting the same patch in 2 queues.  But
> > if I got any advice on how to avoid this in the future it would be appreciated.
> 
> Like I said, just merge your fixes branch into you for-next branch
> when/if you think the fixes are important for further development, or
> the conflicts become to great.

That sounds like a good idea.  Let me do that.

> I can also add you fixes branch to linux-next if you like (I already
> have 86 other "fixes" branches).

I think that should be alright for now, I'll maintain merging the fixes branch
myself when I think it's needed.

Thank you,

-Stafford