Date:	Tue, 25 Jun 2013 17:28:41 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Christian Ruppert <christian.ruppert@...lis.com>,
	Patrice CHOTARD <patrice.chotard@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>,
	Sascha Leuenberger <sascha.leuenberger@...lis.com>,
	Pierrick Hascoet <pierrick.hascoet@...lis.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Alexandre Courbot <acourbot@...dia.com>
Subject: Re: [PATCH 2/2] Make non-linear GPIO ranges accesible from gpiolib

On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren <swarren@...dotorg.org> wrote:

> And finally, I don't really like using pin groups for the purpose of
> defining these mappings, since I intended them to purely represent the
> mapping from register fields to the set of affected pins. However, I can
> see an argument for doing this, since the pin groups are in fact still
> representing /some/ aspect of the pinctrl internal HW.

The groups concept was part of the first pinctrl commit
2744e8afb3b76343e7eb8197e8b3e085036010a5
and there the intention was clearly just to define a discrete
set of pins.

And some drivers use it like this still, with no connection to
physical registers, i.MX come to mind.

But I do seem to recall some endless discussions about this,
I think we need to agree to disagree.

I never saw any heavy reason for the driver not to define groups
in some way it seemed would fit the muxing purposes right, we could
say, if we compare to mathematical philiosophy, that I am a formalist
rather than a platonist (i.e. I'm not requiring the description to strictly
match a reality, but rather prefer that they fulfil a practical purpose).
Here is an item for vacation reading...
http://en.wikipedia.org/wiki/Philosophy_of_mathematics

Maybe I will switch schools one day who knows.

Here is a tongue-in-cheek patch making fun of the whole debate:

diff --git a/include/linux/pinctrl/pinctrl.h b/include/linux/pinctrl/pinctrl.h
index 5979147..d3ad8b0 100644
--- a/include/linux/pinctrl/pinctrl.h
+++ b/include/linux/pinctrl/pinctrl.h
@@ -102,6 +102,21 @@ struct pinctrl_ops {
 };

 /**
+ * enum pinctrl_school - define the interpretation of group concept
+ * @PINCTRL_SCHOOL_PLATONIST: the group concept represents the authors
+ *    idea of a reality "behind" the pin controller, though in data
+ *    sheets and registers we may only see shadows of this reality
+ *    reflected as cavernous shades
+ * @PINCTRL_SCHOOL_FORMALIST: the group concept represents the authors
+ *    practical needs of dealing with pins in ordered groups and nothing
+ *    else
+ */
+enum pinctrl_school {
+    PINCTRL_SCHOOL_PLATONIST,
+    PINCTRL_SCHOOL_FORMALIST,
+};
+
+/**
  * struct pinctrl_desc - pin controller descriptor, register this to pin
  * control subsystem
  * @name: name for the pin controller
@@ -115,6 +130,7 @@ struct pinctrl_ops {
  * @confops: pin config operations vtable, if you support pin configuration in
  *    your driver
  * @owner: module providing the pin controller, used for refcounting
+ * @school: which philosophical school the controller belongs to.
  */
 struct pinctrl_desc {
     const char *name;
@@ -124,6 +140,7 @@ struct pinctrl_desc {
     const struct pinmux_ops *pmxops;
     const struct pinconf_ops *confops;
     struct module *owner;
+    enum pinctrl_school school;
 };

 /* External interface to pin controller */

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

Powered by blists - more mailing lists