linux-kernel - Re: [PATCH] spi: add runtime PM for transfer_one

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]

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.