All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
	ARM <linux-arm-kernel@lists.infradead.org>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Janusz Krzysztofik <jmkrzyszt@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: linux-next: manual merge of the arm-soc tree with Linus' tree
Date: Mon, 29 Oct 2018 08:02:27 -0700	[thread overview]
Message-ID: <20181029150227.GA56754@atomide.com> (raw)
In-Reply-To: <20181029101401.5687153e@canb.auug.org.au>

* Stephen Rothwell <sfr@canb.auug.org.au> [181028 23:14]:
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in:
> 
>   include/linux/platform_data/gpio-omap.h
> 
> between commit:
> 
>   b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")
> 
> from Linus' tree and commit:
> 
>   26683316c92a ("ARM: OMAP1: ams-delta-fiq: Use <linux/platform_data/gpio-omap.h>")
> 
> from the arm-soc 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.

Thanks it probably makes sense to merge in the immutable gpio branch
also into arm-soc tree that Linus Walleij has set up earlier. That's the
ib-omap branch at commit 5284521a290e ("gpio: omap: Get rid of
pm_runtime_irq_safe()").

Regards,

Tony

> diff --cc include/linux/platform_data/gpio-omap.h
> index 8485c6a9a383,ed071f76b642..000000000000
> --- a/include/linux/platform_data/gpio-omap.h
> +++ b/include/linux/platform_data/gpio-omap.h
> @@@ -205,4 -206,18 +208,6 @@@ struct omap_gpio_platform_data 
>   	int (*get_context_loss_count)(struct device *dev);
>   };
>   
>  -#if IS_BUILTIN(CONFIG_GPIO_OMAP)
>  -extern void omap2_gpio_prepare_for_idle(int off_mode);
>  -extern void omap2_gpio_resume_after_idle(void);
>  -#else
>  -static inline void omap2_gpio_prepare_for_idle(int off_mode)
>  -{
>  -}
>  -
>  -static inline void omap2_gpio_resume_after_idle(void)
>  -{
>  -}
>  -#endif
> + #endif /* __ASSEMBLER__ */
> + 
>   #endif

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: linux-next: manual merge of the arm-soc tree with Linus' tree
Date: Mon, 29 Oct 2018 08:02:27 -0700	[thread overview]
Message-ID: <20181029150227.GA56754@atomide.com> (raw)
In-Reply-To: <20181029101401.5687153e@canb.auug.org.au>

* Stephen Rothwell <sfr@canb.auug.org.au> [181028 23:14]:
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in:
> 
>   include/linux/platform_data/gpio-omap.h
> 
> between commit:
> 
>   b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")
> 
> from Linus' tree and commit:
> 
>   26683316c92a ("ARM: OMAP1: ams-delta-fiq: Use <linux/platform_data/gpio-omap.h>")
> 
> from the arm-soc 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.

