[v6,3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

Commit Message

Sai Krishna Potthuri April 22, 2021, 8:30 a.m. UTC

Adding pinctrl driver for Xilinx ZynqMP platform.
This driver queries pin information from firmware and registers
pin control accordingly.

Signed-off-by: Sai Krishna Potthuri <[e-mail]>
---
 drivers/pinctrl/Kconfig          |  14 +
 drivers/pinctrl/Makefile         |   1 +
 drivers/pinctrl/pinctrl-zynqmp.c | 906 +++++++++++++++++++++++++++++++
 3 files changed, 921 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c

Comments

Andy Shevchenko April 23, 2021, 3:53 p.m. UTC | #1

On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
<[e-mail]> wrote:
>
> Adding pinctrl driver for Xilinx ZynqMP platform.
> This driver queries pin information from firmware and registers
> pin control accordingly.
>
> Signed-off-by: Sai Krishna Potthuri <[e-mail]>

You may reduce the number of LOCs by joining some lines. See below.

...

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

...

> +/*
> + * ZynqMP pin controller
> + *
> + * Copyright (C) 2020 Xilinx, Inc.

2021?

> + *
> + * Sai Krishna Potthuri <[e-mail]>
> + * Rajan Vaja <[e-mail]>
> + */

...

> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/firmware/xlnx-zynqmp.h>

...

> +static int zynqmp_pinconf_cfg_get(struct pinctrl_dev *pctldev,
> +                                 unsigned int pin,
> +                                 unsigned long *config)
> +{
> +       unsigned int arg, param = pinconf_to_config_param(*config);
> +       int ret;

> +       if (pin >= zynqmp_desc.npins)
> +               return -EOPNOTSUPP;

Is it possible?

> +       switch (param) {
> +       case PIN_CONFIG_SLEW_RATE:
> +               param = PM_PINCTRL_CONFIG_SLEW_RATE;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               break;
> +       case PIN_CONFIG_BIAS_PULL_UP:
> +               param = PM_PINCTRL_CONFIG_PULL_CTRL;

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

> +               arg = 1;
> +               break;
> +       case PIN_CONFIG_BIAS_PULL_DOWN:
> +               param = PM_PINCTRL_CONFIG_PULL_CTRL;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               if (arg != PM_PINCTRL_BIAS_PULL_DOWN)
> +                       return -EINVAL;

Ditto.

> +               arg = 1;
> +               break;
> +       case PIN_CONFIG_BIAS_DISABLE:
> +               param = PM_PINCTRL_CONFIG_BIAS_STATUS;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               if (arg != PM_PINCTRL_BIAS_DISABLE)
> +                       return -EINVAL;

Ditto.

> +               arg = 1;
> +               break;
> +       case PIN_CONFIG_POWER_SOURCE:
> +               param = PM_PINCTRL_CONFIG_VOLTAGE_STATUS;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               break;
> +       case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> +               param = PM_PINCTRL_CONFIG_SCHMITT_CMOS;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               break;
> +       case PIN_CONFIG_DRIVE_STRENGTH:
> +               param = PM_PINCTRL_CONFIG_DRIVE_STRENGTH;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               switch (arg) {
> +               case PM_PINCTRL_DRIVE_STRENGTH_2MA:
> +                       arg = DRIVE_STRENGTH_2MA;
> +                       break;
> +               case PM_PINCTRL_DRIVE_STRENGTH_4MA:
> +                       arg = DRIVE_STRENGTH_4MA;
> +                       break;
> +               case PM_PINCTRL_DRIVE_STRENGTH_8MA:
> +                       arg = DRIVE_STRENGTH_8MA;
> +                       break;
> +               case PM_PINCTRL_DRIVE_STRENGTH_12MA:
> +                       arg = DRIVE_STRENGTH_12MA;
> +                       break;
> +               default:
> +                       /* Invalid drive strength */
> +                       dev_warn(pctldev->dev,
> +                                "Invalid drive strength for pin %d\n",
> +                                pin);
> +                       return -EINVAL;
> +               }
> +               break;
> +       default:
> +               ret = -EOPNOTSUPP;
> +               break;
> +       }
> +
> +       if (ret)
> +               return ret;
> +
> +       param = pinconf_to_config_param(*config);
> +       *config = pinconf_to_config_packed(param, arg);
> +
> +       return 0;
> +}

...

> +                       ret = -EOPNOTSUPP;

Isn't it ENOTSUP for all cases here?

...

> +       ret = zynqmp_pm_query_data(qdata, payload);
> +       if (ret)
> +               return ret;
> +
> +       *ngroups = payload[1];
> +

> +       return ret;

return 0;

...

> + * Query firmware to get group IDs for each function. Firmware returns
> + * group IDs. Based on group index for the function, group names in

on the group

> + * the function are stored. For example, the first group in "eth0" function
> + * is named as "eth0_0" and second group as "eth0_1" and so on.

and the second

> + *
> + * Based on the group ID received from the firmware, function stores name of
> + * the group for that group ID. For example, if "eth0" first group ID
> + * is x, groups[x] name will be stored as "eth0_0".
> + *
> + * Once done for each function, each function would have its group names
> + * and each groups would also have their names.

each group

...

> +done:
> +       func->groups = fgroups;
> +
> +       return ret;

return 0; ?

...

> +       *nfuncs = payload[1];
> +
> +       return ret;

Ditto.

...

> +       ret = zynqmp_pm_query_data(qdata, payload);
> +       if (ret)
> +               return ret;
> +
> +       memcpy(groups, &payload[1], PINCTRL_GET_PIN_GROUPS_RESP_LEN);
> +
> +       return ret;

Ditto.

...

> + * Query firmware to get groups available for the given pin.
> + * Based on the firmware response(group IDs for the pin), add
> + * pin number to the respective group's pin array.
> + *
> + * Once all pins are queries, each groups would have its number

each group

> + * of pins and pin numbers data.

...

> +       return ret;

return 0;

...

> + * Query number of functions and number of function groups (number
> + * of groups in given function) to allocate required memory buffers

in the given

> + * for functions and groups. Once buffers are allocated to store
> + * functions and groups data, query and store required information
> + * (number of groups and group names for each function, number of
> + * pins and pin numbers for each group).

...

> +       pctrl->funcs = funcs;
> +       pctrl->groups = groups;
> +
> +       return ret;

return 0;

...

> +       *npins = payload[1];
> +
> +       return ret;

Ditto.

...

> +               dev_err(&pdev->dev, "pin desc prepare fail with %d\n",
> +                       ret);

One line.

...

> +               dev_err(&pdev->dev, "function info prepare fail with %d\n",
> +                       ret);

Ditto.

...

> +       pctrl->pctrl = pinctrl_register(&zynqmp_desc, &pdev->dev, pctrl);

devm_pinctrl_register()

> +       if (IS_ERR(pctrl->pctrl))
> +               return PTR_ERR(pctrl->pctrl);

...

> +};

> +

Extra blank line.

> +MODULE_DEVICE_TABLE(of, zynqmp_pinctrl_of_match);

...

> +};

> +

Ditto.

> +module_platform_driver(zynqmp_pinctrl_driver);

Sai Krishna Potthuri April 26, 2021, 1:20 p.m. UTC | #2

Hi Andy Shevchenko,

Thanks for the review.

