From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 49C341332AB; Tue, 6 Feb 2024 13:43:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707227030; cv=none; b=oclCoFOdSvjOJv/rIalQi2MyFC0Q5refBjspivECCMTJLr0sKURGwKe6uyh0HcNzPUnkuioRbStSnHaRmQO0G/hiFvhme/TxJ3EfPINTCJuHG8NnjZG7YN+fK/rNWlVD2VLKwmJ48Q189wMu8mdM9HDSgKE9Jh47mlIkhwwlcE4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707227030; c=relaxed/simple; bh=SUxMOCdGao8f0FWMz+0RjWwJi349adzOCQHtfuEpjss=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FSK7Aa/pTvBOowE8X6gDY7x3syGNWRtLKj5Rwt3DXr3jHpqGOKcl+chbWyT6SVaOZ+ORDLK1TuVDH3dad3rave3l6nH2GWWXuYLUQc2FOdX5HfNSTPh1fpuBxT/eA3ybPJPC5JN0VToORQh8TwH4sct+K4+X+fI8nJ1xpTXSUrA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=jL3lm+sP; arc=none smtp.client-ip=192.198.163.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="jL3lm+sP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707227029; x=1738763029; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=SUxMOCdGao8f0FWMz+0RjWwJi349adzOCQHtfuEpjss=; b=jL3lm+sPfsMHMMBadxpL9MGys9vNbkFCuXiiZz2YVvyKgSsKvSknyyQv S5b3II2RAHMTZWlcr3RmJHKL40T0msGGbQfoxc4NUhU+PYhhhbU5fsW4I U8FX3TeoEyZVuC+652bkZw53Mds7HTNowxdvzrvCeJyhdkfUhPPU1Whaq DRDptd/i/nj4b3H29hU45xvKNWcVybSOQFFyDg/hPlrFhVYQRRTzUjEOy 156gcmT0Uom0cx9NyGEA7yx2taZXfmaW2tW2TxwpkzCUTZC7PV03bAQwD JCyzSFK0X5Xe9RYDcleOUcktxd48lYBaRYuveLJNVFs3k7zAjEzcKVMx3 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10975"; a="1015677" X-IronPort-AV: E=Sophos;i="6.05,247,1701158400"; d="scan'208";a="1015677" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2024 05:43:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10975"; a="909638751" X-IronPort-AV: E=Sophos;i="6.05,247,1701158400"; d="scan'208";a="909638751" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga002.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2024 05:43:45 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1rXLji-00000002LvW-3KDt; Tue, 06 Feb 2024 15:43:42 +0200 Date: Tue, 6 Feb 2024 15:43:42 +0200 From: Andy Shevchenko To: Bartosz Golaszewski Cc: Linus Walleij , Kent Gibson , Alex Elder , Geert Uytterhoeven , "Paul E . McKenney" , Wolfram Sang , linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Bartosz Golaszewski Subject: Re: [PATCH v2 21/23] gpio: protect the pointer to gpio_chip in gpio_device with SRCU Message-ID: References: <20240205093418.39755-1-brgl@bgdev.pl> <20240205093418.39755-22-brgl@bgdev.pl> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Tue, Feb 06, 2024 at 02:23:35PM +0100, Bartosz Golaszewski wrote: > On Tue, Feb 6, 2024 at 2:13 PM Andy Shevchenko > wrote: > > On Tue, Feb 06, 2024 at 01:57:39PM +0100, Bartosz Golaszewski wrote: > > > On Tue, Feb 6, 2024 at 1:24 PM Andy Shevchenko > > > wrote: > > > > On Mon, Feb 05, 2024 at 08:36:39PM +0100, Bartosz Golaszewski wrote: > > > > > On Mon, Feb 5, 2024 at 1:31 PM Andy Shevchenko > > > > > wrote: ... > > > > > > > int gpiod_get_direction(struct gpio_desc *desc) > > > > > > > { > > > > > > > - struct gpio_chip *gc; > > > > > > > unsigned long flags; > > > > > > > unsigned int offset; > > > > > > > int ret; > > > > > > > > > > > > > > - gc = gpiod_to_chip(desc); > > > > > > > + if (!desc) > > > > > > > + /* Sane default is INPUT. */ > > > > > > > + return 1; > > > > > > > > > > > > Hmm... I can't imagine how this value may anyhow be used / useful. > > > > > > > > > > What else would you return for an optional (NULL) GPIO? > > > > > > > > An error. If somebody asks for direction of the non-existing GPIO, there is no > > > > (valid) answer for that. > > > > > All other functions return 0 for desc == NULL to accommodate > > > gpiod_get_optional(). I think we should stay consistent here. > > > > The way you proposed is inconsistent, i.e. you may not return any direction > > for the unknown / non-existing GPIO. You speculate it will be 1, I may consider > > that in my (hypothetical for now) case it should be 0. > > > > Just don't make all bananas to be oranges. It won't work. > > I don't have a strong conviction here. May make it an error as well. > It's still inconsistent though - calling gpiod_direction_output(NULL); > will return 0 and then you get an error when you do > gpiod_get_direction(NULL). I don't have a good solution though. Yes, and this is the best what we can have. Because the real code may rely on the returned value and they should be really aware on the returned values in some cases. -- With Best Regards, Andy Shevchenko