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: <YynnXkGHUTY3Fbxc@sashalap>
Date:   Tue, 20 Sep 2022 12:16:30 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Pavel Machek <pavel@....cz>
Cc:     Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org,
        Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@...inx.com>,
        Amit Kumar Mahapatra <amit.kumar-mahapatra@...inx.com>,
        Mark Brown <broonie@...nel.org>, linux-spi@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 4.9 01/13] spi: spi-cadence: Fix SPI CS gets
 toggling sporadically

On Tue, Sep 20, 2022 at 03:48:32PM +0200, Pavel Machek wrote:
>Hi!
>
>> From: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@...inx.com>
>>
>> [ Upstream commit 21b511ddee09a78909035ec47a6a594349fe3296 ]
>>
>> As part of unprepare_transfer_hardware, SPI controller will be disabled
>> which will indirectly deassert the CS line. This will create a problem
>> in some of the devices where message will be transferred with
>> cs_change flag set(CS should not be deasserted).
>> As per SPI controller implementation, if SPI controller is disabled then
>> all output enables are inactive and all pins are set to input mode which
>> means CS will go to default state high(deassert). This leads to an issue
>> when core explicitly ask not to deassert the CS (cs_change = 1). This
>> patch fix the above issue by checking the Slave select status bits from
>> configuration register before disabling the SPI.
>
>My records say this was already submitted to AUTOSEL at "Jun
>27". There are more patches from that era that were reviewed in
>AUTOSEL but not merged anywhere. Can you investigate?

Yup, there was a batch that never went in, going to queue it up for the
next round of releases.

-- 
Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