linux-kernel - Re: 回复: [PATCH] spi: disable chipselect after complete 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: <Ygpo9YT9PrQAAIH3@sirena.org.uk>
Date:   Mon, 14 Feb 2022 14:36:37 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Yun Zhou <yun.zhou@...driver.com>
Cc:     "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Xue, Ying" <Ying.Xue@...driver.com>
Subject: Re: 回复: [PATCH] spi: disable
 chipselect after complete transfer

On Mon, Feb 14, 2022 at 10:20:21PM +0800, Yun Zhou wrote:

> I can't see from anywhere that when cs_change is true, we must keep CS
> 
> active. If an individual controller needs to keep CS active after the whole
> 
> message transmission complete, I think we should set cs_change to false
> 
> rather than true, because cs_change means to change CS, not keep CS,
> 
> otherwise let us rename cs_change to cs_keep.

*sigh*  Please also look back at how this has historically been handled,
this is not new behaviour.  I'm not saying that this is the greatest API
ever or that it'd be done this way if it were new but that doesn't mean
we can just randomly change the interface and potentially disrupt users.
Whatever else is going on the current behaviour is intentional.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)