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: <CAAfSe-tLpfFzCTzANspxAUVLus2UbWRZ3e6Ut0dx-geoKiuNEw@mail.gmail.com>
Date:   Tue, 3 Nov 2020 15:30:24 +0800
From:   Chunyan Zhang <zhang.lyra@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-spi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Orson Zhai <orsonzhai@...il.com>,
        Baolin Wang <baolin.wang7@...il.com>,
        Chunyan Zhang <chunyan.zhang@...soc.com>,
        Bangzheng Liu <bangzheng.liu@...soc.com>
Subject: Re: [PATCH] spi: add runtime PM for transfer_one_message

On Tue, 3 Nov 2020 at 02:17, Mark Brown <broonie@...nel.org> wrote:
>
> On Mon, Nov 02, 2020 at 07:22:39PM +0800, Chunyan Zhang wrote:
> > From: Chunyan Zhang <chunyan.zhang@...soc.com>
>
> > Before transfer message, spi devices probably have been in runtime suspended,
> > that would cause the kernel crash on some platforms once access spi
> > registers, such as on Unisoc's SoCs. The spi devices can be suspended
> > until message transfer completed.
>
> This commit message is a bit hard to follow so I don't really understand
> what the issue is.  We only ever call transfer_one_message() from within
> __spi_pump_messages() which already handles auto_runtime_pm so I'm not
> seeing the situation where we might get to transfer_one_message()
> without having already runtime resumed the controller.  What exactly is
> the error situation here?  This code has been around for a while and I'm
> not aware of reports of issues here and I can't see anything unusual
> that the Spreadtrum driver is doing.

With further tests and looking into this part of code, the problem we
found recently on our platform which runs kernel 4.14 can be fixed by
this commit [1].
In a word,  there's no issue here indeed, this patch should be
ignored, sorry for the noise and thanks for your review.

Chunyan

[1] https://lkml.org/lkml/2019/10/30/173

>
> Also why are we doing this in transfer_one_message() where it will only
> work for controllers using that?  If we're missing runtime PM in some
> paths then presumably controllers with a custom implementation are also
> going to be affected as well, auto_runtime_pm is supposed to work for
> them as well.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