Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6457189imu; Wed, 14 Nov 2018 01:37:40 -0800 (PST) X-Google-Smtp-Source: AJdET5cIVi8mmgGN18k+JLX/kjPrarpjQz0tIjM7kkdSjf5yLnKUUlWFgqEbUiu/B9xoUWynKm9n X-Received: by 2002:a63:4246:: with SMTP id p67mr1046505pga.335.1542188259967; Wed, 14 Nov 2018 01:37:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542188259; cv=none; d=google.com; s=arc-20160816; b=mkVKPuZMKvK6gaP8orLYgZMV5k+Y+huhC9y6u7QnMIbklcT2wfZrEGsz8YP+NTN83Q 4zu+D/hj/L4VpFiDYf+YPihlA2ps4Ci7zqDwfHqYXcdTf8ziqjoohdCOXc+QL9xYgGEi KKw+1mI0vOnaXJiHMV2USTXOlPkO03yKD1QVS3IahBaLHUBvkY+Itg12gcgGLQye+qrl DEX4wxWMA8kg0TE2IscVCRy/q5eupIw+jaRgRF7m7Gg8vSUopTTN84SkropWeNCUJrFK sdznArCYxVyhrasxKtnHZx8wGoeoYoWOmqjML7LbYfCz55iQZTiVHlJpIg/Yx4JTIl4A mAfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=7OLWlU8out5Z9xYM4wZxrMwRrx9oQY6npAJcnFcIliA=; b=plLVoRLFboSg/brp0zkf85phojiFQxU0alxFPOtjjtdwz9w4S+DuDyYkDwA+7pebOD dVNHW679fCszIuKKATkOJOxtw4BjJJGbUgbg8DWaybrWtZf82emcZSTxSTEpAn2zxQV7 0xeqya5cddUNYFCy9bndDrunLJ6kpX64lLWaDQmW4ZQRg86kGCQ+A4vJ1Ekg7rdnL8nm bItaMItAd2wxGu4JJ3YdR2FAY+kmmrSmCPEipJ5GgxleEiuirq3UBMfOQQHBownDtl1a zQB1y9Uge16b4Lws5+QSbbN4uiNNFgL+D6MPuLxk666h9FE1uw+1vcltyyHIHc3A7rsN D9/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a33-v6si24093968pld.272.2018.11.14.01.37.24; Wed, 14 Nov 2018 01:37:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732234AbeKNTj2 (ORCPT + 99 others); Wed, 14 Nov 2018 14:39:28 -0500 Received: from mga06.intel.com ([134.134.136.31]:22103 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727558AbeKNTj2 (ORCPT ); Wed, 14 Nov 2018 14:39:28 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2018 01:36:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,231,1539673200"; d="scan'208";a="108457865" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by orsmga002.jf.intel.com with ESMTP; 14 Nov 2018 01:36:54 -0800 Received: from andy by smile with local (Exim 4.91) (envelope-from ) id 1gMrbQ-0006uC-H6; Wed, 14 Nov 2018 11:36:52 +0200 Date: Wed, 14 Nov 2018 11:36:52 +0200 From: Andy Shevchenko To: Chanwoo Choi Cc: MyungJoo Ham , USB , Felipe Balbi , Guenter Roeck , "Krogerus, Heikki" , rogerq@ti.com, Linux PM , "Rafael J. Wysocki" , Sebastian Reichel , Linux OMAP Mailing List , Darren Hart , Platform Driver , Greg Kroah-Hartman , Linux Kernel Mailing List , Chen-Yu Tsai , Hans de Goede Subject: Re: [PATCH v1 2/5] extcon: Return -EPROBE_DEFER when extcon device is not found Message-ID: <20181114093652.GK10650@smile.fi.intel.com> References: <20181110181101.24557-1-andriy.shevchenko@linux.intel.com> <20181110181101.24557-2-andriy.shevchenko@linux.intel.com> <5BE8C821.5080002@samsung.com> <5BEB63C3.1020504@samsung.com> <5BEBE741.6050101@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5BEBE741.6050101@samsung.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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. API inside the kernel are not carved in the stone. -- With Best Regards, Andy Shevchenko