Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6494695imu; Wed, 14 Nov 2018 02:21:37 -0800 (PST) X-Google-Smtp-Source: AJdET5eZ1iIoidJnp5lEpkqFQj6tcQM819TIgSJ61WfJkS4C/mEAYgCTh/ssv8Ri2FlSALJQ3Ttw X-Received: by 2002:a63:a51b:: with SMTP id n27mr1204443pgf.17.1542190897357; Wed, 14 Nov 2018 02:21:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542190897; cv=none; d=google.com; s=arc-20160816; b=q9FibUqUZZcJW4R8w4VCdrsOJgbcRkPZqbUvKIEXCFIBWiia+N3dShF1OR7srVBcd2 LXKY075ZPYZKQDy/Yb7UBrYrjLjORUxYQJMEQInvjEQznSgT4JWnKm90/VwVIARGu4Cu 8SqmIAIhLbqVuQiaKliUYWXIZQqdlsLC9xVMBQesxrPgbrZbXKU7d5QdjTqT6OWPW5fR eKVRMgeaFvFuMuzc4ldVr1VOt5g2BvWPPVmbBaZF7uZOCs/HUws9zeQt/eXFl1P4wikH HyoAXMx15T5TJnDk8d7y+1mrF662rZvilfIyTmZmwZD65/sapox5H2gQX81IgIm17ir0 yevg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=dlSofOcssX2yPqieswXODMBZ03gxeXSdESaVcgrsb5M=; b=xnwTBAUNvhtzEuCNrZXbCveo5s1w8Ao1SwmqkcHHRUC6ScjXwnFs0x77Jx4+qJqKSw H0VGhRayG9byhprkObwN0Rwt+zo/B6LKauPti/teN/6/as7sAdJLq0TuK2Wp1D6dPd50 RMNXL3A84s+zX4Kw+KWuDhxdMM0UADSlIo52vIuo1GlVtZ16LGFAvYDOQedYpxnepQDz 8c0Msx9a7nY0nYt4nlR+jWm69q3/ItlzuuBkxLI++XfUMMAmWqQVYqkzeoh62ywg7cml 8iVYm0Mz/JMCmzOgSv9y5vqLI2Fjuj2TUqF8dwqzPRW1ojO/g9cTZT+P3W1uIxiUuY0+ i2BQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fnuNEal6; 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=pass (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 u28-v6si23963666pfi.175.2018.11.14.02.21.21; Wed, 14 Nov 2018 02:21:37 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fnuNEal6; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732852AbeKNUWz (ORCPT + 99 others); Wed, 14 Nov 2018 15:22:55 -0500 Received: from mail-qk1-f193.google.com ([209.85.222.193]:35275 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728071AbeKNUWy (ORCPT ); Wed, 14 Nov 2018 15:22:54 -0500 Received: by mail-qk1-f193.google.com with SMTP id w204so24739298qka.2; Wed, 14 Nov 2018 02:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dlSofOcssX2yPqieswXODMBZ03gxeXSdESaVcgrsb5M=; b=fnuNEal61tnlglehJtuRGIH1hx+YoJBdqdoIhQpTJHDdh2ejEvh+HQnrgSgGq80buu qlbfPDSZB6hh1eK12kFnhhiMWsZ4AyHKxGo2kVDN+MoEIUH/Dw4500IoQypMAnyykhdg vhg3uT1I1TXMiOZOriUAWBAajgSnTVH7wmPkjty94EjrvnoBG6vDtASkIt6tOS6qz67j LNIyoxQZq256/vFT9k0UgrZOwBvw+1hCgPDOhI8+pwBmNys3FIn6BfcJSzvdw8OWTxJE ZxAub5MnFyP4Kx6DeLbs9dKaDc86NS4xNa0SVwGEWEDFkuOk6btZu4GuF3a/PJYH2iST RYGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dlSofOcssX2yPqieswXODMBZ03gxeXSdESaVcgrsb5M=; b=OncW7v9jqY3tbRlURKs/HtQmYXQVT2A5JC5XqlXtFsYVt/Y2FINGiO8T2v2kDejMpe aE3TzSZJxvLpcmppjpqSgIOSOPQXkEdO6GjSS6KfVbHonhObueS3vTvEEGhW1EV2giCR pU+/YANYRLfZdfZOcYvpNPVT0KXbB/k8Yh1aw0ceziqGhYQNKG+wcKcA09Hie+tmStwc uJvNLc5FjQutmDITNoArqElm5bfeN320lWuSG1xREWMIyc2TbSWQ9a0bV1bb4hlZBPyn dgCeZ2RuGJFnvpyNGbNXgnaSVjpBRMlgwBbZsuyM4zzAMz9Nh6+ovm+s9D9j2xAqxZJh 7M/Q== X-Gm-Message-State: AGRZ1gK2jGTcWRvwo35u3Pzxq4kYSP4Ncwe34zPVHGAaWZnvLt7wcj62 lhdjHrALE9XJtjtkv/SJ6jE/oCFCV+FPwuxCSr0= X-Received: by 2002:aed:3e49:: with SMTP id m9mr986862qtf.99.1542190816140; Wed, 14 Nov 2018 02:20:16 -0800 (PST) MIME-Version: 1.0 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> <20181114093652.GK10650@smile.fi.intel.com> <5BEBEF7C.7060003@samsung.com> In-Reply-To: <5BEBEF7C.7060003@samsung.com> From: Andy Shevchenko Date: Wed, 14 Nov 2018 12:20:04 +0200 Message-ID: Subject: Re: [PATCH v1 2/5] extcon: Return -EPROBE_DEFER when extcon device is not found 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 11:48 AM Chanwoo Choi wrote= : > > On 2018=EB=85=84 11=EC=9B=94 14=EC=9D=BC 18:36, Andy Shevchenko wrote: > > On Wed, Nov 14, 2018 at 06:13:37PM +0900, Chanwoo Choi wrote: > >> On 2018=EB=85=84 11=EC=9B=94 14=EC=9D=BC 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 func= tion. > >>>> But, this function might be called on other position instead of prob= e. > >>> > >>> *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 t= he 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() o= r other position > >> in the caller driver. The caller driver should decide the kind of erro= r 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() fuct= ion, > >> 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 th= is 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. > > 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. --=20 With Best Regards, Andy Shevchenko