[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOtvUMc8D9DQFC6vZ+GnaVBg5uFVrQmOrnSQKz7ZPHGh4BCsZg@mail.gmail.com>
Date: Tue, 19 Jun 2018 16:57:15 +0300
From: Gilad Ben-Yossef <gilad@...yossef.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Simon Horman <horms@...ge.net.au>,
Magnus Damm <magnus.damm@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
linux-clk <linux-clk@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Ofir Drang <ofir.drang@....com>
Subject: Re: [PATCH v2 0/5] crypto: ccree: cleanup, fixes and R-Car enabling
On Tue, Jun 19, 2018 at 3:58 PM, Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
> Hi Gilad,
>
> On Thu, May 24, 2018 at 4:19 PM Gilad Ben-Yossef <gilad@...yossef.com> wrote:
>> The patch set enables the use of CryptoCell found in some Renesas R-Car
>> Salvator-X boards and fixes some driver issues uncovered that prevented
>> to work properly.
>
> With DEBUG enabled on R-Car H3, I see lots of
>
> ccree e6601000.crypto: IRR includes unknown cause bits (0x00000098)
> ccree e6601000.crypto: IRR includes unknown cause bits (0x000000C0)
> ccree e6601000.crypto: IRR includes unknown cause bits (0x000000D0)
> ccree e6601000.crypto: IRR includes unknown cause bits (0x000000D8)
> ccree e6601000.crypto: IRR includes unknown cause bits (0x000000E0)
> ccree e6601000.crypto: IRR includes unknown cause bits (0x000000F0)
> ccree e6601000.crypto: IRR includes unknown cause bits (0x000000F8)
>
> during boot. Is that expected?
Yes. The condition itself it is reporting is not necessarily bad. It
means that driver
did not act on certain HW notification during interrupts and that's
OK, we don't act on all of them
depending on configuration - e.g. if you have CONFIG_FIPS enabled and
an active TEE module or not.
I can rate_limit the message if it bothers you but other than that it
is a harmless debug print.
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
values of β will give rise to dom!
Powered by blists - more mailing lists