linux-kernel - Re: [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

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]

Date:	Fri, 4 Mar 2016 10:27:49 +0100
From:	Martin Sperl <martin@...rl.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Eric Anholt <eric@...olt.net>, Mark Rutland <mark.rutland@....com>,
	devicetree@...r.kernel.org,
	Florian Fainelli <f.fainelli@...il.com>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
	Rob Herring <robh+dt@...nel.org>,
	linux-rpi-kernel@...ts.infradead.org,
	Kumar Gala <galak@...eaurora.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.


> On 03.03.2016, at 22:20, Stephen Warren <swarren@...dotorg.org> wrote:
> 
> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
>> function selects do for the pins, and there are a bunch of obvious
>> groupings to be made.  With these created, we'll be able to replace
>> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
>> references to specific groups we want enabled.
> 
>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> 
>> +			spi0_gpio7: spi0_gpio7 {
>> +				brcm,pins = <7 8 9 10 11>;
>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>> +			};
> 
> This is too many pins.
> 
> - It includes both MOSI and MISO, although a particular use-case may only use 1 of those.
> 
> - It includes both chip-select signals, whereas a particular use-case may use 0, 1, or 2 of those. This is especially true since IIRC the mainline bcm283x SPI driver wants to only use GPIOs for chip-selects, not SPI-controller-generated chip-select signals, to avoid some issues with the HW generation of these signals.
That is true: the spi-bcm2835 driver requires GPIO usage for chip-select
to make all those latency optimizations work (but also to avoid some
spi-dma issues).
The reason behind it is that there are observed short term “glitches”
on native CS whenever the SPI control register is touched - even with 
identical values.
And GPIO controlled CS solves this issue (and Mark Brown said that
the GPIO-cs interface is now preferred anyway - hence the auxiliary
spi only implement gpio-cs and requires the CS set as OUTPUT, but
unlike the main spi this does not have “remapping” support for
legacy device-trees (as there never was a driver-version that supported
native-cs).

Maybe split the SPI-portion into 2 sections:
* the SCK, MOSI, MISO (pin 9 to 11) with ALT_0
* the CS GPIOs (standard pins are 7 and 8) with OUTPUT.

That way it is easy to override only this section (plus the gpio-cs property inside the spi node) to extend the number of chip selects or use different mappings.

> 
> I believe a similar comment applies to other SPI nodes too.
I guess the same “splitting” approach should be taken here as well...