linux-kernel - spi-mem and gpio chipselects

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-next>] [day] [month] [year] [list]

Message-ID: <cbe69f5457c4dd1c2cc96a247c6c6fca61c0d43c.camel@alliedtelesis.co.nz>
Date:   Mon, 4 Nov 2019 00:35:24 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "broonie@...nel.org" <broonie@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: spi-mem and gpio chipselects

Hi,

I'm working on a platform that has a slightly complicated scheme for
SPI chip-selects using gpios[1]. The spi controller driver in this case
supports the spi-mem operations which appear to bypass the generic
spi_set_cs().

Would there be any harm in adding calls to spi_set_cs() to spi-mem.c?
Naively spi_mem_access_start() and spi_mem_access_end() seem like
convenient places to start.

--
[1] - similar design to 
https://marc.info/?l=linux-spi&m=155504537628635&w=2 but a different
platform.