linux-kernel - Re: [PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO

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:	Thu, 12 Dec 2013 10:47:58 +0100
From:	Tomasz Figa <tomasz.figa@...il.com>
To:	panchaxari <panchaxari.prasannamurthy@...aro.org>,
	kgene.kim@...sung.com
Cc:	patches@...aro.org, linaro-kernel@...ts.linaro.org,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Heiko Stuebner <heiko@...ech.de>,
	Russell King <linux@....linux.org.uk>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-arm-kernel@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

Hi panchaxari,

On Thursday 12 of December 2013 10:42:32 panchaxari wrote:
> ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR have been enabled as default configs
> to S5P64X0 platforms.
> 
> Introduction of PHYS_VIRT config as default would enable phy-to-virt and
> virt-to-phy translation function at boot and module loading time
> and enforce dynamic reallocation of memory. AUTO_ZRELADDR config would
> enable calculation of kernel load address at run time.
> 
> PHYS_VIRT config is mutually exclusive to XIP_KERNEL, XIP_KERNEL is used in
> systems with NOR flash devices, and ZRELADDR config is mutually exclusive
> to ZBOOT_ROM.
> 
> CFT::Call For Testing
> 
> Requesting maintainers of S5P64X0 platforms to evaluate the changes on the
> board and comment, as I dont have the board for testing and also requesting
> an ACK

Could you explain the purpose of this change on S5P64x0?

This is actually quite a poor platform choice. As of today, the kernel
is stuck with supporting just SMDK6440/6450 boards, which are proprietary
development boards and it doesn't look like any further boards will show
up in future. Kukjin has actually proposed removing support for this
platform at all and I consider this reasonable.

Kukjin, should we proceed with removal?

Best regards,
Tomasz

--
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/