linux-next: Tree for Oct 9

linux-next: Tree for Oct 9

[Thierry Reding]

Hi all,

I've uploaded today's linux-next tree to the master branch of the
repository below:

        git://gitorious.org/thierryreding/linux-next.git

A next-20131009 tag is also provided for convenience.

Gained a few conflicts, but nothing too exciting. x86, ARM, PowerPC and
MIPS default configurations build fine. There were some build failures
unrelated to the merge, most of which I fixed and added as patches on
top of the final merge.

Thierry

[PATCH] ipv6: Unbreak build

[Thierry Reding]

IPv6 specific fields in struct sock_common are accessed in various
places even if IPv6 support is disabled. Fix this by including the
fields unconditionally.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 include/net/sock.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index 7e50df5..c87a8a1 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -192,10 +192,8 @@ struct sock_common {
 	struct net	 	*skc_net;
 #endif
 
-#if IS_ENABLED(CONFIG_IPV6)
 	struct in6_addr		skc_v6_daddr;
 	struct in6_addr		skc_v6_rcv_saddr;
-#endif
 
 	/*
 	 * fields between dontcopy_begin/dontcopy_end
-- 
1.8.4

linux-next: manual merge of the clk tree

[Thierry Reding]

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

	drivers/clk/Makefile

caused by commits f00578d (clk: emev2: Add support for emev2 SMU clocks
with DT), 6cfc229 (clk: keystone: Build Keystone clock drivers) and
308964c (clk: Add APM X-Gene SoC clock driver).

I fixed it up (see below). Please verify that the resolution looks good.

Thanks,
Thierry
---
diff --cc drivers/clk/Makefile
index d25da26,df33820..fe3121b
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@@ -32,7 -32,8 +32,9 @@@ obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500
  obj-$(CONFIG_ARCH_ZYNQ)		+= zynq/
  obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
  obj-$(CONFIG_PLAT_SAMSUNG)	+= samsung/
 +obj-$(CONFIG_ARCH_SHMOBILE_MULTI)	+= shmobile/
+ obj-$(CONFIG_COMMON_CLK_XGENE)  += clk-xgene.o
+ obj-$(CONFIG_COMMON_CLK_KEYSTONE)	+= keystone/
  
  obj-$(CONFIG_X86)		+= x86/
  

linux-next: manual merge of the drm-intel tree

[Thierry Reding]

Today's linux-next merge of the drm-intel tree got conflicts in

	drivers/gpu/drm/i915/i915_dma.c
	drivers/gpu/drm/i915/intel_dp.c

caused by commits 0111be4 (drm: Kill drm perf counter leftovers) and
b14c567 (drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...)
pattern) as well as commits ba0bf12 (drm: Make vblank_disable_allowed
bool) and ce35255 (drm/i915: Fix unclaimed register access due to
delayed VGA memory disable).

I fixed them up (see below). Please verify that the resolution looks
good.

Thanks,
Thierry
---
diff --cc drivers/gpu/drm/i915/i915_dma.c
index 637b695,ad55c02..3316a6f
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@@ -1330,9 -1333,11 +1333,11 @@@ static int i915_load_modeset_init(struc
  
  	/* Always safe in the mode setting case. */
  	/* FIXME: do pre/post-mode set stuff in core KMS code */
 -	dev->vblank_disable_allowed = 1;
 +	dev->vblank_disable_allowed = true;
- 	if (INTEL_INFO(dev)->num_pipes == 0)
+ 	if (INTEL_INFO(dev)->num_pipes == 0) {
+ 		intel_display_power_put(dev, POWER_DOMAIN_VGA);
  		return 0;
+ 	}
  
  	ret = intel_fbdev_init(dev);
  	if (ret)
@@@ -1473,7 -1480,14 +1480,7 @@@ int i915_driver_load(struct drm_device 
  	if (info->gen >= 6 && !drm_core_check_feature(dev, DRIVER_MODESET))
  		return -ENODEV;
  
- 	dev_priv = kzalloc(sizeof(drm_i915_private_t), GFP_KERNEL);
 -	/* i915 has 4 more counters */
 -	dev->counters += 4;
 -	dev->types[6] = _DRM_STAT_IRQ;
 -	dev->types[7] = _DRM_STAT_PRIMARY;
 -	dev->types[8] = _DRM_STAT_SECONDARY;
 -	dev->types[9] = _DRM_STAT_DMA;
 -
+ 	dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
  	if (dev_priv == NULL)
  		return -ENOMEM;
  
diff --cc drivers/gpu/drm/i915/intel_dp.c
index bfbdbb3,c4c280c..3234552
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -1549,8 -1558,8 +1558,8 @@@ static void intel_edp_psr_setup(struct 
  	intel_edp_psr_write_vsc(intel_dp, &psr_vsc);
  
  	/* Avoid continuous PSR exit by masking memup and hpd */
- 	I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
+ 	I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
 -		   EDP_PSR_DEBUG_MASK_HPD);
 +		   EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
  
  	intel_dp->psr_setup_done = true;
  }

linux-next: manual merge of the imx-mxs tree

[Thierry Reding]

Today's linux-next merge of the imx-mxs tree got conflicts in

	arch/arm/mach-imx/clk-imx51-imx53.c
	arch/arm/mach-imx/mach-imx6q.c

caused by commits 0efe995 (ARM: mach-imx: clk-imx51-imx53: Retrieve base
address and irq from dt), d2b36f6 (ARM: imx: replace imx6q_restart()
with mxc_restart()) and 4d9d18a (ARM: imx: remove custom .init_time
hook).

I fixed them up (see below). Please verify that the resolution looks
good.

Thanks,
Thierry
---
diff --cc arch/arm/mach-imx/clk-imx51-imx53.c
index ceaac9c,03ca2e3..fa4de9a
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@@ -11,9 -11,11 +11,12 @@@
  #include <linux/clk.h>
  #include <linux/io.h>
  #include <linux/clkdev.h>
 +#include <linux/clk-provider.h>
  #include <linux/of.h>
  #include <linux/err.h>
+ #include <linux/of.h>
+ #include <linux/of_address.h>
+ #include <linux/of_irq.h>
  
  #include "crm-regs-imx5.h"
  #include "clk.h"
@@@ -464,16 -468,13 +467,17 @@@ int __init mx51_clocks_init(unsigned lo
  	return 0;
  }
  
 -int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 -			unsigned long rate_ckih1, unsigned long rate_ckih2)
 +static void __init mx51_clocks_init_dt(struct device_node *np)
 +{
 +	mx51_clocks_init(0, 0, 0, 0);
 +}
 +CLK_OF_DECLARE(imx51_ccm, "fsl,imx51-ccm", mx51_clocks_init_dt);
 +
 +static void __init mx53_clocks_init(struct device_node *np)
  {
- 	int i;
+ 	int i, irq;
  	unsigned long r;
 -	struct device_node *np;
+ 	void __iomem *base;
  
  	clk[pll1_sw] = imx_clk_pllv2("pll1_sw", "osc", MX53_DPLL1_BASE);
  	clk[pll2_sw] = imx_clk_pllv2("pll2_sw", "osc", MX53_DPLL2_BASE);
@@@ -568,5 -567,22 +569,13 @@@
  
  	r = clk_round_rate(clk[usboh3_per_gate], 54000000);
  	clk_set_rate(clk[usboh3_per_gate], r);
+ 
+ 	np = of_find_compatible_node(NULL, NULL, "fsl,imx53-gpt");
+ 	base = of_iomap(np, 0);
+ 	WARN_ON(!base);
+ 	irq = irq_of_parse_and_map(np, 0);
+ 	mxc_timer_init(base, irq);
+ 
+ 	return 0;
  }
 -
 -int __init mx51_clocks_init_dt(void)
 -{
 -	return mx51_clocks_init(0, 0, 0, 0);
 -}
 -
 -int __init mx53_clocks_init_dt(void)
 -{
 -	return mx53_clocks_init(0, 0, 0, 0);
 -}
 +CLK_OF_DECLARE(imx53_ccm, "fsl,imx53-ccm", mx53_clocks_init);
