[PATCH] pinctrl: imx5: start numbering pad from 0

[swarren@wwwdotorg.org (Stephen Warren)]

On 08/15/2012 09:30 PM, Dong Aisheng wrote:
> On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote:
> ...
>>> Another known issue is that via this way, that means the pinctrl subsystem
>>> can only see the using pads, this is a bit not align with the pinctrl
>>> subsystem design. No sure if Linus would like to see it.
>>>
>> I do not quite follow on this.  The "enum imx51_pads" will still be
>> there, so all the pads will still be visible to the pinctrl system.
>>
> Sorry, i did not describe it accurately.
> The problem is that those pins are visible to pinctrl subystem, but the pinctrl
> subsystem can not manage them all.
> Not sure this meet Linus's original design purpose.
> Because for the way proposed, all the pin's basic properties like mux_reg, config_reg
> are parsed from device tree at runtime.
> If a pin is not used in device tree, the driver can not know this pin's
> corresponding registers.
> Thus, for those unused pins, we can not manage it on mux or config in pinctrl
> subsystem and driver.
> 
> For example, the pin_config_get/pin_config_set API in
> include/linux/pinctrl/consumer.h can not work for such pins.

Hmmm. Given we support all pin mux/config options from the mapping
table, I'd question whether that API should even exist any more...

> Then imx_pinconf_dbg_show in current driver may need change since it does not
> support show all pins's config value.

The pinctrl core assumes that the pin numbering space could be sparse.
For example, see that pinconf.c:pinconf_pins_show() "continues" the loop
if pin_desc_get() fails for a particular pin number. So just based on
what I've read in this one email, I think this is fine.

> It looks like not a big issue currently since i did not see any client driver
> using this API.
> But i'm not sure if we may have this requirement in the future.
> For example, is it possible that pinctrl subsystem may support configure pins
> via sysfs dynamically?

I can't comment on sysfs specifically, but I believe it would be
generally true that a pin that isn't know to the pinctrl subsystem can't
be manipulated in any way.