Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752661AbaGGAw6 (ORCPT ); Sun, 6 Jul 2014 20:52:58 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:44009 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752540AbaGGAwy (ORCPT ); Sun, 6 Jul 2014 20:52:54 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Grant Likely Date: Mon, 7 Jul 2014 01:52:33 +0100 X-Google-Sender-Auth: BMMUE1ZWX-NpfGYac3aLNwWE-nk Message-ID: Subject: Re: [GIT PULL] bug fix for devicetree memory parsing To: Linus Torvalds Cc: Rob Herring , Laura Abbott , "devicetree@vger.kernel.org" , Linux Kernel Mailing List Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 6, 2014 at 8:24 PM, Linus Torvalds wrote: > On Sun, Jul 6, 2014 at 2:37 AM, Grant Likely wrote: >> >> Can you pull this bug fix into your tree please? > > I took it, but I think both your explanation and the patch itself is > actually crap. It may fix the issue, but it's seriously confused. > > Your explanation says that it's a 32-bit platform issue. No it's not. > Most 32-bit configurations still have a 64-bit phys_addr_t (ie > PAE/LPAE etc). > > And the code is crap, because it uses ULONG_MAX etc in ways that > simply make no f*cking sense. And why does it care about sizeof? > > Why does the code not just do something like > > #define MAX_PHYS_ADDR ((phys_addr_t) ~0) > > and then do > > if (base > MAX_PHYS_ADDR || base + size > MAX_PHYS_ADDR) > ... Sure. I'll make sure a cleanup patch gets written and queued up. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/