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"},
{},
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
Hi Stafford,
On Mon, 25 Jan 2021 10:04:46 +0900 Stafford Horne <[email protected]> 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
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 <[email protected]> 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