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 X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5A5FC433E2 for ; Mon, 29 Mar 2021 15:26:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B2CE661932 for ; Mon, 29 Mar 2021 15:26:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231342AbhC2P0V (ORCPT ); Mon, 29 Mar 2021 11:26:21 -0400 Received: from mga07.intel.com ([134.134.136.100]:48469 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231346AbhC2PZx (ORCPT ); Mon, 29 Mar 2021 11:25:53 -0400 IronPort-SDR: OWG3aUqDZXmGmp0RhPPtLvjohN+t5qIajUeeRotdhuuQRLS1yALSpXptkf4BdwcViJ8y7r8kaH U9wWdlJHCPkg== X-IronPort-AV: E=McAfee;i="6000,8403,9938"; a="255565714" X-IronPort-AV: E=Sophos;i="5.81,288,1610438400"; d="scan'208";a="255565714" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2021 08:25:52 -0700 IronPort-SDR: rq1xC6B+ZNCfNwvKuTjI3Ukn5oSNFgV8aADsVbnNANwb9n0N8pt6HOBTo7QeKYM1Sj+NXdP4wx scvTUSMC6FqQ== X-IronPort-AV: E=Sophos;i="5.81,288,1610438400"; d="scan'208";a="606413062" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2021 08:25:49 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lQtly-00H3Yz-VK; Mon, 29 Mar 2021 18:25:46 +0300 Date: Mon, 29 Mar 2021 18:25:46 +0300 From: Andy Shevchenko To: Joe Perches Cc: Matti Vaittinen , Jakub Kicinski , Matti Vaittinen , Linus Walleij , Bartosz Golaszewski , Stephen Boyd , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List Subject: Re: [PATCH 2/2] gpiolib: Allow drivers to return EOPNOTSUPP from config Message-ID: References: <1ceb7dc5c2fa376470ab9274020fddf1c2f1584f.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ceb7dc5c2fa376470ab9274020fddf1c2f1584f.camel@perches.com> 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, Mar 29, 2021 at 08:08:52AM -0700, Joe Perches wrote: > On Mon, 2021-03-29 at 14:59 +0300, Andy Shevchenko wrote: > > On Mon, Mar 29, 2021 at 2:43 PM Matti Vaittinen > > wrote: > > > > > > The checkpacth instructs to switch from ENOSUPP to EOPNOTSUPP. > > > > WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP > > > > > > Make the gpiolib allow drivers to return both so driver developers > > > can avoid one of the checkpatch complaints. > > > > Internally we are fine to use the ENOTSUPP. > > Checkpatch false positives there. > > > > I doubt we need this change. Rather checkpatch should rephrase this to > > point out that this is only applicable to _user-visible_ error path. > > Cc'ed Joe. > > Adding CC for Jakub Kicinski who added that particular rule/test. > > And the output message report of the rule is merely a suggestion indicating > a preference. It's always up to an individual to accept/reject. > > At best, perhaps wordsmithing the checkpatch message might be an OK option. Thanks, Joe! Jakub, what do you think? -- With Best Regards, Andy Shevchenko