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

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