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


pgppZh1DeR836.pgp
Description: OpenPGP digital signature

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

[Tony Lindgren]

* Stephen Rothwell  [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 
> ")
> 
> 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..
> --- 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

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

[Tony Lindgren]

* Stephen Rothwell  [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 
> ")
> 
> 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..
> --- 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]

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 
")

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


pgpAj4cUztXGY.pgp
Description: OpenPGP digital signature

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:

  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 
")

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


pgpAj4cUztXGY.pgp
Description: OpenPGP digital signature

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


pgpD8hNCRckk_.pgp
Description: OpenPGP digital signature

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


pgpD8hNCRckk_.pgp
Description: OpenPGP digital signature

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

[Robert Jarzmik]

Russell King - ARM Linux  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 0x10 0x0e0 0x10>;
reg-names = "smc91x-regs", "smc91x-attrib";
interrupts-extended = <_cplds_irqs 3 IRQ_TYPE_EDGE_RISING>;
pinctrl-names = "default";
pinctrl-0 = <_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(>dev, "reg-io-shift",
+ ))
+   lp->io_shift = val;
}
 #endif
 

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

[Robert Jarzmik]

Russell King - ARM Linux  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 0x10 0x0e0 0x10>;
reg-names = "smc91x-regs", "smc91x-attrib";
interrupts-extended = <_cplds_irqs 3 IRQ_TYPE_EDGE_RISING>;
pinctrl-names = "default";
pinctrl-0 = <_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(>dev, "reg-io-shift",
+ ))
+   lp->io_shift = val;
}
 #endif
 

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

