Commit graph

23 commits

Author SHA1 Message Date
Simon Glass
43ba492670 dtoc: Detect drivers which do not parse correctly
At present if a driver is missing a uclass or compatible stirng, this
is silently ignored. This makes sense in most cases, particularly for
the compatible string, since it is not required except when the driver
is used with of-platdata.

But it is also not very helpful. When there is some sort of problem
with a driver, the missing compatible string (for example) may be the
cause.

Add a warning in this case, showing it only for drivers which are used
by the build.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Walter Lozano <walter.lozano@collabora.com>
2021-07-21 10:27:34 -06:00
Simon Glass
86ff01e890 dtoc: Detect unexpected suffix on .of_match
Some rockchip drivers use a suffix on the of_match line which is not
strictly valid. At present this causes the parsing to fail. Fix this
and offer a warning.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-07-21 10:27:34 -06:00
Simon Glass
893142aa3b dtoc: Correct the re_compat regular expression
This expects a . before the field name (.e.g '.compatible = ...) but
presently accepts anything at all. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Walter Lozano <walter.lozano@collabora.com>
2021-07-21 10:27:34 -06:00
Simon Glass
1b5fe11d95 dtoc: Allow multiple warnings for a driver
At present we show when a driver is missing but this is not always that
useful. There are various reasons why a driver may appear to be missing,
such as a parse error in the source code or a missing field in the driver
declaration.

Update the implementation to record all warnings for each driver, showing
only those which relate to drivers that are actually used. This avoids
spamming the user with warnings related to a driver for a different board.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Walter Lozano <walter.lozano@collabora.com>
2021-07-21 10:27:34 -06:00
Simon Glass
c7967653da dtoc: Avoid using subscripts on match objects
These are not supported before Python 3.6 so avoid them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Walter Lozano <walter.lozano@collabora.com>
2021-07-21 10:27:33 -06:00
Simon Glass
0c59acef34 dtoc: Show driver warnings once at the end
At present warnings are shown as soon as they are discovered in the
source scannner. But the function that detects them may be called multiple
times.

Collect all the warnings and show them at the end.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-04-06 16:33:19 +12:00
Simon Glass
50aae3e62d dtoc: Support processing the root node
The device for the root node is normally bound by driver model on init.
With devices being instantiated at build time, we must handle the root
device also.

Add support for processing the root node, which may not have a compatible
string.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
337d6972f5 dtoc: Set up the uclasses that are used
We only care about uclasses that are actually used. This is determined by
the drivers that use them. Check all the used drivers and build a list of
'valid' uclasses.

Also add references to the uclasses so we can generate C code that uses
them. Attach a uclass to each valid driver.

For the tests, now that we have uclasses we must create an explicit test
for the case where a node does not have one. This should only happen if
the source code does not build, or the source-code scanning fails to find
it.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
1712f8b2b7 dtoc: Detect drivers only at the start of start of line
If a driver declaration is included in a comment, dtoc currently gets
confused. Update the parser to only consider declarations that begin at
the start of a line. Since multi-line comments begin with an asterisk,
this avoids the problem.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
059535291c dtoc: Read aliases for uclasses
Scan the aliases in the device tree to establish the number of devices
within each uclass, and the sequence number of each.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
1d97269756 dtoc: Warn of duplicate drivers
If drivers have the same name then we cannot distinguish them. This only
matters if the driver is actually used by dtoc, but in that case, issue
a warning.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
8d6f2d359e dtoc: Process driver aliases along with drivers
Instead of using a separate step for this processing, handle it while
scanning its associated driver. This allows us to drop the code coverage
exception in this case.

Note that only files containing drivers are scanned by dtoc, so aliases
declared in a file that doesn't hold a driver will not be noticed. It
would be confusing to put them anywhere other than in the driver that they
relate to, but update the documentation to say this explicitly, just in
case.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
735ddfc638 dtoc: Support headers needed for drivers
Typically dtoc can detect the header file needed for a driver by looking
for the structs that it uses. For example, if a driver as a .priv_auto
that uses 'struct serial_priv', then dtoc can search header files for the
definition of that struct and use the file.

In some cases, enums are used in drivers, typically with the .data field
of struct udevice_id. Since dtoc does not support searching for these,
add a way to tell dtoc which header to use. This works as a macro included
in the driver definition.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
b00f0066e5 dtoc: Support tracking the phase of U-Boot
U-Boot operates in several phases, typically TPL, SPL and U-Boot proper.
The latter does not use dtoc.

In some rare cases different drivers are used for two phases. For example,
in TPL it may not be necessary to use the full PCI subsystem, so a simple
driver can be used instead.

This works in the build system simply by compiling in one driver or the
other (e.g. PCI driver + uclass for SPL; simple_bus for TPL). But dtoc has
no way of knowing which code is compiled in for which phase, since it does
not inspect Makefiles or dependency graphs.

So to make this work for dtoc, we need to be able to explicitly mark
drivers with their phase. This is done by adding an empty macro to the
driver. Add support for this in dtoc.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
b9319c4f9b dtoc: Track nodes which are actually used
Mark all nodes that are actually used, so we can perform extra checks on
them.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
fd471e2ce1 dtoc: Process nodes to set up required properties
Add logic to assign property values to nodes as required by dtoc. The
references allow nodes to refer to each other in C code. The macros used
by dtoc are not yet defined in driver model. They will be added along
with the actual driver model implementation.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
acf5cb88b4 dtoc: Support scanning of structs in header files
Drivers can have private / platform data contained in structs and these
struct definitions are generally kept in header files. In order to
generate build-time devices, dtoc needs to generate code that declares
the data contained in those structs. This generated code must include the
relevant header file, to avoid a build error.

We need a way for dtoc to scan header files for struct definitions. Then,
when it wants to generate code that uses a struct, it can make sure it
includes the correct header file, first.

Add a parser for struct information, similar to drivers. Keep a dict of
the structs that were found.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
1a8b4b9d94 dtoc: Support scanning of uclasses
Uclasses can have per-device private / platform data so dtoc needs to
scan these drivers. This allows it to find out the size of this data so
it can be allocated a build time.

Add a parser for uclass information, similar to drivers. Keep a dict of
the uclasses that were found.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
c8b19b0694 dtoc: Collect priv/plat struct info from drivers
In order to output variables to hold the priv/plat information used by
each device, dtoc needs to know the struct for each. With this, it can
declare this at build time:

   u8 xxx_priv [sizeof(struct <name>)];

Collect the various struct names from the drivers.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
36b2220cbd dtoc: Ignore unwanted files when scanning for drivers
We should ignore anything in the .git directory or any of the
build-sandbox, etc. directories created by 'make check'. These can confuse
dtoc. Update the code to ignore these.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:27 +13:00
Simon Glass
c58662fc65 dtoc: Scan drivers for available information
At present we simply record the name of a driver parsed from its
implementation file. We also need to get the uclass and a few other
things so we can instantiate devices at build time. Add support for
collecting this information. This requires parsing each driver file.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-22 19:23:26 +13:00
Simon Glass
10ea9c0b05 dtoc: Move src_scan tests to a separate file
Move the tests related to scanning into their own class, updating them
to avoid using dtb_platdata as a pass-through.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05 12:26:35 -07:00
Simon Glass
a542a70c22 dtoc: Split source-code scanning to a separate file
Before expanding the scanning features any more, move this into a separate
file. This will make it easier to maintain in the future. In particular,
it reduces the size of dtb_platdata.py and allows us to add tests
specifically for scanning, without going through that file.

The pieces moved are the Driver class, the scanning code and the various
naming functions, since they mostly depend on the scanning results.

So far there is are no separate tests for src_scan. These will be added
as new functionality appears.

This introduces no functional change.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05 12:26:35 -07:00