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

Linus Walleij linus.walleij at linaro.org
Tue Aug 21 22:52:43 EST 2012


On Thu, Aug 16, 2012 at 11:12 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 08/15/2012 09:30 PM, Dong Aisheng wrote:

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

If there are no in-kernel users we can delete it. But I can surely see
things like PCI lab boards etc wanting to have full control over pins
from userspace, just like they can hammer GPIO's on/off today
from userspace (i.e. embedded SoCs is not the only use case)
so I wouldn't rule it out. I think this use case is quite real for
automatic control, robotics, factory lines... those guys do use GPIO
sysfs like that already today.

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

sysfs over my dead body ... but exposing pin names to userspace is
another thing, and might be interesting, in case we want to just
sort of list all pins on the system from some command line tool or
HW-info control panel. But that requires designing the userspace
device interface first, so no need to haste.

Yours,
Linus Walleij


More information about the devicetree-discuss mailing list