linux-kernel - Re: [PATCH 0/3] spi: SPI bus multiplexer

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: <d91ab2261a1f4069bc48e090bd4ec702@svr-chch-ex1.atlnz.lc>
Date:   Sun, 28 Apr 2019 22:28:16 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Mark Brown <broonie@...nel.org>
CC:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        Hamish Martin <Hamish.Martin@...iedtelesis.co.nz>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tthayer@...nsource.altera.com" <tthayer@...nsource.altera.com>
Subject: Re: [PATCH 0/3] spi: SPI bus multiplexer

On 12/04/19 8:29 PM, Mark Brown wrote:
> On Fri, Apr 12, 2019 at 05:02:10PM +1200, Chris Packham wrote:
> 
>> Unfortunately recent changes have stopped my hacks from working. I've
>> tried adapting cs-gpios to work with my particular hardware but I came
>> to the realisation that the current cs-gpios support assumes a 1:1
>> mapping of gpio to SPI device whereas my hardware used the state of the
>> gpio selecting the device i.e. a 1:2 mapping.
> 
>> This is my attempt to implement a driver to deal with this. One nice
>> property is that it is pretty much self contained. The only change to
>> the core SPI infrastructure is exposing a function I needed to lookup
>> the spi_controller instance.
> 
> Why not implement the device that demuxes the GPIOs you're using for
> chip select as a GPIO controller?  Presumably it might get used for
> things other than chip selects.
> 

Hmm a gpio-gpio driver. Interesting.

One other problem that I encounter is the interaction between cs-gpio 
and SPI_MASTER_GPIO_SS. Having cs-gpio automatically sets SPI_CS_HIGH 
which has the undesired side-effect that now my real chip select is 
inverted. I actually wonder if this change breaks commit 8eee6b9dd30d 
("spi: Add Flag to Enable Slave Select with GPIO Chip Select.") since 
now there is an extra inversion on the CS enable.