From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752336AbcHHQjr (ORCPT ); Mon, 8 Aug 2016 12:39:47 -0400 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:52510 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752238AbcHHQjq (ORCPT ); Mon, 8 Aug 2016 12:39:46 -0400 Message-ID: <1470674376.2497.49.camel@pengutronix.de> Subject: Re: Why do we need reset_control_get_optional() ? From: Philipp Zabel To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, Masahiro Yamada , Axel Lin , Linux Kernel Mailing List , Hans de Goede , Maxime Ripard , Lee Jones Date: Mon, 08 Aug 2016 18:39:36 +0200 In-Reply-To: <1859714.7lR6dsl2IG@wuerfel> References: <1469703649.12835.34.camel@pengutronix.de> <1859714.7lR6dsl2IG@wuerfel> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:96de:80ff:fec2:9969 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Freitag, den 05.08.2016, 17:50 +0200 schrieb Arnd Bergmann: > On Thursday, July 28, 2016 1:00:49 PM CEST Philipp Zabel wrote: > > Am Donnerstag, den 28.07.2016, 19:52 +0900 schrieb Masahiro Yamada: > > > > > In my experimental patch, I make the _optional functions > > > > return NULL if no "resets" property is provided but return > > > > an error if there are reset lines but the subsystem is > > > > disabled, i.e. an optional reset must be used if it's in the > > > > DT, but can be ignored otherwise. > > > > > > I do not like this idea. > > > > > > reset_control_get() (or variants) should not return NULL, it is ambiguous. > > > It should return ERR_PTR(-ENOENT) if no "resets" property. > > > > > > I only want two types for functions that return a pointer. > > > > > > [1] return a valid pointer on success, or return NULL on failure > > > (for example, kmalloc()) > > > [2] return a valid pointer on success, or return error pointer on failure > > > (many of _register() functions) > > > > > > Mixing [1] and [2] will be a mess. > > Ah, right. I was thinking only of the case where the reset subsystem > is completely disabled here, so returning NULL could be considered > a valid return code that can in turn be passed into the other > functions. > > However, I agree that returning NULL as a valid result from > ..._get_optional() would be bad style, so let's drop my idea > there. > > > I too would prefer to keep that as-is. The reset_control_get_optional > > stub could return -ENOENT if there is no resets device tree property. > > 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. regards Philipp