Hi Masahiro, On 3 December 2014 at 09:25, Masahiro YAMADA <[email protected]> wrote: > Hi Simon, > > > 2014-12-03 2:47 GMT+09:00 Simon Glass <[email protected]>: >> Hi Masahiro, >> >> On 1 December 2014 at 22:31, Masahiro Yamada <[email protected]> >> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
