From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Mundt <lethal@linux-sh.org>,
LKML <linux-kernel@vger.kernel.org>,
Magnus Damm <magnus.damm@gmail.com>,
Linux-sh list <linux-sh@vger.kernel.org>,
"arm@kernel.org" <arm@kernel.org>,
Rob Herring <robherring2@gmail.com>
Subject: Re: [GIT PULL] Renesas SoC updates for v3.4
Date: Fri, 09 Mar 2012 22:27:00 +0000 [thread overview]
Message-ID: <201203092327.00228.rjw@sisk.pl> (raw)
In-Reply-To: <201203092203.49812.arnd@arndb.de>
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
next prev parent reply other threads:[~2012-03-09 22:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-09 20:55 [GIT PULL] Renesas SoC updates for v3.4 Rafael J. Wysocki
2012-03-09 21:34 ` Arnd Bergmann
2012-03-09 21:48 ` Rob Herring
2012-03-09 21:52 ` Rafael J. Wysocki
2012-03-09 22:03 ` Arnd Bergmann
2012-03-09 22:27 ` Rafael J. Wysocki [this message]
2012-03-10 10:53 ` Arnd Bergmann
2012-03-10 21:26 ` Rafael J. Wysocki
2012-03-10 22:06 ` Geert Uytterhoeven
2012-03-12 1:13 ` Paul Mundt
2012-03-12 21:30 ` Rafael J. Wysocki
2012-03-12 22:53 ` [GIT PULL] Renesas SoC updates for v3.4, take 2 Rafael J. Wysocki
2012-03-13 10:26 ` Arnd Bergmann
2012-03-13 19:36 ` Rafael J. Wysocki
2012-03-13 19:39 ` Arnd Bergmann
2012-03-13 20:17 ` Rafael J. Wysocki
2012-03-13 21:42 ` Rafael J. Wysocki
2012-03-14 0:02 ` Olof Johansson
2012-03-14 0:16 ` Rafael J. Wysocki
2012-03-14 0:40 ` Olof Johansson
2012-03-14 9:03 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201203092327.00228.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=arm@kernel.org \
--cc=arnd@arndb.de \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=robherring2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox