At present, the lexer in dtc recognizes only space, tab and newline as
whitespace characters. This is broken; in particular this means that
dtc will get syntax errors on files with DOS-style (CR-LF) newlines.
This patch fixes the problem, using flex's built-int [:space:]
character class.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
- Change include syntax to: /include/ "filename"
- Move private functions directly into dtc-lexer.l
- Define YYID for some older parser templates
Also fix a #include ordering problem around YYLTPE.
Signed-off-by; Jon Loeliger <jdl@freescale.com>
Acked-by: Haiying Wang <Haiying.Wang@freescale.com>
Keeps track of open files in a stack, and assigns
a filenum to source positions for each lexical token.
Modified error reporting to show source file as well.
No policy on file directory basis has been decided.
Still handles stdin.
Tested on all arch/powerpc/boot/dts DTS files
Signed-off-by: Jon Loeliger <jdl@freescale.com>
New syntax d#, b#, o# and h# allow for an explicit prefix
on cell values to specify their base. Eg: <d# 123>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
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 <dwg@au1.ibm.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
lex file has undefined behaviour. In fact it ends up including the stuff
within the definition of the yylex() function, leading to strange warnings
on gcc-3.4 and compile errors with gcc 4.
David Gibson