[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

[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

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

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

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

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

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 Rothwells...@canb.auug.org.au

diff --cc MAINTAINERS
index 5461ecc147dc,0939ce1bdb71..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -1531,9 -1526,8 +1541,8 @@@ F:  drivers/media/platform/s5p-jpeg
  ARM/SHMOBILE ARM ARCHITECTURE
  M:Simon Horman 
  M:Magnus Damm 
 -L:linux...@vger.kernel.org
 -Q:http://patchwork.kernel.org/project/linux-sh/list/
 +L:linux-renesas-...@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:

  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 Rothwells...@canb.auug.org.au

diff --cc MAINTAINERS
index 5461ecc147dc,0939ce1bdb71..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -1531,9 -1526,8 +1541,8 @@@ F:  drivers/media/platform/s5p-jpeg
  ARM/SHMOBILE ARM ARCHITECTURE
  M:Simon Horman 
  M:Magnus Damm 
 -L:linux...@vger.kernel.org
 -Q:http://patchwork.kernel.org/project/linux-sh/list/
 +L:linux-renesas-...@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 Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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 Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Simek]

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




signature.asc
Description: OpenPGP digital signature

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

[Michal Simek]

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




signature.asc
Description: OpenPGP digital signature

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/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 Rothwells...@canb.auug.org.au


pgpkqnKJ87b3J.pgp
Description: OpenPGP digital signature

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/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 Rothwells...@canb.auug.org.au


pgpkqnKJ87b3J.pgp
Description: OpenPGP digital signature

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

[Tony Lindgren]

* Stephen Rothwell  [140526 17:46]:
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-omap2/omap-mpuss-lowpower.c between commit 4e4bb5c72f6b
> ("ARM: l2c: omap2: avoid reading directly from the L2 registers in
> platform code") from the arm tree and commit edfaf05c2fcb ("ARM:
> OMAP2+: raw read and write endian fix") from the arm-soc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

OK thanks. FYI, looks like for this one the subject is missing which
tree it conflicts with.

Regards,

Tony
 
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@@ -187,15 -187,19 +187,15 @@@ static void l2x0_pwrst_prepare(unsigne
>* in every restore MPUSS OFF path.
>*/
>   #ifdef CONFIG_CACHE_L2X0
>  -static void save_l2x0_context(void)
>  +static void __init save_l2x0_context(void)
>   {
> - __raw_writel(l2x0_saved_regs.aux_ctrl,
> -  sar_base + L2X0_AUXCTRL_OFFSET);
> - __raw_writel(l2x0_saved_regs.prefetch_ctrl,
> -  sar_base + L2X0_PREFETCH_CTRL_OFFSET);
>  -u32 val;
>  -void __iomem *l2x0_base = omap4_get_l2cache_base();
>  -if (l2x0_base) {
>  -val = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
>  -writel_relaxed(val, sar_base + L2X0_AUXCTRL_OFFSET);
>  -val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
>  -writel_relaxed(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
>  -}
> ++writel_relaxed(l2x0_saved_regs.aux_ctrl,
> ++   sar_base + L2X0_AUXCTRL_OFFSET);
> ++writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
> ++   sar_base + L2X0_PREFETCH_CTRL_OFFSET);
>   }
>   #else
>  -static void save_l2x0_context(void)
>  +static void __init save_l2x0_context(void)
>   {}
>   #endif
>   


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tony Lindgren]

* Stephen Rothwell s...@canb.auug.org.au [140526 17:46]:
 Hi all,
 
 Today's linux-next merge of the arm-soc tree got a conflict in
 arch/arm/mach-omap2/omap-mpuss-lowpower.c between commit 4e4bb5c72f6b
 (ARM: l2c: omap2: avoid reading directly from the L2 registers in
 platform code) from the arm tree and commit edfaf05c2fcb (ARM:
 OMAP2+: raw read and write endian fix) from the arm-soc tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).

OK thanks. FYI, looks like for this one the subject is missing which
tree it conflicts with.

Regards,

Tony
 
 --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
 +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
 @@@ -187,15 -187,19 +187,15 @@@ static void l2x0_pwrst_prepare(unsigne
* in every restore MPUSS OFF path.
*/
   #ifdef CONFIG_CACHE_L2X0
  -static void save_l2x0_context(void)
  +static void __init save_l2x0_context(void)
   {
 - __raw_writel(l2x0_saved_regs.aux_ctrl,
 -  sar_base + L2X0_AUXCTRL_OFFSET);
 - __raw_writel(l2x0_saved_regs.prefetch_ctrl,
 -  sar_base + L2X0_PREFETCH_CTRL_OFFSET);
  -u32 val;
  -void __iomem *l2x0_base = omap4_get_l2cache_base();
  -if (l2x0_base) {
  -val = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
  -writel_relaxed(val, sar_base + L2X0_AUXCTRL_OFFSET);
  -val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
  -writel_relaxed(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
  -}
 ++writel_relaxed(l2x0_saved_regs.aux_ctrl,
 ++   sar_base + L2X0_AUXCTRL_OFFSET);
 ++writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
 ++   sar_base + L2X0_PREFETCH_CTRL_OFFSET);
   }
   #else
  -static void save_l2x0_context(void)
  +static void __init save_l2x0_context(void)
   {}
   #endif
   


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/omap-mpuss-lowpower.c between commit 4e4bb5c72f6b
("ARM: l2c: omap2: avoid reading directly from the L2 registers in
platform code") from the arm tree and commit edfaf05c2fcb ("ARM:
OMAP2+: raw read and write endian fix") from the arm-soc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 61cb77f8cf12,eb76e47091ad..
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@@ -187,15 -187,19 +187,15 @@@ static void l2x0_pwrst_prepare(unsigne
   * in every restore MPUSS OFF path.
   */
  #ifdef CONFIG_CACHE_L2X0
 -static void save_l2x0_context(void)
 +static void __init save_l2x0_context(void)
  {
-   __raw_writel(l2x0_saved_regs.aux_ctrl,
-sar_base + L2X0_AUXCTRL_OFFSET);
-   __raw_writel(l2x0_saved_regs.prefetch_ctrl,
-sar_base + L2X0_PREFETCH_CTRL_OFFSET);
 -  u32 val;
 -  void __iomem *l2x0_base = omap4_get_l2cache_base();
 -  if (l2x0_base) {
 -  val = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
 -  writel_relaxed(val, sar_base + L2X0_AUXCTRL_OFFSET);
 -  val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
 -  writel_relaxed(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
 -  }
++  writel_relaxed(l2x0_saved_regs.aux_ctrl,
++ sar_base + L2X0_AUXCTRL_OFFSET);
++  writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
++ sar_base + L2X0_PREFETCH_CTRL_OFFSET);
  }
  #else
 -static void save_l2x0_context(void)
 +static void __init save_l2x0_context(void)
  {}
  #endif
  


signature.asc
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/omap-mpuss-lowpower.c between commit 4e4bb5c72f6b
(ARM: l2c: omap2: avoid reading directly from the L2 registers in
platform code) from the arm tree and commit edfaf05c2fcb (ARM:
OMAP2+: raw read and write endian fix) from the arm-soc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 61cb77f8cf12,eb76e47091ad..
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@@ -187,15 -187,19 +187,15 @@@ static void l2x0_pwrst_prepare(unsigne
   * in every restore MPUSS OFF path.
   */
  #ifdef CONFIG_CACHE_L2X0
 -static void save_l2x0_context(void)
 +static void __init save_l2x0_context(void)
  {
-   __raw_writel(l2x0_saved_regs.aux_ctrl,
-sar_base + L2X0_AUXCTRL_OFFSET);
-   __raw_writel(l2x0_saved_regs.prefetch_ctrl,
-sar_base + L2X0_PREFETCH_CTRL_OFFSET);
 -  u32 val;
 -  void __iomem *l2x0_base = omap4_get_l2cache_base();
 -  if (l2x0_base) {
 -  val = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
 -  writel_relaxed(val, sar_base + L2X0_AUXCTRL_OFFSET);
 -  val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
 -  writel_relaxed(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
 -  }
++  writel_relaxed(l2x0_saved_regs.aux_ctrl,
++ sar_base + L2X0_AUXCTRL_OFFSET);
++  writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
++ sar_base + L2X0_PREFETCH_CTRL_OFFSET);
  }
  #else
 -static void save_l2x0_context(void)
 +static void __init save_l2x0_context(void)
  {}
  #endif
  


signature.asc
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got conflicts in
arch/arm/boot/dts/qcom-msm8960.dtsi, arch/arm/boot/dts/qcom-msm8974.dtsi,
arch/arm/mach-omap2/pdata-quirks.c, arch/arm/mach-zynq/Kconfig,
drivers/watchdog/Kconfig and sound/soc/kirkwood/Kconfig between various
merge commits from Linus' tree and various merge commits from the arm-soc
tree.

I used the versions from Linus' tree.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpr90UH7v0d9.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got conflicts in
arch/arm/boot/dts/qcom-msm8960.dtsi, arch/arm/boot/dts/qcom-msm8974.dtsi,
arch/arm/mach-omap2/pdata-quirks.c, arch/arm/mach-zynq/Kconfig,
drivers/watchdog/Kconfig and sound/soc/kirkwood/Kconfig between various
merge commits from Linus' tree and various merge commits from the arm-soc
tree.

I used the versions from Linus' tree.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpr90UH7v0d9.pgp
Description: PGP signature

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  wrote:
> On Wed, Jan 29, 2014 at 4:19 PM, Stephen Rothwell  
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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 khil...@linaro.org wrote:
 On Wed, Jan 29, 2014 at 4:19 PM, Stephen Rothwell s...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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/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 Rothwells...@canb.auug.org.au

diff --cc drivers/clk/Makefile
index a367a9831717,7c7f40e9ba05..
--- 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/


pgpGvhMwrUeW_.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc drivers/clk/Makefile
index a367a9831717,7c7f40e9ba05..
--- 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/


pgpGvhMwrUeW_.pgp
Description: PGP signature

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 s...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm/boot/dts/bcm11351.dtsi
index dd8e878741c0,375a2f8eb878..
--- 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 = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <_clk>;
+   status = "disabled";
+   };
+ 
+   i2c@3e017000 {
+   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+   reg = <0x3e017000 0x80>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <_clk>;
+   status = "disabled";
+   };
+ 
+   i2c@3e018000 {
+   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+   reg = <0x3e018000 0x80>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <_clk>;
+   status = "disabled";
+   };
+ 
+   i2c@3500d000 {
+   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+   reg = <0x3500d000 0x80>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <_bsc_clk>;
+   status = "disabled";
+   };
+ 
+   clocks {
+   bsc1_clk: bsc1 {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   };
+ 
+   bsc2_clk: bsc2 {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   };
+ 
+   bsc3_clk: bsc3 {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   };
+ 
+   pmu_bsc_clk: pmu_bsc {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #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 = <2600>;
+   #clock-cells = <0>;
+   };
+ 
+   sdio1_clk: sdio1 {
+   compatible = "fixed-clock";
+   clock-frequency = <4800>;
+   #clock-cells = <0>;
+   };
+ 
+   sdio2_clk: sdio2 {
+   compatible = "fixed-clock";
+   clock-frequency = <4800>;
+   #clock-cells = <0>;
+   };
+ 
+   sdio3_clk: sdio3 {
+   compatible = "fixed-clock";
+   clock-frequency = <4800>;
+   #clock-cells = <0>;
+   };
+ 
+   sdio4_clk: sdio4 {
+   compatible = "fixed-clock";
+   clock-frequency = <4800>;
+   #clock-cells = <0>;
+   };
+ 
+   tmon_1m_clk: tmon_1m {
+   compatible = "fixed-clock";
+   clock-frequency = <100>;
+   #clock-cells = <0>;
+   };
+ 
+   uartb_clk: uartb {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   };
+ 
+   uartb2_clk: uartb2 {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   };
+ 
+   uartb3_clk: uartb3 {
+   compatible = "fixed-clock";
+   clock-frequency = 

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm/boot/dts/bcm11351.dtsi
index dd8e878741c0,375a2f8eb878..
--- 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 = 1300;
+   #clock-cells = 0;
+   };
+ 
+   bsc2_clk: bsc2 {
+   compatible = fixed-clock;
+   clock-frequency = 1300;
+   #clock-cells = 0;
+   };
+ 
+   bsc3_clk: bsc3 {
+   compatible = fixed-clock;
+   clock-frequency = 1300;
+   #clock-cells = 0;
+   };
+ 
+   pmu_bsc_clk: pmu_bsc {
+   compatible = fixed-clock;
+   clock-frequency = 1300;
+   #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 = 2600;
+   #clock-cells = 0;
+   };
+ 
+   sdio1_clk: sdio1 {
+   compatible = fixed-clock;
+   clock-frequency = 4800;
+   #clock-cells = 0;
+   };
+ 
+   sdio2_clk: sdio2 {
+   compatible = fixed-clock;
+   clock-frequency = 4800;
+   #clock-cells = 0;
+   };
+ 
+   sdio3_clk: sdio3 {
+   compatible = fixed-clock;
+   clock-frequency = 4800;
+   #clock-cells = 0;
+   };
+ 
+   sdio4_clk: sdio4 {
+   compatible = fixed-clock;
+   clock-frequency = 4800;
+   #clock-cells = 0;
+   };
+ 
+   tmon_1m_clk: tmon_1m {
+   compatible = fixed-clock;
+   clock-frequency = 100;
+   #clock-cells = 0;
+   };
+ 
+   uartb_clk: uartb {
+   compatible = fixed-clock;
+   clock-frequency = 1300;
+   #clock-cells = 0;
+   };
+ 
+   uartb2_clk: uartb2 {
+   compatible = fixed-clock;
+   clock-frequency = 1300;
+   #clock-cells = 0;
+   };
+ 
+   uartb3_clk: uartb3 {
+   compatible = fixed-clock;
+   clock-frequency = 

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/Kconfig between commit 85649711a895 ("ARM: gemini: delete
") from the gpio tree and commit f3372c01816e ("ARM: gemini:
convert to GENERIC_CLOCKEVENTS") from the arm-soc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/Kconfig
index 55be62c92b60,04163fece49f..
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -391,8 -385,10 +390,9 @@@ config ARCH_CLPS711
  config ARCH_GEMINI
bool "Cortina Systems Gemini"
select ARCH_REQUIRE_GPIOLIB
-   select ARCH_USES_GETTIMEOFFSET
+   select CLKSRC_MMIO
select CPU_FA526
+   select GENERIC_CLOCKEVENTS
 -  select NEED_MACH_GPIO_H
help
  Support for the Cortina Systems Gemini family SoCs
  


pgpnx5zbU1gZY.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/Kconfig between commit 85649711a895 (ARM: gemini: delete
mach/gpio.h) from the gpio tree and commit f3372c01816e (ARM: gemini:
convert to GENERIC_CLOCKEVENTS) from the arm-soc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/Kconfig
index 55be62c92b60,04163fece49f..
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -391,8 -385,10 +390,9 @@@ config ARCH_CLPS711
  config ARCH_GEMINI
bool Cortina Systems Gemini
select ARCH_REQUIRE_GPIOLIB
-   select ARCH_USES_GETTIMEOFFSET
+   select CLKSRC_MMIO
select CPU_FA526
+   select GENERIC_CLOCKEVENTS
 -  select NEED_MACH_GPIO_H
help
  Support for the Cortina Systems Gemini family SoCs
  


pgpnx5zbU1gZY.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi Stephen,

On Tue, 27 Aug 2013 10:17:21 -0600 Stephen Warren  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@c500 { status = "okay"; -   nvidia,vbus-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 Rothwells...@canb.auug.org.au


pgpuHAsiSKiwD.pgp
Description: PGP signature

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@c500 { status = "okay"; - nvidia,vbus-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:-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm/boot/dts/tegra20-trimslice.dts
index 1e9d33a,22e227f..000
--- 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 = <_clk_reg>;
+   vdd-supply = <_vdd_reg>;
+ 
+   pci@1,0 {
+   status = "okay";
+   };
+   };
+ 
usb@c500 {
status = "okay";
 -  nvidia,vbus-gpio = < TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>;
};
  
usb-phy@c500 {
@@@ -410,10 -421,26 +420,28 @@@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
enable-active-high;
-   gpio = < 170 0>; /* PV2 */
+   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 = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+ 
+   pci_vdd_reg: regulator@4 {
+   compatible = "regulator-fixed";
+   reg = <4>;
+   regulator-name = "pci_vdd";
+   regulator-min-microvolt = <105>;
+   regulator-max-microvolt = <105>;
+   regulator-always-on;
+   };
};
  
sound {


pgpI912EipOxn.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm/boot/dts/tegra20-seaboard.dts
index c824253,f44a9b8..000
--- 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 = <500>;
regulator-max-microvolt = <500>;
enable-active-high;
-   gpio = < 24 0>; /* PD0 */
+   gpio = < TEGRA_GPIO(D, 0) 0>;
 +  regulator-always-on;
 +  regulator-boot-on;
};
};
  


pgpvNVSiUVPrU.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm/boot/dts/tegra20-seaboard.dts
index c824253,f44a9b8..000
--- 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 = 500;
regulator-max-microvolt = 500;
enable-active-high;
-   gpio = gpio 24 0; /* PD0 */
+   gpio = gpio TEGRA_GPIO(D, 0) 0;
 +  regulator-always-on;
 +  regulator-boot-on;
};
};
  


pgpvNVSiUVPrU.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm/boot/dts/tegra20-trimslice.dts
index 1e9d33a,22e227f..000
--- 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@c500 {
status = okay;
 -  nvidia,vbus-gpio = gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH;
};
  
usb-phy@c500 {
@@@ -410,10 -421,26 +420,28 @@@
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
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 = 330;
+   regulator-max-microvolt = 330;
+   regulator-always-on;
+   };
+ 
+   pci_vdd_reg: regulator@4 {
+   compatible = regulator-fixed;
+   reg = 4;
+   regulator-name = pci_vdd;
+   regulator-min-microvolt = 105;
+   regulator-max-microvolt = 105;
+   regulator-always-on;
+   };
};
  
sound {


pgpI912EipOxn.pgp
Description: PGP signature

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@c500 { 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:-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Stephen,

On Tue, 27 Aug 2013 10:17:21 -0600 Stephen Warren swar...@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@c500 { 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 Rothwells...@canb.auug.org.au


pgpuHAsiSKiwD.pgp
Description: PGP signature

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-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 Rothwells...@canb.auug.org.au


pgpG8Vjyb4Ex3.pgp
Description: PGP signature

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-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 Rothwells...@canb.auug.org.au


pgpG8Vjyb4Ex3.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
include/linux/mfd/davinci_voicecodec.h between commit 997174705458 ("mfd:
davinci_voicecodec: Fix build breakage") from the mfd tree and commit
3ad7a42d5a9c ("ARM: davinci: move private EDMA API to arm/common") from
the arm-soc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc include/linux/mfd/davinci_voicecodec.h
index 810aee7,7dd6524..000
--- a/include/linux/mfd/davinci_voicecodec.h
+++ b/include/linux/mfd/davinci_voicecodec.h
@@@ -26,10 -26,8 +26,10 @@@
  #include 
  #include 
  #include 
+ #include 
  
- #include 
 +#include 
 +
  /*
   * Register values.
   */


pgpqvU7I8W9eL.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
include/linux/mfd/davinci_voicecodec.h between commit 997174705458 (mfd:
davinci_voicecodec: Fix build breakage) from the mfd tree and commit
3ad7a42d5a9c (ARM: davinci: move private EDMA API to arm/common) from
the arm-soc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc include/linux/mfd/davinci_voicecodec.h
index 810aee7,7dd6524..000
--- a/include/linux/mfd/davinci_voicecodec.h
+++ b/include/linux/mfd/davinci_voicecodec.h
@@@ -26,10 -26,8 +26,10 @@@
  #include linux/kernel.h
  #include linux/platform_device.h
  #include linux/mfd/core.h
+ #include linux/platform_data/edma.h
  
- #include mach/edma.h
 +#include mach/hardware.h
 +
  /*
   * Register values.
   */


pgpqvU7I8W9eL.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm/boot/dts/snowball.dts
index d3ec32f,b095e85..000
--- 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";


pgp4CNnXXM9iB.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/arm/boot/dts/snowball.dts
index d3ec32f,b095e85..000
--- 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;


pgp4CNnXXM9iB.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-spear13xx/spear13xx.c between commit b47394911c26 ("ARM:
SPEAr13xx: Pass DW DMAC platform data from DT") from the slave-dma tree
and commit 3e270ba6e915 ("ARM: SPEAr13xx: Remove fields not required for
ssp controller") from the arm-soc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/mach-spear13xx/spear13xx.c
index 0e166fa,c4af775..000
--- a/arch/arm/mach-spear13xx/spear13xx.c
+++ b/arch/arm/mach-spear13xx/spear13xx.c
@@@ -25,14 -25,60 +25,12 @@@
  #include 
  #include 
  
 -/* common dw_dma filter routine to be used by peripherals */
 -bool dw_dma_filter(struct dma_chan *chan, void *slave)
 -{
 -  struct dw_dma_slave *dws = (struct dw_dma_slave *)slave;
 -
 -  if (chan->device->dev == dws->dma_dev) {
 -  chan->private = slave;
 -  return true;
 -  } else {
 -  return false;
 -  }
 -}
 -
  /* ssp device registration */
 -static struct dw_dma_slave ssp_dma_param[] = {
 -  {
 -  /* Tx */
 -  .cfg_hi = DWC_CFGH_DST_PER(DMA_REQ_SSP0_TX),
 -  .cfg_lo = 0,
 -  .src_master = DMA_MASTER_MEMORY,
 -  .dst_master = DMA_MASTER_SSP0,
 -  }, {
 -  /* Rx */
 -  .cfg_hi = DWC_CFGH_SRC_PER(DMA_REQ_SSP0_RX),
 -  .cfg_lo = 0,
 -  .src_master = DMA_MASTER_SSP0,
 -  .dst_master = DMA_MASTER_MEMORY,
 -  }
 -};
 -
  struct pl022_ssp_controller pl022_plat_data = {
-   .bus_id = 0,
.enable_dma = 1,
 -  .dma_filter = dw_dma_filter,
 -  .dma_rx_param = _dma_param[1],
 -  .dma_tx_param = _dma_param[0],
 -};
 -
 -/* CF device registration */
 -struct dw_dma_slave cf_dma_priv = {
 -  .cfg_hi = 0,
 -  .cfg_lo = 0,
 -  .src_master = 0,
 -  .dst_master = 0,
 -};
 -
 -/* dmac device registeration */
 -struct dw_dma_platform_data dmac_plat_data = {
 -  .nr_channels = 8,
 -  .chan_allocation_order = CHAN_ALLOCATION_DESCENDING,
 -  .chan_priority = CHAN_PRIORITY_DESCENDING,
 -  .block_size = 4095U,
 -  .nr_masters = 2,
 -  .data_width = { 3, 3, 0, 0 },
 +  .dma_filter = dw_dma_generic_filter,
 +  .dma_rx_param = "ssp0_rx",
 +  .dma_tx_param = "ssp0_tx",
-   .num_chipselect = 3,
  };
  
  void __init spear13xx_l2x0_init(void)


pgpKEX2zGvprl.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-spear13xx/spear13xx.c between commit b47394911c26 (ARM:
SPEAr13xx: Pass DW DMAC platform data from DT) from the slave-dma tree
and commit 3e270ba6e915 (ARM: SPEAr13xx: Remove fields not required for
ssp controller) from the arm-soc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/mach-spear13xx/spear13xx.c
index 0e166fa,c4af775..000
--- a/arch/arm/mach-spear13xx/spear13xx.c
+++ b/arch/arm/mach-spear13xx/spear13xx.c
@@@ -25,14 -25,60 +25,12 @@@
  #include mach/generic.h
  #include mach/spear.h
  
 -/* common dw_dma filter routine to be used by peripherals */
 -bool dw_dma_filter(struct dma_chan *chan, void *slave)
 -{
 -  struct dw_dma_slave *dws = (struct dw_dma_slave *)slave;
 -
 -  if (chan-device-dev == dws-dma_dev) {
 -  chan-private = slave;
 -  return true;
 -  } else {
 -  return false;
 -  }
 -}
 -
  /* ssp device registration */
 -static struct dw_dma_slave ssp_dma_param[] = {
 -  {
 -  /* Tx */
 -  .cfg_hi = DWC_CFGH_DST_PER(DMA_REQ_SSP0_TX),
 -  .cfg_lo = 0,
 -  .src_master = DMA_MASTER_MEMORY,
 -  .dst_master = DMA_MASTER_SSP0,
 -  }, {
 -  /* Rx */
 -  .cfg_hi = DWC_CFGH_SRC_PER(DMA_REQ_SSP0_RX),
 -  .cfg_lo = 0,
 -  .src_master = DMA_MASTER_SSP0,
 -  .dst_master = DMA_MASTER_MEMORY,
 -  }
 -};
 -
  struct pl022_ssp_controller pl022_plat_data = {
-   .bus_id = 0,
.enable_dma = 1,
 -  .dma_filter = dw_dma_filter,
 -  .dma_rx_param = ssp_dma_param[1],
 -  .dma_tx_param = ssp_dma_param[0],
 -};
 -
 -/* CF device registration */
 -struct dw_dma_slave cf_dma_priv = {
 -  .cfg_hi = 0,
 -  .cfg_lo = 0,
 -  .src_master = 0,
 -  .dst_master = 0,
 -};
 -
 -/* dmac device registeration */
 -struct dw_dma_platform_data dmac_plat_data = {
 -  .nr_channels = 8,
 -  .chan_allocation_order = CHAN_ALLOCATION_DESCENDING,
 -  .chan_priority = CHAN_PRIORITY_DESCENDING,
 -  .block_size = 4095U,
 -  .nr_masters = 2,
 -  .data_width = { 3, 3, 0, 0 },
 +  .dma_filter = dw_dma_generic_filter,
 +  .dma_rx_param = ssp0_rx,
 +  .dma_tx_param = ssp0_tx,
-   .num_chipselect = 3,
  };
  
  void __init spear13xx_l2x0_init(void)


pgpKEX2zGvprl.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/x86/include/asm/Kbuild
index 1595d68,66e5f0e..000
--- 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


pgp5wIov1BzU0.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc arch/x86/include/asm/Kbuild
index 1595d68,66e5f0e..000
--- 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


pgp5wIov1BzU0.pgp
Description: PGP signature

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

[Tony Prisk]

On Tue, 2012-09-25 at 16:37 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> Documentation/devicetree/bindings/usb/platform-uhci.txt between commit
> 100d45970327 ("ARM: vt8500: Add support for UHCI companion controller")
> from the usb tree and commit 95e9fd10f06c ("arm: vt8500: doc: Add device
> tree bindings for arch-vt8500 devices") from the arm-soc tree.
> 
> I used the version from the arm-soc tree and can carry the fix as
> necessary (no action is required).
> 

Both versions were the same (my bad for not removing it from the arm-soc
patch).
Thanks Stephen

Regards

Tony P

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
Documentation/devicetree/bindings/usb/platform-uhci.txt between commit
100d45970327 ("ARM: vt8500: Add support for UHCI companion controller")
from the usb tree and commit 95e9fd10f06c ("arm: vt8500: doc: Add device
tree bindings for arch-vt8500 devices") from the arm-soc tree.

I used the version from the arm-soc tree and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgplls4CcdlLM.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
Documentation/devicetree/bindings/usb/platform-uhci.txt between commit
100d45970327 (ARM: vt8500: Add support for UHCI companion controller)
from the usb tree and commit 95e9fd10f06c (arm: vt8500: doc: Add device
tree bindings for arch-vt8500 devices) from the arm-soc tree.

I used the version from the arm-soc tree and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgplls4CcdlLM.pgp
Description: PGP signature

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

[Tony Prisk]

On Tue, 2012-09-25 at 16:37 +1000, Stephen Rothwell wrote:
 Hi all,
 
 Today's linux-next merge of the arm-soc tree got a conflict in
 Documentation/devicetree/bindings/usb/platform-uhci.txt between commit
 100d45970327 (ARM: vt8500: Add support for UHCI companion controller)
 from the usb tree and commit 95e9fd10f06c (arm: vt8500: doc: Add device
 tree bindings for arch-vt8500 devices) from the arm-soc tree.
 
 I used the version from the arm-soc tree and can carry the fix as
 necessary (no action is required).
 

Both versions were the same (my bad for not removing it from the arm-soc
patch).
Thanks Stephen

Regards

Tony P

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-imx/clk-imx51-imx53.c between commit 75453a08e365 ("ARM:
i.MX5: Add nand oftree support") from the mtd tree and commit
a745f039b901 ("ARM i.MX53: register CAN clocks") from the arm-soc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/mach-imx/clk-imx51-imx53.c
index e81f17a,e5165a8..000
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@@ -456,7 -461,10 +462,11 @@@ int __init mx53_clocks_init(unsigned lo
clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "63fcc000.ssi");
clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "50014000.ssi");
clk_register_clkdev(clk[ssi3_ipg_gate], NULL, "63fd.ssi");
 +  clk_register_clkdev(clk[nfc_gate], NULL, "63fdb000.nand");
+   clk_register_clkdev(clk[can1_ipg_gate], "ipg", "53fc8000.can");
+   clk_register_clkdev(clk[can1_serial_gate], "per", "53fc8000.can");
+   clk_register_clkdev(clk[can2_ipg_gate], "ipg", "53fcc000.can");
+   clk_register_clkdev(clk[can2_serial_gate], "per", "53fcc000.can");
  
/* set SDHC root clock to 200MHZ*/
clk_set_rate(clk[esdhc_a_podf], 2);


pgpwMTZ5B9nmr.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-imx/clk-imx51-imx53.c between commit 75453a08e365 (ARM:
i.MX5: Add nand oftree support) from the mtd tree and commit
a745f039b901 (ARM i.MX53: register CAN clocks) from the arm-soc tree.

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/mach-imx/clk-imx51-imx53.c
index e81f17a,e5165a8..000
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@@ -456,7 -461,10 +462,11 @@@ int __init mx53_clocks_init(unsigned lo
clk_register_clkdev(clk[ssi1_ipg_gate], NULL, 63fcc000.ssi);
clk_register_clkdev(clk[ssi2_ipg_gate], NULL, 50014000.ssi);
clk_register_clkdev(clk[ssi3_ipg_gate], NULL, 63fd.ssi);
 +  clk_register_clkdev(clk[nfc_gate], NULL, 63fdb000.nand);
+   clk_register_clkdev(clk[can1_ipg_gate], ipg, 53fc8000.can);
+   clk_register_clkdev(clk[can1_serial_gate], per, 53fc8000.can);
+   clk_register_clkdev(clk[can2_ipg_gate], ipg, 53fcc000.can);
+   clk_register_clkdev(clk[can2_serial_gate], per, 53fcc000.can);
  
/* set SDHC root clock to 200MHZ*/
clk_set_rate(clk[esdhc_a_podf], 2);


pgpwMTZ5B9nmr.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc drivers/watchdog/orion_wdt.c
index a73bea4,1531e02..000
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@@ -23,7 -24,8 +23,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  #include 
  
  /*
@@@ -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, _status))
 -  orion_wdt_disable();
 +  orion_wdt_stop(_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),


pgpZghqpLzRUb.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc drivers/watchdog/orion_wdt.c
index a73bea4,1531e02..000
--- 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),


pgpZghqpLzRUb.pgp
Description: PGP signature