Hi Marek,
Another U-Boot engineer and I are looking at running up driver model.
It seems to work in sandbox quite nicely. I had half a mind to try to get some core patches together for this merge window, but have questions.
For 'struct instance' it seems to be an attempt to keep the constant data separate from the dynamic data to reduce early RAM usage. But when I look at struct driver_instance, it seems to have a 'struct instance' within it (not a pointer). So doesn't this defeat that benefit? You presumably can't put struct driver_instance in read-only memory because you need it updates its flags.
I still have trouble keeping track of some of the naming - e.g. and instance feels to me like it should be called a device, and the naming of 'core' seems odd although I do understand the concept. Also bind/unbind seems like register/unregister to me - but maybe there is a difference.
There is:
struct driver_info struct instance struct core_instance struct driver_instance struct u_boot_driver struct u_boot_core
Anyway I'll leave that alone for now.
There seems to be a lot of boilerplate code about. For example the bind/unbind methods just call a core_...() function and it seems that the core library could do this itself. It seems to me that some of the methods could be NULL for most drivers, and that would reduce the porting effort.
If we do this I would like to build in device tree from the start so that on boards that use CONFIG_OF_CONTROL there is no need for static data.
I think the existing 'demo' driver is a really good idea since it gives people something to copy.
Regards, Simon