Tighten up these comments to make the behaviour clearer.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present it is possible to call uclass_get() before driver model is
inited. In fact this happens on x86 boards which use Intel FSPv1, since
mrccache_get_region() tries to get the SPI flash device very early
during init.

This has always been undefined behaviour. Previously it generally worked,
i.e. returned an error code without crashing, because gd->uclass_root_s
is zeroed and the uclass can be added despite driver model not being
ready, due to the way lists are implemented. With the change to use a
gd->uclass_root pointer, this no-longer works. For example, it causes a
hang on minnowmax.

Fix this by adding a check that driver model is ready when uclass_get() is
called. This function is called in the process of locating any device, so
it is a good place to add the check.

This fixes booting on minnowmax.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 8a715530bb1 ("dm: core: Allow the uclass list to move")

Each _device_ belonging to a given uclass of course has its own ->ops,
of a type determined by and known to the uclass.

However, no instance of a uclass_driver seems to populate ->ops, and
the only reference to it in code is this relocation.

Moreover, it's not really clear what could sensibly be assigned; it
would have to be some "struct uclass_ops *" providing a set of methods
for the core to call on that particular uclass, but should the need
for that ever arise, it would be better to have a member of that
particular type instead of void*.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

Add macros which work with instantiated devices and uclasses, as created
at build time by dtoc. Include variants that can be used in data
structures.

These are mostly used by dtoc but it is worth documenting them fully for
the occasional case where they might come up in user code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

Support a common method to probe all devices associated with uclass.

This includes data structures and code for finding the first device and
looping for remaining devices associated with uclasses (groups of devices
with the same purpose, e.g. all SERIAL ports will be in the same uclass).

An example is SBSA compliant PL011 UART IP, where firmware does the serial
port initialization and prepare uart device to let the kernel use it for
sending and reveiving the characters.SERIAL uclass will use this function
to initialize PL011 UART ports.

The feature is enabled with CONFIG_DM.

Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Sean Anderson <seanga2@gmail.com>

In the spirit of using the same base name for all of these related macros,
rename this to have the operation at the end. This is not widely used so
the impact is fairly small.

Signed-off-by: Simon Glass <sjg@chromium.org>

These are supposed to be private to driver model, not accessed by any code
outside. Add a trailing underscore to indicate this.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add functions so this information is not accessed directly. This will be
needed for of-platdata which stores it in a different place.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present the name 'uclass_driver' is used for the uclass linker list.
This does not follow the convention of using the struct name. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>

This function is not needed anymore. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>