From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tnt@246tNt.com>
Received: from outmx004.isp.belgacom.be (outmx004.isp.belgacom.be
	[195.238.4.101])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by ozlabs.org (Postfix) with ESMTP id 1E35ADDF61
	for <linuxppc-dev@ozlabs.org>; Fri, 12 Jan 2007 21:46:19 +1100 (EST)
Received: from outmx004.isp.belgacom.be (localhost [127.0.0.1])
	by outmx004.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with ESMTP id l0CAk2QL005264
	for <linuxppc-dev@ozlabs.org>; Fri, 12 Jan 2007 11:46:02 +0100
	(envelope-from <tnt@246tNt.com>)
Message-ID: <45A76663.4030705@246tNt.com>
Date: Fri, 12 Jan 2007 11:43:47 +0100
From: Sylvain Munaut <tnt@246tNt.com>
MIME-Version: 1.0
To: Sascha Hauer <s.hauer@pengutronix.de>
Subject: Re: [PATCH] add restart function for mpc52xx
References: <20070111122855.GF11226@localhost.localdomain>
	<37B2A6BB-4F36-4765-A1C2-A4F8D30D4503@kernel.crashing.org>
	<20070111152137.GG11226@localhost.localdomain>
	<17831.627.162751.166002@cargo.ozlabs.ibm.com>
	<20070112084612.GJ11226@localhost.localdomain>
	<45A74E2F.2000901@246tNt.com>
	<20070112104211.GQ11226@localhost.localdomain>
In-Reply-To: <20070112104211.GQ11226@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1
Cc: linuxppc-dev Development <linuxppc-dev@ozlabs.org>,
	Paul Mackerras <paulus@samba.org>
List-Id: Linux on PowerPC Developers Mail List <linuxppc-dev.ozlabs.org>
List-Unsubscribe: <https://ozlabs.org/mailman/listinfo/linuxppc-dev>,
	<mailto:linuxppc-dev-request@ozlabs.org?subject=unsubscribe>
List-Archive: <http://ozlabs.org/pipermail/linuxppc-dev>
List-Post: <mailto:linuxppc-dev@ozlabs.org>
List-Help: <mailto:linuxppc-dev-request@ozlabs.org?subject=help>
List-Subscribe: <https://ozlabs.org/mailman/listinfo/linuxppc-dev>,
	<mailto:linuxppc-dev-request@ozlabs.org?subject=subscribe>

Sascha Hauer wrote:
> On Fri, Jan 12, 2007 at 10:00:31AM +0100, Sylvain Munaut wrote:
>   
>> I'm not saying the system is perfect but this issue is more related to
>> recent
>> bindings that the of thing as a whole. That's more the problem with of
>> is that
>> when you need to define bindings for something that has none, you may not
>> anticipate everything ....
>>     
>
> No, you can never do that. Lets hope there will never be incompatible
> changes in the device tree so that we have to use this device tree for this
> kernel version and another one for other kernel versions.
>   
I would *not* base anything (production) on the current bindings, because
the changes we consider now are pretty "basic" and not compatible.

But it's clear that it's probably the last opportunity we have to do
such changes,
afterwards we'll be bound to whatever we decide in the next few weeks.


    Sylvain