| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <201203092203.49812.arnd@arndb.de> Date: Fri, 9 Mar 2012 22:03:49 +0000 From: Arnd Bergmann <arnd@...db.de> To: "Rafael J. Wysocki" <rjw@...k.pl> Cc: Paul Mundt <lethal@...ux-sh.org>, LKML <linux-kernel@...r.kernel.org>, Magnus Damm <magnus.damm@...il.com>, "Linux-sh list" <linux-sh@...r.kernel.org>, "arm@...nel.org" <arm@...nel.org>, Rob Herring <robherring2@...il.com> Subject: Re: [GIT PULL] Renesas SoC updates for v3.4 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@...ppe2:~/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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists