RE: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

[Sai Krishna Potthuri]

Hi Linus,

> -----Original Message-----
> From: Linus Walleij <linus.walleij@xxxxxxxxxx>
> Sent: Thursday, March 25, 2021 2:27 PM
> To: Sai Krishna Potthuri <lakshmis@xxxxxxxxxx>
> Cc: Andy Shevchenko <andy.shevchenko@xxxxxxxxx>; Rob Herring
> <robh+dt@xxxxxxxxxx>; Michal Simek <michals@xxxxxxxxxx>; Greg Kroah-
> Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; linux-arm Mailing List <linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx>; Linux Kernel Mailing List <linux-
> kernel@xxxxxxxxxxxxxxx>; devicetree <devicetree@xxxxxxxxxxxxxxx>; open
> list:GPIO SUBSYSTEM <linux-gpio@xxxxxxxxxxxxxxx>; git <git@xxxxxxxxxx>;
> saikrishna12468@xxxxxxxxx
> Subject: Re: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> On Mon, Mar 22, 2021 at 4:25 PM Sai Krishna Potthuri
> <lakshmis@xxxxxxxxxx> wrote:
> > [Andy]
> 
> > > > > > +       PIN_CONFIG_IOSTANDARD = PIN_CONFIG_END + 1, };
> > > > >
> > > > > I'm lost here. What is IO standard exactly? Why it can't be in
> > > > > generic headers?
> > > > It represents LVCMOS 3.3 volts/ LVCMOS 1.8 volts.
> > > > Since this is specific to Xilinx ZynqMP platform, considered to be
> > > > added in the driver file.
> > >
> > > So, why can't we create a couple of bits to represent this voltages
> > > in the generic header and gain usability for others as well?
> >
> > I see some drivers are maintaining the configuration list in the
> > driver file, if the configuration is specific to the driver.
> >
> > We can move this to generic header if it is used by others as well.
> > Ok, will wait for Linus to comment.
> > >
> > > Linus?
> 
> While it is fine to add custom pin config options to pin controllers for
> hopelessly idiomatic stuff, this does look like it should be using
> PIN_CONFIG_POWER_SOURCE with the voltage rail as parameter, see
> include/linux/pinctrl/pinconf-generic.h
Thanks.
I will update the driver to use 'power-source' option.

Regards
Sai Krishna
> 
> If you're not using that then tell us why.
> 
> Yours,
> Linus Walleij