* Re: [GIT PULL] Renesas SoC updates for v3.4
@ 2012-03-09 21:34 ` Arnd Bergmann
0 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2012-03-09 21:34 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: LKML, Magnus Damm, Linux-sh list, arm, Paul Mundt, Rob Herring
On Friday 09 March 2012, Rafael J. Wysocki wrote:
> Hi,
>
> Please pull Renesas SoC updates for v3.4 since commit
> ce8fea7aa4ad9e3b40999a08622ef27c77159659:
>
> mmap: EINVAL not ENOMEM when rejecting VM_GROWS
>
> with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
Hi Rafael,
Please rebase this on an -rc release, otherwise we get a rather
messy history in the arm-soc tree.
> ARM: mach-shmobile: default to no earlytimer
>
> from the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc
>
> They include:
>
> * The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
> possible future name space collision with common struct clk code.
>
> This also affects drivers that are shared with the sh architecture,
> so the branch containing this part of the material, clk_ops-rename,
> will be merged into the Paul Mundt's sh tree if necessary.
>
> * Introduction of L2 Cache support for r8a7779.
>
> * Conversion of the mach-shmobile subarch to properly use a per-SoC
> map_io and separate init_early callback for early serial console
> support on platforms where that is possible.
>
> Magnus Damm is the author of all the changes.
For next time, I think it would be good to make those things separate pull
requests, since they are all rather big. In particular, the clk rework
could be a series by itself.
One thing I noticed while browsing through the patches was this hunk
that Rob should know about:
@@ -242,6 +243,10 @@ static struct platform_device *r8a7779_late_devices[] __initdata = {
void __init r8a7779_add_standard_devices(void)
{
+#ifdef CONFIG_CACHE_L2X0
+ /* Early BRESP enable, Shared attribute override enable, 64K*16way */
+ l2x0_init(__io(0xf0100000), 0x40470000, 0x82000fff);
+#endif
r8a7779_pm_init();
r8a7779_init_pm_domain(&r8a7779_sh4a);
Here you are abusing the __io() macro rather badly as a typecast. This breaks
with Rob's series to turn __io(foo) into a NULL pointer for the case where
PCI is disabled. I found a few more of these, mostly in mach-shmobile but
also some others:
arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
arch/arm/mach-cns3xxx/core.c: gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
arch/arm/mach-cns3xxx/core.c: __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
arch/arm/mach-cns3xxx/core.c: u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
arch/arm/mach-cns3xxx/core.c: cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
arch/arm/mach-cns3xxx/devices.c: u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
arch/arm/mach-netx/generic.c: vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs) __io(NETX_VA_SYSTEM + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs) __io(NETX_VA_GPIO + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs) __io(NETX_VA_PIO + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU __io(NETX_VA_MIIMU)
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs) __io(NETX_VA_PFIFO + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs) __io(NETX_VA_MEMCR + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs) __io(NETX_VA_DPMAS + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs) __io(NETX_VA_I2C, (ofs))
arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
arch/arm/mach-shmobile/board-ag5evm.c: l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
arch/arm/mach-shmobile/board-bonito.c: l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
arch/arm/mach-shmobile/board-kota2.c: l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
arch/arm/mach-shmobile/include/mach/io.h:#define __io(a) ((void __iomem *)(a))
arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_dist_base = __io(0xf0001000);
arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_cpu_base = __io(0xf0000100);
arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_dist_base = __io(0xf0001000);
arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_cpu_base = __io(0xf0000100);
arch/arm/mach-shmobile/smp-r8a7779.c: __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
arch/arm/mach-shmobile/smp-sh73a0.c: if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) == 3)
arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(WUPCR)); /* wake up */
arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(SRESCR)); /* reset */
arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(0, __io(APARMBAREA)); /* 4k */
arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
These are all broken and need to be changed to something else before we add the
global definition for __io.
Arnd
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
2012-03-09 21:34 ` Arnd Bergmann
@ 2012-03-09 21:48 ` Rob Herring
-1 siblings, 0 replies; 39+ messages in thread
From: Rob Herring @ 2012-03-09 21:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rafael J. Wysocki, LKML, Magnus Damm, Linux-sh list, arm, Paul Mundt
On 03/09/2012 03:34 PM, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
>> Hi,
>>
>> Please pull Renesas SoC updates for v3.4 since commit
>> ce8fea7aa4ad9e3b40999a08622ef27c77159659:
>>
>> mmap: EINVAL not ENOMEM when rejecting VM_GROWS
>>
>> with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
>
> Hi Rafael,
>
> Please rebase this on an -rc release, otherwise we get a rather
> messy history in the arm-soc tree.
>
>> ARM: mach-shmobile: default to no earlytimer
>>
>> from the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc
>>
>> They include:
>>
>> * The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
>> possible future name space collision with common struct clk code.
>>
>> This also affects drivers that are shared with the sh architecture,
>> so the branch containing this part of the material, clk_ops-rename,
>> will be merged into the Paul Mundt's sh tree if necessary.
>>
>> * Introduction of L2 Cache support for r8a7779.
>>
>> * Conversion of the mach-shmobile subarch to properly use a per-SoC
>> map_io and separate init_early callback for early serial console
>> support on platforms where that is possible.
>>
>> Magnus Damm is the author of all the changes.
>
> For next time, I think it would be good to make those things separate pull
> requests, since they are all rather big. In particular, the clk rework
> could be a series by itself.
>
> One thing I noticed while browsing through the patches was this hunk
> that Rob should know about:
>
> @@ -242,6 +243,10 @@ static struct platform_device *r8a7779_late_devices[] __initdata = {
>
> void __init r8a7779_add_standard_devices(void)
> {
> +#ifdef CONFIG_CACHE_L2X0
> + /* Early BRESP enable, Shared attribute override enable, 64K*16way */
> + l2x0_init(__io(0xf0100000), 0x40470000, 0x82000fff);
> +#endif
> r8a7779_pm_init();
>
> r8a7779_init_pm_domain(&r8a7779_sh4a);
>
> Here you are abusing the __io() macro rather badly as a typecast. This breaks
> with Rob's series to turn __io(foo) into a NULL pointer for the case where
> PCI is disabled. I found a few more of these, mostly in mach-shmobile but
> also some others:
>
> arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> arch/arm/mach-cns3xxx/core.c: gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> arch/arm/mach-cns3xxx/core.c: __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> arch/arm/mach-cns3xxx/core.c: u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> arch/arm/mach-cns3xxx/core.c: cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> arch/arm/mach-cns3xxx/devices.c: u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> arch/arm/mach-netx/generic.c: vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs) __io(NETX_VA_SYSTEM + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs) __io(NETX_VA_GPIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs) __io(NETX_VA_PIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU __io(NETX_VA_MIIMU)
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs) __io(NETX_VA_PFIFO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs) __io(NETX_VA_MEMCR + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs) __io(NETX_VA_DPMAS + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs) __io(NETX_VA_I2C, (ofs))
> arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> arch/arm/mach-shmobile/board-ag5evm.c: l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> arch/arm/mach-shmobile/board-bonito.c: l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> arch/arm/mach-shmobile/board-kota2.c: l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> arch/arm/mach-shmobile/include/mach/io.h:#define __io(a) ((void __iomem *)(a))
> arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/smp-r8a7779.c: __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> arch/arm/mach-shmobile/smp-sh73a0.c: if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) = 3)
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(WUPCR)); /* wake up */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(SRESCR)); /* reset */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(0, __io(APARMBAREA)); /* 4k */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
>
> These are all broken and need to be changed to something else before we add the
> global definition for __io.
Several platforms define IO_MEM for the purpose of casting the defines
to void __iomem *, so I'll make that common unless you have better
suggestion. I'd guess that changing the defines themselves will cause
lots of warnings in other places.
Rob
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
@ 2012-03-09 21:48 ` Rob Herring
0 siblings, 0 replies; 39+ messages in thread
From: Rob Herring @ 2012-03-09 21:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rafael J. Wysocki, LKML, Magnus Damm, Linux-sh list, arm, Paul Mundt
On 03/09/2012 03:34 PM, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
>> Hi,
>>
>> Please pull Renesas SoC updates for v3.4 since commit
>> ce8fea7aa4ad9e3b40999a08622ef27c77159659:
>>
>> mmap: EINVAL not ENOMEM when rejecting VM_GROWS
>>
>> with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
>
> Hi Rafael,
>
> Please rebase this on an -rc release, otherwise we get a rather
> messy history in the arm-soc tree.
>
>> ARM: mach-shmobile: default to no earlytimer
>>
>> from the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc
>>
>> They include:
>>
>> * The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
>> possible future name space collision with common struct clk code.
>>
>> This also affects drivers that are shared with the sh architecture,
>> so the branch containing this part of the material, clk_ops-rename,
>> will be merged into the Paul Mundt's sh tree if necessary.
>>
>> * Introduction of L2 Cache support for r8a7779.
>>
>> * Conversion of the mach-shmobile subarch to properly use a per-SoC
>> map_io and separate init_early callback for early serial console
>> support on platforms where that is possible.
>>
>> Magnus Damm is the author of all the changes.
>
> For next time, I think it would be good to make those things separate pull
> requests, since they are all rather big. In particular, the clk rework
> could be a series by itself.
>
> One thing I noticed while browsing through the patches was this hunk
> that Rob should know about:
>
> @@ -242,6 +243,10 @@ static struct platform_device *r8a7779_late_devices[] __initdata = {
>
> void __init r8a7779_add_standard_devices(void)
> {
> +#ifdef CONFIG_CACHE_L2X0
> + /* Early BRESP enable, Shared attribute override enable, 64K*16way */
> + l2x0_init(__io(0xf0100000), 0x40470000, 0x82000fff);
> +#endif
> r8a7779_pm_init();
>
> r8a7779_init_pm_domain(&r8a7779_sh4a);
>
> Here you are abusing the __io() macro rather badly as a typecast. This breaks
> with Rob's series to turn __io(foo) into a NULL pointer for the case where
> PCI is disabled. I found a few more of these, mostly in mach-shmobile but
> also some others:
>
> arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> arch/arm/mach-cns3xxx/core.c: gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> arch/arm/mach-cns3xxx/core.c: __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> arch/arm/mach-cns3xxx/core.c: u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> arch/arm/mach-cns3xxx/core.c: cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> arch/arm/mach-cns3xxx/devices.c: u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> arch/arm/mach-netx/generic.c: vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs) __io(NETX_VA_SYSTEM + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs) __io(NETX_VA_GPIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs) __io(NETX_VA_PIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU __io(NETX_VA_MIIMU)
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs) __io(NETX_VA_PFIFO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs) __io(NETX_VA_MEMCR + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs) __io(NETX_VA_DPMAS + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs) __io(NETX_VA_I2C, (ofs))
> arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> arch/arm/mach-shmobile/board-ag5evm.c: l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> arch/arm/mach-shmobile/board-bonito.c: l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> arch/arm/mach-shmobile/board-kota2.c: l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> arch/arm/mach-shmobile/include/mach/io.h:#define __io(a) ((void __iomem *)(a))
> arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/smp-r8a7779.c: __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> arch/arm/mach-shmobile/smp-sh73a0.c: if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) == 3)
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(WUPCR)); /* wake up */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(SRESCR)); /* reset */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(0, __io(APARMBAREA)); /* 4k */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
>
> These are all broken and need to be changed to something else before we add the
> global definition for __io.
Several platforms define IO_MEM for the purpose of casting the defines
to void __iomem *, so I'll make that common unless you have better
suggestion. I'd guess that changing the defines themselves will cause
lots of warnings in other places.
Rob
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
2012-03-09 21:34 ` Arnd Bergmann
@ 2012-03-09 21:52 ` Rafael J. Wysocki
-1 siblings, 0 replies; 39+ messages in thread
From: Rafael J. Wysocki @ 2012-03-09 21:52 UTC (permalink / raw)
To: Arnd Bergmann, Paul Mundt
Cc: LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
Hi,
On Friday, March 09, 2012, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > Hi,
> >
> > Please pull Renesas SoC updates for v3.4 since commit
> > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> >
> > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> >
> > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
>
> Hi Rafael,
>
> Please rebase this on an -rc release, otherwise we get a rather
> messy history in the arm-soc tree.
Well, OK, I can rebase it on -rc7 if there is one, unless Paul
has already pulled from clk_ops-rename. Paul?
> > ARM: mach-shmobile: default to no earlytimer
> >
> > from the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc
> >
> > They include:
> >
> > * The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
> > possible future name space collision with common struct clk code.
> >
> > This also affects drivers that are shared with the sh architecture,
> > so the branch containing this part of the material, clk_ops-rename,
> > will be merged into the Paul Mundt's sh tree if necessary.
> >
> > * Introduction of L2 Cache support for r8a7779.
> >
> > * Conversion of the mach-shmobile subarch to properly use a per-SoC
> > map_io and separate init_early callback for early serial console
> > support on platforms where that is possible.
> >
> > Magnus Damm is the author of all the changes.
>
> For next time, I think it would be good to make those things separate pull
> requests, since they are all rather big. In particular, the clk rework
> could be a series by itself.
It is a series by itself. You can readily pull it from clk_ops-rename even. :-)
I'm not sure, though, what exactly the point of this would be.
> One thing I noticed while browsing through the patches was this hunk
> that Rob should know about:
>
> @@ -242,6 +243,10 @@ static struct platform_device *r8a7779_late_devices[] __initdata = {
>
> void __init r8a7779_add_standard_devices(void)
> {
> +#ifdef CONFIG_CACHE_L2X0
> + /* Early BRESP enable, Shared attribute override enable, 64K*16way */
> + l2x0_init(__io(0xf0100000), 0x40470000, 0x82000fff);
> +#endif
> r8a7779_pm_init();
>
> r8a7779_init_pm_domain(&r8a7779_sh4a);
>
> Here you are abusing the __io() macro rather badly as a typecast. This breaks
> with Rob's series to turn __io(foo) into a NULL pointer for the case where
> PCI is disabled. I found a few more of these, mostly in mach-shmobile but
> also some others:
>
> arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> arch/arm/mach-cns3xxx/core.c: gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> arch/arm/mach-cns3xxx/core.c: __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> arch/arm/mach-cns3xxx/core.c: u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> arch/arm/mach-cns3xxx/core.c: cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> arch/arm/mach-cns3xxx/devices.c: u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> arch/arm/mach-netx/generic.c: vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs) __io(NETX_VA_SYSTEM + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs) __io(NETX_VA_GPIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs) __io(NETX_VA_PIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU __io(NETX_VA_MIIMU)
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs) __io(NETX_VA_PFIFO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs) __io(NETX_VA_MEMCR + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs) __io(NETX_VA_DPMAS + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs) __io(NETX_VA_I2C, (ofs))
> arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> arch/arm/mach-shmobile/board-ag5evm.c: l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> arch/arm/mach-shmobile/board-bonito.c: l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> arch/arm/mach-shmobile/board-kota2.c: l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> arch/arm/mach-shmobile/include/mach/io.h:#define __io(a) ((void __iomem *)(a))
> arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/smp-r8a7779.c: __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> arch/arm/mach-shmobile/smp-sh73a0.c: if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) = 3)
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(WUPCR)); /* wake up */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(SRESCR)); /* reset */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(0, __io(APARMBAREA)); /* 4k */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
>
> These are all broken and need to be changed to something else before we add the
> global definition for __io.
While I generally agree with that, I think it's not super-urgent, is it?
Rafael
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
@ 2012-03-09 21:52 ` Rafael J. Wysocki
0 siblings, 0 replies; 39+ messages in thread
From: Rafael J. Wysocki @ 2012-03-09 21:52 UTC (permalink / raw)
To: Arnd Bergmann, Paul Mundt
Cc: LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
Hi,
On Friday, March 09, 2012, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > Hi,
> >
> > Please pull Renesas SoC updates for v3.4 since commit
> > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> >
> > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> >
> > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
>
> Hi Rafael,
>
> Please rebase this on an -rc release, otherwise we get a rather
> messy history in the arm-soc tree.
Well, OK, I can rebase it on -rc7 if there is one, unless Paul
has already pulled from clk_ops-rename. Paul?
> > ARM: mach-shmobile: default to no earlytimer
> >
> > from the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc
> >
> > They include:
> >
> > * The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
> > possible future name space collision with common struct clk code.
> >
> > This also affects drivers that are shared with the sh architecture,
> > so the branch containing this part of the material, clk_ops-rename,
> > will be merged into the Paul Mundt's sh tree if necessary.
> >
> > * Introduction of L2 Cache support for r8a7779.
> >
> > * Conversion of the mach-shmobile subarch to properly use a per-SoC
> > map_io and separate init_early callback for early serial console
> > support on platforms where that is possible.
> >
> > Magnus Damm is the author of all the changes.
>
> For next time, I think it would be good to make those things separate pull
> requests, since they are all rather big. In particular, the clk rework
> could be a series by itself.
It is a series by itself. You can readily pull it from clk_ops-rename even. :-)
I'm not sure, though, what exactly the point of this would be.
> One thing I noticed while browsing through the patches was this hunk
> that Rob should know about:
>
> @@ -242,6 +243,10 @@ static struct platform_device *r8a7779_late_devices[] __initdata = {
>
> void __init r8a7779_add_standard_devices(void)
> {
> +#ifdef CONFIG_CACHE_L2X0
> + /* Early BRESP enable, Shared attribute override enable, 64K*16way */
> + l2x0_init(__io(0xf0100000), 0x40470000, 0x82000fff);
> +#endif
> r8a7779_pm_init();
>
> r8a7779_init_pm_domain(&r8a7779_sh4a);
>
> Here you are abusing the __io() macro rather badly as a typecast. This breaks
> with Rob's series to turn __io(foo) into a NULL pointer for the case where
> PCI is disabled. I found a few more of these, mostly in mach-shmobile but
> also some others:
>
> arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> arch/arm/mach-cns3xxx/core.c: gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> arch/arm/mach-cns3xxx/core.c: __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> arch/arm/mach-cns3xxx/core.c: u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> arch/arm/mach-cns3xxx/core.c: cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> arch/arm/mach-cns3xxx/devices.c: u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> arch/arm/mach-netx/generic.c: vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs) __io(NETX_VA_SYSTEM + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs) __io(NETX_VA_GPIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs) __io(NETX_VA_PIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU __io(NETX_VA_MIIMU)
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs) __io(NETX_VA_PFIFO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs) __io(NETX_VA_MEMCR + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs) __io(NETX_VA_DPMAS + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs) __io(NETX_VA_I2C, (ofs))
> arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> arch/arm/mach-shmobile/board-ag5evm.c: l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> arch/arm/mach-shmobile/board-bonito.c: l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> arch/arm/mach-shmobile/board-kota2.c: l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> arch/arm/mach-shmobile/include/mach/io.h:#define __io(a) ((void __iomem *)(a))
> arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/smp-r8a7779.c: __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> arch/arm/mach-shmobile/smp-sh73a0.c: if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) == 3)
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(WUPCR)); /* wake up */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(SRESCR)); /* reset */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(0, __io(APARMBAREA)); /* 4k */
> arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
>
> These are all broken and need to be changed to something else before we add the
> global definition for __io.
While I generally agree with that, I think it's not super-urgent, is it?
Rafael
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
2012-03-09 21:52 ` Rafael J. Wysocki
@ 2012-03-09 22:03 ` Arnd Bergmann
-1 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2012-03-09 22:03 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Paul Mundt, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
On Friday 09 March 2012, Rafael J. Wysocki wrote:
> Hi,
>
> On Friday, March 09, 2012, Arnd Bergmann wrote:
> > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > Please pull Renesas SoC updates for v3.4 since commit
> > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > >
> > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > >
> > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> >
> > Hi Rafael,
> >
> > Please rebase this on an -rc release, otherwise we get a rather
> > messy history in the arm-soc tree.
>
> Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> has already pulled from clk_ops-rename. Paul?
Why not rebase back to -rc6?
> >
> > For next time, I think it would be good to make those things separate pull
> > requests, since they are all rather big. In particular, the clk rework
> > could be a series by itself.
>
> It is a series by itself. You can readily pull it from clk_ops-rename even. :-)
>
> I'm not sure, though, what exactly the point of this would be.
Mostly it helps make obvious which things are logically connected.
Another reason is that when one of the branches has a problem, we
can still pull all the other ones.
Finally, we sometimes make new topic branches in the arm-soc tree
when a lot of maintainers send similar things, e.g. we had a
'next/clk' branch in the past that half of your patches would
have applied to (this time we don't have one of those). By having
more branches for logically separate things, it allows us to group
them in more flexible ways across platforms.
It's not very important this time, so I didn't ask you to rebase
them just for that.
> > arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> > arch/arm/mach-cns3xxx/core.c: gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> > arch/arm/mach-cns3xxx/core.c: __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> > arch/arm/mach-cns3xxx/core.c: u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> > arch/arm/mach-cns3xxx/core.c: cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> > arch/arm/mach-cns3xxx/devices.c: u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> > arch/arm/mach-netx/generic.c: vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs) __io(NETX_VA_SYSTEM + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs) __io(NETX_VA_GPIO + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs) __io(NETX_VA_PIO + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU __io(NETX_VA_MIIMU)
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs) __io(NETX_VA_PFIFO + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs) __io(NETX_VA_MEMCR + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs) __io(NETX_VA_DPMAS + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs) __io(NETX_VA_I2C, (ofs))
> > arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> > arch/arm/mach-shmobile/board-ag5evm.c: l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> > arch/arm/mach-shmobile/board-bonito.c: l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> > arch/arm/mach-shmobile/board-kota2.c: l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> > arch/arm/mach-shmobile/include/mach/io.h:#define __io(a) ((void __iomem *)(a))
> > arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_dist_base = __io(0xf0001000);
> > arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> > arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_dist_base = __io(0xf0001000);
> > arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> > arch/arm/mach-shmobile/smp-r8a7779.c: __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> > arch/arm/mach-shmobile/smp-sh73a0.c: if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) = 3)
> > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(WUPCR)); /* wake up */
> > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(SRESCR)); /* reset */
> > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(0, __io(APARMBAREA)); /* 4k */
> > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> > arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> >
> > These are all broken and need to be changed to something else before we add the
> > global definition for __io.
>
> While I generally agree with that, I think it's not super-urgent, is it?
No, it's not. I just wanted to let you all know now so we don't forget it.
Arnd
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
@ 2012-03-09 22:03 ` Arnd Bergmann
0 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2012-03-09 22:03 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Paul Mundt, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
On Friday 09 March 2012, Rafael J. Wysocki wrote:
> Hi,
>
> On Friday, March 09, 2012, Arnd Bergmann wrote:
> > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > Please pull Renesas SoC updates for v3.4 since commit
> > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > >
> > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > >
> > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> >
> > Hi Rafael,
> >
> > Please rebase this on an -rc release, otherwise we get a rather
> > messy history in the arm-soc tree.
>
> Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> has already pulled from clk_ops-rename. Paul?
Why not rebase back to -rc6?
> >
> > For next time, I think it would be good to make those things separate pull
> > requests, since they are all rather big. In particular, the clk rework
> > could be a series by itself.
>
> It is a series by itself. You can readily pull it from clk_ops-rename even. :-)
>
> I'm not sure, though, what exactly the point of this would be.
Mostly it helps make obvious which things are logically connected.
Another reason is that when one of the branches has a problem, we
can still pull all the other ones.
Finally, we sometimes make new topic branches in the arm-soc tree
when a lot of maintainers send similar things, e.g. we had a
'next/clk' branch in the past that half of your patches would
have applied to (this time we don't have one of those). By having
more branches for logically separate things, it allows us to group
them in more flexible ways across platforms.
It's not very important this time, so I didn't ask you to rebase
them just for that.
> > arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> > arch/arm/mach-cns3xxx/core.c: gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> > arch/arm/mach-cns3xxx/core.c: __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> > arch/arm/mach-cns3xxx/core.c: u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> > arch/arm/mach-cns3xxx/core.c: cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> > arch/arm/mach-cns3xxx/devices.c: u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> > arch/arm/mach-netx/generic.c: vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs) __io(NETX_VA_SYSTEM + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs) __io(NETX_VA_GPIO + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs) __io(NETX_VA_PIO + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU __io(NETX_VA_MIIMU)
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs) __io(NETX_VA_PFIFO + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs) __io(NETX_VA_MEMCR + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs) __io(NETX_VA_DPMAS + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs) __io(NETX_VA_I2C, (ofs))
> > arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> > arch/arm/mach-shmobile/board-ag5evm.c: l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> > arch/arm/mach-shmobile/board-bonito.c: l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> > arch/arm/mach-shmobile/board-kota2.c: l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> > arch/arm/mach-shmobile/include/mach/io.h:#define __io(a) ((void __iomem *)(a))
> > arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_dist_base = __io(0xf0001000);
> > arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> > arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_dist_base = __io(0xf0001000);
> > arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> > arch/arm/mach-shmobile/smp-r8a7779.c: __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> > arch/arm/mach-shmobile/smp-sh73a0.c: if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) == 3)
> > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(WUPCR)); /* wake up */
> > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(SRESCR)); /* reset */
> > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(0, __io(APARMBAREA)); /* 4k */
> > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> > arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> >
> > These are all broken and need to be changed to something else before we add the
> > global definition for __io.
>
> While I generally agree with that, I think it's not super-urgent, is it?
No, it's not. I just wanted to let you all know now so we don't forget it.
Arnd
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
2012-03-09 22:03 ` Arnd Bergmann
@ 2012-03-09 22:27 ` Rafael J. Wysocki
-1 siblings, 0 replies; 39+ messages in thread
From: Rafael J. Wysocki @ 2012-03-09 22:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Paul Mundt, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
Hi,
On Friday, March 09, 2012, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > Hi,
> > > >
> > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > >
> > > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > >
> > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > >
> > > Hi Rafael,
> > >
> > > Please rebase this on an -rc release, otherwise we get a rather
> > > messy history in the arm-soc tree.
> >
> > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > has already pulled from clk_ops-rename. Paul?
>
> Why not rebase back to -rc6?
Well, I can do that too, if I have to, but still I'd like to be sure that
Paul hasn't pulled from the clk_ops-rename branch yet.
> > > For next time, I think it would be good to make those things separate pull
> > > requests, since they are all rather big. In particular, the clk rework
> > > could be a series by itself.
> >
> > It is a series by itself. You can readily pull it from clk_ops-rename even. :-)
> >
> > I'm not sure, though, what exactly the point of this would be.
>
> Mostly it helps make obvious which things are logically connected.
> Another reason is that when one of the branches has a problem, we
> can still pull all the other ones.
> Finally, we sometimes make new topic branches in the arm-soc tree
> when a lot of maintainers send similar things, e.g. we had a
> 'next/clk' branch in the past that half of your patches would
> have applied to (this time we don't have one of those). By having
> more branches for logically separate things, it allows us to group
> them in more flexible ways across platforms.
OK
> It's not very important this time, so I didn't ask you to rebase
> them just for that.
OK, thanks!
> > > arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> > > arch/arm/mach-cns3xxx/core.c: gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> > > arch/arm/mach-cns3xxx/core.c: __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> > > arch/arm/mach-cns3xxx/core.c: u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> > > arch/arm/mach-cns3xxx/core.c: cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> > > arch/arm/mach-cns3xxx/devices.c: u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> > > arch/arm/mach-netx/generic.c: vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs) __io(NETX_VA_SYSTEM + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs) __io(NETX_VA_GPIO + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs) __io(NETX_VA_PIO + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU __io(NETX_VA_MIIMU)
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs) __io(NETX_VA_PFIFO + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs) __io(NETX_VA_MEMCR + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs) __io(NETX_VA_DPMAS + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs) __io(NETX_VA_I2C, (ofs))
> > > arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> > > arch/arm/mach-shmobile/board-ag5evm.c: l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> > > arch/arm/mach-shmobile/board-bonito.c: l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> > > arch/arm/mach-shmobile/board-kota2.c: l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> > > arch/arm/mach-shmobile/include/mach/io.h:#define __io(a) ((void __iomem *)(a))
> > > arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_dist_base = __io(0xf0001000);
> > > arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> > > arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_dist_base = __io(0xf0001000);
> > > arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> > > arch/arm/mach-shmobile/smp-r8a7779.c: __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> > > arch/arm/mach-shmobile/smp-sh73a0.c: if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) = 3)
> > > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(WUPCR)); /* wake up */
> > > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(SRESCR)); /* reset */
> > > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(0, __io(APARMBAREA)); /* 4k */
> > > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> > > arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> > >
> > > These are all broken and need to be changed to something else before we add the
> > > global definition for __io.
> >
> > While I generally agree with that, I think it's not super-urgent, is it?
>
> No, it's not. I just wanted to let you all know now so we don't forget it.
OK
Thanks,
Rafael
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
@ 2012-03-09 22:27 ` Rafael J. Wysocki
0 siblings, 0 replies; 39+ messages in thread
From: Rafael J. Wysocki @ 2012-03-09 22:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Paul Mundt, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
Hi,
On Friday, March 09, 2012, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > Hi,
> > > >
> > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > >
> > > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > >
> > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > >
> > > Hi Rafael,
> > >
> > > Please rebase this on an -rc release, otherwise we get a rather
> > > messy history in the arm-soc tree.
> >
> > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > has already pulled from clk_ops-rename. Paul?
>
> Why not rebase back to -rc6?
Well, I can do that too, if I have to, but still I'd like to be sure that
Paul hasn't pulled from the clk_ops-rename branch yet.
> > > For next time, I think it would be good to make those things separate pull
> > > requests, since they are all rather big. In particular, the clk rework
> > > could be a series by itself.
> >
> > It is a series by itself. You can readily pull it from clk_ops-rename even. :-)
> >
> > I'm not sure, though, what exactly the point of this would be.
>
> Mostly it helps make obvious which things are logically connected.
> Another reason is that when one of the branches has a problem, we
> can still pull all the other ones.
> Finally, we sometimes make new topic branches in the arm-soc tree
> when a lot of maintainers send similar things, e.g. we had a
> 'next/clk' branch in the past that half of your patches would
> have applied to (this time we don't have one of those). By having
> more branches for logically separate things, it allows us to group
> them in more flexible ways across platforms.
OK
> It's not very important this time, so I didn't ask you to rebase
> them just for that.
OK, thanks!
> > > arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> > > arch/arm/mach-cns3xxx/core.c: gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> > > arch/arm/mach-cns3xxx/core.c: __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> > > arch/arm/mach-cns3xxx/core.c: u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> > > arch/arm/mach-cns3xxx/core.c: cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> > > arch/arm/mach-cns3xxx/devices.c: u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> > > arch/arm/mach-netx/generic.c: vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs) __io(NETX_VA_SYSTEM + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs) __io(NETX_VA_GPIO + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs) __io(NETX_VA_PIO + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU __io(NETX_VA_MIIMU)
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs) __io(NETX_VA_PFIFO + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs) __io(NETX_VA_MEMCR + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs) __io(NETX_VA_DPMAS + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs) __io(NETX_VA_I2C, (ofs))
> > > arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> > > arch/arm/mach-shmobile/board-ag5evm.c: l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> > > arch/arm/mach-shmobile/board-bonito.c: l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> > > arch/arm/mach-shmobile/board-kota2.c: l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> > > arch/arm/mach-shmobile/include/mach/io.h:#define __io(a) ((void __iomem *)(a))
> > > arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_dist_base = __io(0xf0001000);
> > > arch/arm/mach-shmobile/intc-r8a7779.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> > > arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_dist_base = __io(0xf0001000);
> > > arch/arm/mach-shmobile/intc-sh73a0.c: void __iomem *gic_cpu_base = __io(0xf0000100);
> > > arch/arm/mach-shmobile/smp-r8a7779.c: __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> > > arch/arm/mach-shmobile/smp-sh73a0.c: if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) == 3)
> > > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(WUPCR)); /* wake up */
> > > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(1 << cpu, __io(SRESCR)); /* reset */
> > > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(0, __io(APARMBAREA)); /* 4k */
> > > arch/arm/mach-shmobile/smp-sh73a0.c: __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> > > arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n) __io(IO_ADDRESS(n))
> > >
> > > These are all broken and need to be changed to something else before we add the
> > > global definition for __io.
> >
> > While I generally agree with that, I think it's not super-urgent, is it?
>
> No, it's not. I just wanted to let you all know now so we don't forget it.
OK
Thanks,
Rafael
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
2012-03-09 22:27 ` Rafael J. Wysocki
(?)
@ 2012-03-10 10:53 ` Arnd Bergmann
2012-03-10 21:26 ` Rafael J. Wysocki
-1 siblings, 1 reply; 39+ messages in thread
From: Arnd Bergmann @ 2012-03-10 10:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Paul Mundt, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
On Friday 09 March 2012, Rafael J. Wysocki wrote:
> On Friday, March 09, 2012, Arnd Bergmann wrote:
> > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > > Hi,
> > > > >
> > > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > > >
> > > > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > > >
> > > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > > >
> > > > Hi Rafael,
> > > >
> > > > Please rebase this on an -rc release, otherwise we get a rather
> > > > messy history in the arm-soc tree.
> > >
> > > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > > has already pulled from clk_ops-rename. Paul?
> >
> > Why not rebase back to -rc6?
>
> Well, I can do that too, if I have to, but still I'd like to be sure that
> Paul hasn't pulled from the clk_ops-rename branch yet.
The point is that there might not be an -rc7 any more. I'd suggest that
you rebase on -rc6 if Paul has not yet pulled them, otherwise we will
merge them in the current state and put an explanation into the merge
changeset.
Arnd
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
2012-03-10 10:53 ` Arnd Bergmann
@ 2012-03-10 21:26 ` Rafael J. Wysocki
0 siblings, 0 replies; 39+ messages in thread
From: Rafael J. Wysocki @ 2012-03-10 21:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Paul Mundt, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
On Saturday, March 10, 2012, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > Hi,
> > > >
> > > > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > > > >
> > > > > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > > > >
> > > > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > > > >
> > > > > Hi Rafael,
> > > > >
> > > > > Please rebase this on an -rc release, otherwise we get a rather
> > > > > messy history in the arm-soc tree.
> > > >
> > > > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > > > has already pulled from clk_ops-rename. Paul?
> > >
> > > Why not rebase back to -rc6?
> >
> > Well, I can do that too, if I have to, but still I'd like to be sure that
> > Paul hasn't pulled from the clk_ops-rename branch yet.
>
> The point is that there might not be an -rc7 any more.
Yes, I'm aware of that. :-)
> I'd suggest that you rebase on -rc6 if Paul has not yet pulled them,
I'm still waiting for a word from Paul.
> otherwise we will merge them in the current state and put an explanation
> into the merge changeset.
Well, if there's no -rc7 (which means that the final v3.3 is released tomorrow)
or there's no information from Paul within the next few days, I'm afraid
rebasing won't be very safe.
Thanks a lot and sorry for the trouble (I think I didn't understand you
correctly when you said you wanted things to be based on -rc, I thought you
meant the Linus' tree in general and not specific commits).
Rafael
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
@ 2012-03-10 21:26 ` Rafael J. Wysocki
0 siblings, 0 replies; 39+ messages in thread
From: Rafael J. Wysocki @ 2012-03-10 21:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Paul Mundt, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
On Saturday, March 10, 2012, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > Hi,
> > > >
> > > > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > > > >
> > > > > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > > > >
> > > > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > > > >
> > > > > Hi Rafael,
> > > > >
> > > > > Please rebase this on an -rc release, otherwise we get a rather
> > > > > messy history in the arm-soc tree.
> > > >
> > > > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > > > has already pulled from clk_ops-rename. Paul?
> > >
> > > Why not rebase back to -rc6?
> >
> > Well, I can do that too, if I have to, but still I'd like to be sure that
> > Paul hasn't pulled from the clk_ops-rename branch yet.
>
> The point is that there might not be an -rc7 any more.
Yes, I'm aware of that. :-)
> I'd suggest that you rebase on -rc6 if Paul has not yet pulled them,
I'm still waiting for a word from Paul.
> otherwise we will merge them in the current state and put an explanation
> into the merge changeset.
Well, if there's no -rc7 (which means that the final v3.3 is released tomorrow)
or there's no information from Paul within the next few days, I'm afraid
rebasing won't be very safe.
Thanks a lot and sorry for the trouble (I think I didn't understand you
correctly when you said you wanted things to be based on -rc, I thought you
meant the Linus' tree in general and not specific commits).
Rafael
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
2012-03-10 21:26 ` Rafael J. Wysocki
@ 2012-03-10 22:06 ` Geert Uytterhoeven
-1 siblings, 0 replies; 39+ messages in thread
From: Geert Uytterhoeven @ 2012-03-10 22:06 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, Paul Mundt, LKML, Magnus Damm, Linux-sh list, arm,
Rob Herring
On Sat, Mar 10, 2012 at 22:26, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> The point is that there might not be an -rc7 any more.
>
> Yes, I'm aware of that. :-)
It seems there is.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
@ 2012-03-10 22:06 ` Geert Uytterhoeven
0 siblings, 0 replies; 39+ messages in thread
From: Geert Uytterhoeven @ 2012-03-10 22:06 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, Paul Mundt, LKML, Magnus Damm, Linux-sh list, arm,
Rob Herring
On Sat, Mar 10, 2012 at 22:26, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> The point is that there might not be an -rc7 any more.
>
> Yes, I'm aware of that. :-)
It seems there is.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
2012-03-09 21:52 ` Rafael J. Wysocki
@ 2012-03-12 1:13 ` Paul Mundt
-1 siblings, 0 replies; 39+ messages in thread
From: Paul Mundt @ 2012-03-12 1:13 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
On Fri, Mar 09, 2012 at 10:52:47PM +0100, Rafael J. Wysocki wrote:
> On Friday, March 09, 2012, Arnd Bergmann wrote:
> > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > Please pull Renesas SoC updates for v3.4 since commit
> > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > >
> > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > >
> > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> >
> > Hi Rafael,
> >
> > Please rebase this on an -rc release, otherwise we get a rather
> > messy history in the arm-soc tree.
>
> Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> has already pulled from clk_ops-rename. Paul?
>
Nope, I haven't had a chance yet. Feel free to rebase as necessary and
I'll grab them afterwards.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
@ 2012-03-12 1:13 ` Paul Mundt
0 siblings, 0 replies; 39+ messages in thread
From: Paul Mundt @ 2012-03-12 1:13 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
On Fri, Mar 09, 2012 at 10:52:47PM +0100, Rafael J. Wysocki wrote:
> On Friday, March 09, 2012, Arnd Bergmann wrote:
> > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > Please pull Renesas SoC updates for v3.4 since commit
> > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > >
> > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > >
> > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> >
> > Hi Rafael,
> >
> > Please rebase this on an -rc release, otherwise we get a rather
> > messy history in the arm-soc tree.
>
> Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> has already pulled from clk_ops-rename. Paul?
>
Nope, I haven't had a chance yet. Feel free to rebase as necessary and
I'll grab them afterwards.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
2012-03-12 1:13 ` Paul Mundt
@ 2012-03-12 21:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 39+ messages in thread
From: Rafael J. Wysocki @ 2012-03-12 21:30 UTC (permalink / raw)
To: Paul Mundt
Cc: Arnd Bergmann, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
On Monday, March 12, 2012, Paul Mundt wrote:
> On Fri, Mar 09, 2012 at 10:52:47PM +0100, Rafael J. Wysocki wrote:
> > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > >
> > > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > >
> > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > >
> > > Hi Rafael,
> > >
> > > Please rebase this on an -rc release, otherwise we get a rather
> > > messy history in the arm-soc tree.
> >
> > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > has already pulled from clk_ops-rename. Paul?
> >
> Nope, I haven't had a chance yet. Feel free to rebase as necessary and
> I'll grab them afterwards.
Thanks, I've just rebased clk_ops-rename on top of -rc7.
Rafael
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [GIT PULL] Renesas SoC updates for v3.4
@ 2012-03-12 21:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 39+ messages in thread
From: Rafael J. Wysocki @ 2012-03-12 21:30 UTC (permalink / raw)
To: Paul Mundt
Cc: Arnd Bergmann, LKML, Magnus Damm, Linux-sh list, arm, Rob Herring
On Monday, March 12, 2012, Paul Mundt wrote:
> On Fri, Mar 09, 2012 at 10:52:47PM +0100, Rafael J. Wysocki wrote:
> > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > >
> > > > mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > >
> > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > >
> > > Hi Rafael,
> > >
> > > Please rebase this on an -rc release, otherwise we get a rather
> > > messy history in the arm-soc tree.
> >
> > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > has already pulled from clk_ops-rename. Paul?
> >
> Nope, I haven't had a chance yet. Feel free to rebase as necessary and
> I'll grab them afterwards.
Thanks, I've just rebased clk_ops-rename on top of -rc7.
Rafael
^ permalink raw reply [flat|nested] 39+ messages in thread