linux-kernel - Re: [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 May 2012 19:47:38 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux@....linux.org.uk,
	linux-sh@...r.kernel.org, lethal@...ux-sh.org,
	linux-kernel@...r.kernel.org, rjw@...k.pl, horms@...ge.net.au,
	olof@...om.net
Subject: Re: [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support

On Friday 04 May 2012, Arnd Bergmann wrote:
> 
> On Thursday 03 May 2012, Magnus Damm wrote:
> 
> > +
> > +/* EMEV2 SMU registers */
> > +#define USIAU0_RSTCTRL 0xe0110094
> > +#define USIBU1_RSTCTRL 0xe01100ac
> > +#define USIBU2_RSTCTRL 0xe01100b0
> > +#define USIBU3_RSTCTRL 0xe01100b4
> > +#define STI_RSTCTRL 0xe0110124
> > +#define USIAU0GCLKCTRL 0xe01104a0
> > +#define USIBU1GCLKCTRL 0xe01104b8
> > +#define USIBU2GCLKCTRL 0xe01104bc
> > +#define USIBU3GCLKCTRL 0xe01104c0
> > +#define STIGCLKCTRL 0xe0110528
> > +#define USIAU0SCLKDIV 0xe011061c
> > +#define USIB2SCLKDIV 0xe011065c
> > +#define USIB3SCLKDIV 0xe0110660
> > +#define STI_CLKSEL 0xe0110688
> 
> Please cast to __iomem* here, e.g. using the IOMEM() macro, as these are
> virtual addresses.

I should revise that: there is no excuse to hardcode these virtual address
here at all. Just use call ioremap() on the physical address for the
clock registers (0xe0110000) and use the resulting pointer with an
offset that you define locally in this file.

It is safe to call ioremap when you get to emev2_clock_init()
and you will still get a large page mapping with the recent
code reworks for map_desc.

Regarding the iotable that is currently defined as

+static struct map_desc emev2_io_desc[] __initdata = {
+       /* 128K entity map for 0xe0020000 (GIC) */
+       {
+               .virtual        = 0xe0020000,
+               .pfn            = __phys_to_pfn(0xe0020000),
+               .length         = SZ_128K,
+               .type           = MT_UNCACHED
+       },
+       /* 128K entity map for 0xe0100000 (SMU) */
+       {
+               .virtual        = 0xe0100000,
+               .pfn            = __phys_to_pfn(0xe0100000),
+               .length         = SZ_128K,
+               .type           = MT_DEVICE
+       },
+};

I would recommend just mapping the entire 16MB page around this, or at least
2 MB, so you can benefit from the larger mappings. If you don't do that,
better remove the entire iotable registration and rely on ioremap, the
result will be the same and you can be prevent any hacks from creeping in
that rely on the virtual address being the same as the physical address.

	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/