> -----Original Message-----
> From: Andy Shevchenko <[e-mail]>
> Sent: Friday, April 23, 2021 9:24 PM
> To: Sai Krishna Potthuri <[e-mail]>
> Cc: Linus Walleij <[e-mail]>; Rob Herring
> <[e-mail]>; Michal Simek <[e-mail]>; Greg Kroah-
> Hartman <[e-mail]>; linux-arm Mailing List <linux-arm-
> [e-mail]>; Linux Kernel Mailing List <linux-
> [e-mail]>; devicetree <[e-mail]>; open
> list:GPIO SUBSYSTEM <[e-mail]>; git <[e-mail]>;
> [e-mail]
> Subject: Re: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> <[e-mail]> wrote:
> >
> > Adding pinctrl driver for Xilinx ZynqMP platform.
> > This driver queries pin information from firmware and registers pin
> > control accordingly.
> >
> > Signed-off-by: Sai Krishna Potthuri
> > <[e-mail]>
> 
> You may reduce the number of LOCs by joining some lines. See below.
> 
> ...
> 
> > +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?
> 
> ...
> 
> > +/*
> > + * ZynqMP pin controller
> > + *
> > + * 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?
> 
> > + *
> > + * Sai Krishna Potthuri <[e-mail]>
> > + * Rajan Vaja <[e-mail]> */
> 
> ...
> 
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/of_address.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/firmware/xlnx-zynqmp.h>
> 
> ...
> 
> > +static int zynqmp_pinconf_cfg_get(struct pinctrl_dev *pctldev,
> > +                                 unsigned int pin,
> > +                                 unsigned long *config)
> > +{
> > +       unsigned int arg, param = pinconf_to_config_param(*config);
> > +       int ret;
> 
> > +       if (pin >= zynqmp_desc.npins)
> > +               return -EOPNOTSUPP;
> 
> Is it possible?
This is a safe check.
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.
> 
> > +       switch (param) {
> > +       case PIN_CONFIG_SLEW_RATE:
> > +               param = PM_PINCTRL_CONFIG_SLEW_RATE;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               break;
> > +       case PIN_CONFIG_BIAS_PULL_UP:
> > +               param = PM_PINCTRL_CONFIG_PULL_CTRL;
> 
> > +               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;
ret non-zero case, we are handling at the end of switch case.
> 
> > +               arg = 1;
> > +               break;
> > +       case PIN_CONFIG_BIAS_PULL_DOWN:
> > +               param = PM_PINCTRL_CONFIG_PULL_CTRL;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               if (arg != PM_PINCTRL_BIAS_PULL_DOWN)
> > +                       return -EINVAL;
> 
> Ditto.
Same as above.
> 
> > +               arg = 1;
> > +               break;
> > +       case PIN_CONFIG_BIAS_DISABLE:
> > +               param = PM_PINCTRL_CONFIG_BIAS_STATUS;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               if (arg != PM_PINCTRL_BIAS_DISABLE)
> > +                       return -EINVAL;
> 
> Ditto.
Same as above.
> 
> > +               arg = 1;
> > +               break;
> > +       case PIN_CONFIG_POWER_SOURCE:
> > +               param = PM_PINCTRL_CONFIG_VOLTAGE_STATUS;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               break;
> > +       case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> > +               param = PM_PINCTRL_CONFIG_SCHMITT_CMOS;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               break;
> > +       case PIN_CONFIG_DRIVE_STRENGTH:
> > +               param = PM_PINCTRL_CONFIG_DRIVE_STRENGTH;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               switch (arg) {
> > +               case PM_PINCTRL_DRIVE_STRENGTH_2MA:
> > +                       arg = DRIVE_STRENGTH_2MA;
> > +                       break;
> > +               case PM_PINCTRL_DRIVE_STRENGTH_4MA:
> > +                       arg = DRIVE_STRENGTH_4MA;
> > +                       break;
> > +               case PM_PINCTRL_DRIVE_STRENGTH_8MA:
> > +                       arg = DRIVE_STRENGTH_8MA;
> > +                       break;
> > +               case PM_PINCTRL_DRIVE_STRENGTH_12MA:
> > +                       arg = DRIVE_STRENGTH_12MA;
> > +                       break;
> > +               default:
> > +                       /* Invalid drive strength */
> > +                       dev_warn(pctldev->dev,
> > +                                "Invalid drive strength for pin %d\n",
> > +                                pin);
> > +                       return -EINVAL;
> > +               }
> > +               break;
> > +       default:
> > +               ret = -EOPNOTSUPP;
> > +               break;
> > +       }
> > +
> > +       if (ret)
> > +               return ret;
> > +
> > +       param = pinconf_to_config_param(*config);
> > +       *config = pinconf_to_config_packed(param, arg);
> > +
> > +       return 0;
> > +}
> 
> ...
> 
> > +                       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.
> 
> ...
> 
> > +       ret = zynqmp_pm_query_data(qdata, payload);
> > +       if (ret)
> > +               return ret;
> > +
> > +       *ngroups = payload[1];
> > +
> 
> > +       return ret;
> 
> return 0;
I will fix.
> 
> ...
> 
> > + * Query firmware to get group IDs for each function. Firmware returns
> > + * group IDs. Based on group index for the function, group names in
> 
> on the group
> 
> > + * the function are stored. For example, the first group in "eth0" function
> > + * is named as "eth0_0" and second group as "eth0_1" and so on.
> 
> and the second
> 
> > + *
> > + * Based on the group ID received from the firmware, function stores
> name of
> > + * the group for that group ID. For example, if "eth0" first group ID
> > + * is x, groups[x] name will be stored as "eth0_0".
> > + *
> > + * Once done for each function, each function would have its group names
> > + * and each groups would also have their names.
> 
> each group
I will fix all the above.
> 
> ...
> 
> > +done:
> > +       func->groups = fgroups;
> > +
> > +       return ret;
> 
> return 0; ?
> 
> ...
> 
> > +       *nfuncs = payload[1];
> > +
> > +       return ret;
> 
> Ditto.
> 
> ...
> 
> > +       ret = zynqmp_pm_query_data(qdata, payload);
> > +       if (ret)
> > +               return ret;
> > +
> > +       memcpy(groups, &payload[1],
> PINCTRL_GET_PIN_GROUPS_RESP_LEN);
> > +
> > +       return ret;
> 
> Ditto.
> 
> ...
> 
> > + * Query firmware to get groups available for the given pin.
> > + * Based on the firmware response(group IDs for the pin), add
> > + * pin number to the respective group's pin array.
> > + *
> > + * Once all pins are queries, each groups would have its number
> 
> each group
> 
> > + * of pins and pin numbers data.
> 
> ...
> 
> > +       return ret;
> 
> return 0;
> 
> ...
> 
> > + * Query number of functions and number of function groups (number
> > + * of groups in given function) to allocate required memory buffers
> 
> in the given
> 
> > + * for functions and groups. Once buffers are allocated to store
> > + * functions and groups data, query and store required information
> > + * (number of groups and group names for each function, number of
> > + * pins and pin numbers for each group).
> 
> ...
> 
> > +       pctrl->funcs = funcs;
> > +       pctrl->groups = groups;
> > +
> > +       return ret;
> 
> return 0;
> 
> ...
> 
> > +       *npins = payload[1];
> > +
> > +       return ret;
> 
> Ditto.
I will fix all the above similar comments.
> 
> ...
> 
> > +               dev_err(&pdev->dev, "pin desc prepare fail with %d\n",
> > +                       ret);
> 
> One line.
> 
> ...
> 
> > +               dev_err(&pdev->dev, "function info prepare fail with %d\n",
> > +                       ret);
> 
> Ditto.
I will fix all.
> 
> ...
> 
> > +       pctrl->pctrl = pinctrl_register(&zynqmp_desc, &pdev->dev, pctrl);
> 
> devm_pinctrl_register()
I will update.
> 
> > +       if (IS_ERR(pctrl->pctrl))
> > +               return PTR_ERR(pctrl->pctrl);
> 
> ...
> 
> > +};
> 
> > +
> 
> Extra blank line.
> 
> > +MODULE_DEVICE_TABLE(of, zynqmp_pinctrl_of_match);
> 
> ...
> 
> > +};
> 
> > +
> 
> Ditto.
I see some drivers are maintaining the extra line in above two cases.
We shouldn't maintain extra line after struct declaration?

