[RFC PATCH 1/5] OMAP3:I2C: Add device tree nodes for beagle board
Grant Likely
grant.likely at secretlab.ca
Wed Jul 20 19:14:05 EDT 2011
On Wed, Jul 20, 2011 at 4:33 PM, Shawn Guo <shawn.guo at freescale.com> wrote:
> On Wed, Jul 20, 2011 at 12:55:13PM -0600, Grant Likely wrote:
>> On Wed, Jul 20, 2011 at 07:04:20PM +0800, Shawn Guo wrote:
>> > > Mostly consistency. Most of the experience we have with the flattened
>> > > device tree up to this point hasn't bothered with the 'status'
>> > > property. It is only when AMP and hypervisors cam online that it
>> > > became important to use a status property, and that only when the
>> > > kernel needs to be told that the device does indeed exist, but it must
>> > > not be touched. I'd like to continue that pattern for new DT users
>> > > with the default assumption that a device is enabled unless the board
>> > > .dts explicitly disables it.
>> [...]
>> > Besides the bothering that we have to list so many unused controllers
>> > in individual board dts file, it's also hard to tell which controllers
>> > are actually available on the board. People have to look at imx53.dts
>> > to get a full list and then exclude the ones in imx53-<board>.dts as
>> > "disabled".
>> >
>> > And if we go the way opposite, adding "disabled" status for everyone
>> > in imx53.dts, we will only need to specify the peripherals that are
>> > actually available on board with "okay" status in imx53-<board>.dts.
>> > And it's much more clear for people to see what peripherals are
>> > available on individual board.
>> >
>> > So I'm going the way than you suggested. Please let me know if you
>> > strongly dislikes it.
>>
>> Yes, I strongly dislike it. I understand the concern, but at this
>> early stage with converting to device tree I think consistency between
>> platforms is more important. We can talk about the issue at Linaro
>> Connect in 2 weeks, but in the mean time please use the
>> enabled-by-default/explicitly-disabled pattern.
>>
> Okay, hope you will not ask me to use the opposite pattern when you
> actually see the patch :)
:-)
g.
More information about the linux-arm-kernel
mailing list