From: Andy Shevchenko <andy.shevchenko@gmail.com> To: Sai Krishna Potthuri <lakshmis@xilinx.com> Cc: Linus Walleij <linus.walleij@linaro.org>, Rob Herring <robh+dt@kernel.org>, Michal Simek <michals@xilinx.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, devicetree <devicetree@vger.kernel.org>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, git <git@xilinx.com>, "saikrishna12468@gmail.com" <saikrishna12468@gmail.com> Subject: Re: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support Date: Mon, 26 Apr 2021 17:04:42 +0300 [thread overview] Message-ID: <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com> (raw) In-Reply-To: <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri <lakshmis@xilinx.com> wrote: > > From: Andy Shevchenko <andy.shevchenko@gmail.com> > > Sent: Friday, April 23, 2021 9:24 PM > > On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri > > <lakshmi.sai.krishna.potthuri@xilinx.com> wrote: ... > > > +config PINCTRL_ZYNQMP > > > + tristate "Pinctrl driver for Xilinx ZynqMP" > > > + depends on ZYNQMP_FIRMWARE > > > + select PINMUX > > > + select GENERIC_PINCONF > > > + default ZYNQMP_FIRMWARE > > > + help > > > + This selects the pinctrl driver for Xilinx ZynqMP platform. > > > + This driver will query the pin information from the firmware > > > + and allow configuring the pins. > > > + Configuration can include the mux function to select on those > > > + pin(s)/group(s), and various pin configuration parameters > > > + such as pull-up, slew rate, etc. > > > > Missed module name. > Is this (module name) a configuration option in Kconfig? It's a text in a free form that sheds light on how the module will be named in case the user will choose "m". ... > > > + * Copyright (C) 2020 Xilinx, Inc. > > > > 2021? > Couple of versions for this patch series sent in 2020, hence maintaining > the same. > Is it like we maintain the year when this patch series is applied, which is > 2021? 2020, 2021 sounds okay as well. ... > > > + if (pin >= zynqmp_desc.npins) > > > + return -EOPNOTSUPP; > > > > Is it possible? > This is a safe check. I.o.w. dead code, right? > Pin information will get from dt files/Xilinx firmware (query pin information > for a group)/user application and there are chances of getting wrong pin. I'm not sure I understand this. How comes that pin control core will ask for a pin higher than npins? ... > > > + ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg); > > > + if (arg != PM_PINCTRL_BIAS_PULL_UP) > > > + return -EINVAL; > > > > Error code being shadowed. Instead check it here properly. > Are you mentioning the case where ret is also a non-zero? > If yes, then I will update this check to > if (!ret && arg != PM_PINCTRL_BIAS_PULL_UP) > return -EINVAL; No, this is wrong in the same way. > ret non-zero case, we are handling at the end of switch case. I meant that you need to pass the real return code to the (upper) caller. Ditto for all other cases (mentioned and not mentioned) ... > > > + ret = -EOPNOTSUPP; > > > > Isn't it ENOTSUP for all cases here? > Giving 'Operation Not Supported (EOPNOTSUPP)' error, when > driver gets a request for unsupported pin or configuration. > Can you please elaborate your question if I didn't answer properly. The pin control subsystem along with the GPIO library are using -ENOTSUPP error code for internal operations. EOPNOTSUPP is the one that should be returned to user space. Is it the case here? ... > > > +}; > > > > > + > > > > Ditto. > I see some drivers are maintaining the extra line in above two cases. > We shouldn't maintain extra line after struct declaration? What's the point to add more blank lines where they won't add any value? > > > +module_platform_driver(zynqmp_pinctrl_driver); -- With Best Regards, Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andy.shevchenko@gmail.com> To: Sai Krishna Potthuri <lakshmis@xilinx.com> Cc: Linus Walleij <linus.walleij@linaro.org>, Rob Herring <robh+dt@kernel.org>, Michal Simek <michals@xilinx.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, devicetree <devicetree@vger.kernel.org>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, git <git@xilinx.com>, "saikrishna12468@gmail.com" <saikrishna12468@gmail.com> Subject: Re: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support Date: Mon, 26 Apr 2021 17:04:42 +0300 [thread overview] Message-ID: <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com> (raw) In-Reply-To: <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri <lakshmis@xilinx.com> wrote: > > From: Andy Shevchenko <andy.shevchenko@gmail.com> > > Sent: Friday, April 23, 2021 9:24 PM > > On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri > > <lakshmi.sai.krishna.potthuri@xilinx.com> wrote: ... > > > +config PINCTRL_ZYNQMP > > > + tristate "Pinctrl driver for Xilinx ZynqMP" > > > + depends on ZYNQMP_FIRMWARE > > > + select PINMUX > > > + select GENERIC_PINCONF > > > + default ZYNQMP_FIRMWARE > > > + help > > > + This selects the pinctrl driver for Xilinx ZynqMP platform. > > > + This driver will query the pin information from the firmware > > > + and allow configuring the pins. > > > + Configuration can include the mux function to select on those > > > + pin(s)/group(s), and various pin configuration parameters > > > + such as pull-up, slew rate, etc. > > > > Missed module name. > Is this (module name) a configuration option in Kconfig? It's a text in a free form that sheds light on how the module will be named in case the user will choose "m". ... > > > + * Copyright (C) 2020 Xilinx, Inc. > > > > 2021? > Couple of versions for this patch series sent in 2020, hence maintaining > the same. > Is it like we maintain the year when this patch series is applied, which is > 2021? 2020, 2021 sounds okay as well. ... > > > + if (pin >= zynqmp_desc.npins) > > > + return -EOPNOTSUPP; > > > > Is it possible? > This is a safe check. I.o.w. dead code, right? > Pin information will get from dt files/Xilinx firmware (query pin information > for a group)/user application and there are chances of getting wrong pin. I'm not sure I understand this. How comes that pin control core will ask for a pin higher than npins? ... > > > + ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg); > > > + if (arg != PM_PINCTRL_BIAS_PULL_UP) > > > + return -EINVAL; > > > > Error code being shadowed. Instead check it here properly. > Are you mentioning the case where ret is also a non-zero? > If yes, then I will update this check to > if (!ret && arg != PM_PINCTRL_BIAS_PULL_UP) > return -EINVAL; No, this is wrong in the same way. > ret non-zero case, we are handling at the end of switch case. I meant that you need to pass the real return code to the (upper) caller. Ditto for all other cases (mentioned and not mentioned) ... > > > + ret = -EOPNOTSUPP; > > > > Isn't it ENOTSUP for all cases here? > Giving 'Operation Not Supported (EOPNOTSUPP)' error, when > driver gets a request for unsupported pin or configuration. > Can you please elaborate your question if I didn't answer properly. The pin control subsystem along with the GPIO library are using -ENOTSUPP error code for internal operations. EOPNOTSUPP is the one that should be returned to user space. Is it the case here? ... > > > +}; > > > > > + > > > > Ditto. > I see some drivers are maintaining the extra line in above two cases. > We shouldn't maintain extra line after struct declaration? What's the point to add more blank lines where they won't add any value? > > > +module_platform_driver(zynqmp_pinctrl_driver); -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-26 14:05 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-22 8:29 [PATCH v6 0/3] Add ZynqMP pinctrl driver Sai Krishna Potthuri 2021-04-22 8:29 ` Sai Krishna Potthuri 2021-04-22 8:30 ` [PATCH v6 1/3] firmware: xilinx: Add pinctrl support Sai Krishna Potthuri 2021-04-22 8:30 ` Sai Krishna Potthuri 2021-04-22 8:30 ` [PATCH v6 2/3] dt-bindings: pinctrl: Add binding for ZynqMP pinctrl driver Sai Krishna Potthuri 2021-04-22 8:30 ` Sai Krishna Potthuri 2021-04-22 8:30 ` [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support Sai Krishna Potthuri 2021-04-22 8:30 ` Sai Krishna Potthuri 2021-04-22 16:39 ` kernel test robot 2021-04-23 15:53 ` Andy Shevchenko 2021-04-23 15:53 ` Andy Shevchenko 2021-04-26 13:20 ` Sai Krishna Potthuri 2021-04-26 13:20 ` Sai Krishna Potthuri 2021-04-26 14:04 ` Andy Shevchenko [this message] 2021-04-26 14:04 ` Andy Shevchenko 2021-04-27 7:23 ` Michal Simek 2021-04-27 7:23 ` Michal Simek 2021-04-27 7:31 ` Andy Shevchenko 2021-04-27 7:31 ` Andy Shevchenko 2021-04-27 7:38 ` Michal Simek 2021-04-27 7:38 ` Michal Simek 2021-04-27 8:39 ` Andy Shevchenko 2021-04-27 8:39 ` Andy Shevchenko 2021-04-27 9:59 ` Michal Simek 2021-04-27 9:59 ` Michal Simek 2021-04-27 14:04 ` Andy Shevchenko 2021-04-27 14:04 ` Andy Shevchenko 2021-04-28 5:33 ` Sai Krishna Potthuri 2021-04-28 5:33 ` Sai Krishna Potthuri 2021-05-11 12:38 ` Sai Krishna Potthuri 2021-05-11 12:38 ` Sai Krishna Potthuri 2021-06-17 6:37 ` Sai Krishna Potthuri 2021-06-17 6:37 ` Sai Krishna Potthuri 2021-06-17 7:18 ` Andy Shevchenko 2021-06-17 7:18 ` Andy Shevchenko 2021-06-17 7:31 ` Greg Kroah-Hartman 2021-06-17 7:31 ` Greg Kroah-Hartman 2021-04-22 9:13 ` [PATCH v6 0/3] Add ZynqMP pinctrl driver Linus Walleij 2021-04-22 9:13 ` Linus Walleij 2021-04-23 15:54 ` Andy Shevchenko 2021-04-23 15:54 ` Andy Shevchenko 2021-04-29 14:21 ` Linus Walleij 2021-04-29 14:21 ` Linus Walleij 2021-04-29 14:32 ` Sai Krishna Potthuri 2021-04-29 14:32 ` Sai Krishna Potthuri
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com' \ --to=andy.shevchenko@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=git@xilinx.com \ --cc=gregkh@linuxfoundation.org \ --cc=lakshmis@xilinx.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=michals@xilinx.com \ --cc=robh+dt@kernel.org \ --cc=saikrishna12468@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.