Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support

[Linus Walleij]

On Sat, Apr 12, 2014 at 12:54 AM, Timur Tabi <timur@xxxxxxxxxxxxxx> wrote:

> I know it's been ten months since you posted this driver, but I have a
> question.  If this driver does not touch the pin muxing, and it
> doesn't even call pinctrl_register(), then why is it in
> drivers/pinctrl?  It's not a pinctrl driver.  Why isn't this a regular
> GPIO drivers in drivers/gpio?

- It uses the GPIO ranges concept in the pinctrl framework, because
  it internally actually deals with pin numbers, not GPIO numbers
  or predictable offsets. This way the basic pin control properties
  that ACPI should "hide" have already leaked to the driver,
  see score_pins[], ncore_pins[] etc.

- Pin control is not only about muxing, it is also about electrical
  config, see e.g. include/linux/pinctrl/pinconf-generic.h
  ACPI contain very unnerving stuff like PullDefault, PullUp,
  etc. In Linux terms that stuff is NOT GPIO, it is pin control.
  That ACPI choose to call it "GPIO" does not matter one bit.
  Now I am informed that this is read-only information, yet
  you may want to model it to Linux in the end, and then
  pin control provides the right infrastructure.

- Since the driver already knows this, it can be augmented to
  register a pin controller struct and display the actual names
  of all the pins in debugfs. And the pull state of each maybe?

- The magic muxing and biasing etc registers obviously exist
  in the register range of this IP block. Someone may start
  hacking to do fun stuff. Like bypass ACPI when it's doing
  something wrong. (Oh that never would happen, right?)
  Then the driver is in the right place to start hacking.

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/