[U-Boot] Many questions about U-Boot's Driver Model

[Masahiro Yamada]

Hi.

I am digging into the driver model.


I fear this triggers a controversy, but, first,
it looks like the driver model of U-Boot is pretty different from
the Linux's one, in spite of the fact that U-Boot has ported lots of
Linux sources and ideas (looks like U-Boot is getting a mirror of Linux)
and most of U-Boot developers are also working on Linux development.

This seems kind of unfortunate because
we have to study a new driver model in addition to Linux's one.
(Perhaps isn't it an obstacle in the future?)


[1] Why is usage (needed to be) different?

I expect the usage is something like this:

static int foo_init(void)
{
         return foo_driver_register(&vendorA_foo_driver);
}
module_init(foo_init)


I mean, something is triggered by "register"ing something
in each init function.




[2] Why uclass?

In Linux, struct device_driver is something like a superclass
of each driver such platform_driver, uart_driver, usb_driver.

Usually, struct foo_device includes(inherits) struct device
and struct foo_driver includes struct device_driver.



   |----------------|      |----------------------|
   |                |      |                      |
   | struct device  |      | struct device_driver |
   |                |      |                      |
   |----------------|      |----------------------|
          /|\                       /|\
           |                         |       include (inherit)
           |                         |
   |--------------------|  |-------------------|
   | struct             |  | struct            |
   |   platform_device  |  |   platform_driver |
   |                    |  |                   |
   |--------------------|  |-------------------|


struct uclass is a totally different approach.

For ex.

  int demo_hello(struct udevice *dev, int ch)

takes a pointer to struct udevice, but it must be the one of
DEMO class.

We can still pass a udevice belonging to GPIO class,
which the compiler never complains about, but it will crash at run time.

I'd like to know the philosophy in the background of this approach.



[3] Is platform driver(device) a special case?


I am not sure if I understood correctly,
but it looks like platform data in U-Boot is a special case.

I do not understand well the difference between
"platdata"  and "priv" (private data).

The platform driver(platform device) is derived from
device_driver(device), isn't it?



[4] What does "struct driver_info" stand for?

I cannot understand the following comment block at all.

/**
 * struct driver_info - Information required to instantiate a device
 *
 * @name:	Device name
 * @platdata:	Driver-specific platform data
 */
struct driver_info {
	const char *name;
	const void *platdata;
};



Does this structure give information of a driver or a device?

My first guess was the former because of the name "driver_info".

But this comment says, the "name" member of struct drive_info
means "Device name".

Moreover, U_BOOT_DEVICE macro is a shorthand of "struct driver_info".


U_BOOT_DEVICE(demo0) = {
	.name = "demo_shape_drv",
	.platdata = &red_square,
};

U_BOOT_DEVICE(demo1) = {
	.name = "demo_simple_drv",
	.platdata = &red_square,
};

U_BOOT_DEVICE(demo2) = {
	.name = "demo_shape_drv",
	.platdata = &green_triangle,
};


looks like instances of devices, not drivers.

I am wordering if "struct driver_info" should have been named "struct device_info"?




I found another confusing part.


/**
 * lists_bind_drivers() - search for and bind all drivers to parent
 *
 * This searches the U_BOOT_DEVICE() structures and creates new devices for
 * each one. The devices will have @parent as their parent.
 *
 * @parent: parent driver (root)
 * @early_only: If true, bind only drivers with the DM_INIT_F flag. If false
 * bind all drivers.
 */
int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only)


This comment says, the "parent" argument is "parent driver".
                                                    ^^^^^^^
So, do you mean, "struct udevice" is a driver?

It is absolutely a device, right?

I think comments and namings are confusing.




Sorry if I am wrong.
Perhaps I am writing this mail without understaing the code correctly.
But I do not feel comfortable to move forward base on something I cannot understand.
Also, I want to be sure if this is the right direction we should go to
before lots of conversions occur.



Best Regards
Masahiro Yamada