diff --cc arch/arm/mach-imx/mach-imx6q.c
index 3be0fa0,53e70f4..0f9f241
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@@ -11,9 -11,10 +11,8 @@@
   */
  
  #include <linux/clk.h>
 -#include <linux/clk-provider.h>
  #include <linux/clkdev.h>
 -#include <linux/clocksource.h>
  #include <linux/cpu.h>
- #include <linux/delay.h>
  #include <linux/export.h>
  #include <linux/init.h>
  #include <linux/io.h>
@@@ -190,8 -133,13 +131,16 @@@ static void __init imx6q_1588_init(void
  
  static void __init imx6q_init_machine(void)
  {
+ 	struct device *parent;
+ 
 +	imx_print_silicon_rev(cpu_is_imx6dl() ? "i.MX6DL" : "i.MX6Q",
- 			      imx6q_revision());
++			      imx_get_soc_revision());
++
+ 	mxc_arch_reset_init_dt();
+ 
+ 	parent = imx_soc_device_init();
+ 	if (parent == NULL)
+ 		pr_warn("failed to initialize soc device\n");
  
  	imx6q_enet_phy_init();
  

linux-next: manual merge of the mvebu tree

[Thierry Reding]

Today's linux-next merge of the mvebu tree got conflicts in

	arch/arm/mach-dove/board-dt.c
	arch/arm/mach-kirkwood/board-dt.c

caused by commits ebd7d3a (ARM: kirkwood: retain MAC address for DT
ethernet), 511aaab (ARM: kirkwood: Remove unneeded MBus initialization)
and a169e3a (ARM: kirkwood: remove custom .init_time hook) as well as
ccbd35c (ARM: dove: remove legacy pcie and clock init), e5901b5 (ARM:
dove: switch to DT probed mbus address windows) and 51e40f5 (ARM: dove:
remove custom .init_time hook).

I fixed them up (see below). Please verify that the resolution looks
good.

Thanks,
Thierry
---
diff --cc arch/arm/mach-dove/board-dt.c
index ddb8663,9a116d7..49fa9ab
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-dove/board-dt.c
@@@ -17,37 -20,15 +17,8 @@@
  #include <mach/dove.h>
  #include <mach/pm.h>
  #include <plat/common.h>
 -#include <plat/irq.h>
  #include "common.h"
  
- /*
-  * There are still devices that doesn't even know about DT,
-  * get clock gates here and add a clock lookup.
-  */
- static void __init dove_legacy_clk_init(void)
- {
- 	struct device_node *np = of_find_compatible_node(NULL, NULL,
- 					 "marvell,dove-gating-clock");
- 	struct of_phandle_args clkspec;
- 
- 	clkspec.np = np;
- 	clkspec.args_count = 1;
- 
- 	clkspec.args[0] = CLOCK_GATING_BIT_PCIE0;
- 	orion_clkdev_add("0", "pcie",
- 			 of_clk_get_from_provider(&clkspec));
- 
- 	clkspec.args[0] = CLOCK_GATING_BIT_PCIE1;
- 	orion_clkdev_add("1", "pcie",
- 			 of_clk_get_from_provider(&clkspec));
- }
- 
- static void __init dove_dt_init_early(void)
 -static void __init dove_dt_time_init(void)
--{
- 	mvebu_mbus_init("marvell,dove-mbus",
- 			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
- 			DOVE_MC_WINS_BASE, DOVE_MC_WINS_SZ);
 -	of_clk_init(NULL);
 -	clocksource_of_init();
--}
--
  static void __init dove_dt_init(void)
  {
  	pr_info("Dove 88AP510 SoC\n");
@@@ -73,7 -47,7 +37,6 @@@ static const char * const dove_dt_board
  
  DT_MACHINE_START(DOVE_DT, "Marvell Dove (Flattened Device Tree)")
  	.map_io		= dove_map_io,
- 	.init_early	= dove_dt_init_early,
 -	.init_time	= dove_dt_time_init,
  	.init_machine	= dove_dt_init,
  	.restart	= dove_restart,
  	.dt_compat	= dove_dt_board_compat,
diff --cc arch/arm/mach-kirkwood/board-dt.c
index a32a3e5,2ac2a3f..9caa4fe
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@@ -13,8 -13,11 +13,10 @@@
  #include <linux/kernel.h>
  #include <linux/init.h>
  #include <linux/of.h>
+ #include <linux/of_address.h>
+ #include <linux/of_net.h>
  #include <linux/of_platform.h>
  #include <linux/clk-provider.h>
 -#include <linux/clocksource.h>
  #include <linux/dma-mapping.h>
  #include <linux/irqchip.h>
  #include <linux/kexec.h>
@@@ -65,13 -60,91 +59,85 @@@ static void __init kirkwood_legacy_clk_
  	clk_prepare_enable(clk);
  }
  
- static void __init kirkwood_dt_init_early(void)
+ #define MV643XX_ETH_MAC_ADDR_LOW	0x0414
+ #define MV643XX_ETH_MAC_ADDR_HIGH	0x0418
+ 
+ static void __init kirkwood_dt_eth_fixup(void)
  {
- 	mvebu_mbus_init("marvell,kirkwood-mbus",
- 			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
- 			DDR_WINDOW_CPU_BASE, DDR_WINDOW_CPU_SZ);
+ 	struct device_node *np;
+ 
+ 	/*
+ 	 * The ethernet interfaces forget the MAC address assigned by u-boot
+ 	 * if the clocks are turned off. Usually, u-boot on kirkwood boards
+ 	 * has no DT support to properly set local-mac-address property.
+ 	 * As a workaround, we get the MAC address from mv643xx_eth registers
+ 	 * and update the port device node if no valid MAC address is set.
+ 	 */
+ 	for_each_compatible_node(np, NULL, "marvell,kirkwood-eth-port") {
+ 		struct device_node *pnp = of_get_parent(np);
+ 		struct clk *clk;
+ 		struct property *pmac;
+ 		void __iomem *io;
+ 		u8 *macaddr;
+ 		u32 reg;
+ 
+ 		if (!pnp)
+ 			continue;
+ 
+ 		/* skip disabled nodes or nodes with valid MAC address*/
+ 		if (!of_device_is_available(pnp) || of_get_mac_address(np))
+ 			goto eth_fixup_skip;
+ 
+ 		clk = of_clk_get(pnp, 0);
+ 		if (IS_ERR(clk))
+ 			goto eth_fixup_skip;
+ 
+ 		io = of_iomap(pnp, 0);
+ 		if (!io)
+ 			goto eth_fixup_no_map;
+ 
+ 		/* ensure port clock is not gated to not hang CPU */
+ 		clk_prepare_enable(clk);
+ 
+ 		/* store MAC address register contents in local-mac-address */
+ 		pr_err(FW_INFO "%s: local-mac-address is not set\n",
+ 		       np->full_name);
+ 
+ 		pmac = kzalloc(sizeof(*pmac) + 6, GFP_KERNEL);
+ 		if (!pmac)
+ 			goto eth_fixup_no_mem;
+ 
+ 		pmac->value = pmac + 1;
+ 		pmac->length = 6;
+ 		pmac->name = kstrdup("local-mac-address", GFP_KERNEL);
+ 		if (!pmac->name) {
+ 			kfree(pmac);
+ 			goto eth_fixup_no_mem;
+ 		}
+ 
+ 		macaddr = pmac->value;
+ 		reg = readl(io + MV643XX_ETH_MAC_ADDR_HIGH);
+ 		macaddr[0] = (reg >> 24) & 0xff;
+ 		macaddr[1] = (reg >> 16) & 0xff;
+ 		macaddr[2] = (reg >> 8) & 0xff;
+ 		macaddr[3] = reg & 0xff;
+ 
+ 		reg = readl(io + MV643XX_ETH_MAC_ADDR_LOW);
+ 		macaddr[4] = (reg >> 8) & 0xff;
+ 		macaddr[5] = reg & 0xff;
+ 
+ 		of_update_property(np, pmac);
+ 
+ eth_fixup_no_mem:
+ 		iounmap(io);
+ 		clk_disable_unprepare(clk);
+ eth_fixup_no_map:
+ 		clk_put(clk);
+ eth_fixup_skip:
+ 		of_node_put(pnp);
+ 	}
  }
  
 -static void __init kirkwood_dt_time_init(void)
 -{
 -	of_clk_init(NULL);
 -	clocksource_of_init();
 -}
 -
  static void __init kirkwood_dt_init(void)
  {
  	pr_info("Kirkwood: %s, TCLK=%d.\n", kirkwood_id(), kirkwood_tclk);
@@@ -114,7 -187,7 +180,6 @@@ static const char * const kirkwood_dt_b
  DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
  	/* Maintainer: Jason Cooper <jason@lakedaemon.net> */
  	.map_io		= kirkwood_map_io,
- 	.init_early	= kirkwood_dt_init_early,
 -	.init_time	= kirkwood_dt_time_init,
  	.init_machine	= kirkwood_dt_init,
  	.restart	= kirkwood_restart,
  	.dt_compat	= kirkwood_dt_board_compat,

Re: linux-next: manual merge of the mvebu tree

[Jason Cooper]

On Wed, Oct 09, 2013 at 04:14:27PM +0200, Thierry Reding wrote:
> Today's linux-next merge of the mvebu tree got conflicts in
> 
> 	arch/arm/mach-dove/board-dt.c
> 	arch/arm/mach-kirkwood/board-dt.c
> 
> caused by commits ebd7d3a (ARM: kirkwood: retain MAC address for DT
> ethernet), 511aaab (ARM: kirkwood: Remove unneeded MBus initialization)
> and a169e3a (ARM: kirkwood: remove custom .init_time hook) as well as
> ccbd35c (ARM: dove: remove legacy pcie and clock init), e5901b5 (ARM:
> dove: switch to DT probed mbus address windows) and 51e40f5 (ARM: dove:
> remove custom .init_time hook).
> 
> I fixed them up (see below). Please verify that the resolution looks
> good.

Looks good to me, thanks for picking up the linux-next duties, it's a
big help.

thx,

Jason.

Re: linux-next: manual merge of the mvebu tree

[Jason Cooper]

Thierry,

On Wed, Oct 09, 2013 at 04:14:27PM +0200, Thierry Reding wrote:
> Today's linux-next merge of the mvebu tree got conflicts in

I looked in your scripts repo, and couldn't find the script you use to
send out this email thread :(  Since I can't create a patch, I'll just
ask, could you include the commit id of the branch you pulled in the
email?

eg:

Today's linux-next merge of the mvebu tree (477cdaf) got conflicts in
...

I had uploaded a new for-next branch less than 30 minutes before you
sent this out, so I wasn't sure which you were working with.  Not a big
deal, just thought I'd pass along the idea for the next time you're
tweaking your scripts.

thx,

Jason.

Re: [PATCH] ipv6: Unbreak build

[Eric Dumazet]

On Wed, 2013-10-09 at 16:14 +0200, Thierry Reding wrote:
> IPv6 specific fields in struct sock_common are accessed in various
> places even if IPv6 support is disabled. Fix this by including the
> fields unconditionally.

Well no. There is a reason we keep CONFIG_IPV6 at all.

The right fix is under review :
http://patchwork.ozlabs.org/patch/281784/

Thanks

Re: linux-next: Tree for Oct 9

[Guenter Roeck]

On Wed, Oct 09, 2013 at 04:14:22PM +0200, Thierry Reding wrote:
> Hi all,
> 
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
> 
>         git://gitorious.org/thierryreding/linux-next.git
> 
> A next-20131009 tag is also provided for convenience.
> 
> Gained a few conflicts, but nothing too exciting. x86, ARM, PowerPC and
> MIPS default configurations build fine. There were some build failures
> unrelated to the merge, most of which I fixed and added as patches on
> top of the final merge.
> 
Build results:
	total: 110 pass: 93 skipped: 4 fail: 13
	[3.12-rc4: total: 110 pass: 105 skipped: 3 fail: 2]

Failed builds:
	alpha:allmodconfig
	arm:allmodconfig
	blackfin:defconfig
	i386:allyesconfig
	i386:allmodconfig
	m68k:allmodconfig
	mips:allmodconfig
	mips:nlm_xlp_defconfig
	powerpc:allmodconfig
	sparc64:allmodconfig
	x86_64:allmodconfig
	x86_64:allyesconfig
	xtensa:allmodconfig

Many of the failures are due to ceph:

fs/ceph/file.c: In function 'ceph_sync_read':
fs/ceph/file.c:437:25: error: 'struct iov_iter' has no member named 'iov'
...

Guenter

Re: linux-next: Tree for Oct 9

[Guenter Roeck]

On Wed, Oct 09, 2013 at 08:29:06AM -0700, Guenter Roeck wrote:
> On Wed, Oct 09, 2013 at 04:14:22PM +0200, Thierry Reding wrote:
> > Hi all,
> > 
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> > 
> >         git://gitorious.org/thierryreding/linux-next.git
> > 
> > A next-20131009 tag is also provided for convenience.
> > 
> > Gained a few conflicts, but nothing too exciting. x86, ARM, PowerPC and
> > MIPS default configurations build fine. There were some build failures
> > unrelated to the merge, most of which I fixed and added as patches on
> > top of the final merge.
> > 
> Build results:
> 	total: 110 pass: 93 skipped: 4 fail: 13
> 	[3.12-rc4: total: 110 pass: 105 skipped: 3 fail: 2]
> 
> Failed builds:
> 	alpha:allmodconfig
> 	arm:allmodconfig
> 	blackfin:defconfig
> 	i386:allyesconfig
> 	i386:allmodconfig
> 	m68k:allmodconfig
> 	mips:allmodconfig
> 	mips:nlm_xlp_defconfig
> 	powerpc:allmodconfig
> 	sparc64:allmodconfig
> 	x86_64:allmodconfig
> 	x86_64:allyesconfig
> 	xtensa:allmodconfig
> 
> Many of the failures are due to ceph:
> 
> fs/ceph/file.c: In function 'ceph_sync_read':
> fs/ceph/file.c:437:25: error: 'struct iov_iter' has no member named 'iov'
> ...
> 
Sorry, that was the result for yesterday's tree. I should have results for the
October 9 tree in a couple of hours.

Guenter

Re: linux-next: manual merge of the imx-mxs tree

[Fabio Estevam]

Hi Thierry,

On Wed, Oct 9, 2013 at 11:14 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> Today's linux-next merge of the imx-mxs tree got conflicts in
>
>         arch/arm/mach-imx/clk-imx51-imx53.c
>         arch/arm/mach-imx/mach-imx6q.c
>
> caused by commits 0efe995 (ARM: mach-imx: clk-imx51-imx53: Retrieve base
> address and irq from dt), d2b36f6 (ARM: imx: replace imx6q_restart()
> with mxc_restart()) and 4d9d18a (ARM: imx: remove custom .init_time
> hook).
>
> I fixed them up (see below). Please verify that the resolution looks
> good.
...

>  +static void __init mx53_clocks_init(struct device_node *np)
>   {
> -       int i;
> +       int i, irq;
>         unsigned long r;
>  -      struct device_node *np;
> +       void __iomem *base;
>
>         clk[pll1_sw] = imx_clk_pllv2("pll1_sw", "osc", MX53_DPLL1_BASE);
>         clk[pll2_sw] = imx_clk_pllv2("pll2_sw", "osc", MX53_DPLL2_BASE);
> @@@ -568,5 -567,22 +569,13 @@@
>
>         r = clk_round_rate(clk[usboh3_per_gate], 54000000);
>         clk_set_rate(clk[usboh3_per_gate], r);
> +
> +       np = of_find_compatible_node(NULL, NULL, "fsl,imx53-gpt");
> +       base = of_iomap(np, 0);
> +       WARN_ON(!base);
> +       irq = irq_of_parse_and_map(np, 0);
> +       mxc_timer_init(base, irq);
> +
> +       return 0;

This 'return 0' should be removed as the  function now changed to void.

I have sent a patch fixing it.

Regards,

Fabio Estevam

Re: linux-next: Tree for Oct 9

[Guenter Roeck]

On Wed, Oct 09, 2013 at 08:44:24AM -0700, Guenter Roeck wrote:
> On Wed, Oct 09, 2013 at 08:29:06AM -0700, Guenter Roeck wrote:
> > On Wed, Oct 09, 2013 at 04:14:22PM +0200, Thierry Reding wrote:
> > > Hi all,
> > > 
> > > I've uploaded today's linux-next tree to the master branch of the
> > > repository below:
> > > 
> > >         git://gitorious.org/thierryreding/linux-next.git
> > > 
> > > A next-20131009 tag is also provided for convenience.
> > > 
> > > Gained a few conflicts, but nothing too exciting. x86, ARM, PowerPC and
> > > MIPS default configurations build fine. There were some build failures
> > > unrelated to the merge, most of which I fixed and added as patches on
> > > top of the final merge.
> > > 
> > Build results:
> > 	total: 110 pass: 93 skipped: 4 fail: 13
> > 	[3.12-rc4: total: 110 pass: 105 skipped: 3 fail: 2]
> > 
> > Failed builds:
> > 	alpha:allmodconfig
> > 	arm:allmodconfig
> > 	blackfin:defconfig
> > 	i386:allyesconfig
> > 	i386:allmodconfig
> > 	m68k:allmodconfig
> > 	mips:allmodconfig
> > 	mips:nlm_xlp_defconfig
> > 	powerpc:allmodconfig
> > 	sparc64:allmodconfig
> > 	x86_64:allmodconfig
> > 	x86_64:allyesconfig
> > 	xtensa:allmodconfig
> > 
> > Many of the failures are due to ceph:
> > 
> > fs/ceph/file.c: In function 'ceph_sync_read':
> > fs/ceph/file.c:437:25: error: 'struct iov_iter' has no member named 'iov'
> > ...
> > 
> Sorry, that was the result for yesterday's tree. I should have results for the
> October 9 tree in a couple of hours.
> 
October 9 results are exactly the same.

Guenter

Re: [PATCH] ipv6: Unbreak build

[Thierry Reding]

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

On Wed, Oct 09, 2013 at 07:41:43AM -0700, Eric Dumazet wrote:
> On Wed, 2013-10-09 at 16:14 +0200, Thierry Reding wrote:
> > IPv6 specific fields in struct sock_common are accessed in various
> > places even if IPv6 support is disabled. Fix this by including the
> > fields unconditionally.
> 
> Well no. There is a reason we keep CONFIG_IPV6 at all.
> 
> The right fix is under review :
> http://patchwork.ozlabs.org/patch/281784/

Yes that's obviously the better fix. In fact doing exactly that was my
first instinct as well, but it seemed to be more invasive and I really
just wanted a temporary fix for the build errors.

I see that David has already applied the above patch, so this band-aid
should no longer be necessary.

Thanks,
Thierry

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

Re: linux-next: manual merge of the mvebu tree

[Thierry Reding]

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

On Wed, Oct 09, 2013 at 10:37:27AM -0400, Jason Cooper wrote:
> Thierry,
> 
> On Wed, Oct 09, 2013 at 04:14:27PM +0200, Thierry Reding wrote:
> > Today's linux-next merge of the mvebu tree got conflicts in
> 
> I looked in your scripts repo, and couldn't find the script you use to
> send out this email thread :( 

Well, that's because I'm doing them manually.

> Since I can't create a patch, I'll just ask, could you include the
> commit id of the branch you pulled in the email?
> 
> eg:
> 
> Today's linux-next merge of the mvebu tree (477cdaf) got conflicts in
> ...
> 
> I had uploaded a new for-next branch less than 30 minutes before you
> sent this out, so I wasn't sure which you were working with.  Not a big
> deal, just thought I'd pass along the idea for the next time you're
> tweaking your scripts.

It should be possible to extend the Next/fetch script with something
that writes the SHA1 of each tree to a file. Stephen's linux-next trees
contain such a file (Next/SHA1s). I'll see if I can find the time to
update my scripts to do the same. That won't make it magically appear in
the notification email, but I can probably remember to do that in the
future.

Thanks,
Thierry

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

Re: linux-next: manual merge of the mvebu tree

[Jason Cooper]

On Thu, Oct 10, 2013 at 12:57:03PM +0200, Thierry Reding wrote:
> On Wed, Oct 09, 2013 at 10:37:27AM -0400, Jason Cooper wrote:
> > Thierry,
> > 
> > On Wed, Oct 09, 2013 at 04:14:27PM +0200, Thierry Reding wrote:
> > > Today's linux-next merge of the mvebu tree got conflicts in
> > 
> > I looked in your scripts repo, and couldn't find the script you use to
> > send out this email thread :( 
> 
> Well, that's because I'm doing them manually.

:)  Nice.  I do like the threading, it provides a nice consolidated
summary of the day's tree.

> > Since I can't create a patch, I'll just ask, could you include the
> > commit id of the branch you pulled in the email?
> > 
> > eg:
> > 
> > Today's linux-next merge of the mvebu tree (477cdaf) got conflicts in
> > ...
> > 
> > I had uploaded a new for-next branch less than 30 minutes before you
> > sent this out, so I wasn't sure which you were working with.  Not a big
> > deal, just thought I'd pass along the idea for the next time you're
> > tweaking your scripts.
> 
> It should be possible to extend the Next/fetch script with something
> that writes the SHA1 of each tree to a file. Stephen's linux-next trees
> contain such a file (Next/SHA1s). I'll see if I can find the time to
> update my scripts to do the same. That won't make it magically appear in
> the notification email, but I can probably remember to do that in the
> future.

No, not necessary.  I don't want to add unnecessary work to your plate.
If the script modification put it in the email notification
automagically, it might be worth doing, but if a tree owner is already
looking at your -next tree, it's trivial to go one step further and look
at the merge commit (which is what I did in this case).

thanks, and sorry for the noise.

Jason.