Received-SPF: pass (google.com: domain of linux-kernel+bounces-133327-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Fri, 5 Apr 2024 19:16:56 +0300
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>, Peng Fan <peng.fan@nxp.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	"brgl@bgdev.pl" <brgl@bgdev.pl>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] pinctrl: pinconf-generic: check error value EOPNOTSUPP
Message-ID: <ZhAj-LZWv4M3vS6F@smile.fi.intel.com>
References: <20240401141031.3106216-1-peng.fan@oss.nxp.com>
 <CACRpkdZAuNXGyg2wwYcQG4oO9w7jPS6vj4Vt0=kqX5fJ+QpNmw@mail.gmail.com>
 <Zg7dwcFz5eD7Am2u@smile.fi.intel.com>
 <DU0PR04MB941777DA29D70013342721A788032@DU0PR04MB9417.eurprd04.prod.outlook.com>
 <ZhAa3NPO19mINYJP@smile.fi.intel.com>
 <ZhAdB4T7sTa2Z7db@bogus>
 <ZhAhcI3g4xJ1ANzu@pluto>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ZhAhcI3g4xJ1ANzu@pluto>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

On Fri, Apr 05, 2024 at 05:06:08PM +0100, Cristian Marussi wrote:
> On Fri, Apr 05, 2024 at 04:47:19PM +0100, Sudeep Holla wrote:
> > On Fri, Apr 05, 2024 at 06:38:04PM +0300, Andy Shevchenko wrote:
> > > On Fri, Apr 05, 2024 at 02:13:28AM +0000, Peng Fan wrote:
> > > > > On Thu, Apr 04, 2024 at 01:44:50PM +0200, Linus Walleij wrote:
> > > > > > On Mon, Apr 1, 2024 at 4:02 PM Peng Fan (OSS) <peng.fan@oss.nxp.com>
> > > > > wrote:

..

> > > > > > >                         ret = pin_config_get_for_pin(pctldev, pin, &config);
> > > > > > >                 /* These are legal errors */
> > > > > > > -               if (ret == -EINVAL || ret == -ENOTSUPP)
> > > > > > > +               if (ret == -EINVAL || ret == -ENOTSUPP || ret ==
> > > > > > > + -EOPNOTSUPP)
> > > > > >
> > > > > > TBH it's a bit odd to call an in-kernel API such as
> > > > > > pin_config_get_for_pin() and get -EOPNOTSUPP back. But it's not like I care
> > > > > a lot, so patch applied.
> > > > >
> > > > > Hmm... I would like actually to get this being consistent. The documentation
> > > > > explicitly says that in-kernel APIs uses Linux error code and not POSIX one.
> > > >
> > > > Would you please share me the documentation?
> > >
> > > Sure.
> > > https://elixir.bootlin.com/linux/latest/source/include/linux/pinctrl/pinconf.h#L24
> > > https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib.c#L2825
> > > https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib.c#L2845
> > >
> > > I admit that this is not the best documented, feel free to produce a proper
> > > documentation.
> > 
> > Ah OK, my bad. I assumed you were referring to the entire kernel tree and
> > not just GPIO/pinux. Sorry for that.
> 
> ... from this thread, my understanding too was that this forbidden usage of
> POSIX errors for in-kernel API was general to any subsystem...so the ask
> for docs about this...
> 
> > > > > This check opens a Pandora box.
> > > > >
> > > > > FWIW, it just like dozen or so drivers that needs to be fixed, I prefer to have
> > > > > them being moved to ENOTSUPP, rather this patch.
> > > >
> > > > I see many patches convert to use EOPNOTSUPP by checking git log.
> > >
> > > How is that related? You mean for GPIO/pin control drivers?
> > >
> > > > And checkpatch.pl reports warning for using ENOTSUPP.
> > >
> > > checkpatch has false-positives, this is just one of them.
> > 
> > Fair enough.
> >
> > > > BTW: is there any issue if using EOPNOTSUPP here?
> > >
> > > Yes. we don't want to be inconsistent. Using both in one subsystem is asking
> > > for troubles. If you want EOPNOTSUPP, please convert *all* users and drop
> > > ENOTSUPP completely (series out of ~100+ patches I believe :-), which probably
> > > will be not welcome).
> > 
> > Well, I don't agree with that 100% now since this is GPIO/pinmux sub-system
> > practice only. What if we change the source/root error cause(SCMI) in this
> > case and keep GPIO/pinmux happy today but tomorrow when this needs to be
> > used in some other subsystem which uses EOPNOTSUPP by default/consistently.
> > Now how do we address that then, hence I mentioned I am not 100% in agreement
> > now while I was before knowing that this is GPIO/pinmux strategy.
> > 
> > I don't know how to proceed now ????.
> 
> from checkpatch.pl:
> 
> # ENOTSUPP is not a standard error code and should be avoided in new patches.    
> # Folks usually mean EOPNOTSUPP (also called ENOTSUP), when they type ENOTSUPP.  
> # Similarly to ENOSYS warning a small number of false positives is expected.     
>  
> ...so it seems to me that the this is NOT a false positive BUT Pinctrl/GPIO
> subsystem is an exception in these regards, since this is what is explcitly
> state in checkpatch comments AND there is no generalized doc on this....

Checkpatch is false positive _in this case_.
And in practice it's not the first and not the last false positive by checkpatch.
Again, checkpatch is a recommendation, not a letter of law. Documentation is.

> ....but twe can happily oblige to Pinctrl expectations by remapping to ENOTSUPP
> in the pinctrl protocol layer or driver...just I won't certainly do that at the
> SCMI core layer at all at this point...as Sudeep said ...especially because there
> is NO generalized docs for the above ban of POSIX errors for in-Linux kernel API...

There is no ban, we use POSIX error codes heavily in kernel.

If you think GPIO/pin control has a flaw, send patches. I'm not a maintainer there,
perhaps conversion of all GPIO and pin control drivers to POSIX error code will be
warmly welcome, who knows.

But before that, we want to have ENOTSUPP from callbacks that are used in
GPIO/pin control drivers for the sake of consistency.

For that, I'm going to submit fixes to Intel PMIC GPIO drivers soon.

-- 
With Best Regards,
Andy Shevchenko