Message-Id: <1243497343.3171.158.camel@pasglop>
Date:	Thu, 28 May 2009 17:55:43 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Wolfram Sang <w.sang@...gutronix.de>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Robert Schwebel <r.schwebel@...gutronix.de>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	Jon Smirl <jonsmirl@...il.com>,
	Scott Wood <scottwood@...escale.com>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	Timur Tabi <timur@...escale.com>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Thu, 2009-05-28 at 08:34 +0200, Wolfram Sang wrote:
> 
> > OTOH, if it is appropriate for the device, then the binding can be defined to
> > include things like page size and flags encoded explicitly in additional
> > properties.
> 
> ..., so I think a property like "page-size" could really be argumented for.

Most definitely. And it's in fact reasonably easy to define such
bindings. And if somebody later decide do invent a fancier property
called "page-data" that contains more structured informations, the
driver can still fall back to using "page-size" when the later is not
found. It's rarely needed but the technique works reasonably well.

> Actually, I am quite optimistic that there could be agreement on it. Maybe we
> could also reuse the "read-only" property which is used for partitions. Still,
> this discussion has to be done, and that is additional work for mainlining.

Well, it depends. You don't need to have defined all the bindings for
all possible devices on the planet before adding to your architecture
the core bits to have the ability to use device-trees :-)

However, it does make sense for a platform using it, to at least try
to make sure that bindings for the devices it uses are in reasonable
shape.

Again, no solution is ever perfect and whatever the technique is,
somebody can make a mess of it. But my experience is that most of
the time, those things come pretty easily out of common sense when
talking about bindings for a -device-. Bindings for -busses- take
a bit more thoughts, I agree.

> Also, this would be _another_ wrapper to collect data from the device tree and
> pass it into platform_data.
>  I think it is difficult to maintain.

It's easier to have -one- piece of code taking data for device type X
to create the platform data and than all platforms around having C code
spread around that manufactures that platform data in 36 different ways.

So here, I disagree.

>  If somebody
> extends at24 and forgets about the of-wrapper, it may easily get broken.

No. If somebody adds new fields and not knowing about them doesn't break
existing users, then only the first person to try to use the new
functionality will discover the need for a new property and update the
wrapper.

If somebody however changes the platform data in incompatible ways, that
person is supposed to fix all users right ? So grep all platforms etc...
and the wrapper will show up in that grep.

Also, it might be a lot easier to change just the wrapper don't you
think ? :-)
  
>  Plus,at least for me, coding always very similar stuff, feels like bloating the
> kernel. I did it a few times now, and that made me really wonder if we can't
> have a more generic solution to that problem. Sadly, I could neither come up
> with anything useful :(

Well, the device-tree does avoid a -lot- of code duplication... you can
see that easily when you look at our 4xx based platforms today vs. what
they were in arch/ppc

Cheers,
Ben.


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