Regards
Sai Krishna
> 
> > +module_platform_driver(zynqmp_pinctrl_driver);
> 
> --
> With Best Regards,
> Andy Shevchenko

Andy Shevchenko April 26, 2021, 2:04 p.m. UTC | #3

On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
<[e-mail]> wrote:
> > From: Andy Shevchenko <[e-mail]>
> > Sent: Friday, April 23, 2021 9:24 PM
> > On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> > <[e-mail]> 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);

Michal Simek April 27, 2021, 7:23 a.m. UTC | #4

Hi Andy,

On 4/26/21 4:04 PM, Andy Shevchenko wrote:
> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
> <[e-mail]> wrote:
>>> From: Andy Shevchenko <[e-mail]>
>>> Sent: Friday, April 23, 2021 9:24 PM
>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
>>> <[e-mail]> 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".

Is this described somewhere in documentation that module name should be
the part of symbol description? I was looking at pinctrl Kconfig and I
can't see any description like this there that's why I want to double
check.

Also if this is a rule checkpatch should be extended to checking this.

Thanks,
Michal

Andy Shevchenko April 27, 2021, 7:31 a.m. UTC | #5

On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <[e-mail]> wrote:
>
> Hi Andy,
>
> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
> > On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
> > <[e-mail]> wrote:
> >>> From: Andy Shevchenko <[e-mail]>
> >>> Sent: Friday, April 23, 2021 9:24 PM
> >>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> >>> <[e-mail]> 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".
>
> Is this described somewhere in documentation that module name should be
> the part of symbol description? I was looking at pinctrl Kconfig and I
> can't see any description like this there that's why I want to double
> check.

I dunno if it is described, the group of maintainers require that for some time.
I personally found this as a good practice.

> Also if this is a rule checkpatch should be extended to checking this.

There was a discussion at some point to add a check that help
description shouldn't be less than 3 lines. Not sure what the outcome
of it.

Michal Simek April 27, 2021, 7:38 a.m. UTC | #6

Hi,

On 4/27/21 9:31 AM, Andy Shevchenko wrote:
> On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <[e-mail]> wrote:
>>
>> Hi Andy,
>>
>> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
>>> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
>>> <[e-mail]> wrote:
>>>>> From: Andy Shevchenko <[e-mail]>
>>>>> Sent: Friday, April 23, 2021 9:24 PM
>>>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
>>>>> <[e-mail]> 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".
>>
>> Is this described somewhere in documentation that module name should be
>> the part of symbol description? I was looking at pinctrl Kconfig and I
>> can't see any description like this there that's why I want to double
>> check.
> 
> I dunno if it is described, the group of maintainers require that for some time.
> I personally found this as a good practice.

I don't think it is a big deal to add it but it is a question if this
information is useful because module names should correspond target in
Makefile which can be considered as additional information.

> 
>> Also if this is a rule checkpatch should be extended to checking this.
> 
> There was a discussion at some point to add a check that help
> description shouldn't be less than 3 lines. Not sure what the outcome
> of it.

This check is likely there because I have definitely seen these messages
coming but never seen any name checking.

Thanks,
Michal

Andy Shevchenko April 27, 2021, 8:39 a.m. UTC | #7

On Tue, Apr 27, 2021 at 10:38 AM Michal Simek <[e-mail]> wrote:
> On 4/27/21 9:31 AM, Andy Shevchenko wrote:
> > On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <[e-mail]> wrote:
> >> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
> >>> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
> >>> <[e-mail]> wrote:
> >>>>> From: Andy Shevchenko <[e-mail]>
> >>>>> Sent: Friday, April 23, 2021 9:24 PM
> >>>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> >>>>> <[e-mail]> wrote:

...

> >>>>>> +       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".
> >>
> >> Is this described somewhere in documentation that module name should be
> >> the part of symbol description? I was looking at pinctrl Kconfig and I
> >> can't see any description like this there that's why I want to double
> >> check.
> >
> > I dunno if it is described, the group of maintainers require that for some time.
> > I personally found this as a good practice.
>
> I don't think it is a big deal to add it but it is a question if this
> information is useful because module names should correspond target in
> Makefile which can be considered as additional information.

For you as a *developer* — yes, for me as a *user* — no. You are
telling me something like "hey, if you want to know more you must dig
into kernel sources". No, this is not how we should treat users,
should we?


> >> Also if this is a rule checkpatch should be extended to checking this.
> >
> > There was a discussion at some point to add a check that help
> > description shouldn't be less than 3 lines. Not sure what the outcome
> > of it.
>
> This check is likely there because I have definitely seen these messages
> coming but never seen any name checking.

Yeah, it was about insisting developers to be more verbose in the help
descriptions, but the name is, as I said, an activity "de facto"
rather than "de jure". Just look around for the latest new driver
contributions (I follow IIO, I2C, SPI, GPIO, pin control) for how they
provide their help descriptions (I admit that not everybody follows
that practice).

Michal Simek April 27, 2021, 9:59 a.m. UTC | #8

On 4/27/21 10:39 AM, Andy Shevchenko wrote:
> On Tue, Apr 27, 2021 at 10:38 AM Michal Simek <[e-mail]> wrote:
>> On 4/27/21 9:31 AM, Andy Shevchenko wrote:
>>> On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <[e-mail]> wrote:
>>>> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
>>>>> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
>>>>> <[e-mail]> wrote:
>>>>>>> From: Andy Shevchenko <[e-mail]>
>>>>>>> Sent: Friday, April 23, 2021 9:24 PM
>>>>>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
>>>>>>> <[e-mail]> wrote:
> 
> ...
> 
>>>>>>>> +       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".
>>>>
>>>> Is this described somewhere in documentation that module name should be
>>>> the part of symbol description? I was looking at pinctrl Kconfig and I
>>>> can't see any description like this there that's why I want to double
>>>> check.
>>>
>>> I dunno if it is described, the group of maintainers require that for some time.
>>> I personally found this as a good practice.
>>
>> I don't think it is a big deal to add it but it is a question if this
>> information is useful because module names should correspond target in
>> Makefile which can be considered as additional information.
> 
> For you as a *developer* — yes, for me as a *user* — no. You are
> telling me something like "hey, if you want to know more you must dig
> into kernel sources". No, this is not how we should treat users,
> should we?

As I said it is not big deal but we should care about consistency on
this. Adding Joe here if we can extend checkpatch to report a warning
about it. Then it will be visible and can be checked.

>>>> Also if this is a rule checkpatch should be extended to checking this.
>>>
>>> There was a discussion at some point to add a check that help
>>> description shouldn't be less than 3 lines. Not sure what the outcome
>>> of it.
>>
>> This check is likely there because I have definitely seen these messages
>> coming but never seen any name checking.
> 
> Yeah, it was about insisting developers to be more verbose in the help
> descriptions, but the name is, as I said, an activity "de facto"
> rather than "de jure". Just look around for the latest new driver
> contributions (I follow IIO, I2C, SPI, GPIO, pin control) for how they
> provide their help descriptions (I admit that not everybody follows
> that practice).
> 

I have seen some on linux-next but really when any rule/recommendation
like this is introduced it should be more visible and checked by
standard tools (checkpatch or by bots) then people will start to do it.

