linux-kernel - Re: [PATCH] ARM: at91: at91sam9x5: sets NPCS0 (PA14) back to GPIO

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20140724175848.44f5da10@bbrezillon>
Date:	Thu, 24 Jul 2014 17:58:48 +0200
From:	Boris BREZILLON <boris.brezillon@...e-electrons.com>
To:	jiri.prchal@...ignal.cz
Cc:	Bo Shen <voice.shen@...el.com>, nicolas.ferre@...el.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH] ARM: at91: at91sam9x5: sets NPCS0 (PA14) back to GPIO

On Thu, 24 Jul 2014 17:06:43 +0200
Jiří Prchal <jiri.prchal@...ignal.cz> wrote:

> Hi,
> 
> Dne 24.7.2014 v 16:26 Boris BREZILLON napsal(a):
> > Hello Jiří,
> >
> > First of all, please try to use git format-patch when submitting a
> > patch to any kernel mailing list.
> Sorry for that.
> >
> > On Thu, 24 Jul 2014 15:38:24 +0200
> > Jiří Prchal <jiri.prchal@...ignal.cz> wrote:
> >
> >> After ROMBOOT tries boot from flash on SPI0 NPCS0, this NPCS0 (PA14) remains set to PERIPH_A.
> >> Because of that, this pin is unusable to something else.
> >> This patch sets it back to GPIO.
> >
> > The policy is to leave pins in an unknown state till some peripheral
> > need them.
> >
> > What are you trying to use this pin for ?
> For chip select, but #3. And when SPI communicate with cs0 (PA22), it goes down too (PA14), so 2 devices on bus were 
> selected.

Are you using a 9x5ek board or a custom one, in the latter case could
you paste your spi0 node definition ?

> > If you just want to use it as a chip select for an spi device, take a
> > look at [1].
> At [1] it's OK until as cs0 is for example PA22 and cs1 is PA14.

If you want PA14 to control cs1 and PA22 to control cs0 (both
configured as GPIOs), you'll have the following definition:

cs-gpios = <&pioA 22 0>, <&pioA 14 0>, <0>, <0>;

> >
> > Here the gpio is requested by the spi core when defining the cs-gpios
> > property. The gpio controller then request the listed pins to the pin
> > controller (pinctrl driver).
> GPIO is not set in driver as GPIO, at least I didn't find it.

Take a look at [1], which is set as the gpio_request_enable callback,
called by pinctrl core when a gpio is requested.


[1]http://lxr.free-electrons.com/source/drivers/pinctrl/pinctrl-at91.c#L665


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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/