linux-kernel - Re: [PATCH 1/2] bmips: add BCM6358 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:	Mon, 18 Jan 2016 14:35:48 +0100
From:	Jonas Gorski <jogo@...nwrt.org>
To:	Álvaro Fernández Rojas <noltari@...il.com>
Cc:	Florian Fainelli <f.fainelli@...il.com>,
	MIPS Mailing List <linux-mips@...ux-mips.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Kevin Cernekee <cernekee@...il.com>
Subject: Re: [PATCH 1/2] bmips: add BCM6358 support

Hi,

On 18 January 2016 at 10:42, Álvaro Fernández Rojas <noltari@...il.com> wrote:
> I can refine it to support a custom offset for each cpu instead of a generic one, but defining a custom offset for new SoCs such as BCM6368 or BCM6328 would actually break them, since that way the address wouldn't be remapped to 0xb0000000.
> See: https://github.com/torvalds/linux/blob/master/arch/mips/include/asm/io.h#L213
> In those CPUs the remapping is done automatically (from 0x10000000 to 0xb0000000), since the registers are located in the low 512MB of address space (0x1fffffffULL).
>
> However, the older CPUs such as BCM6358 (or BCM3368) need that custom ioremap, since those registers aren't located in the low 512MB of address space.
> If you want, I can do something like this: https://gist.github.com/Noltari/bc5fe029c52cf053a454
> And after that we could add other CPUs such as the BCM3368, which needs a different offset: "{ "brcm,bcm3368", 0xfff80000 }"
>
> What do you think? Should we keep a generic offset (0xfff00000) or should we add SoC specific compatible strings with each custom offset?

How about using the arm approach [1] and adding support for
registering static mappings? That way we avoid adding a custom
plat_ioremap() and keep the amount of bmips code to a minimum.


Jonas

[1]:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ed8fd2186a4e4f3b98434093b56f9b793d48443e
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=101eeda38c0ab8a4f916176e325d9e036d981a24