Thanks,
Michal

Andy Shevchenko April 27, 2021, 2:04 p.m. UTC | #9

On Tue, Apr 27, 2021 at 12:59 PM Michal Simek <[e-mail]> wrote:
> On 4/27/21 10:39 AM, Andy Shevchenko wrote:
> > On Tue, Apr 27, 2021 at 10:38 AM Michal Simek <[e-mail]> wrote:
> >> On 4/27/21 9:31 AM, Andy Shevchenko wrote:
> >>> On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <[e-mail]> wrote:
> >>>> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
> >>>>> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
> >>>>> <[e-mail]> wrote:
> >>>>>>> From: Andy Shevchenko <[e-mail]>
> >>>>>>> Sent: Friday, April 23, 2021 9:24 PM
> >>>>>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> >>>>>>> <[e-mail]> wrote:
> >
> > ...
> >
> >>>>>>>> +       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".
> >>>>
> >>>> Is this described somewhere in documentation that module name should be
> >>>> the part of symbol description? I was looking at pinctrl Kconfig and I
> >>>> can't see any description like this there that's why I want to double
> >>>> check.
> >>>
> >>> I dunno if it is described, the group of maintainers require that for some time.
> >>> I personally found this as a good practice.
> >>
> >> I don't think it is a big deal to add it but it is a question if this
> >> information is useful because module names should correspond target in
> >> Makefile which can be considered as additional information.
> >
> > For you as a *developer* — yes, for me as a *user* — no. You are
> > telling me something like "hey, if you want to know more you must dig
> > into kernel sources". No, this is not how we should treat users,
> > should we?
>
> As I said it is not big deal but we should care about consistency on
> this. Adding Joe here if we can extend checkpatch to report a warning
> about it. Then it will be visible and can be checked.

> >>>> Also if this is a rule checkpatch should be extended to checking this.
> >>>
> >>> There was a discussion at some point to add a check that help
> >>> description shouldn't be less than 3 lines. Not sure what the outcome
> >>> of it.
> >>
> >> This check is likely there because I have definitely seen these messages
> >> coming but never seen any name checking.
> >
> > Yeah, it was about insisting developers to be more verbose in the help
> > descriptions, but the name is, as I said, an activity "de facto"
> > rather than "de jure". Just look around for the latest new driver
> > contributions (I follow IIO, I2C, SPI, GPIO, pin control) for how they
> > provide their help descriptions (I admit that not everybody follows
> > that practice).
>
> I have seen some on linux-next but really when any rule/recommendation
> like this is introduced it should be more visible and checked by
> standard tools (checkpatch or by bots) then people will start to do it.

I agree on this.

Sai Krishna Potthuri April 28, 2021, 5:33 a.m. UTC | #10

Hi Andy Shevchenko,

> -----Original Message-----
> From: Andy Shevchenko <[e-mail]>
> Sent: Monday, April 26, 2021 7:35 PM
> To: Sai Krishna Potthuri <[e-mail]>
> Cc: Linus Walleij <[e-mail]>; Rob Herring
> <[e-mail]>; Michal Simek <[e-mail]>; Greg Kroah-
> Hartman <[e-mail]>; linux-arm Mailing List <linux-arm-
> [e-mail]>; Linux Kernel Mailing List <linux-
> [e-mail]>; devicetree <[e-mail]>; open
> list:GPIO SUBSYSTEM <[e-mail]>; git <[e-mail]>;
> [e-mail]
> Subject: Re: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
> <[e-mail]> wrote:
> > > From: Andy Shevchenko <[e-mail]>
> > > Sent: Friday, April 23, 2021 9:24 PM
> > > On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> > > <[e-mail]> 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".
Ok, I will add.
> 
> ...
> 
> > > > + * 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.
Ok, I will update.
> 
> ...
> 
> > > > +       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?
Ok, I got your point.
It is duplicate and will remove this check.
> 
> ...
> 
> > > > +               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.
Here we are checking for valid argument and not the return value of the API.
If the read value(argument) is not valid and return value of the API is
zero (SUCCESS) then framework expects driver to be returned with
'-EINVAL' and it is a legal error code in this case.
> 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?
Got your point, I will update error code with ENOTSUPP.
> 
> ...
> 
> > > > +};
> > >
> > > > +
> > >
> > > 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?
I will remove.

Regards
Sai Krishna
> 
> > > > +module_platform_driver(zynqmp_pinctrl_driver);
> 
> --
> With Best Regards,
> Andy Shevchenko

Sai Krishna Potthuri May 11, 2021, 12:38 p.m. UTC | #11

Hi Andy Shevchenko,

> -----Original Message-----
> From: Sai Krishna Potthuri
> Sent: Wednesday, April 28, 2021 11:04 AM
> To: Andy Shevchenko <[e-mail]>
> Cc: Linus Walleij <[e-mail]>; Rob Herring
> <[e-mail]>; Michal Simek <[e-mail]>; Greg Kroah-
> Hartman <[e-mail]>; linux-arm Mailing List <linux-arm-
> [e-mail]>; Linux Kernel Mailing List <linux-
> [e-mail]>; devicetree <[e-mail]>; open
> list:GPIO SUBSYSTEM <[e-mail]>; git <[e-mail]>;
> [e-mail]
> Subject: RE: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> Hi Andy Shevchenko,
> 
> > -----Original Message-----
> > From: Andy Shevchenko <[e-mail]>
> > Sent: Monday, April 26, 2021 7:35 PM
> > To: Sai Krishna Potthuri <[e-mail]>
> > Cc: Linus Walleij <[e-mail]>; Rob Herring
> > <[e-mail]>; Michal Simek <[e-mail]>; Greg Kroah-
> > Hartman <[e-mail]>; linux-arm Mailing List <linux-arm-
> > [e-mail]>; Linux Kernel Mailing List <linux-
> > [e-mail]>; devicetree <[e-mail]>; open
> > list:GPIO SUBSYSTEM <[e-mail]>; git <[e-mail]>;
> > [e-mail]
> > Subject: Re: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver
> support
...
> >
> > > > > +               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.
> Here we are checking for valid argument and not the return value of the API.
> If the read value(argument) is not valid and return value of the API is
> zero (SUCCESS) then framework expects driver to be returned with
> '-EINVAL' and it is a legal error code in this case.
Do you agree on this?
I am ready with the other changes, will send out the patch to address your comments.

Regards
Sai Krishna

Sai Krishna Potthuri June 17, 2021, 6:37 a.m. UTC | #12

Ping!

