[U-Boot] [Driver Model] post_bind() and pre_unbind() handler
Hi Simon,
I have a question about handlers of struct uclass_driver.
When binding a device, "uc->uc_drv->post_bind()" is called *before* "drv->bind()", so the name "pre_bind()" is more suitable than "post_bind()", isn't it?
Likewise, when unbinding a device, "uc->uc_drv->pre_unbind()" is called *after* "drv->unbind()" so the name "post_unbind()" is more suitable than "pre_unbind()".
I think pre_ and post_ is opposite here, and it looks confusing to me.
Am I misunderstanding something?
Best Regards Masahiro Yamada
Hi Masahiro,
On 1 December 2014 at 22:31, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Simon,
I have a question about handlers of struct uclass_driver.
When binding a device, "uc->uc_drv->post_bind()" is called *before* "drv->bind()", so the name "pre_bind()" is more suitable than "post_bind()", isn't it?
The uclass post_bind() is called after the device is bound to the uclass. The device's bind() call is made last, so that it can do any last-minute adjustments, and can rely on any uclass setup having occurred.
The 'bind' step does not rely on calling the device's bind(). In fact the bind has already happened. This is just offering the device an opportunity to do a little after-processing.
Likewise, when unbinding a device, "uc->uc_drv->pre_unbind()" is called *after* "drv->unbind()" so the name "post_unbind()" is more suitable than "pre_unbind()".
Similar to the above.
I think pre_ and post_ is opposite here, and it looks confusing to me.
Am I misunderstanding something?
Do you have a need to change the ordering?
Regards, Simon
Hi Simon,
2014-12-03 2:47 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 1 December 2014 at 22:31, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Simon,
I have a question about handlers of struct uclass_driver.
When binding a device, "uc->uc_drv->post_bind()" is called *before* "drv->bind()", so the name "pre_bind()" is more suitable than "post_bind()", isn't it?
The uclass post_bind() is called after the device is bound to the uclass. The device's bind() call is made last, so that it can do any last-minute adjustments, and can rely on any uclass setup having occurred.
The 'bind' step does not rely on calling the device's bind(). In fact the bind has already happened. This is just offering the device an opportunity to do a little after-processing.
I thought that the 'bind' step meant calling the drv->bind() method. In your explanation, it rather means manipulation of struct list_head etc.
If so, "post_" is redundant, maybe?
We have two handlers to give side effects of the 'bind' step. The global one is uc->uc_drv->bind() and the driver-specific one is drv->bind().
Likewise, when unbinding a device, "uc->uc_drv->pre_unbind()" is called *after* "drv->unbind()" so the name "post_unbind()" is more suitable than "pre_unbind()".
Similar to the above.
I think pre_ and post_ is opposite here, and it looks confusing to me.
Am I misunderstanding something?
Do you have a need to change the ordering?
No. The order should be kept as it is, I think.
Perhaps it is less confusing to rename the handlers of uclass driver, but I am not sure if it is a good reason for the change.
Hi Masahiro,
On 3 December 2014 at 09:25, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-12-03 2:47 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 1 December 2014 at 22:31, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Simon,
I have a question about handlers of struct uclass_driver.
When binding a device, "uc->uc_drv->post_bind()" is called *before* "drv->bind()", so the name "pre_bind()" is more suitable than "post_bind()", isn't it?
The uclass post_bind() is called after the device is bound to the uclass. The device's bind() call is made last, so that it can do any last-minute adjustments, and can rely on any uclass setup having occurred.
The 'bind' step does not rely on calling the device's bind(). In fact the bind has already happened. This is just offering the device an opportunity to do a little after-processing.
I thought that the 'bind' step meant calling the drv->bind() method. In your explanation, it rather means manipulation of struct list_head etc.
If so, "post_" is redundant, maybe?
By the time the uclass's 'post' method is called, the driver is stitched in and the uclass can access it. In some cases the driver's bind method may create some dependent child devices. Of course the process of binding a device involves multiple steps, but conceptually the uclass's post_bind() method is called after the device is bound.
We have two handlers to give side effects of the 'bind' step. The global one is uc->uc_drv->bind() and the driver-specific one is drv->bind().
Right.
Likewise, when unbinding a device, "uc->uc_drv->pre_unbind()" is called *after* "drv->unbind()" so the name "post_unbind()" is more suitable than "pre_unbind()".
Similar to the above.
I think pre_ and post_ is opposite here, and it looks confusing to me.
Am I misunderstanding something?
Do you have a need to change the ordering?
No. The order should be kept as it is, I think.
Perhaps it is less confusing to rename the handlers of uclass driver, but I am not sure if it is a good reason for the change.
OK. I like it as it is for now. But I wonder whether the lifecycle docs should be expanded even further :-(
Regards, Simon
participants (3)
-
Masahiro YAMADA -
Masahiro Yamada
-
Simon Glass