On 12/16/21 5:05 PM, 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()? If it is possible to know extcon_get_extcon_dev() will be only callled on probe, it is no problem. But, it is not able to guarantee that extcon_get_extcon_dev() is called on probe. Because of this reason, this issue should be handled in each device driver. -EPROBE_DEFER is only for probe step. If return -EPROBE_DEFER except for probe, it is wrong return value. > > regards, > dan carpenter > > > -- Best Regards, Chanwoo Choi Samsung Electronics
