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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/x86/include/asm/Kbuild between commit 10b63956fce7 ("UAPI: Plumb the
UAPI Kbuilds into the user header installation and checking") from Linus'
tree and commit e7a570ff7dff ("asm-generic: Add default clkdev.h") from
the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/include/asm/Kbuild
index 1595d68,66e5f0e..0000000
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@@ -22,3 -22,9 +22,5 @@@ header-y += sigcontext32.
  header-y += ucontext.h
  header-y += vm86.h
  header-y += vsyscall.h
+ 
 -genhdr-y += unistd_32.h
 -genhdr-y += unistd_64.h
 -genhdr-y += unistd_x32.h
 -
+ generic-y += clkdev.h

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/clocksource/Makefile

between commit:

  c92e7ef16400 ("clocksource/drivers: Add a goldfish-timer clocksource")

from Linus' tree and commit:

  5184f4bf151b ("clocksource/drivers/timer-gxp: Add HPE GXP Timer")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/clocksource/Makefile
index 833cfb7a96c1,98017abf6c03..000000000000
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@@ -85,4 -88,4 +85,5 @@@ obj-$(CONFIG_GX6605S_TIMER)		+= timer-g
  obj-$(CONFIG_HYPERV_TIMER)		+= hyperv_timer.o
  obj-$(CONFIG_MICROCHIP_PIT64B)		+= timer-microchip-pit64b.o
  obj-$(CONFIG_MSC313E_TIMER)		+= timer-msc313e.o
 +obj-$(CONFIG_GOLDFISH_TIMER)		+= timer-goldfish.o
+ obj-$(CONFIG_GXP_TIMER)			+= timer-gxp.o

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

RE: linux-next: manual merge of the arm-soc tree with Linus' tree

[Hawkins, Nick]

> Today's linux-next merge of the arm-soc tree got a conflict in:

>   drivers/clocksource/Makefile

> between commit:

>   c92e7ef16400 ("clocksource/drivers: Add a goldfish-timer clocksource")

> from Linus' tree and commit:

>   5184f4bf151b ("clocksource/drivers/timer-gxp: Add HPE GXP Timer")

> 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.

Hi Stephen,

Thank you for resolving the merge issue. I am relatively new to this process.. Can you provide a link to where you were notified of the merge conflict?

-Nick Hawkins

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

[Stephen Rothwell]

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

Hi Nick,

On Fri, 27 May 2022 15:38:56 +0000 "Hawkins, Nick" <nick.hawkins@hpe.com> wrote:
>
> > Today's linux-next merge of the arm-soc tree got a conflict in:  
> >
> >   drivers/clocksource/Makefile  
> >
> > between commit:  
> >
> >   c92e7ef16400 ("clocksource/drivers: Add a goldfish-timer clocksource")  
> >
> > from Linus' tree and commit:  
> >
> >   5184f4bf151b ("clocksource/drivers/timer-gxp: Add HPE GXP Timer")  
> >
> > 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.  
> 
> Hi Stephen,
> 
> Thank you for resolving the merge issue. I am relatively new to this
> process.. Can you provide a link to where you were notified of the
> merge conflict?

The purpose of linux-next (which is my project) is integration testing,
so I spend all day merging the branches that Linus will merge during
the merge window. The conflict appeared when I merged the arm-soc tree
yesterday.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm/include/debug/netx.S

between commit:

  d2912cb15bdd ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500")

from Linus' tree and commit:

  ceb02dcf676f ("ARM: delete netx machine")

from the arm-soc tree.

I fixed it up (I just removed the file) 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

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

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

[Stephen Rothwell]

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

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.

-- 
Cheers,
Stephen Rothwell

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

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

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

[Tony Lindgren]

* 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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/soc/qcom/Kconfig

between commit:

  a978a5b8d83f ("net/kconfig: Make QCOM_QMI_HELPERS available when COMPILE_TEST")

from Linus' tree and commit:

  ccfb464cd106 ("soc: qcom: Allow COMPILE_TEST of qcom SoC Kconfigs")

from the arm-soc tree.

I fixed it up (I just used the version in Linus' tree) 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

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

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

[Stephen Rothwell]

Hi all,

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

  arch/arm/mach-realview/core.c

between commit:

  2fb04fdf3019 ("net: smc91x: fix SMC accesses")

from Linus' tree and commit:

  7484c727b636 ("ARM: realview: delete the RealView board files")

from the arm-soc tree.

I fixed it up (I deleted the file) 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

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

[Russell King - ARM Linux]

On Mon, Sep 05, 2016 at 10:58:03AM +1000, Stephen Rothwell wrote:
> I fixed it up (I deleted the file) 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.

That's the "simple" way of making the conflict go away, but I'm afraid
it's really not that simple.

Having just looked at the SMC91x definition for realview, it shows that
the SMC91x binding, like many of the conversions that the patch in my
tree fixes, has been created without a proper understanding of the
hardware.  To put it simply, it is broken.

The binding only allows _one_ register width to be specified, which is
completely incorrect: the binding _must_ allow multiple register widths
to be specified.  This is what SMC91x has always expected: to be told
which register access widths it is permitted to make.

That must include at least one of 8 or 16 bit accesses, but 32-bit
access is optional.

The result will be that - despite I've fixed up all the static platform
data to be correct, there's no way to fix up the DT binding without
inventing a new one.

So, deleting the Realview (and other) board files results in platforms
that can't use networking - it's worse than that, because the smc91x
driver will BUG() as a result of this at boot time.

Since the patch in my tree is fixing a regression caused by the broken
conversions, I'm not mindful to drop it from the merge window - I
actually want to push it into -rc kernels.  We _do_ need to fix the
DT regressions, and quickly though, and push those with this patch.

Since I don't use the SMC91x with DT, that's outside of what I can
test, so consider this a call for help on that subject.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

[Arnd Bergmann]

On Monday, September 5, 2016 7:26:03 PM CEST Russell King - ARM Linux wrote:
> On Mon, Sep 05, 2016 at 10:58:03AM +1000, Stephen Rothwell wrote:
> > I fixed it up (I deleted the file) 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.
> 
> That's the "simple" way of making the conflict go away, but I'm afraid
> it's really not that simple.
> 
> Having just looked at the SMC91x definition for realview, it shows that
> the SMC91x binding, like many of the conversions that the patch in my
> tree fixes, has been created without a proper understanding of the
> hardware.  To put it simply, it is broken.
> 
> The binding only allows _one_ register width to be specified, which is
> completely incorrect: the binding _must_ allow multiple register widths
> to be specified.  This is what SMC91x has always expected: to be told
> which register access widths it is permitted to make.

This is what is documented:

Documentation/devicetree/bindings/net/smsc-lan91c111.txt
- reg-io-width : Mask of sizes (in bytes) of the IO accesses that
  are supported on the device.  Valid value for SMSC LAN91c111 are
  1, 2 or 4.  If it's omitted or invalid, the size would be 2 meaning
  16-bit access only.

and this appears to match what the driver does, although it is a
rather unconventional definition (I would have expected an array
of widths in bytes).

Almost all of the users leave out the property, so they get 16-bit
access, nomadik-nhk15 is the only one that actually specifies
the width explicitly, and it also requests 16-bit only. I don't
think your patch changes anything for these cases.

	Arnd

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

[Russell King - ARM Linux]

On Tue, Sep 06, 2016 at 12:17:48PM +0200, Arnd Bergmann wrote:
> On Monday, September 5, 2016 7:26:03 PM CEST Russell King - ARM Linux wrote:
> > On Mon, Sep 05, 2016 at 10:58:03AM +1000, Stephen Rothwell wrote:
> > > I fixed it up (I deleted the file) 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.
> > 
> > That's the "simple" way of making the conflict go away, but I'm afraid
> > it's really not that simple.
> > 
> > Having just looked at the SMC91x definition for realview, it shows that
> > the SMC91x binding, like many of the conversions that the patch in my
> > tree fixes, has been created without a proper understanding of the
> > hardware.  To put it simply, it is broken.
> > 
> > The binding only allows _one_ register width to be specified, which is
> > completely incorrect: the binding _must_ allow multiple register widths
> > to be specified.  This is what SMC91x has always expected: to be told
> > which register access widths it is permitted to make.
> 
> This is what is documented:
> 
> Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> - reg-io-width : Mask of sizes (in bytes) of the IO accesses that
>   are supported on the device.  Valid value for SMSC LAN91c111 are
>   1, 2 or 4.  If it's omitted or invalid, the size would be 2 meaning
>   16-bit access only.
> 
> and this appears to match what the driver does, although it is a
> rather unconventional definition (I would have expected an array
> of widths in bytes).

It doesn't match what the driver does - have you not been following the
discussion on the breakage caused by your commit b70661c70830 ?

> Almost all of the users leave out the property, so they get 16-bit
> access, nomadik-nhk15 is the only one that actually specifies
> the width explicitly, and it also requests 16-bit only. I don't
> think your patch changes anything for these cases.

Okay, so all the DT users _only_ use 16-bit accesses, and end up
_emulating_ 8-bit accesses through a 16-bit read-modify-write
sequence, even when they may be perfectly capable of 8-bit accesses,
because this fine detail of the SMC91x driver hasn't been understood.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

[Robert Jarzmik]

Russell King - ARM Linux <linux@armlinux.org.uk> writes:

> On Mon, Sep 05, 2016 at 10:58:03AM +1000, Stephen Rothwell wrote:
>> I fixed it up (I deleted the file) 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.

...zip...
> Since the patch in my tree is fixing a regression caused by the broken
> conversions, I'm not mindful to drop it from the merge window - I
> actually want to push it into -rc kernels.  We _do_ need to fix the
> DT regressions, and quickly though, and push those with this patch.
>
> Since I don't use the SMC91x with DT, that's outside of what I can
> test, so consider this a call for help on that subject.
Then consider you have one more tester, for a 16-bits access.

My lubbock is now DT aware, with a smc91x ethernet card actually working,
provided the small patch in [2].

Cheers.

-- 
Robert

[1] DT extract
	ethernet@extbus {
		compatible = "smsc,lan91c94";
		reg = <0x0c000c00 0x100000 0x0e00000 0x100000>;
		reg-names = "smc91x-regs", "smc91x-attrib";
		interrupts-extended = <&pxa_cplds_irqs 3 IRQ_TYPE_EDGE_RISING>;
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_eth_default>;
		reg-io-width = <2>;
		reg-io-shift = <2>;
	};


[2] Patch for lubbock
---8>---
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 726b80f45906..6d4fdac6c0e0 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2316,6 +2316,9 @@ static int smc_drv_probe(struct platform_device *pdev)
 		} else {
 			lp->cfg.flags |= SMC91X_USE_16BIT;
 		}
+		if (!device_property_read_u32(&pdev->dev, "reg-io-shift",
+					      &val))
+			lp->io_shift = val;
 	}
 #endif
 

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