> -----Original Message-----
> From: Sai Krishna Potthuri <[e-mail]>
> Sent: Tuesday, May 11, 2021 6:08 PM
> To: Andy Shevchenko <[e-mail]>
> Cc: Linus Walleij <[e-mail]>; Rob Herring
> <[e-mail]>; Michal Simek <[e-mail]>; Greg Kroah-
> Hartman <[e-mail]>; linux-arm Mailing List <linux-arm-
> [e-mail]>; Linux Kernel Mailing List <linux-
> [e-mail]>; devicetree <[e-mail]>; open
> list:GPIO SUBSYSTEM <[e-mail]>; git <[e-mail]>;
> [e-mail]
> Subject: RE: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> Hi Andy Shevchenko,
> 
> > -----Original Message-----
> > From: Sai Krishna Potthuri
> > Sent: Wednesday, April 28, 2021 11:04 AM
> > To: Andy Shevchenko <[e-mail]>
> > Cc: Linus Walleij <[e-mail]>; Rob Herring
> > <[e-mail]>; Michal Simek <[e-mail]>; Greg Kroah-
> > Hartman <[e-mail]>; linux-arm Mailing List
> > <linux-arm- [e-mail]>; Linux Kernel Mailing List
> > <linux- [e-mail]>; devicetree
> > <[e-mail]>; open list:GPIO SUBSYSTEM
> > <[e-mail]>; git <[e-mail]>;
> > [e-mail]
> > Subject: RE: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver
> > support
> >
> > Hi Andy Shevchenko,
> >
> > > -----Original Message-----
> > > From: Andy Shevchenko <[e-mail]>
> > > Sent: Monday, April 26, 2021 7:35 PM
> > > To: Sai Krishna Potthuri <[e-mail]>
> > > Cc: Linus Walleij <[e-mail]>; Rob Herring
> > > <[e-mail]>; Michal Simek <[e-mail]>; Greg Kroah-
> > > Hartman <[e-mail]>; linux-arm Mailing List
> > > <linux-arm- [e-mail]>; Linux Kernel Mailing List
> > > <linux- [e-mail]>; devicetree
> > > <[e-mail]>; open list:GPIO SUBSYSTEM
> > > <[e-mail]>; git <[e-mail]>;
> > > [e-mail]
> > > Subject: Re: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl
> > > driver
> > support
> ...
> > >
> > > > > > +               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.
> > Here we are checking for valid argument and not the return value of the
> API.
> > If the read value(argument) is not valid and return value of the API
> > is zero (SUCCESS) then framework expects driver to be returned with
> > '-EINVAL' and it is a legal error code in this case.
> Do you agree on this?
> I am ready with the other changes, will send out the patch to address your
> comments.
> 
> Regards
> Sai Krishna

Andy Shevchenko June 17, 2021, 7:18 a.m. UTC | #13

On Thu, Jun 17, 2021 at 9:37 AM Sai Krishna Potthuri
<[e-mail]> wrote:
> Ping!

Do not top-post.
Do not ping for the sake of pings.

> > From: Sai Krishna Potthuri <[e-mail]>
> > Sent: Tuesday, May 11, 2021 6:08 PM
> > > From: Sai Krishna Potthuri
> > > Sent: Wednesday, April 28, 2021 11:04 AM
> > > > From: Andy Shevchenko <[e-mail]>
> > > > Sent: Monday, April 26, 2021 7:35 PM

...

> > > > > > > +               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.
> > > Here we are checking for valid argument and not the return value of the
> > API.
> > > If the read value(argument) is not valid and return value of the API
> > > is zero (SUCCESS) then framework expects driver to be returned with
> > > '-EINVAL' and it is a legal error code in this case.
> > Do you agree on this?
> > I am ready with the other changes, will send out the patch to address your
> > comments.

If you are ready, drop a new version (note, ~1w is a good time to send
a new version if no one answered the doubts in your previous one,
which means "silent agreement").

Greg KH June 17, 2021, 7:31 a.m. UTC | #14

On Thu, Jun 17, 2021 at 06:37:18AM +0000, Sai Krishna Potthuri wrote:
> Ping!

ping what?

Patch

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 9502775afc11..c2c7e7963ed0 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -323,6 +323,20 @@  config PINCTRL_ZYNQ
 	help
 	  This selects the pinctrl driver for Xilinx Zynq.
 
+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.
+
 config PINCTRL_INGENIC
 	bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
 	default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 8bf459c32a76..5ef5334a797f 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -40,6 +40,7 @@  obj-$(CONFIG_PINCTRL_TB10X)	+= pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST) 	+= pinctrl-st.o
 obj-$(CONFIG_PINCTRL_STMFX) 	+= pinctrl-stmfx.o
 obj-$(CONFIG_PINCTRL_ZYNQ)	+= pinctrl-zynq.o
+obj-$(CONFIG_PINCTRL_ZYNQMP)	+= pinctrl-zynqmp.o
 obj-$(CONFIG_PINCTRL_INGENIC)	+= pinctrl-ingenic.o
 obj-$(CONFIG_PINCTRL_RK805)	+= pinctrl-rk805.o
 obj-$(CONFIG_PINCTRL_OCELOT)	+= pinctrl-ocelot.o
diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
new file mode 100644
index 000000000000..d5497003ce71
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -0,0 +1,906 @@ 
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP pin controller
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Sai Krishna Potthuri <[e-mail]>
+ * Rajan Vaja <[e-mail]>
+ */
+
+#include <dt-bindings/pinctrl/pinctrl-zynqmp.h>
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/firmware/xlnx-zynqmp.h>
+
+#include <linux/pinctrl/pinmux.h>
+#include <linux/pinctrl/pinconf-generic.h>
+
+#include "core.h"
+#include "pinctrl-utils.h"
+
+#define ZYNQMP_PIN_PREFIX			"MIO"
+#define PINCTRL_GET_FUNC_NAME_RESP_LEN		16
+#define MAX_FUNC_NAME_LEN			16
+#define MAX_GROUP_PIN				50
+#define MAX_PIN_GROUPS				50
+#define END_OF_FUNCTIONS			"END_OF_FUNCTIONS"
+#define NUM_GROUPS_PER_RESP			6
+
+#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN	12
+#define PINCTRL_GET_PIN_GROUPS_RESP_LEN		12
+#define NA_GROUP				0xFFFF
+#define RESERVED_GROUP				0xFFFE
+
+#define DRIVE_STRENGTH_2MA	2
+#define DRIVE_STRENGTH_4MA	4
+#define DRIVE_STRENGTH_8MA	8
+#define DRIVE_STRENGTH_12MA	12
+
+/**
+ * struct zynqmp_pmux_function - a pinmux function
+ * @name:	Name of the pin mux function
+ * @groups:	List of pin groups for this function
+ * @ngroups:	Number of entries in @groups
+ * @node:	Firmware node matching with the function
+ *
+ * This structure holds information about pin control function
+ * and function group names supporting that function.
+ */
+struct zynqmp_pmux_function {
+	char name[MAX_FUNC_NAME_LEN];
+	const char * const *groups;
+	unsigned int ngroups;
+};
+
+/**
+ * struct zynqmp_pinctrl - driver data
+ * @pctrl:	Pin control device
+ * @groups:	Pin groups
+ * @ngroups:	Number of @groups
+ * @funcs:	Pin mux functions
+ * @nfuncs:	Number of @funcs
+ *
+ * This struct is stored as driver data and used to retrieve
+ * information regarding pin control functions, groups and
+ * group pins.
+ */
+struct zynqmp_pinctrl {
+	struct pinctrl_dev *pctrl;
+	const struct zynqmp_pctrl_group *groups;
+	unsigned int ngroups;
+	const struct zynqmp_pmux_function *funcs;
+	unsigned int nfuncs;
+};
+
+/**
+ * struct zynqmp_pctrl_group - Pin control group info
+ * @name:	Group name
+ * @pins:	Group pin numbers
+ * @npins:	Number of pins in the group
+ */
+struct zynqmp_pctrl_group {
+	const char *name;
+	unsigned int pins[MAX_GROUP_PIN];
+	unsigned int npins;
+};
+
+static struct pinctrl_desc zynqmp_desc;
+
+static int zynqmp_pctrl_get_groups_count(struct pinctrl_dev *pctldev)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->ngroups;
+}
+
+static const char *zynqmp_pctrl_get_group_name(struct pinctrl_dev *pctldev,
+					       unsigned int selector)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->groups[selector].name;
+}
+
+static int zynqmp_pctrl_get_group_pins(struct pinctrl_dev *pctldev,
+				       unsigned int selector,
+				       const unsigned int **pins,
+				       unsigned int *npins)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	*pins = pctrl->groups[selector].pins;
+	*npins = pctrl->groups[selector].npins;
+
+	return 0;
+}
+
+static const struct pinctrl_ops zynqmp_pctrl_ops = {
+	.get_groups_count = zynqmp_pctrl_get_groups_count,
+	.get_group_name = zynqmp_pctrl_get_group_name,
+	.get_group_pins = zynqmp_pctrl_get_group_pins,
+	.dt_node_to_map = pinconf_generic_dt_node_to_map_all,
+	.dt_free_map = pinctrl_utils_free_map,
+};
+
+static int zynqmp_pinmux_request_pin(struct pinctrl_dev *pctldev,
+				     unsigned int pin)
+{
+	int ret;
+
+	ret = zynqmp_pm_pinctrl_request(pin);
+	if (ret) {
+		dev_err(pctldev->dev, "request failed for pin %u\n", pin);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int zynqmp_pmux_get_functions_count(struct pinctrl_dev *pctldev)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->nfuncs;
+}
+
+static const char *zynqmp_pmux_get_function_name(struct pinctrl_dev *pctldev,
+						 unsigned int selector)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->funcs[selector].name;
+}
+
+/**
+ * zynqmp_pmux_get_function_groups() - Get groups for the function
+ * @pctldev:	Pincontrol device pointer.
+ * @selector:	Function ID
+ * @groups:	Group names.
+ * @num_groups:	Number of function groups.
+ *
+ * Get function's group count and group names.
+ */
+static int zynqmp_pmux_get_function_groups(struct pinctrl_dev *pctldev,
+					   unsigned int selector,
+					   const char * const **groups,
+					   unsigned * const num_groups)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	*groups = pctrl->funcs[selector].groups;
+	*num_groups = pctrl->funcs[selector].ngroups;
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinmux_set_mux() - Set requested function for the group
+ * @pctldev:	Pincontrol device pointer.
+ * @function:	Function ID.
+ * @group:	Group ID.
+ *
+ * Loop through all pins of the group and call firmware API
+ * to set requested function for all pins in the group.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinmux_set_mux(struct pinctrl_dev *pctldev,
+				 unsigned int function,
+				 unsigned int group)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+	const struct zynqmp_pctrl_group *pgrp = &pctrl->groups[group];
+	int ret, i;
+
+	for (i = 0; i < pgrp->npins; i++) {
+		unsigned int pin = pgrp->pins[i];
+
+		ret = zynqmp_pm_pinctrl_set_function(pin, function);
+		if (ret) {
+			dev_err(pctldev->dev, "set mux failed for pin %u\n",
+				pin);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int zynqmp_pinmux_release_pin(struct pinctrl_dev *pctldev,
+				     unsigned int pin)
+{
+	int ret;
+
+	ret = zynqmp_pm_pinctrl_release(pin);
+	if (ret) {
+		dev_err(pctldev->dev, "free pin failed for pin %u\n",
+			pin);
+		return ret;
+	}
+
+	return 0;
+}
+
+static const struct pinmux_ops zynqmp_pinmux_ops = {
+	.request = zynqmp_pinmux_request_pin,
+	.get_functions_count = zynqmp_pmux_get_functions_count,
+	.get_function_name = zynqmp_pmux_get_function_name,
+	.get_function_groups = zynqmp_pmux_get_function_groups,
+	.set_mux = zynqmp_pinmux_set_mux,
+	.free = zynqmp_pinmux_release_pin,
+};
+
+/**
+ * zynqmp_pinconf_cfg_get() - get config value for the pin
+ * @pctldev:	Pin control device pointer.
+ * @pin:	Pin number.
+ * @config:	Value of config param.
+ *
+ * Get value of the requested configuration parameter for the
+ * given pin.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinconf_cfg_get(struct pinctrl_dev *pctldev,
+				  unsigned int pin,
+				  unsigned long *config)
+{
+	unsigned int arg, param = pinconf_to_config_param(*config);
+	int ret;
+
+	if (pin >= zynqmp_desc.npins)
+		return -EOPNOTSUPP;
+
+	switch (param) {
+	case PIN_CONFIG_SLEW_RATE:
+		param = PM_PINCTRL_CONFIG_SLEW_RATE;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		break;
+	case PIN_CONFIG_BIAS_PULL_UP:
+		param = PM_PINCTRL_CONFIG_PULL_CTRL;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		if (arg != PM_PINCTRL_BIAS_PULL_UP)
+			return -EINVAL;
+
+		arg = 1;
+		break;
+	case PIN_CONFIG_BIAS_PULL_DOWN:
+		param = PM_PINCTRL_CONFIG_PULL_CTRL;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		if (arg != PM_PINCTRL_BIAS_PULL_DOWN)
+			return -EINVAL;
+
+		arg = 1;
+		break;
+	case PIN_CONFIG_BIAS_DISABLE:
+		param = PM_PINCTRL_CONFIG_BIAS_STATUS;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		if (arg != PM_PINCTRL_BIAS_DISABLE)
+			return -EINVAL;
+
+		arg = 1;
+		break;
+	case PIN_CONFIG_POWER_SOURCE:
+		param = PM_PINCTRL_CONFIG_VOLTAGE_STATUS;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		break;
+	case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+		param = PM_PINCTRL_CONFIG_SCHMITT_CMOS;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		break;
+	case PIN_CONFIG_DRIVE_STRENGTH:
+		param = PM_PINCTRL_CONFIG_DRIVE_STRENGTH;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		switch (arg) {
+		case PM_PINCTRL_DRIVE_STRENGTH_2MA:
+			arg = DRIVE_STRENGTH_2MA;
+			break;
+		case PM_PINCTRL_DRIVE_STRENGTH_4MA:
+			arg = DRIVE_STRENGTH_4MA;
+			break;
+		case PM_PINCTRL_DRIVE_STRENGTH_8MA:
+			arg = DRIVE_STRENGTH_8MA;
+			break;
+		case PM_PINCTRL_DRIVE_STRENGTH_12MA:
+			arg = DRIVE_STRENGTH_12MA;
+			break;
+		default:
+			/* Invalid drive strength */
+			dev_warn(pctldev->dev,
+				 "Invalid drive strength for pin %d\n",
+				 pin);
+			return -EINVAL;
+		}
+		break;
+	default:
+		ret = -EOPNOTSUPP;
+		break;
+	}
+
+	if (ret)
+		return ret;
+
+	param = pinconf_to_config_param(*config);
+	*config = pinconf_to_config_packed(param, arg);
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinconf_cfg_set() - Set requested config for the pin
+ * @pctldev:		Pincontrol device pointer.
+ * @pin:		Pin number.
+ * @configs:		Configuration to set.
+ * @num_configs:	Number of configurations.
+ *
+ * Loop through all configurations and call firmware API
+ * to set requested configurations for the pin.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinconf_cfg_set(struct pinctrl_dev *pctldev,
+				  unsigned int pin, unsigned long *configs,
+				  unsigned int num_configs)
+{
+	int i, ret;
+
+	if (pin >= zynqmp_desc.npins)
+		return -EOPNOTSUPP;
+
+	for (i = 0; i < num_configs; i++) {
+		unsigned int param = pinconf_to_config_param(configs[i]);
+		unsigned int arg = pinconf_to_config_argument(configs[i]);
+		unsigned int value;
+
+		switch (param) {
+		case PIN_CONFIG_SLEW_RATE:
+			param = PM_PINCTRL_CONFIG_SLEW_RATE;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_BIAS_PULL_UP:
+			param = PM_PINCTRL_CONFIG_PULL_CTRL;
+			arg = PM_PINCTRL_BIAS_PULL_UP;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_BIAS_PULL_DOWN:
+			param = PM_PINCTRL_CONFIG_PULL_CTRL;
+			arg = PM_PINCTRL_BIAS_PULL_DOWN;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_BIAS_DISABLE:
+			param = PM_PINCTRL_CONFIG_BIAS_STATUS;
+			arg = PM_PINCTRL_BIAS_DISABLE;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+			param = PM_PINCTRL_CONFIG_SCHMITT_CMOS;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_DRIVE_STRENGTH:
+			switch (arg) {
+			case DRIVE_STRENGTH_2MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_2MA;
+				break;
+			case DRIVE_STRENGTH_4MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_4MA;
+				break;
+			case DRIVE_STRENGTH_8MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_8MA;
+				break;
+			case DRIVE_STRENGTH_12MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_12MA;
+				break;
+			default:
+				/* Invalid drive strength */
+				dev_warn(pctldev->dev,
+					 "Invalid drive strength for pin %d\n",
+					 pin);
+				return -EINVAL;
+			}
+
+			param = PM_PINCTRL_CONFIG_DRIVE_STRENGTH;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, value);
+			break;
+		case PIN_CONFIG_POWER_SOURCE:
+			param = PM_PINCTRL_CONFIG_VOLTAGE_STATUS;
+			ret = zynqmp_pm_pinctrl_get_config(pin, param, &value);
+
+			if (arg != value)
+				dev_warn(pctldev->dev,
+					 "Invalid IO Standard requested for pin %d\n",
+					 pin);
+
+			break;
+		case PIN_CONFIG_BIAS_HIGH_IMPEDANCE:
+		case PIN_CONFIG_MODE_LOW_POWER:
+			/*
+			 * These cases are mentioned in dts but configurable
+			 * registers are unknown. So falling through to ignore
+			 * boot time warnings as of now.
+			 */
+			ret = 0;
+			break;
+		default:
+			dev_warn(pctldev->dev,
+				 "unsupported configuration parameter '%u'\n",
+				 param);
+			ret = -EOPNOTSUPP;
+			break;
+		}
+
+		param = pinconf_to_config_param(configs[i]);
+		arg = pinconf_to_config_argument(configs[i]);
+		if (ret)
+			dev_warn(pctldev->dev,
+				 "failed to set: pin %u param %u value %u\n",
+				 pin, param, arg);
+	}
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinconf_group_set() - Set requested config for the group
+ * @pctldev:		Pincontrol device pointer.
+ * @selector:		Group ID.
+ * @configs:		Configuration to set.
+ * @num_configs:	Number of configurations.
+ *
+ * Call function to set configs for each pin in the group.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinconf_group_set(struct pinctrl_dev *pctldev,
+				    unsigned int selector,
+				    unsigned long *configs,
+				    unsigned int num_configs)
+{
+	int i, ret;
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+	const struct zynqmp_pctrl_group *pgrp = &pctrl->groups[selector];
+
+	for (i = 0; i < pgrp->npins; i++) {
+		ret = zynqmp_pinconf_cfg_set(pctldev, pgrp->pins[i], configs,
+					     num_configs);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static const struct pinconf_ops zynqmp_pinconf_ops = {
+	.is_generic = true,
+	.pin_config_get = zynqmp_pinconf_cfg_get,
+	.pin_config_set = zynqmp_pinconf_cfg_set,
+	.pin_config_group_set = zynqmp_pinconf_group_set,
+};
+
+static struct pinctrl_desc zynqmp_desc = {
+	.name = "zynqmp_pinctrl",
+	.owner = THIS_MODULE,
+	.pctlops = &zynqmp_pctrl_ops,
+	.pmxops = &zynqmp_pinmux_ops,
+	.confops = &zynqmp_pinconf_ops,
+};
+
+static int zynqmp_pinctrl_get_function_groups(u32 fid, u32 index, u16 *groups)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_FUNCTION_GROUPS;
+	qdata.arg1 = fid;
+	qdata.arg2 = index;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	memcpy(groups, &payload[1], PINCTRL_GET_FUNC_GROUPS_RESP_LEN);
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_get_func_num_groups(u32 fid, unsigned int *ngroups)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_NUM_FUNCTION_GROUPS;
+	qdata.arg1 = fid;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	*ngroups = payload[1];
+
+	return ret;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_func_groups() - prepare function and groups data
+ * @dev:	Device pointer.
+ * @fid:	Function ID.
+ * @func:	Function data.
+ * @groups:	Groups data.
+ *
+ * Query firmware to get group IDs for each function. Firmware returns
+ * group IDs. Based on group index for the function, group names in
+ * the function are stored. For example, the first group in "eth0" function
+ * is named as "eth0_0" and second group as "eth0_1" and so on.
+ *
+ * Based on the group ID received from the firmware, function stores name of
+ * the group for that group ID. For example, if "eth0" first group ID
+ * is x, groups[x] name will be stored as "eth0_0".
+ *
+ * Once done for each function, each function would have its group names
+ * and each groups would also have their names.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_func_groups(struct device *dev, u32 fid,
+					      struct zynqmp_pmux_function *func,
+					      struct zynqmp_pctrl_group *groups)
+{
+	u16 resp[NUM_GROUPS_PER_RESP] = {0};
+	const char **fgroups;
+	int ret = 0, index, i;
+
+	fgroups = devm_kzalloc(dev, sizeof(*fgroups) * func->ngroups, GFP_KERNEL);
+	if (!fgroups)
+		return -ENOMEM;
+
+	for (index = 0; index < func->ngroups; index += NUM_GROUPS_PER_RESP) {
+		ret = zynqmp_pinctrl_get_function_groups(fid, index, resp);
+		if (ret)
+			return ret;
+
+		for (i = 0; i < NUM_GROUPS_PER_RESP; i++) {
+			if (resp[i] == NA_GROUP)
+				goto done;
+
+			if (resp[i] == RESERVED_GROUP)
+				continue;
+
+			fgroups[index + i] = devm_kasprintf(dev, GFP_KERNEL,
+							    "%s_%d_grp",
+							    func->name,
+							    index + i);
+			if (!fgroups[index + i])
+				return -ENOMEM;
+
+			groups[resp[i]].name = devm_kasprintf(dev, GFP_KERNEL,
+							      "%s_%d_grp",
+							      func->name,
+							      index + i);
+			if (!groups[resp[i]].name)
+				return -ENOMEM;
+		}
+	}
+done:
+	func->groups = fgroups;
+
+	return ret;
+}
+
+static void zynqmp_pinctrl_get_function_name(u32 fid, char *name)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+
+	qdata.qid = PM_QID_PINCTRL_GET_FUNCTION_NAME;
+	qdata.arg1 = fid;
+
+	/*
+	 * Name of the function is maximum 16 bytes and cannot
+	 * accommodate the return value in SMC buffers, hence ignoring
+	 * the return value for this specific qid.
+	 */
+	zynqmp_pm_query_data(qdata, payload);
+	memcpy(name, payload, PINCTRL_GET_FUNC_NAME_RESP_LEN);
+}
+
+static int zynqmp_pinctrl_get_num_functions(unsigned int *nfuncs)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_NUM_FUNCTIONS;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	*nfuncs = payload[1];
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_get_pin_groups(u32 pin, u32 index, u16 *groups)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_PIN_GROUPS;
+	qdata.arg1 = pin;
+	qdata.arg2 = index;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	memcpy(groups, &payload[1], PINCTRL_GET_PIN_GROUPS_RESP_LEN);
+
+	return ret;
+}
+
+static void zynqmp_pinctrl_group_add_pin(struct zynqmp_pctrl_group *group,
+					 unsigned int pin)
+{
+	group->pins[group->npins++] = pin;
+}
+
+/**
+ * zynqmp_pinctrl_create_pin_groups() - assign pins to respective groups
+ * @dev:	Device pointer.
+ * @groups:	Groups data.
+ * @pin:	Pin number.
+ *
+ * Query firmware to get groups available for the given pin.
+ * Based on the firmware response(group IDs for the pin), add
+ * pin number to the respective group's pin array.
+ *
+ * Once all pins are queries, each groups would have its number
+ * of pins and pin numbers data.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_create_pin_groups(struct device *dev,
+					    struct zynqmp_pctrl_group *groups,
+					    unsigned int pin)
+{
+	u16 resp[NUM_GROUPS_PER_RESP] = {0};
+	int ret, i, index = 0;
+
+	do {
+		ret = zynqmp_pinctrl_get_pin_groups(pin, index, resp);
+		if (ret)
+			return ret;
+
+		for (i = 0; i < NUM_GROUPS_PER_RESP; i++) {
+			if (resp[i] == NA_GROUP)
+				return ret;
+
+			if (resp[i] == RESERVED_GROUP)
+				continue;
+
+			zynqmp_pinctrl_group_add_pin(&groups[resp[i]], pin);
+		}
+		index += NUM_GROUPS_PER_RESP;
+	} while (index <= MAX_PIN_GROUPS);
+
+	return ret;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_group_pins() - prepare each group's pin data
+ * @dev:	Device pointer.
+ * @groups:	Groups data.
+ * @ngroups:	Number of groups.
+ *
+ * Prepare pin number and number of pins data for each pins.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_group_pins(struct device *dev,
+					     struct zynqmp_pctrl_group *groups,
+					     unsigned int ngroups)
+{
+	unsigned int pin;
+	int ret;
+
+	for (pin = 0; pin < zynqmp_desc.npins; pin++) {
+		ret = zynqmp_pinctrl_create_pin_groups(dev, groups, pin);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_function_info() - prepare function info
+ * @dev:	Device pointer.
+ * @pctrl:	Pin control driver data.
+ *
+ * Query firmware for functions, groups and pin information and
+ * prepare pin control driver data.
+ *
+ * Query number of functions and number of function groups (number
+ * of groups in given function) to allocate required memory buffers
+ * for functions and groups. Once buffers are allocated to store
+ * functions and groups data, query and store required information
+ * (number of groups and group names for each function, number of
+ * pins and pin numbers for each group).
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_function_info(struct device *dev,
+						struct zynqmp_pinctrl *pctrl)
+{
+	struct zynqmp_pmux_function *funcs;
+	struct zynqmp_pctrl_group *groups;
+	int ret, i;
+
+	ret = zynqmp_pinctrl_get_num_functions(&pctrl->nfuncs);
+	if (ret)
+		return ret;
+
+	funcs = devm_kzalloc(dev, sizeof(*funcs) * pctrl->nfuncs, GFP_KERNEL);
+	if (!funcs)
+		return -ENOMEM;
+
+	for (i = 0; i < pctrl->nfuncs; i++) {
+		zynqmp_pinctrl_get_function_name(i, funcs[i].name);
+
+		ret = zynqmp_pinctrl_get_func_num_groups(i, &funcs[i].ngroups);
+		if (ret)
+			return ret;
+
+		pctrl->ngroups += funcs[i].ngroups;
+	}
+
+	groups = devm_kzalloc(dev, sizeof(*groups) * pctrl->ngroups, GFP_KERNEL);
+	if (!groups)
+		return -ENOMEM;
+
+	for (i = 0; i < pctrl->nfuncs; i++) {
+		ret = zynqmp_pinctrl_prepare_func_groups(dev, i, &funcs[i],
+							 groups);
+		if (ret)
+			return ret;
+	}
+
+	ret = zynqmp_pinctrl_prepare_group_pins(dev, groups, pctrl->ngroups);
+	if (ret)
+		return ret;
+
+	pctrl->funcs = funcs;
+	pctrl->groups = groups;
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_get_num_pins(unsigned int *npins)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_NUM_PINS;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	*npins = payload[1];
+
+	return ret;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_pin_desc() - prepare pin description info
+ * @dev:		Device pointer.
+ * @zynqmp_pins:	Pin information.
+ * @npins:		Number of pins.
+ *
+ * Query number of pins information from firmware and prepare pin
+ * description containing pin number and pin name.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_pin_desc(struct device *dev,
+					   const struct pinctrl_pin_desc
+					   **zynqmp_pins,
+					   unsigned int *npins)
+{
+	struct pinctrl_pin_desc *pins, *pin;
+	int ret;
+	int i;
+
+	ret = zynqmp_pinctrl_get_num_pins(npins);
+	if (ret)
+		return ret;
+
+	pins = devm_kzalloc(dev, sizeof(*pins) * *npins, GFP_KERNEL);
+	if (!pins)
+		return -ENOMEM;
+
+	for (i = 0; i < *npins; i++) {
+		pin = &pins[i];
+		pin->number = i;
+		pin->name = devm_kasprintf(dev, GFP_KERNEL, "%s%d",
+					   ZYNQMP_PIN_PREFIX, i);
+		if (!pin->name)
+			return -ENOMEM;
+	}
+
+	*zynqmp_pins = pins;
+
+	return 0;
+}
+
+static int zynqmp_pinctrl_probe(struct platform_device *pdev)
+{
+	struct zynqmp_pinctrl *pctrl;
+	int ret;
+
+	pctrl = devm_kzalloc(&pdev->dev, sizeof(*pctrl), GFP_KERNEL);
+	if (!pctrl)
+		return -ENOMEM;
+
+	ret = zynqmp_pinctrl_prepare_pin_desc(&pdev->dev,
+					      &zynqmp_desc.pins,
+					      &zynqmp_desc.npins);
+	if (ret) {
+		dev_err(&pdev->dev, "pin desc prepare fail with %d\n",
+			ret);
+		return ret;
+	}
+
+	ret = zynqmp_pinctrl_prepare_function_info(&pdev->dev, pctrl);
+	if (ret) {
+		dev_err(&pdev->dev, "function info prepare fail with %d\n",
+			ret);
+		return ret;
+	}
+
+	pctrl->pctrl = pinctrl_register(&zynqmp_desc, &pdev->dev, pctrl);
+	if (IS_ERR(pctrl->pctrl))
+		return PTR_ERR(pctrl->pctrl);
+
+	platform_set_drvdata(pdev, pctrl);
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_remove(struct platform_device *pdev)
+{
+	struct zynqmp_pinctrl *pctrl = platform_get_drvdata(pdev);
+
+	pinctrl_unregister(pctrl->pctrl);
+
+	return 0;
+}
+
+static const struct of_device_id zynqmp_pinctrl_of_match[] = {
+	{ .compatible = "xlnx,zynqmp-pinctrl" },
+	{ }
+};
+
+MODULE_DEVICE_TABLE(of, zynqmp_pinctrl_of_match);
+
+static struct platform_driver zynqmp_pinctrl_driver = {
+	.driver = {
+		.name = "zynqmp-pinctrl",
+		.of_match_table = zynqmp_pinctrl_of_match,
+	},
+	.probe = zynqmp_pinctrl_probe,
+	.remove = zynqmp_pinctrl_remove,
+};
+
+module_platform_driver(zynqmp_pinctrl_driver);
+
+MODULE_AUTHOR("Sai Krishna Potthuri <[e-mail]>");
+MODULE_DESCRIPTION("ZynqMP Pin Controller Driver");
+MODULE_LICENSE("GPL v2");