Hi Stepan,
What is the status of this fix?
I am looking forward it to be merged, but it seems not have happend, yet.
Are you waiting for it to be merged, too? or planning to post v2?
# IMHO, v2 is not needed. Checked conditions and places are reasonable.
I just confirmed on 3.11-rc7, that
- The i
Hello Stepan,
On Fri, May 31, 2013 at 6:45 AM, Stepan Moskovchenko
wrote:
> Some LPAE-capable systems may use a Device Tree containing
> memory nodes that describe memory extending beyond the 4GB
> physical address boundary. Ignore or truncate these memory
> nodes on kernels that have not been bu
On 5/30/2013 3:24 PM, Arnd Bergmann wrote:
+ if (size > ((phys_addr_t)~0))
+ size = ((phys_addr_t)~0);
+
+ /* arm_add_memory() already checks for the case of base + size > 4GB */
+#endif
arm_add_memory(base, size);
}
This looks wrong for the case where 'base
On Thursday 30 May 2013 14:45:20 Stepan Moskovchenko wrote:
>
> void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> {
> +#ifndef CONFIG_ARM_LPAE
> + if (base > ((phys_addr_t)~0)) {
> + pr_crit("Ignoring memory at 0x%08llx due to lack of LPAE
> support\n",
> +
On Thu, May 30, 2013 at 02:45:20PM -0700, Stepan Moskovchenko wrote:
> void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> {
> +#ifndef CONFIG_ARM_LPAE
> + if (base > ((phys_addr_t)~0)) {
The #ifdef is probably not necessary here, simply checking that
base/size can be represented
Some LPAE-capable systems may use a Device Tree containing
memory nodes that describe memory extending beyond the 4GB
physical address boundary. Ignore or truncate these memory
nodes on kernels that have not been built with LPAE
support, to prevent the extended physical addresses from
being truncat
6 matches
Mail list logo
