linux-kernel - Re: [PATCH v2 2/8] spi: spi-ep93xx: Prepare clock before using it

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: <37e15955-771f-56a8-cf8e-4342c3c2c3a3@gmail.com>
Date:   Mon, 2 Aug 2021 09:36:19 +0200
From:   Alexander Sverdlin <alexander.sverdlin@...il.com>
To:     Mark Brown <broonie@...nel.org>,
        Nikita Shubin <nikita.shubin@...uefel.me>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        "open list:SPI SUBSYSTEM" <linux-spi@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/8] spi: spi-ep93xx: Prepare clock before using it

Hello Mark,

On 26/07/2021 18:51, Mark Brown wrote:
> On Mon, Jul 26, 2021 at 04:59:50PM +0300, Nikita Shubin wrote:
>> From: Alexander Sverdlin <alexander.sverdlin@...il.com>
>>
>> Use clk_prepare_enable()/clk_disable_unprepare() in preparation for switch
>> to Common Clock Framework, otherwise the following is visible:
> Acked-by: Mark Brown <broonie@...nel.org>

It looks like we didn't manage to bring the whole series as one lot to any
maintainer and two patches were applied to two different trees.
Could you please take this one to your tree as well?

>> WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:1011 clk_core_enable+0x9c/0xbc
>> Enabling unprepared ep93xx-spi.0
>> ...
>> Hardware name: Cirrus Logic EDB9302 Evaluation Board
>> ...
>> clk_core_enable
>> clk_core_enable_lock
>> ep93xx_spi_prepare_hardware
> Please think hard before including complete backtraces in upstream
> reports, they are very large and contain almost no useful information
> relative to their size so often obscure the relevant content in your
> message. If part of the backtrace is usefully illustrative (it often is
> for search engines if nothing else) then it's usually better to pull out
> the relevant sections.

Yes, I noted your comment first time and this was already stripped version
of the backtrace, but please feel free to strip it even harder if you
take the patch.

Thank you for the review,
--
Alex.