From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752680AbcHHVkV (ORCPT ); Mon, 8 Aug 2016 17:40:21 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:64315 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752343AbcHHVkU (ORCPT ); Mon, 8 Aug 2016 17:40:20 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Philipp Zabel , Axel Lin , Hans de Goede , Linux Kernel Mailing List , Masahiro Yamada , Maxime Ripard , Lee Jones Subject: Re: Why do we need reset_control_get_optional() ? Date: Mon, 08 Aug 2016 23:39:38 +0200 Message-ID: <8414390.v8zIvdprGF@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-31-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <1470674376.2497.49.camel@pengutronix.de> References: <1859714.7lR6dsl2IG@wuerfel> <1470674376.2497.49.camel@pengutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:48GHEYZMVXj9fMhMFecOV5z4NCFITyXsffjPtd6oB5ULTpoRCrZ W0m0R+TQTFfk6XckkUagofaZ9uUxk5Fwa8nCQmu0JaurxT/WNE1/HbV6HmkAgeWK0bXBOso Y8Glt8Y/2duA6Gl26pa/N7d2TY14I/a59wlQ42ZEserOrMFwmHzsRLHetrJW1ciRvCALevK IkZteBUg0xCBWXQsYIRvw== X-UI-Out-Filterresults: notjunk:1;V01:K0:HNFYAEtYuyM=:7lrogd9yofFy5It9V6Cz6a WFkp92j8UH37mQe0hpdEOVEIL/6ngzec9xDe+Rlc69r87FeAgNtcxoQa4M7VUWJauHTLKqjWM /N7JCT+seXp520/ZsnrZJ9QR2qSZb4n6k4EsfDfbzUyW+NzNz96uviUSBiDsC9OcSyEXbtR57 CmyGJc8R3+V6Oy1CfHg6ZVZNpkPgbh7OkyPLkOoICVBcL4srCHRzeShLEmcbu4uTEHC3j47+h WN0X9ncKHSYGhYA4Uy1ULAZFPrlcAhc9kfnviomZAhFGbAelcM8oJi0Kc2NMI+LJRKPxCIiBM oqFn10Z68UFiagYu7TJ4zb/n2B6pXxM2+ac8/VmwOFD8upVubrbcnSOsKpmyj7S2drBnuK3zT DTr4X5RzrvrpZsp0hWNBNWGpCtTDIIX5g6D/zX9UPRV6WriZ0b76DDoPheIyfOwABgUIfVoFq MvTonD0NFMeoooELtSugO4OQdfywY3ks0nhZyjb5R9iOQKqABHIYYpW5+G5QkO8qaGTU1ZBmY UMmtAJaq3XQp3K7iURzSHOmpDkbcjU2n9WPv3k+mSaFDGnNDhDKt4EqL6g3itcA/0s+QhcvtY 3EmO1uvIi8MHYeC3WToLVMAT4LQjr79knbG6mY3ssgYNmjZWkefHcw/PkZMuLhdMUKTdHQQsu Y5MONa/PutJjnopVS48Mr0JZy1KfZoVwe/Ucst7zF0CjyuQc+Pt8fluJ/JtdqfKLlQ+RL8oXZ BI2uWqw+S8/yhwLk Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, August 8, 2016 6:39:36 PM CEST Philipp Zabel wrote: > > Now I'm also confused about what we really need > > reset_control_get_optional() for, and which error codes the callers > > are supposed to check. > > > > This is the matrix I think you mean for _get_optional: > > > [...] > > CONFIG_RESET_CONTROLLER=n, dt entry present: -EOPNOTSUPP > > CONFIG_RESET_CONTROLLER=n, dt entry missing: -ENOENT > > ^^ I didn't consider this distiction. > > > Is this what you had in mind? If so, what is the value of the > > added runtime warning for reset_control_get? Any caller of that > > function would already check for errors, the only difference > > I see is that callers of _optional can ignore -ENOENT. > > My initial motivation was to make it as hard as possible to misconfigure > the kernel, which is why I initially didn't want stubs for the > non-optional variant. Of course that would cause build failures and/or > reduced compile test coverage, so we added the stubs and the warning to > make it obvious when a misconfigured kernel is running: on a kernel with > RESET_CONTROLLER=n drivers that use reset_control_get are expected to > build, but they are not expected to work. I suppose the same is the case > for _optional, if the dt entry is present, so maybe we should drop > reset_control_get_optional and add always a warning in case of > -EOPNOTSUPP. > I don't want all drivers to have to differentiate between -EOPNOTSUPP > and -ENOENT error codes, only current reset_control_get_optional users > have to do that. In almost all cases, I think drivers that require the reset line wouldn't even check the failure code but just pass it down to the caller (usually platform_device_probe()), so the really don't need to care. Some drivers might want to handle -EPROBE_DEFER (by not warning about it before returning from probe), and -ENOENT can be handled in a similar way (by continuing instead of failing). Arnd