Re: [PATCH 2/2] pinctrl: add a generic control interface

[Linus Walleij]

On Thu, Oct 20, 2011 at 11:17 AM, Barry Song <21cnbao@xxxxxxxxx> wrote:
> [Shawn]
>> I like Stephen's idea about having 'u32 param' and let pinctrl drivers
>> to encode/decode this u32 for their pinctrl controller.  It makes
>> people's life much easier.
>
> A multifunctional API is actually  a bad and hard-to-use API. i agree
> we can make param u32 instead of enum and let specific driver
> customizes the param by itself.

I am hesitant about that idea because it echoes something I have
heard before, about how every system is so very special.

Greg had this very famous quote, "yes you're special, just like
everyone else"...

I think (and of course this may be completely wrong, but it's my
working hypthesis) that the things that software wants to do to
pins are:

- Enumerable, not vast

- Actually often very much the same things, just named
  differently

- Often possible to express in terms of SI-units (Ohms, nanoseconds,
  Farad, Volt per sec, ...)

> But if there are some common params, for example, PULL, OC/OD,
> WAKEUP_ENABLE, which almost all platforms need,  why don't we make
> them have common definitions like:
>
> #define PIN_CONFIG_PULL                             0
> #define PIN_CONFIG_OPEN_DRAIN                1
> ....
> #define PIN_CONFIG_USER                            5 (in case)
>
> if one platform has config not in the up list, then:
>
> #define PIN_CONFIG_TERGA_XXX                PIN_CONFIG_USER
> #define PIN_CONFIG_TERGA_YYY                (PIN_CONFIG_USER + 1)
>
> without the common definition from  PIN_CONFIG_PULL to
> PIN_CONFIG_USER, many platforms will need to definite them repeatedly.
> that is what we hate.

In the patch you're quoting:

>>> + * @PIN_CONFIG_END: this is the last enumerator for pin configurations, if
>>> + *   you need to pass in custom configurations to the pin controller, use
>>> + *   PIN_CONFIG_END+1 as the base offset

So you begin your custom enum like this:

#include <linus/pinctrl/pinctrl.h>

enum foo_pin_config {
    PIN_CONFIG_FOO_XXX = PIN_CONFIG_END+1,
    PIN_CONFIG_FOO_YYY,
    ....
};

Enums are good because in theory they give some
type safety. (Maybe not in practice. Hm.) But lecture me a bit
about why this is such a bad idea and I will change them into
#define:s but I want a solid case for it first.

Maybe PIN_CONFIG_END is not such a good name for the
last enum since there are more configs in the expanded cases...

Yet again, can I have some examples of what
PIN_CONFIG_USER may *actually* be, which would be
absolutely impossible to express in some neutral way, and
ridiculous to have in the generic enum?

There is a lot of things with strange names in some current
pin controllers/muxes, but strange names doesn't count,
it has to be a strange concept behind it to be strange for real.

At one point when I was creating pinmux I was told this was
pointless because one platform was doing pinmux, another
padmux, a third "mission modes", a fourth "alternat functions".
But it turns out that these are just different names for one and
the same thing, so I have this maybe naïve idea that pin
control/bias/drive/etc may largely be the same.

Example setting a pin "floating", "high impedance", tristate",
"high-Z" or "off" turns out to often mean the exact same thing.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/