On Tue, Nov 04, 2014 at 12:02:32PM -0800, Kees Cook wrote:
> > I considered doing that, but didn't want to risk listing too many
> > details of one architecture, and too few of others.
>
> Well, the others only say "memory mapped peripherals", so that's what
> I was suggesting adding the x86 langu
On Tue, Nov 04, 2014 at 10:43:00AM -0800, Kees Cook wrote:
> > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> > index efefd12..39f7817 100644
> > --- a/drivers/char/Kconfig
> > +++ b/drivers/char/Kconfig
> > @@ -6,6 +6,22 @@ menu "Character devices"
> >
> > source "drivers/tty/Kconfig"
Most, but not all, architectures supporting CONFIG_STRICT_DEVMEM treat
it as a debug feature - although its function is pretty much the
opposite of debug.
This patch deletes all architecture-specific config options and moves
the option to core code, as a non-debug option.
Signed-off-by: Leif
On Wed, Apr 23, 2014 at 02:10:58PM +0100, Grant Likely wrote:
> > Does anyone have a LongTrail DT to hand, and if so does the root have a
> > compatible string? From grepping through the kernel I could only find a
> > model string ("IBM,LongTrail").
>
> Actually, on LongTrail this can be removed f
On Wed, Apr 23, 2014 at 02:15:08PM +0100, Grant Likely wrote:
> > The reason for me doing that is because we (including you) agreed at
> > the discussion held during LCU13 that this was the safest way of
> > preventing "mischief" like userland trying to read information from
> > /proc/device-tree..
On Tue, Apr 22, 2014 at 02:08:29PM +0100, Grant Likely wrote:
> > I would prefer to see a "WARN_ON(!IS_ENABLED(CONFIG_PPC32));" added here.
>
> I completely agree.
OK. So do we keep this around on unaffected architectures in perpetuity?
Or can there be some cut-off date when the majority of DT-e
On Fri, Apr 18, 2014 at 04:28:17PM -0500, Rob Herring wrote:
> >> > 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.
> >
> > In addition to, or
On Fri, Apr 18, 2014 at 10:37:58AM -0500, Rob Herring wrote:
> >> 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
Hi Geert,
On Fri, Apr 18, 2014 at 10:04:15AM +0200, Geert Uytterhoeven wrote:
> On Thu, Apr 17, 2014 at 7:42 PM, Leif Lindholm
> wrote:
> > In order to deal with an firmware bug on a specific ppc32 platform
> > (longtrail), early_init_dt_scan_memory() looks for a node called
&
On Thu, Apr 17, 2014 at 07:43:13PM -0500, Rob Herring wrote:
> On Thu, Apr 17, 2014 at 12:41 PM, Leif Lindholm
> 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 -
In order to deal with an firmware bug on a specific ppc32 platform
(longtrail), early_init_dt_scan_memory() looks for a node called
memory@0 on all platforms. Restrict this quirk to ppc32 kernels only.
Signed-off-by: Leif Lindholm
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Grant Likely
Cc: Mark
-ker...@vger.kernel.org
Cc: Mark Rutland
Leif Lindholm (3):
arm: dts: add device_type="memory" for ste-ccu8540
mips: dts: add device_type="memory" where missing
of: Handle memory@0 node on PPC32 only
arch/arm/boot/dts/ste-ccu8540.dts |1 +
arch/mips/lantiq/dts/eas
12 matches
Mail list logo
