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, 22 Apr 2014 15:05:26 +0100, Leif Lindholm
wrote:
> 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 p
On Tue, 22 Apr 2014 15:05:26 +0100, Leif Lindholm
wrote:
> 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 p
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, 18 Apr 2014 10:37:58 -0500, Rob Herring wrote:
> On Fri, Apr 18, 2014 at 7:48 AM, Leif Lindholm
> 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
> >> wrote:
> >> > drivers/of/fdt.c contains a workaround for a
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 3:13 PM, Leif Lindholm wrote:
> 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
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
On Fri, Apr 18, 2014 at 7:48 AM, Leif Lindholm 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
>> wrote:
>> > drivers/of/fdt.c contains a workaround for a missing memory type
>> > entry on longtrail firmware. Make that quirk
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 - fix up the .dts files in t
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 - fix up the .dts files in the tree currently working only
> because of that quirk.
But why do you
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.
Cc: devicet...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ker
12 matches
Mail list logo
