[U-Boot] [Driver Model] post_bind() and pre_unbind() handler

[Simon Glass]

Hi Masahiro,

On 3 December 2014 at 09:25, Masahiro YAMADA <yamada.m at jp.panasonic.com> wrote:
> Hi Simon,
>
>
> 2014-12-03 2:47 GMT+09:00 Simon Glass <sjg at chromium.org>:
>> Hi Masahiro,
>>
>> On 1 December 2014 at 22:31, Masahiro Yamada <yamada.m at 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