linux-kernel - Re: [PATCH v1 2/5] extcon: Return -EPROBE_DEFER when extcon device is not found

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <5BEC018E.8020102@samsung.com>
Date:   Wed, 14 Nov 2018 20:05:50 +0900
From:   Chanwoo Choi <cw00.choi@...sung.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     MyungJoo Ham <myungjoo.ham@...sung.com>,
        USB <linux-usb@...r.kernel.org>, Felipe Balbi <balbi@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        "Krogerus, Heikki" <heikki.krogerus@...ux.intel.com>,
        rogerq@...com, Linux PM <linux-pm@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Sebastian Reichel <sre@...nel.org>,
        Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
        Darren Hart <dvhart@...radead.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Chen-Yu Tsai <wens@...e.org>,
        Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH v1 2/5] extcon: Return -EPROBE_DEFER when extcon device
 is not found

On 2018년 11월 14일 19:20, Andy Shevchenko wrote:
> On Wed, Nov 14, 2018 at 11:48 AM Chanwoo Choi <cw00.choi@...sung.com> wrote:
>>
>> On 2018년 11월 14일 18:36, Andy Shevchenko wrote:
>>> On Wed, Nov 14, 2018 at 06:13:37PM +0900, Chanwoo Choi wrote:
>>>> On 2018년 11월 14일 17:35, Andy Shevchenko wrote:
>>>>> On Wed, Nov 14, 2018 at 1:53 AM Chanwoo Choi <cw00.choi@...sung.com> wrote:
>>>>>
>>>>>> I was thinking about again to change from NULL to EPROBE_DEFER.
>>>>>>
>>>>>> extcon_get_extcon_dev() function was almost called in the probe function.
>>>>>> But, this function might be called on other position instead of probe.
>>>>>
>>>>> *Might be* sounds like a theoretical thing, care to share what is in you mind?
>>>>> Current users and more important the new coming one are *all* doing the same.
>>>>>
>>>>>> ENODEV is more correct error instead of EPROBE_DEFER.
>>>>>
>>>>> So, you are proposing to continue duplicating conversion from ENODEV
>>>>> to EPROBE_DEFER in *each* caller?
>>>>
>>>> The extcon core don't know the caller situation is in either probe() or other position
>>>> in the caller driver. The caller driver should decide the kind of error value
>>>> by using the return value of extcon_get_extcon_dev().
>>>>
>>>> extcon_get_extcon_dev() function cannot be modified for only one case.
>>>> If some device driver call extcon_get_extcon_dev() out of probe() fuction,
>>>> EPROBE_DEFER is not always correct.
>>>
>>> I agree with this, but look at the current state of affairs. All users do the same.
>>> If we need to have another case we may consider this later.
>>
>> Because we know the potential wrong case of this change, I can't agree this change.
>> If extcon_get_extcon_dev() returns ENODEV instead of EPROBE_DEFER,
>> it is clear and then there are no problem on both current and future.
> 
> Changing NULL to -ENODEV is a trading bad to worse.
> I would not go that way, so, it's your call.

If you think that this change is not necessary, just keep the current code
without the modification. Please drop this patch on next version.

> 
>>> API inside the kernel are not carved in the stone.
> 
> Only can repeat myself (see above). While I see *theoretical*
> rationale on your side, mine has *practical* proofs.
> So, I'm giving up on this and will duplicate same what it's done in 4
> current callers.
> 

I think that it is more important for removing the potential wrong case
instead of removing the duplicate code. The many device drivers already
decided the proper error value by using the return value of function of 
kernel framework.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics