[PATCH v3 3/4] gpio: imx-rpmsg: add imx-rpmsg GPIO driver
Shenwei Wang
shenwei.wang at nxp.com
Mon Oct 13 11:41:10 PDT 2025
> -----Original Message-----
> From: Andrew Lunn <andrew at lunn.ch>
> Sent: Monday, October 13, 2025 11:56 AM
> To: Shenwei Wang <shenwei.wang at nxp.com>
> Cc: Bjorn Andersson <andersson at kernel.org>; Mathieu Poirier
> <mathieu.poirier at linaro.org>; Rob Herring <robh at kernel.org>; Krzysztof
> Kozlowski <krzk+dt at kernel.org>; Conor Dooley <conor+dt at kernel.org>; Shawn
> Guo <shawnguo at kernel.org>; Sascha Hauer <s.hauer at pengutronix.de>; Linus
> Walleij <linus.walleij at linaro.org>; Bartosz Golaszewski <brgl at bgdev.pl>;
> Pengutronix Kernel Team <kernel at pengutronix.de>; Fabio Estevam
> <festevam at gmail.com>; Peng Fan <peng.fan at nxp.com>; linux-
> remoteproc at vger.kernel.org; devicetree at vger.kernel.org; imx at lists.linux.dev;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; dl-linux-imx
> <linux-imx at nxp.com>
> Subject: [EXT] Re: [PATCH v3 3/4] gpio: imx-rpmsg: add imx-rpmsg GPIO driver
> > > Notice how ENOPNOTSUPP can be 45, 122, 223, or 95. Returning
> > > EL2NSYNC or EDQUOT to user space is going to cause confusion...
> > >
> >
>
> > I think we should just follow the definitions in
> > include/uapi/asm-generic/errno.h, right?
>
> No.
>
> Try a make for mips, and look at includes you end up with. You will find it goes
> something like:
>
> # 1 "./arch/mips/include/asm/errno.h" 1
> # 11 "./arch/mips/include/asm/errno.h"
> # 1 "./arch/mips/include/uapi/asm/errno.h" 1 # 16
> "./arch/mips/include/uapi/asm/errno.h"
> # 1 "./include/uapi/asm-generic/errno-base.h" 1 # 17
> "./arch/mips/include/uapi/asm/errno.h" 2
>
> and this results in
>
> #define EOPNOTSUPP 122 /* Operation not supported on transport
> endpoint */
>
> not what you get from asm-generic/errno.h:
>
> #define EOPNOTSUPP 95 /* Operation not supported on transport endpoint
> */
>
That shouldn't be an issue in this case.
For instance, if we define the error code as 1 in the return message, the driver will interpret it and just return -EOPNOTSUPP, regardless of the architecture.
Thanks,
Shenwei
> Andrew
More information about the linux-arm-kernel
mailing list