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

Message-ID: <07aca74d-c74e-c2a3-b8eb-bdcf9ed21a55@windriver.com>
Date:   Thu, 10 Feb 2022 10:03:16 +0800
From:   Yun Zhou <yun.zhou@...driver.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
        ying.xue@...driver.com
Subject: Re: [PATCH] spi: disable chipselect after complete transfer

Hi Brown,

Nice to get feedback from you!

In current source code of spi_transfer_one_message(),

1420     bool keep_cs = false;

1488         if (xfer->cs_change) {
1489             if (list_is_last(&xfer->transfer_list,
1490                      &msg->transfers)) {
1491                 keep_cs = true;
1492             } else {
1493                 spi_set_cs(msg->spi, false, false);
1494                 _spi_transfer_cs_change_delay(msg, xfer);
1495                 spi_set_cs(msg->spi, true, false);
1496             }
1497         }

1502 out:
1503     if (ret != 0 || !keep_cs)
1504         spi_set_cs(msg->spi, false, false);

if the last xfer->cs_change is true, keep_cs will be true, and it will 
not call spi_set_cs() to set CS to false. Do you mean to keep CS enabled 
in this case?

On 2/9/22 9:40 PM, Mark Brown wrote:
> On Wed, Feb 09, 2022 at 06:00:42PM +0800, Yun Zhou wrote:
>> If there are 2 slaves or more on a spi bus, e.g. A and B, we processed a
>> transfer to A, the CS will be selected for A whose 'last_cs_enable' will
>> be recorded to true at the same time. Then we processed a transfer to B,
>> the CS will be switched to B. And then if we transmit data to A again, it
>> will not enable CS back to A because 'last_cs_enable' is true.
>> In addition, if CS is not disabled, Some controllers in automatic
>> transmission state will receive unpredictable data, such as Cadence SPI
>> controller.
> This sounds like you've got an issue with mixing devices with and
> without CS_HIGH - that is probably broken but...
>
>>   out:
>> -	if (ret != 0 || !keep_cs)
>> -		spi_set_cs(msg->spi, false, false);
>> +	spi_set_cs(msg->spi, false, false);
> ...this will obviously break cs_change support, clearly that's not OK.
> The last_cs_high should be moved to the device.

I do not think it will break cs_change support. In my understanding, 
cs_change indicates whether or not change CS after an xfer completed. 
But at present if the last xfer->cs_change is true, we will not change 
CS to disabled state. Is this the result we want? I'm confused.

I look forward to your help and explanation.

Regards,

Yun