Messages in this thread | | | Date | Thu, 16 Dec 2021 10:08:36 +0100 | Subject | Re: [PATCH v2] extcon: fix extcon_get_extcon_dev() error handling | From | Hans de Goede <> |
| |
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@samsung.com/ >>>> >>>> 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 >
| |