linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Rob Herring <robherring2@gmail.com>,
	Leif Lindholm <leif.lindholm@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linaro Patches <patches@linaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only
Date: Tue, 22 Apr 2014 14:08:29 +0100	[thread overview]
Message-ID: <20140422130829.CA29DC4042C@trevor.secretlab.ca> (raw)
In-Reply-To: <CAL_JsqKdFyhHfkcC1E9QuKjQTrXwoELYG+CFTpgf2-jqDvxGmA@mail.gmail.com>

On Fri, 18 Apr 2014 10:37:58 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On Fri, Apr 18, 2014 at 7:48 AM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > On Thu, Apr 17, 2014 at 07:43:13PM -0500, Rob Herring wrote:
> >> On Thu, Apr 17, 2014 at 12:41 PM, Leif Lindholm
> >> <leif.lindholm@linaro.org> wrote:
> >> > drivers/of/fdt.c contains a workaround for a missing memory type
> >> > entry on longtrail firmware. Make that quirk PPC32 only, and while
> >> > at it - fix up the .dts files in the tree currently working only
> >> > because of that quirk.
> >>
> >> But why do you need this?
> >
> > Apart from the current code permitting recreating a 15+ year old
> > firmware bug into completely new platform ports?
> 
> I would prefer to see a "WARN_ON(!IS_ENABLED(CONFIG_PPC32));" added here.

I completely agree.

> Really, I would like to see quirks like this fixed up out of line from
> the normal flow somewhat like how PCI quirks are handled. So in this
> example, we would just add the missing property to the dtb for the
> broken platform before doing the memory scan. That does then require
> libfdt which is something I'm working on.

In fact, for Leif's purposes, I would rather have a flag when booting via
UEFI, and make the kernel skip the memory node parsing if the UEFI
memory map is available. Then the stub doesn't need to do any munging of
the DTB at all.

g.


  parent reply	other threads:[~2014-04-22 13:08 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-17 17:41 [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only Leif Lindholm
2014-04-17 17:41 ` [PATCH 1/3] arm: dts: add device_type="memory" for ste-ccu8540 Leif Lindholm
2014-04-22  7:39   ` Lee Jones
2014-04-22 13:09     ` Grant Likely
2014-04-22 13:26   ` Linus Walleij
2014-05-15 14:50     ` Grant Likely
2014-04-17 17:42 ` [PATCH 2/3] mips: dts: add device_type="memory" where missing Leif Lindholm
2014-04-18 17:16   ` John Crispin
2014-04-22 13:13   ` Grant Likely
2014-05-15 14:50     ` Grant Likely
2014-04-17 17:42 ` [PATCH 3/3] of: Handle memory@0 node on PPC32 only Leif Lindholm
2014-04-18  8:04   ` Geert Uytterhoeven
2014-04-18 12:59     ` Leif Lindholm
2014-04-18 13:11       ` Geert Uytterhoeven
2014-04-21 12:56       ` Rob Herring
2014-04-23 10:35         ` Mark Rutland
2014-04-22 13:35       ` Grant Likely
2014-04-23 10:45         ` Mark Rutland
2014-04-23 11:14           ` Geert Uytterhoeven
2014-04-23 13:10           ` Grant Likely
2014-04-24  9:26             ` Leif Lindholm
2014-05-15 14:59               ` Grant Likely
2014-04-18  0:43 ` [PATCH 0/3] of: dts: enable memory@0 quirk for " Rob Herring
2014-04-18 12:48   ` Leif Lindholm
2014-04-18 15:37     ` Rob Herring
2014-04-18 20:13       ` Leif Lindholm
2014-04-18 21:28         ` Rob Herring
2014-04-19  0:36           ` Leif Lindholm
2014-04-22 13:08       ` Grant Likely [this message]
2014-04-22 14:05         ` Leif Lindholm
2014-04-23 13:15           ` Grant Likely
2014-04-23 17:25             ` Leif Lindholm
2014-04-23 13:17           ` Grant Likely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140422130829.CA29DC4042C@trevor.secretlab.ca \
    --to=grant.likely@secretlab.ca \
    --cc=devicetree@vger.kernel.org \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mark.rutland@arm.com \
    --cc=patches@linaro.org \
    --cc=robherring2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).