Received-SPF: pass (google.com: domain of linux-kernel+bounces-133307-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 5 Apr 2024 17:06:08 +0100
From: Cristian Marussi <cristian.marussi@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Andy Shevchenko <andriy.shevchenko@intel.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: <ZhAhcI3g4xJ1ANzu@pluto>
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>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ZhAdB4T7sTa2Z7db@bogus>

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....

...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...

Thanks,
Cristian