linux-kernel - McSPI hangs with cs_change after "Switch driver to use transfer

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: <561675AA.4010505@baylibre.com>
Date:	Thu, 8 Oct 2015 14:54:50 +0100
From:	Neil Armstrong <narmstrong@...libre.com>
To:	Mark Brown <broonie@...nel.org>, linux-spi@...r.kernel.org,
	linux-kernel@...r.kernel.org, Michael Welling <mwelling@...e.org>,
	Fionn Cleary <clearyf@....ie>,
	Wolfram Sang <wsa@...-dreams.de>,
	Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
	Sebastian Reichel <sre@...nel.org>
Subject: McSPI hangs with cs_change after "Switch driver to use transfer_one"
 change

Hi All,

I'm in a use case where I use cs_change on McSPI channel 3 on a single transfer Full-Duplex message, then I transfer a single full duplex message without cs_change on channel 1.

Here is a better representation :
-- 1 transfer message cs_change=1
cs3 : set_cs(0)
cs3 : full-duplex transfer
cs3 : transfer ok
-- 1 transfer message cs_change=1
cs3 : set_cs(0)
cs3 : full-duplex transfer
cs3 : transfer ok
...
-- 1 transfer message cs_change=1
cs3 : set_cs(0)
cs3 : full-duplex transfer
cs3 : transfer ok
-- 1 transfer message cs_change=1
cs1 : set_cs(0)
cs1 : full-duplex transfer
cs1 : RXS timed out
cs1 : set_cs(1)

Then "RXS timed out" on each non-cs3 transfers.

The previous behavior of cs_change was :
- between transfers, unassert CS and re-assert-it for the following transfer
- between messages, unassert CS

The new behaviour inherited from the SPI core spi_transfer_one_message function :
- between transfers, unassert CS and re-assert-it for the following transfer
- between messages, leave CS asserted

We tried disabling the DMA, and the FIFO, but the behavior was actually the same, only reverting back before the "Switch driver to use transfer_one" fixed the issue.

Then actually disabling the cs_change corrected the issue. It may be why the original driver ignored the "leave it on after last xfer" hint.

The problem is : how can we disable this hint since it is managed in SPI core spi_transfer_one_message ?

A solution will be to track down the current asserted CS and unassert it them when the active channel changes.

Neil
--
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/