linux-kernel - RE: [PATCHv2] wlcore: spi: add wl18xx support

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:	Thu, 21 Apr 2016 11:07:37 +0000
From:	"Reizer, Eyal" <eyalr@...com>
To:	Mark Brown <broonie@...nel.org>
CC:	"kvalo@...eaurora.org" <kvalo@...eaurora.org>,
	���� ����� 
	<eyalreizer@...il.com>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>
Subject: RE: [PATCHv2] wlcore: spi: add wl18xx support

> 
> > Thanks! Glad the illustration helped.
> > I will try it out again as if i recall cotrectly, i did try that l, and it didnt produce
> the correct waveform, but perhaps i didnt understand the usage of
> .cs_change correctly.
> > Will double check anyway.
> 
> It could also be a bug in your controller driver, it's common for them to not
> handle cs_change correctly (at least those that open code the message loop,
> obviously modern ones just factor this out into the core).

Tried looking into using cs_change and not sure I understand how it would do what I need.
According to, include/linux/spi/spi.h:

* All SPI transfers start with the relevant chipselect active.  Normally
* it stays selected until after the last transfer in a message.  Drivers
* can affect the chipselect signal using cs_change.
*
* (i) If the transfer isn't the last one in the message, this flag is
* used to make the chipselect briefly go inactive in the middle of the
* message.  Toggling chipselect in this way may be needed to terminate
* a chip command, letting a single spi_message perform all of group of
* chip transactions together.

Now, in my case I need the CS pin to go inactive and stay inactive during the transfer 
of the next byte for completing the SPI init correctly (sending the extra clock cycles while CS is inactive)
If I read the above correctly, CS will only briefly go inactive but will when the next byte 
is sent it will be active again.
What am I missing?

Best Regards,
Eyal