linux-kernel - Re: [PATCH v5] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87vb02x4h8.fsf@kamboji.qca.qualcomm.com>
Date:	Mon, 18 Jul 2016 20:04:19 +0300
From:	Kalle Valo <kvalo@...eaurora.org>
To:	"Reizer\, Eyal" <eyalr@...com>
Cc:	Rob Herring <robh@...nel.org>,
	"linux-wireless\@vger.kernel.org" <linux-wireless@...r.kernel.org>,
	"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree\@vger.kernel.org" <devicetree@...r.kernel.org>,
	"linux-spi\@vger.kernel.org" <linux-spi@...r.kernel.org>
Subject: Re: [PATCH v5] wlcore: spi: add wl18xx support

"Reizer, Eyal" <eyalr@...com> writes:

> Add support for using with both wl12xx and wl18xx.
>
> - all wilink family needs special init command for entering wspi mode.
>   extra clock cycles should be sent after the spi init command while the
>   cs pin is high.
> - Use inverted chip select for sending a dummy 4 bytes command that
>   completes the init stage.
>
> Signed-off-by: Eyal Reizer <eyalr@...com>
> Acked-by: Rob Herring <robh@...nel.org>
> ---
> v1->v2:update device tree bindings configuration
> v2->v3:revert from manual gpio manipulation. use inverted chip select 
> instead for sending the extra init cycle which, achieves the same hardware 
> purpose.
> update device tree bindings docucmentation accordingly
> v3->v4: Remove redundant data form binding documentation and fix chip 
> select number mismatch in wl1271 example
> v4->v5: Rebase on top of head of wireless-drivers-next

You now sent me two patches with v5 which is just confusing. To make the
life of maintainers easier ALWAYS increase the revision number, no
matter how small the change is.

But the "latter" v5 is corrupted somehow in patchwork:

https://patchwork.kernel.org/patch/9233597/

The "former" v5 again looks ok:

https://patchwork.kernel.org/patch/9222403/

I can't immeaditely see why that happened, but please resend.

-- 
Kalle Valo