[Stephen Rothwell]

Hi all,

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

  MAINTAINERS

between commit:

  4a121096db9c ("MAINTAINERS: Update mailing list for Renesas SoC Development")

from Linus' tree and commit:

  804b0d7011ee ("MAINTAINERS: Remove link to oss.renesas.com which is closed")

from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc MAINTAINERS
index 5461ecc147dc,0939ce1bdb71..000000000000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -1531,9 -1526,8 +1541,8 @@@ F:	drivers/media/platform/s5p-jpeg
  ARM/SHMOBILE ARM ARCHITECTURE
  M:	Simon Horman <horms@verge.net.au>
  M:	Magnus Damm <magnus.damm@gmail.com>
 -L:	linux-sh@vger.kernel.org
 -Q:	http://patchwork.kernel.org/project/linux-sh/list/
 +L:	linux-renesas-soc@vger.kernel.org
- W:	http://oss.renesas.com
 +Q:	http://patchwork.kernel.org/project/linux-renesas-soc/list/
  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git next
  S:	Supported
  F:	arch/arm/boot/dts/emev2*

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

[Stephen Rothwell]

Hi all,

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

  drivers/cpufreq/exynos-cpufreq.c

between commit:

  62c3f2fddd43 ("cpufreq: exynos: Fix for memory leak in case SoC name does not match")