Thanks it probably makes sense to merge in the immutable gpio branch
also into arm-soc tree that Linus Walleij has set up earlier. That's the
ib-omap branch at commit 5284521a290e ("gpio: omap: Get rid of
pm_runtime_irq_safe()").

Regards,

Tony

> diff --cc include/linux/platform_data/gpio-omap.h
> index 8485c6a9a383,ed071f76b642..000000000000
> --- a/include/linux/platform_data/gpio-omap.h
> +++ b/include/linux/platform_data/gpio-omap.h
> @@@ -205,4 -206,18 +208,6 @@@ struct omap_gpio_platform_data 
>   	int (*get_context_loss_count)(struct device *dev);
>   };
>   
>  -#if IS_BUILTIN(CONFIG_GPIO_OMAP)
>  -extern void omap2_gpio_prepare_for_idle(int off_mode);
>  -extern void omap2_gpio_resume_after_idle(void);
>  -#else
>  -static inline void omap2_gpio_prepare_for_idle(int off_mode)
>  -{
>  -}
>  -
>  -static inline void omap2_gpio_resume_after_idle(void)
>  -{
>  -}
>  -#endif
> + #endif /* __ASSEMBLER__ */
> + 
>   #endif

  reply	other threads:[~2018-10-29 15:02 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-28 23:14 linux-next: manual merge of the arm-soc tree with Linus' tree Stephen Rothwell
2018-10-28 23:14 ` Stephen Rothwell
2018-10-29 15:02 ` Tony Lindgren [this message]
2018-10-29 15:02   ` Tony Lindgren
  -- strict thread matches above, loose matches on Subject: below --
2022-05-27  0:39 Stephen Rothwell
2022-05-27  0:39 ` Stephen Rothwell
2022-05-27 15:38 ` Hawkins, Nick
2022-05-27 15:38   ` Hawkins, Nick
2022-05-28  0:29   ` Stephen Rothwell
2022-05-28  0:29     ` Stephen Rothwell
2019-06-23 22:54 Stephen Rothwell
2019-06-23 22:54 ` Stephen Rothwell
2018-10-28 23:08 Stephen Rothwell
2018-10-28 23:08 ` Stephen Rothwell
2016-09-05  0:58 Stephen Rothwell
2016-09-05  0:58 ` Stephen Rothwell
2016-09-05 18:26 ` Russell King - ARM Linux
2016-09-05 18:26   ` Russell King - ARM Linux
2016-09-06 10:17   ` Arnd Bergmann
2016-09-06 10:17     ` Arnd Bergmann
2016-09-06 10:42     ` Russell King - ARM Linux
2016-09-06 10:42       ` Russell King - ARM Linux
2016-09-25 16:07   ` Robert Jarzmik
2016-09-25 16:07     ` Robert Jarzmik
2016-01-20 22:40 Stephen Rothwell
2016-01-20 22:40 ` Stephen Rothwell
2016-01-20 22:40 ` Stephen Rothwell
2015-08-23 23:55 Stephen Rothwell
2015-08-23 23:55 ` Stephen Rothwell
2015-08-23 23:55 ` Stephen Rothwell
2015-06-01  0:25 Stephen Rothwell
2015-06-01  0:25 ` Stephen Rothwell
2015-06-01  0:25 ` Stephen Rothwell
2015-06-01  7:12 ` Michal Simek
2015-06-01  7:12   ` Michal Simek
2014-01-30  0:19 Stephen Rothwell
2014-01-30  0:19 ` Stephen Rothwell
2014-01-30  0:19 ` Stephen Rothwell
2014-01-30  5:33 ` Kevin Hilman
2014-01-30  5:33   ` Kevin Hilman
2014-01-30 21:47   ` Mike Turquette
2014-01-30 21:47     ` Mike Turquette
2014-01-23  0:23 Stephen Rothwell
2014-01-23  0:23 ` Stephen Rothwell
2014-01-23  0:23 ` Stephen Rothwell
2013-08-27  8:29 Stephen Rothwell
2013-08-27  8:29 ` Stephen Rothwell
2013-08-27  8:29 ` Stephen Rothwell
2013-08-27 16:17 ` Stephen Warren
2013-08-27 16:17   ` Stephen Warren
2013-08-28  0:06   ` Stephen Rothwell
2013-08-28  0:06     ` Stephen Rothwell
2013-08-27  8:26 Stephen Rothwell
2013-08-27  8:26 ` Stephen Rothwell
2013-08-27  8:26 ` Stephen Rothwell
2013-07-08  4:03 Stephen Rothwell
2013-07-08  4:03 ` Stephen Rothwell
2013-07-08  4:03 ` Stephen Rothwell
2013-03-18  3:49 Stephen Rothwell
2013-03-18  3:49 ` Stephen Rothwell
2013-03-18  3:49 ` Stephen Rothwell
2012-10-04  4:33 Stephen Rothwell
2012-10-04  4:33 ` Stephen Rothwell
2012-10-04  4:33 ` Stephen Rothwell
2012-07-30  2:53 Stephen Rothwell
2012-07-30  2:53 ` Stephen Rothwell
2012-07-30  2:53 ` Stephen Rothwell
2012-03-15  6:50 Stephen Rothwell
2012-03-15  6:50 ` Stephen Rothwell
2012-03-15  6:50 ` Stephen Rothwell
2012-03-15  9:51 ` Laurent Pinchart
2012-03-15  9:51   ` Laurent Pinchart
2012-03-15 20:01   ` Arnd Bergmann
2012-03-15 20:01     ` Arnd Bergmann
2012-03-15 21:36     ` Rafael J. Wysocki
2012-03-15 21:36       ` Rafael J. Wysocki
2012-03-08  6:07 Stephen Rothwell
2012-03-08  6:07 ` Stephen Rothwell
2012-03-08  6:07 ` Stephen Rothwell
2011-11-24  0:58 Stephen Rothwell
2011-11-24  0:58 ` Stephen Rothwell
2011-11-24 15:55 ` Arnd Bergmann
2011-11-06 23:33 Stephen Rothwell
2011-11-07 19:07 ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181029150227.GA56754@atomide.com \
    --to=tony@atomide.com \
    --cc=arnd@arndb.de \
    --cc=jmkrzyszt@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.