From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99B65C83F3E for ; Mon, 4 Sep 2023 12:46:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352982AbjIDMqF (ORCPT ); Mon, 4 Sep 2023 08:46:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235031AbjIDMp5 (ORCPT ); Mon, 4 Sep 2023 08:45:57 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0AD1ACD5; Mon, 4 Sep 2023 05:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1693831553; x=1725367553; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=Wa35J9ZX/nel6BiikunBPw+XkZUx/f4ld1V2g3fh7Q0=; b=j9nsnUmGoxmRJ4UVyJmMH2wnX1LdzPp39Ew0nQVO8yG7viDQqLtaDjjs ScnSzpPyUokyOcgOq6rnPYqPAfaWRDaLw83vqhyK9Y8VIF/B0+YHc6dua 3lQcweXx1gmzP5x7EptrgiQYzBo2q9Q7DYEKkQTCZeCdjydlzJL3+ue2w zbGPH6mrfuIrVJe2Y5p3yEe1ch13sCR8jKtqcgrKG0F3XBX48KIWFgnz8 a4Vhf51k8sxssFNiCMA8CS87VqGI2niYbm+1cz7O6awt3MaqCmcGFin23 SOxseavOGXtSy+TzGXWvtFn8D9KY+jRQG5xDggKIDKwQbTi9O5bgRQs84 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10823"; a="407589426" X-IronPort-AV: E=Sophos;i="6.02,226,1688454000"; d="scan'208";a="407589426" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Sep 2023 05:45:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10823"; a="806251547" X-IronPort-AV: E=Sophos;i="6.02,226,1688454000"; d="scan'208";a="806251547" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga008.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Sep 2023 05:45:50 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qd8xf-006QSG-2q; Mon, 04 Sep 2023 15:45:47 +0300 Date: Mon, 4 Sep 2023 15:45:47 +0300 From: Andy Shevchenko To: Bartosz Golaszewski Cc: Linus Walleij , Andrew Jeffery , linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Bartosz Golaszewski Subject: Re: [PATCH] gpiolib: unexport gpiod_set_transitory() Message-ID: References: <20230903190657.12393-1-brgl@bgdev.pl> 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 04, 2023 at 01:32:38PM +0200, Bartosz Golaszewski wrote: > On Mon, Sep 4, 2023 at 1:19 PM Andy Shevchenko > wrote: ... > This is still inconsistent with the rest of the public symbols - > especially those in gpio/driver.h. My long-term plan - before making > locking great again - is to limit the usage of any gpiochip_ symbols > to GPIO providers (as the chip is not guaranteed to be valid, unlike > gpio_device) and provide a bunch of gpio_device_ or gpiodev_ > interfaces for use by those who *really* need it. Now am I going to > make up two distinct prefixes for public and non-public APIs? That > will be even more confusing IMO. > > Just like in C++ you don't make up special names for public vs private > methods except for some deranged coding styles that also require you > to name arguments like "in_foo" and "out_bar". Yeah, I understand your point of view on this, but as I said "disagree and commit" (used to be corporate value at some point :-). On my side I criticized and proposed... It's your turn what to do with that, I'm not insisting on my way, I'm just telling I don't like yours, but I will survive, no hard feelings :-) -- With Best Regards, Andy Shevchenko