from Linus' tree and commits:

  ac4c90c82e4d ("cpufreq: exynos: remove exynos5250 specific cpufreq driver support")
  966f2a71a92d ("cpufreq: exynos: remove Exynos4x12 specific cpufreq driver support")

from the arm-soc tree.

I fixed it up (the latter commit removed the file, so I did that) and
can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/zynq-7000.dtsi between commit 9eeb5161397a ("ARM:
zynq: DT: Use the zynq binding with macb") from Linus' tree and commit
4481b18b7cf0 ("ARM: zynq: DT: Use the zynq binding with macb") from the
arm-soc tree.

I fixed it up (it looks like that latter is a newer version of the
former, so I used it) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

[Michal Simek]

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

Hi,

On 06/01/2015 02:25 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/boot/dts/zynq-7000.dtsi between commit 9eeb5161397a ("ARM:
> zynq: DT: Use the zynq binding with macb") from Linus' tree and commit
> 4481b18b7cf0 ("ARM: zynq: DT: Use the zynq binding with macb") from the
> arm-soc tree.
> 
> I fixed it up (it looks like that latter is a newer version of the
> former, so I used it) and can carry the fix as necessary (no action
> is required).
> 

David applied v1 of the patch. I have applied v2 (pulled via arm-soc)
which also keep backward compatible string. There should be two
compatible strings.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/clk/Makefile between commit fd3fdaf09f26 ("clk: sort Makefile")
from Linus' tree and commit 7ee2c5117483 ("clk: bcm281xx: add initial
clock framework support") from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/clk/Makefile
index a367a9831717,7c7f40e9ba05..000000000000
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@@ -9,44 -9,44 +9,45 @@@ obj-$(CONFIG_COMMON_CLK)	+= clk-gate.
  obj-$(CONFIG_COMMON_CLK)	+= clk-mux.o
  obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
  
 -# SoCs specific
 -obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
 -obj-$(CONFIG_ARCH_EFM32)	+= clk-efm32gg.o
 -obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
 -obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
 -obj-$(CONFIG_ARCH_HI3xxx)	+= hisilicon/
 -obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
 -obj-$(CONFIG_ARCH_MXS)		+= mxs/
 -obj-$(CONFIG_ARCH_SOCFPGA)	+= socfpga/
 -obj-$(CONFIG_PLAT_SPEAR)	+= spear/
 -obj-$(CONFIG_ARCH_U300)		+= clk-u300.o
 -obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
 -obj-$(CONFIG_ARCH_SIRF)		+= clk-prima2.o
 -obj-$(CONFIG_PLAT_ORION)	+= mvebu/
 +# hardware specific clock types
 +# please keep this section sorted lexicographically by file/directory path name
++obj-$(CONFIG_ARCH_BCM)			+= bcm/
 +obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)	+= clk-axi-clkgen.o
 +obj-$(CONFIG_ARCH_BCM2835)		+= clk-bcm2835.o
 +obj-$(CONFIG_ARCH_EFM32)		+= clk-efm32gg.o
 +obj-$(CONFIG_ARCH_HIGHBANK)		+= clk-highbank.o
 +obj-$(CONFIG_MACH_LOONGSON1)		+= clk-ls1x.o
 +obj-$(CONFIG_COMMON_CLK_MAX77686)	+= clk-max77686.o
 +obj-$(CONFIG_ARCH_NOMADIK)		+= clk-nomadik.o
 +obj-$(CONFIG_ARCH_NSPIRE)		+= clk-nspire.o
 +obj-$(CONFIG_CLK_PPC_CORENET)		+= clk-ppc-corenet.o
 +obj-$(CONFIG_COMMON_CLK_S2MPS11)	+= clk-s2mps11.o
 +obj-$(CONFIG_COMMON_CLK_SI5351)		+= clk-si5351.o
 +obj-$(CONFIG_COMMON_CLK_SI570)		+= clk-si570.o
 +obj-$(CONFIG_CLK_TWL6040)		+= clk-twl6040.o
 +obj-$(CONFIG_ARCH_U300)			+= clk-u300.o
 +obj-$(CONFIG_ARCH_VT8500)		+= clk-vt8500.o
 +obj-$(CONFIG_COMMON_CLK_WM831X)		+= clk-wm831x.o
 +obj-$(CONFIG_COMMON_CLK_XGENE)		+= clk-xgene.o
 +obj-$(CONFIG_COMMON_CLK_AT91)		+= at91/
 +obj-$(CONFIG_ARCH_HI3xxx)		+= hisilicon/
 +obj-$(CONFIG_COMMON_CLK_KEYSTONE)	+= keystone/
  ifeq ($(CONFIG_COMMON_CLK), y)
 -obj-$(CONFIG_ARCH_MMP)		+= mmp/
 +obj-$(CONFIG_ARCH_MMP)			+= mmp/
  endif
 -obj-$(CONFIG_MACH_LOONGSON1)	+= clk-ls1x.o
 -obj-$(CONFIG_ARCH_ROCKCHIP)	+= rockchip/
 -obj-$(CONFIG_ARCH_SUNXI)	+= sunxi/
 -obj-$(CONFIG_ARCH_U8500)	+= ux500/
 -obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
 -obj-$(CONFIG_ARCH_ZYNQ)		+= zynq/
 -obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 -obj-$(CONFIG_PLAT_SAMSUNG)	+= samsung/
 -obj-$(CONFIG_COMMON_CLK_XGENE)  += clk-xgene.o
 -obj-$(CONFIG_COMMON_CLK_KEYSTONE)	+= keystone/
 -obj-$(CONFIG_COMMON_CLK_AT91)	+= at91/
 +obj-$(CONFIG_PLAT_ORION)		+= mvebu/
 +obj-$(CONFIG_ARCH_MXS)			+= mxs/
 +obj-$(CONFIG_COMMON_CLK_QCOM)		+= qcom/
 +obj-$(CONFIG_ARCH_ROCKCHIP)		+= rockchip/
 +obj-$(CONFIG_PLAT_SAMSUNG)		+= samsung/
  obj-$(CONFIG_ARCH_SHMOBILE_MULTI)	+= shmobile/
 -
 -obj-$(CONFIG_X86)		+= x86/
 -obj-$(CONFIG_ARCH_BCM)		+= bcm/
 -
 -# Chip specific
 -obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
 -obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 -obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
 -obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
 -obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
 -obj-$(CONFIG_CLK_TWL6040)	+= clk-twl6040.o
 -obj-$(CONFIG_CLK_PPC_CORENET)	+= clk-ppc-corenet.o
 +obj-$(CONFIG_ARCH_SIRF)			+= sirf/
 +obj-$(CONFIG_ARCH_SOCFPGA)		+= socfpga/
 +obj-$(CONFIG_PLAT_SPEAR)		+= spear/
 +obj-$(CONFIG_ARCH_SUNXI)		+= sunxi/
 +obj-$(CONFIG_ARCH_TEGRA)		+= tegra/
 +obj-$(CONFIG_ARCH_OMAP2PLUS)		+= ti/
 +obj-$(CONFIG_ARCH_U8500)		+= ux500/
 +obj-$(CONFIG_COMMON_CLK_VERSATILE)	+= versatile/
 +obj-$(CONFIG_X86)			+= x86/
 +obj-$(CONFIG_ARCH_ZYNQ)			+= zynq/

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

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

[Kevin Hilman]

On Wed, Jan 29, 2014 at 4:19 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/clk/Makefile between commit fd3fdaf09f26 ("clk: sort Makefile")
> from Linus' tree and commit 7ee2c5117483 ("clk: bcm281xx: add initial
> clock framework support") from the arm-soc tree.

Ugh.  Looks like some last minute cleanup stuff went into clk-next
that didn't spend time in linux-next, and now causes conflicts with
some clk stuff we still have queued in arm-soc (ack'd by Mike.)

Now, based on the Hulk's response to Mike's pull request, if we submit
this, introducing yet more conflicts in the Makefile, it will surely
be Hulk angry, Hulk smash.

Kevin

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

[Mike Turquette]

On Wed, Jan 29, 2014 at 9:33 PM, Kevin Hilman <khilman@linaro.org> wrote:
> On Wed, Jan 29, 2014 at 4:19 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> Today's linux-next merge of the arm-soc tree got a conflict in
>> drivers/clk/Makefile between commit fd3fdaf09f26 ("clk: sort Makefile")
>> from Linus' tree and commit 7ee2c5117483 ("clk: bcm281xx: add initial
>> clock framework support") from the arm-soc tree.
>
> Ugh.  Looks like some last minute cleanup stuff went into clk-next
> that didn't spend time in linux-next, and now causes conflicts with
> some clk stuff we still have queued in arm-soc (ack'd by Mike.)
>
> Now, based on the Hulk's response to Mike's pull request, if we submit
> this, introducing yet more conflicts in the Makefile, it will surely
> be Hulk angry, Hulk smash.

Well this is clearly my fault. Please place appropriate blame on me
for sneaking in that Makefile cleanup.

/me prepares to be smashed.

Regards,
Mike

>
> Kevin

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/bcm11351.dtsi between commit 67a57be85e68 ("ARM:
bcm11351: Enable pinctrl for Broadcom Capri SoCs") from Linus' tree and
commit 0bd898b872ac ("ARM: dts: Declare clocks as fixed on bcm11351") and
several following commits from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/boot/dts/bcm11351.dtsi
index dd8e878741c0,375a2f8eb878..000000000000
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@@ -142,8 -146,159 +146,164 @@@
  		status = "disabled";
  	};
  
 +	pinctrl@35004800 {
 +		compatible = "brcm,capri-pinctrl";
 +		reg = <0x35004800 0x430>;
 +	};
++
+ 	i2c@3e016000 {
+ 		compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ 		reg = <0x3e016000 0x80>;
+ 		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ 		#address-cells = <1>;
+ 		#size-cells = <0>;
+ 		clocks = <&bsc1_clk>;
+ 		status = "disabled";
+ 	};
+ 
+ 	i2c@3e017000 {
+ 		compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ 		reg = <0x3e017000 0x80>;
+ 		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+ 		#address-cells = <1>;
+ 		#size-cells = <0>;
+ 		clocks = <&bsc2_clk>;
+ 		status = "disabled";
+ 	};
+ 
+ 	i2c@3e018000 {
+ 		compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ 		reg = <0x3e018000 0x80>;
+ 		interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ 		#address-cells = <1>;
+ 		#size-cells = <0>;
+ 		clocks = <&bsc3_clk>;
+ 		status = "disabled";
+ 	};
+ 
+ 	i2c@3500d000 {
+ 		compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ 		reg = <0x3500d000 0x80>;
+ 		interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ 		#address-cells = <1>;
+ 		#size-cells = <0>;
+ 		clocks = <&pmu_bsc_clk>;
+ 		status = "disabled";
+ 	};
+ 
+ 	clocks {
+ 		bsc1_clk: bsc1 {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <13000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		bsc2_clk: bsc2 {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <13000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		bsc3_clk: bsc3 {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <13000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		pmu_bsc_clk: pmu_bsc {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <13000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		hub_timer_clk: hub_timer {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <32768>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		pwm_clk: pwm {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <26000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		sdio1_clk: sdio1 {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <48000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		sdio2_clk: sdio2 {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <48000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		sdio3_clk: sdio3 {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <48000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		sdio4_clk: sdio4 {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <48000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		tmon_1m_clk: tmon_1m {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <1000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		uartb_clk: uartb {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <13000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		uartb2_clk: uartb2 {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <13000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		uartb3_clk: uartb3 {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <13000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		uartb4_clk: uartb4 {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <13000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 
+ 		usb_otg_ahb_clk: usb_otg_ahb {
+ 			compatible = "fixed-clock";
+ 			clock-frequency = <52000000>;
+ 			#clock-cells = <0>;
+ 		};
+ 	};
+ 
+ 	usbotg: usb@3f120000 {
+ 		compatible = "snps,dwc2";
+ 		reg = <0x3f120000 0x10000>;
+ 		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ 		clocks = <&usb_otg_ahb_clk>;
+ 		clock-names = "otg";
+ 		phys = <&usbphy>;
+ 		phy-names = "usb2-phy";
+ 		status = "disabled";
+ 	};
+ 
+ 	usbphy: usb-phy@3f130000 {
+ 		compatible = "brcm,kona-usb2-phy";
+ 		reg = <0x3f130000 0x28>;
+ 		#phy-cells = <0>;
+ 		status = "disabled";
+ 	};
  };

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/tegra20-trimslice.dts between commit 30ca2226bea6
("ARM: tegra: always enable USB VBUS regulators") from Linus' tree and
commit 23f95ef2d951 ("ARM: tegra: use TEGRA_GPIO() in a couple more
places") from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/boot/dts/tegra20-trimslice.dts
index 1e9d33a,22e227f..0000000
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@@ -310,8 -310,19 +310,18 @@@
  		nvidia,sys-clock-req-active-high;
  	};
  
+ 	pcie-controller {
+ 		status = "okay";
+ 		pex-clk-supply = <&pci_clk_reg>;
+ 		vdd-supply = <&pci_vdd_reg>;
+ 
+ 		pci@1,0 {
+ 			status = "okay";
+ 		};
+ 	};
+ 
  	usb@c5000000 {
  		status = "okay";
 -		nvidia,vbus-gpio = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>;
  	};
  
  	usb-phy@c5000000 {
@@@ -410,10 -421,26 +420,28 @@@
  			regulator-min-microvolt = <5000000>;
  			regulator-max-microvolt = <5000000>;
  			enable-active-high;
- 			gpio = <&gpio 170 0>; /* PV2 */
+ 			gpio = <&gpio TEGRA_GPIO(V, 2) 0>;
 +			regulator-always-on;
 +			regulator-boot-on;
  		};
+ 
+ 		pci_clk_reg: regulator@3 {
+ 			compatible = "regulator-fixed";
+ 			reg = <3>;
+ 			regulator-name = "pci_clk";
+ 			regulator-min-microvolt = <3300000>;
+ 			regulator-max-microvolt = <3300000>;
+ 			regulator-always-on;
+ 		};
+ 
+ 		pci_vdd_reg: regulator@4 {
+ 			compatible = "regulator-fixed";
+ 			reg = <4>;
+ 			regulator-name = "pci_vdd";
+ 			regulator-min-microvolt = <1050000>;
+ 			regulator-max-microvolt = <1050000>;
+ 			regulator-always-on;
+ 		};
  	};
  
  	sound {

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

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

[Stephen Warren]

On 08/27/2013 02:29 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in 
> arch/arm/boot/dts/tegra20-trimslice.dts between commit
> 30ca2226bea6 ("ARM: tegra: always enable USB VBUS regulators") from
> Linus' tree and commit 23f95ef2d951 ("ARM: tegra: use TEGRA_GPIO()
> in a couple more places") from the arm-soc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no
> action is required).

> diff --cc arch/arm/boot/dts/tegra20-trimslice.dts

> usb@c5000000 { status = "okay"; -		nvidia,vbus-gpio = <&gpio
> TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>; };

That chunk isn't part of either of the two commits above.

It is however part of commit 103566e "arm: tegra: Remove obsolete
nvidia,vbus-gpio properties" from the USB tree, so it's fine that the
change is part of linux-next.

I'm just not sure if it's expected for that chunk to show up in this
merge resolution email? If it's normal, then there's no problem; the
issue would be with me not having too much git merge conflict
resolution experience:-)

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

[Stephen Rothwell]

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

Hi Stephen,

On Tue, 27 Aug 2013 10:17:21 -0600 Stephen Warren <swarren@wwwdotorg.org> wrote:
>
> On 08/27/2013 02:29 AM, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the arm-soc tree got a conflict in 
> > arch/arm/boot/dts/tegra20-trimslice.dts between commit
> > 30ca2226bea6 ("ARM: tegra: always enable USB VBUS regulators") from
> > Linus' tree and commit 23f95ef2d951 ("ARM: tegra: use TEGRA_GPIO()
> > in a couple more places") from the arm-soc tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary (no
> > action is required).
> 
> > diff --cc arch/arm/boot/dts/tegra20-trimslice.dts
> 
> > usb@c5000000 { status = "okay"; -		nvidia,vbus-gpio = <&gpio
> > TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>; };
> 
> That chunk isn't part of either of the two commits above.

Yeah.

> It is however part of commit 103566e "arm: tegra: Remove obsolete
> nvidia,vbus-gpio properties" from the USB tree, so it's fine that the
> change is part of linux-next.
>
> I'm just not sure if it's expected for that chunk to show up in this
> merge resolution email? If it's normal, then there's no problem; the
> issue would be with me not having too much git merge conflict
> resolution experience:-)

It did not actually cause a conflict that I had to fix manually, but is
part of the overall merge changes.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/tegra20-seaboard.dts between commit 30ca2226bea6 ("ARM:
tegra: always enable USB VBUS regulators") from Linus' tree and commit
23f95ef2d951 ("ARM: tegra: use TEGRA_GPIO() in a couple more places")
from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/boot/dts/tegra20-seaboard.dts
index c824253,f44a9b8..0000000
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@@ -828,9 -829,7 +828,9 @@@
  			regulator-min-microvolt = <5000000>;
  			regulator-max-microvolt = <5000000>;
  			enable-active-high;
- 			gpio = <&gpio 24 0>; /* PD0 */
+ 			gpio = <&gpio TEGRA_GPIO(D, 0) 0>;
 +			regulator-always-on;
 +			regulator-boot-on;
  		};
  	};
  

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/Kconfig between commit 4a1b573346ee ("ARM: 7758/1:
introduce config HAS_BANDGAP") from Linus' tree and commit 59d92875a6d9
("ARM: OMAP: build mach-omap code only if needed") from the arm-soc tree.

I fixed it up (the latter moved the "config ARCH_OMAP2PLUS" and included
the "select ARCH_HAS_BANDGAP" despite there being no ARCH_HAS_BANDGAP
config in the arm-soc tree :-() and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/snowball.dts between commit d52701d39e37 ("mfd: ab8500:
Kill "reg" property from binding") from Linus' tree and commit
924e82dacab9 ("ARM: ux500: allow Snowball access to the AB8500 GPIO
pins") from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/boot/dts/snowball.dts
index d3ec32f,b095e85..0000000
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@@ -298,7 -298,11 +298,11 @@@
  				};
  			};
  
 -			ab8500@5 {
 +			ab8500 {
+ 				ab8500-gpio {
+ 					compatible = "stericsson,ab8500-gpio";
+ 				};
+ 
  				ab8500-regulators {
  					ab8500_ldo_aux1_reg: ab8500_ldo_aux1 {
  						regulator-name = "V-DISPLAY";

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/watchdog/orion_wdt.c between commit 0dd6e4847ed8 ("watchdog:
orion_wdt: Convert driver to watchdog core") from Linus' tree and commit
1e7bad0f5b91 ("ARM: Orion: DTify the watchdog timer") from the arm-soc
tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/watchdog/orion_wdt.c
index a73bea4,1531e02..0000000
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@@ -23,7 -24,8 +23,8 @@@
  #include <linux/io.h>
  #include <linux/spinlock.h>
  #include <linux/clk.h>
 +#include <linux/err.h>
+ #include <linux/of.h>
  #include <mach/bridge-regs.h>
  
  /*
@@@ -189,9 -292,16 +190,15 @@@ static int __devexit orion_wdt_remove(s
  
  static void orion_wdt_shutdown(struct platform_device *pdev)
  {
 -	if (test_bit(WDT_IN_USE, &wdt_status))
 -		orion_wdt_disable();
 +	orion_wdt_stop(&orion_wdt);
  }
  
+ static const struct of_device_id orion_wdt_of_match_table[] __devinitdata = {
+ 	{ .compatible = "marvell,orion-wdt", },
+ 	{},
+ };
+ MODULE_DEVICE_TABLE(of, orion_wdt_of_match_table);
+ 
  static struct platform_driver orion_wdt_driver = {
  	.probe		= orion_wdt_probe,
  	.remove		= __devexit_p(orion_wdt_remove),

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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-shmobile/board-mackerel.c between commit 1740d3448012
("ARM: mach-shmobile: mackerel: Reserve DMA memory for the frame buffer")
from Linus' tree and commit 5d7220ec000f ("ARM: mach-shmobile: sh7372
map_io and init_early update") from the arm-soc tree.

The latter moved the code to another file
arch/arm/mach-shmobile/setup-sh7372.c and I have no idea how to fix this
up, so I just removed the change done by the former.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

[Laurent Pinchart]

Hi Stephen,

On Thursday 15 March 2012 17:50:00 Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-shmobile/board-mackerel.c between commit 1740d3448012
> ("ARM: mach-shmobile: mackerel: Reserve DMA memory for the frame buffer")
> from Linus' tree and commit 5d7220ec000f ("ARM: mach-shmobile: sh7372
> map_io and init_early update") from the arm-soc tree.
> 
> The latter moved the code to another file
> arch/arm/mach-shmobile/setup-sh7372.c and I have no idea how to fix this
> up, so I just removed the change done by the former.

The following patch (5d7220ec000f rebased on top of 1740d3448012) shows the
correct conflict resolution in my opinion.

>From f040ba69632a54c86767974768d68b308901061c Mon Sep 17 00:00:00 2001
From: Magnus Damm <damm@opensource.se>
Date: Wed, 29 Feb 2012 12:37:19 +0900
Subject: [PATCH] ARM: mach-shmobile: sh7372 map_io and init_early update

ARM: mach-shmobile: sh7372 map_io and init_early update

Update the sh7372 SoC and the AP4EVB and Mackerel boards to make use
of the functions sh7372_map_io() and sh7372_add_early_devices().

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 arch/arm/mach-shmobile/board-ap4evb.c        |   25 ++-----------------------
 arch/arm/mach-shmobile/board-mackerel.c      |   21 +++------------------
 arch/arm/mach-shmobile/include/mach/common.h |    1 +
 arch/arm/mach-shmobile/setup-sh7372.c        |   22 ++++++++++++++++++++++
 4 files changed, 28 insertions(+), 41 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
index eeb4d96..c57ded1 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -61,7 +61,6 @@
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
-#include <asm/mach/map.h>
 #include <asm/mach/time.h>
 #include <asm/setup.h>
 
@@ -1190,27 +1189,6 @@ static struct i2c_board_info i2c1_devices[] = {
 	},
 };
 
-static struct map_desc ap4evb_io_desc[] __initdata = {
-	/* create a 1:1 entity map for 0xe6xxxxxx
-	 * used by CPGA, INTC and PFC.
-	 */
-	{
-		.virtual	= 0xe6000000,
-		.pfn		= __phys_to_pfn(0xe6000000),
-		.length		= 256 << 20,
-		.type		= MT_DEVICE_NONSHARED
-	},
-};
-
-static void __init ap4evb_map_io(void)
-{
-	iotable_init(ap4evb_io_desc, ARRAY_SIZE(ap4evb_io_desc));
-
-	/* setup early devices and console here as well */
-	sh7372_add_early_devices();
-	shmobile_setup_console();
-}
-
 #define GPIO_PORT9CR	0xE6051009
 #define GPIO_PORT10CR	0xE605100A
 #define USCCR1		0xE6058144
@@ -1469,7 +1447,8 @@ static struct sys_timer ap4evb_timer = {
 };
 
 MACHINE_START(AP4EVB, "ap4evb")
-	.map_io		= ap4evb_map_io,
+	.map_io		= sh7372_map_io,
+	.init_early	= sh7372_add_early_devices,
 	.init_irq	= sh7372_init_irq,
 	.handle_irq	= shmobile_handle_irq_intc,
 	.init_machine	= ap4evb_init,
diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 7b53cda..b5bbab7 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -58,7 +58,6 @@
 
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
-#include <asm/mach/map.h>
 #include <asm/mach-types.h>
 
 /*
@@ -1337,29 +1336,14 @@ static struct i2c_board_info i2c1_devices[] = {
 	},
 };
 
-static struct map_desc mackerel_io_desc[] __initdata = {
-	/* create a 1:1 entity map for 0xe6xxxxxx
-	 * used by CPGA, INTC and PFC.
-	 */
-	{
-		.virtual	= 0xe6000000,
-		.pfn		= __phys_to_pfn(0xe6000000),
-		.length		= 256 << 20,
-		.type		= MT_DEVICE_NONSHARED
-	},
-};
-
 static void __init mackerel_map_io(void)
 {
-	iotable_init(mackerel_io_desc, ARRAY_SIZE(mackerel_io_desc));
+	sh7372_map_io();
+
 	/* DMA memory at 0xff200000 - 0xffdfffff. The default 2MB size isn't
 	 * enough to allocate the frame buffer memory.
 	 */
 	init_consistent_dma_size(12 << 20);
-
-	/* setup early devices and console here as well */
-	sh7372_add_early_devices();
-	shmobile_setup_console();
 }
 
 #define GPIO_PORT9CR	0xE6051009
@@ -1592,6 +1576,7 @@ static struct sys_timer mackerel_timer = {
 
 MACHINE_START(MACKEREL, "mackerel")
 	.map_io		= mackerel_map_io,
+	.init_early	= sh7372_add_early_devices,
 	.init_irq	= sh7372_init_irq,
 	.handle_irq	= shmobile_handle_irq_intc,
 	.init_machine	= mackerel_init,
diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index e4b945e..b327402 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -30,6 +30,7 @@ extern struct clk sh7377_extalc1_clk;
 extern struct clk sh7377_extal2_clk;
 
 extern void sh7372_init_irq(void);
+extern void sh7372_map_io(void);
 extern void sh7372_add_early_devices(void);
 extern void sh7372_add_standard_devices(void);
 extern void sh7372_clock_init(void);
diff --git a/arch/arm/mach-shmobile/setup-sh7372.c b/arch/arm/mach-shmobile/setup-sh7372.c
index a83cf51..12b4378 100644
--- a/arch/arm/mach-shmobile/setup-sh7372.c
+++ b/arch/arm/mach-shmobile/setup-sh7372.c
@@ -33,9 +33,28 @@
 #include <linux/pm_domain.h>
 #include <mach/hardware.h>
 #include <mach/sh7372.h>
+#include <mach/common.h>
+#include <asm/mach/map.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
+static struct map_desc sh7372_io_desc[] __initdata = {
+	/* create a 1:1 entity map for 0xe6xxxxxx
+	 * used by CPGA, INTC and PFC.
+	 */
+	{
+		.virtual	= 0xe6000000,
+		.pfn		= __phys_to_pfn(0xe6000000),
+		.length		= 256 << 20,
+		.type		= MT_DEVICE_NONSHARED
+	},
+};
+
+void __init sh7372_map_io(void)
+{
+	iotable_init(sh7372_io_desc, ARRAY_SIZE(sh7372_io_desc));
+}
+
 /* SCIFA0 */
 static struct plat_sci_port scif0_platform_data = {
 	.mapbase	= 0xe6c40000,
@@ -1049,4 +1068,7 @@ void __init sh7372_add_early_devices(void)
 {
 	early_platform_add_devices(sh7372_early_devices,
 				   ARRAY_SIZE(sh7372_early_devices));
+
+	/* setup early console here as well */
+	shmobile_setup_console();
 }

-- 
Regards,

Laurent Pinchart

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

[Arnd Bergmann]

On Thursday 15 March 2012, Laurent Pinchart wrote:
> The following patch (5d7220ec000f rebased on top of 1740d3448012) shows the
> correct conflict resolution in my opinion.
> 
> From f040ba69632a54c86767974768d68b308901061c Mon Sep 17 00:00:00 2001
> From: Magnus Damm <damm@opensource.se>
> Date: Wed, 29 Feb 2012 12:37:19 +0900
> Subject: [PATCH] ARM: mach-shmobile: sh7372 map_io and init_early update
> 
> ARM: mach-shmobile: sh7372 map_io and init_early update
> 
> Update the sh7372 SoC and the AP4EVB and Mackerel boards to make use
> of the functions sh7372_map_io() and sh7372_add_early_devices().
> 
> Signed-off-by: Magnus Damm <damm@opensource.se>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Hi Laurent,

I've merged Paul's branch into my renesas/soc branch, because I don't
rebase the branches once they are merged into arm-soc. Thanks a lot
for the resolution you suggested, I used the same resulting code
in the merge commit.

I'm not particularly happy about how we got here. Obviously, the bug
fixes that Paul sent should have gone through the arm-soc tree to
avoid this situation, and they should have been based on a -rc release
rather than some random commit after -rc6. It's not a big issue
because the next/soc branch already contains -rc7 though.

	Arnd

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

[Rafael J. Wysocki]

On Thursday, March 15, 2012, Arnd Bergmann wrote:
> On Thursday 15 March 2012, Laurent Pinchart wrote:
> > The following patch (5d7220ec000f rebased on top of 1740d3448012) shows the
> > correct conflict resolution in my opinion.
> > 
> > From f040ba69632a54c86767974768d68b308901061c Mon Sep 17 00:00:00 2001
> > From: Magnus Damm <damm@opensource.se>
> > Date: Wed, 29 Feb 2012 12:37:19 +0900
> > Subject: [PATCH] ARM: mach-shmobile: sh7372 map_io and init_early update
> > 
> > ARM: mach-shmobile: sh7372 map_io and init_early update
> > 
> > Update the sh7372 SoC and the AP4EVB and Mackerel boards to make use
> > of the functions sh7372_map_io() and sh7372_add_early_devices().
> > 
> > Signed-off-by: Magnus Damm <damm@opensource.se>
> > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Hi Laurent,
> 
> I've merged Paul's branch into my renesas/soc branch, because I don't
> rebase the branches once they are merged into arm-soc. Thanks a lot
> for the resolution you suggested, I used the same resulting code
> in the merge commit.
> 
> I'm not particularly happy about how we got here. Obviously, the bug
> fixes that Paul sent should have gone through the arm-soc tree to
> avoid this situation, and they should have been based on a -rc release
> rather than some random commit after -rc6. It's not a big issue
> because the next/soc branch already contains -rc7 though.

This is a consequece of our decision that Paul would handle v3.3 fixes
and push them directly to Linus, while I would take new material for v3.4,
sorry about that.

It should be a temporary problem only, though, because once v3.3 has been
released, all arm/mach-shmobile fixes will go through the arm-soc tree.

Thanks,
Rafael

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-vexpress/Kconfig between commit 43a6955fa8c3 ("ARM: 7346/1:
errata: fix PL310 erratum #753970 workaround selection") from Linus' tree
and commit 8deed1786a64 ("ARM: vexpress: Add Device Tree support") from
the arm-soc tree.

The latter took the former into account, so I dropped the former for this
file.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

[Stephen Rothwell]

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

Hi Arnd,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/net/ethernet/cadence/Kconfig between commit eccab1ec87d0
("net/cadence: enable by default NET_ATMEL") from Linus' tree and commit
f75ba50bdc2b ("macb: initial support for Cadence GEM") from the arm-soc
tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/ethernet/cadence/Kconfig
index b48378a,a2e1500..0000000
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@@ -5,9 -5,8 +5,9 @@@
  config HAVE_NET_MACB
  	bool
  
- config NET_ATMEL
- 	bool "Atmel devices"
+ config NET_CADENCE
+ 	bool "Cadence devices"
 +	default y
  	depends on HAVE_NET_MACB || (ARM && ARCH_AT91RM9200)
  	---help---
  	  If you have a network (Ethernet) card belonging to this class, say Y.

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

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

[Arnd Bergmann]

On Thursday 24 November 2011, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/net/ethernet/cadence/Kconfig between commit eccab1ec87d0
> ("net/cadence: enable by default NET_ATMEL") from Linus' tree and commit
> f75ba50bdc2b ("macb: initial support for Cadence GEM") from the arm-soc
> tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Yes, looks good.

Thanks,

	Arnd

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

[Stephen Rothwell]

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

Hi Arnd,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-exynos/Kconfig between commit830145796a5c ("ARM: EXYNOS:
Add ARCH_EXYNOS and reorganize arch/arm/mach-exynos") from Linus' tree
and commit 8f7e34205f6f ("Merge branch 'next/cleanup3' into for-next")
from the arm-soc tree.

I just used the version from Linus' tree.  Arnd, it seems that some of
these merges were done differently by Linus, so can you please clean up
the arm-soc tree now that it looks like Linus may have merged all its
content.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

[Arnd Bergmann]

On Monday 07 November 2011, Stephen Rothwell wrote:

> I just used the version from Linus' tree.  Arnd, it seems that some of
> these merges were done differently by Linus, so can you please clean up
> the arm-soc tree now that it looks like Linus may have merged all its
> content.

Ok, done. Thanks for the info!

	Arnd