linux-kernel - Re: [PATCH 1/2] pinmux: Add TB10x pinmux driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130524115053.GB5203@ab42.lan>
Date:	Fri, 24 May 2013 13:50:54 +0200
From:	Christian Ruppert <christian.ruppert@...lis.com>
To:	Haojian Zhuang <haojian.zhuang@...aro.org>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Shiraz HASHIM <shiraz.hashim@...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>
Subject: Re: [PATCH 1/2] pinmux: Add TB10x pinmux driver

Hello Haojian,

On Thu, May 23, 2013 at 03:43:27PM +0800, Haojian Zhuang wrote:
> On 22 May 2013 22:28, Christian Ruppert <christian.ruppert@...lis.com> wrote:
> >
> > On Mon, May 20, 2013 at 10:10:33AM +0200, Linus Walleij wrote:
> > > On Thu, May 16, 2013 at 2:12 AM, Stephen Warren <swarren@...dotorg.org> wrote:
> > > > On 05/10/2013 02:25 AM, Christian Ruppert wrote:
> > >
> > > >> (*1) TB100 GPIO ranges are defined as a phandle to the I/O function
> > > >>      which provides all pins of a given GPIO port. This function is not
> > > >>      necessarily requested from pinctrl and GPIO ports may overlap with
> > > >>      other functions. The pin controller knows about this and provides
> > > >>      whatever GPIO pin is available after mapping other requested
> > > >>      functions.
> > > >> (*2) Here, the entire GPIOB port is explicitly requested by the GPIO
> > > >>      module, i.e. all pins of the port are made available as GPIOs.
> > > >
> > > > So I think all you're looking for is a way in DT to represent GPIO
> > > > ranges? I don't think that should be by string name, but rather numbers:
> > > >
> > > > (actually, doesn't pinctrl-simple already have this?)
> > >
> > > Now I'm ever more confused ... we already have this :-)
> > >
> > > It's not even pinctrl-simple-centric it is completely generic.
> > > The code is in drivers/gpio/gpiolib-of.c.
> > >
> > > It was written by Shiraz Hashin and Haojian Zhuang.
> > > At the time I augmented the core code quite a bit to make
> > > a good fit.
> >
> > I agree. Unluckily, it uses pinctrl-internal pin numbering which we
> > would have to make coherent with the physical pin numbers of the
> > individual packaging variants of the chip in order to expose them to
> > customers (see my previous mail at https://lkml.org/lkml/2013/5/22/207).
> >
> > Adapting the kernel-internal pin numbering in function of the product
> > variant doesn't seem such a good idea to me: All pin groups etc. will
> > have to be redefined for every product, a huge source of bugs and
> > unnecessary static data within the drivers.
> >I review two methods you mentioned in this mail.
> 
> I think that you want to keep the logic simple. If so, I prefer you can
> check pinctrl-single driver first. All pins are defined in DTS instead.

Thanks for the hint. I haven't understood how to associate GPIOs to
other functions, however: Our hardware pin controller makes GPIO pins
available depending on the configuration of the non-GPIO interfaces.
This means that in many configurations, GPIO banks are only partially
available because some pins are used for other purposes. We can't expect
our customers to manually change the pin assignments in the device tree
in order to take this into account for every PCB.

Is there a way to make different pinmux functions mutually exclusive in
pinctrl-single, e.g. a pin is either a GPIO or part of an SPI interface?
Can the same thing be done for example to mux either SPI or I2C on the
same pins? If the answer to both questions is yes, we could predefine
all functions as we currently do and our pinctrl driver could be
entirely replaced with pinctrl-single.

> [...]

Greetings,
  Christian

-- 
  Christian Ruppert              ,          <christian.ruppert@...lis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pré-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates
--
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/