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]
Message-Id: <20140422130829.CA29DC4042C@trevor.secretlab.ca>
Date:	Tue, 22 Apr 2014 14:08:29 +0100
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Rob Herring <robherring2@...il.com>,
	Leif Lindholm <leif.lindholm@...aro.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linaro Patches <patches@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
	Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only

On Fri, 18 Apr 2014 10:37:58 -0500, Rob Herring <robherring2@...il.com> wrote:
> On Fri, Apr 18, 2014 at 7:48 AM, Leif Lindholm <leif.lindholm@...aro.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@...aro.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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