Hi, On 12/16/21 09:05, Dan Carpenter wrote: > On Thu, Dec 16, 2021 at 05:24:30PM +0900, Chanwoo Choi wrote: >> On 12/16/21 4:52 PM, Dan Carpenter wrote: >>> On Thu, Dec 16, 2021 at 03:39:46PM +0900, Chanwoo Choi wrote: >>>> Hi Dan, >>>> >>>> First of all, sorry for late reply. >>>> >>>> There is one issue. About this issue, I already discussed on patch[1] >>>> [1] https://lore.kernel.org/lkml/5BEB63C3.1020504@xxxxxxxxxxx/ >>>> >>>> extcon_get_extcon_dev() is used for anywhere except for probe step. >>>> But EPROBE_DEFER is only used on probe step. >>>> >>>> So that it is not clear to return EPROBE_DEFER from extcon_get_extcon_dev() >>>> because extcon_get_extcon_dev() never know either call it on probe function >>>> or not. >>> >>> Currently extcon_get_extcon_dev() is only called from probe so it's not >>> an issue. >> >> Even if extcon_get_extcon_dev() is used on probe until now, >> it is possible to use on anywhere as I commented. >> >> It is difficult to agree this approach without any other solution. >> >> Basically, the subsystem core never know either probe time or not. >> It means that this issue should be handled in each device driver. >> > > To be honest, I'm not sure how this differs from other functions which > return -EPROBE_DEFER. How do other functions guarantee they will only > be called from probe()? Right I have to agree with Dan here, all "get" functons for resources like gpios, clks, regulators, phys, pwms, etc. may return -EPROBE_DEFER and since these functions may return -EPROBE_DEFER they *must* only be called from a driver's probe() function. So I believe that the solution here is to simply add a kernel-doc comment on extcon_get_extcon_dev() which documents that it may return -EPROBE_DEFER and that it thus *must* only be called from a driver's probe() function. Regards, Hans > > regards, > dan carpenter >
