Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v2 2/8] spi: spi-ep93xx: Prepare clock before using it
To:     Mark Brown <broonie@kernel.org>,
        Nikita Shubin <nikita.shubin@maquefel.me>
Cc:     Geert Uytterhoeven <geert@linux-m68k.org>,
        "open list:SPI SUBSYSTEM" <linux-spi@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
References: <20210726115058.23729-1-nikita.shubin@maquefel.me>
 <20210726140001.24820-1-nikita.shubin@maquefel.me>
 <20210726140001.24820-3-nikita.shubin@maquefel.me>
 <20210726165105.GI4670@sirena.org.uk>
From:   Alexander Sverdlin <alexander.sverdlin@gmail.com>
Message-ID: <37e15955-771f-56a8-cf8e-4342c3c2c3a3@gmail.com>
Date:   Mon, 2 Aug 2021 09:36:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <20210726165105.GI4670@sirena.org.uk>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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@gmail.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@kernel.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.