Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754425AbaKSJIS (ORCPT ); Wed, 19 Nov 2014 04:08:18 -0500 Received: from mail-ie0-f182.google.com ([209.85.223.182]:41115 "EHLO mail-ie0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752065AbaKSJIM convert rfc822-to-8bit (ORCPT ); Wed, 19 Nov 2014 04:08:12 -0500 MIME-Version: 1.0 In-Reply-To: <20141119090222.GU27002@pengutronix.de> References: <1360738983-22436-1-git-send-email-gnurou@gmail.com> <1360738983-22436-3-git-send-email-gnurou@gmail.com> <20141117090915.GE27002@pengutronix.de> <20141119084432.GT27002@pengutronix.de> <20141119090222.GU27002@pengutronix.de> From: Alexandre Courbot Date: Wed, 19 Nov 2014 18:07:50 +0900 Message-ID: Subject: Re: [PATCH 2/4] gpiolib: use const parameters when possible To: =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= Cc: Grant Likely , Linus Walleij , Linux Kernel Mailing List , Alexandre Courbot Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 19, 2014 at 6:02 PM, Uwe Kleine-König wrote: > Hello Alexandre, > > On Wed, Nov 19, 2014 at 05:57:46PM +0900, Alexandre Courbot wrote: >> On Wed, Nov 19, 2014 at 5:44 PM, Uwe Kleine-König >> wrote: >> > Hello Alexandre, >> > >> > On Wed, Nov 19, 2014 at 05:33:42PM +0900, Alexandre Courbot wrote: >> >> On Mon, Nov 17, 2014 at 6:09 PM, Uwe Kleine-König >> >> wrote: >> >> > Hello, >> >> > >> >> > On Wed, Feb 13, 2013 at 04:03:00PM +0900, Alexandre Courbot wrote: >> >> >> From: Alexandre Courbot >> >> >> >> >> >> Constify descriptor parameter of gpiod_* functions for those that >> >> >> should obviously not modify it. This includes value or direction get, >> >> >> cansleep, and IRQ number query. >> >> >> >> >> >> Signed-off-by: Alexandre Courbot >> >> > This patch is applied as def634338d3ffb32fbe9b0a2d70cc24ef909cd4f since >> >> > v3.9-rc2. >> >> > >> >> >> drivers/gpio/gpiolib.c | 29 ++++++++++++++++------------- >> >> >> 1 file changed, 16 insertions(+), 13 deletions(-) >> >> >> >> >> >> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c >> >> >> index 8a2cf9c..ad6df6b 100644 >> >> >> --- a/drivers/gpio/gpiolib.c >> >> >> +++ b/drivers/gpio/gpiolib.c >> >> >> @@ -207,7 +208,7 @@ static int gpiochip_find_base(int ngpio) >> >> >> } >> >> >> >> >> >> /* caller ensures gpio is valid and requested, chip->get_direction may sleep */ >> >> >> -static int gpiod_get_direction(struct gpio_desc *desc) >> >> >> +static int gpiod_get_direction(const struct gpio_desc *desc) >> >> >> { >> >> >> struct gpio_chip *chip; >> >> >> unsigned offset; >> >> >> @@ -223,11 +224,13 @@ static int gpiod_get_direction(struct gpio_desc *desc) >> >> >> if (status > 0) { >> >> >> /* GPIOF_DIR_IN, or other positive */ >> >> >> status = 1; >> >> >> - clear_bit(FLAG_IS_OUT, &desc->flags); >> >> >> + /* FLAG_IS_OUT is just a cache of the result of get_direction(), >> >> >> + * so it does not affect constness per se */ >> >> >> + clear_bit(FLAG_IS_OUT, &((struct gpio_desc *)desc)->flags); >> >> > I think this is worse than not having gpiod_get_direction take a const >> >> > descriptor. >> >> >> >> Yeah, this kind of sucks but ultimately gpiod_get_direction() is >> >> without side-effect to the caller and the const parameter helps >> >> highlighting that fact. >> > Does that mean you want to keep the const and take the risk that it >> > might introduce some hard to debug problem when the compiler changes its >> > optimisation strategies? I hope you don't. >> >> Nope, I would like to keep that const but correctness is more >> important than prototype aesthetics. I will fix that. > Fine. > >> >> >> > I don't know an example for this particular case where this could break, >> >> > but usually casting away a const is bad and can break in various ways. >> >> > >> >> > Maybe even drop the public function gpiod_get_direction completely. >> >> > As of next-20141114 there are only two users of this function (apart >> >> > from drivers/gpio/gpiolib*) and both are wrong (as discussed in >> >> > http://thread.gmane.org/gmane.linux.serial/16808/focus=4783). >> >> >> >> Or maybe gpiod_direction_*() should register the last set direction to >> >> be used by gpiod_get_direction() if the controller does not implement >> >> the get_direction op? On the other hand callers can also track the >> >> direction themselves (since they presumably set it), so this function >> >> is really only useful for users who want to read the *hardware* state >> >> of a GPIO. Which might still be a useful feature? >> > I think it's useful to be able to check how a given gpio is configured >> > in hardware. So you really want to look into the register and not cache >> > the direction in gpiod_direction_*. >> > And I'd say having /sys/kernel/debug/gpio is good enough. So IMHO there >> > is no reason to hide gpiod_get_direction from general misuse. >> >> Mmm so are you suggesting that we should keep gpiod_get_direction() in the end? > I'd make gpiod_get_direction static and only use it to fill in > /sys/kernel/debug/gpio. That's very tempting. I see only atmel_serial.c using this function, and there is no gpio_get_direction() declared anywhere so no user of this either. I'm not sure what I was thinking when I decided to export it? So yeah, if you can fix the current users, I agree with your proposal. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/