From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: David Gibson Subject: Re: [dtc] Allow multipart property values In-Reply-To: Your message of "Wed, 07 Feb 2007 16:37:50 +1100." <20070207053750.GG23870@localhost.localdomain> References: <20070207032343.GD23870@localhost.localdomain> <41B393C3-9A8F-46EC-9B47-FCF8E0733994@kernel.crashing.org> <20070207044616.GF23870@localhost.localdomain> <20070207053750.GG23870@localhost.localdomain> Date: Thu, 08 Feb 2007 17:29:03 -0600 From: Jon Loeliger Message-Id: Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , So, like, the other day David Gibson mumbled: > > There's nothing in tests/ though - I always meant to make a testsuite, > but I never got around to it. Current plan is to implement a > testsuite by merging libfdt into the dtc tree. > > Here's a revised patch which adds an example usage to test.dts > > [dtc] Allow multipart property values > > At present each property definition in a dts file must give as the > value either a string ("abc..."), a bytestring ([12abcd...]) or a cell > list (<1 2 3 ...>). This patch allows a property value to be given as > several of these, comma-separated. The final property value is just > the components appended together. So a property could have a list of > cells followed by a string, or a bytestring followed by some cells. > Cells are always aligned, so if cells are given following a string or > bytestring which is not a multiple of 4 bytes long, zero bytes are > inserted to align the following cells. > > The primary motivation for this feature, however, is to allow defining > a property as a list of several strings. This is what's needed for > defining OF 'compatible' properties, and is less ugly and fiddly than > using embedded \0s in the strings. > > Signed-off-by: David Gibson Applied. Thanks, jdl