From: Antoine Tenart <antoine.tenart@free-electrons.com>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Antoine Tenart <antoine.tenart@free-electrons.com>,
Corentin Labbe <clabbe.montjoie@gmail.com>,
herbert@gondor.apana.org.au, davem@davemloft.net, wens@csie.org,
linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 10/11] crypto: sun4i-ss: fix large block size support
Date: Mon, 29 May 2017 11:15:04 +0200 [thread overview]
Message-ID: <20170529091503.GB3169@kwain> (raw)
In-Reply-To: <20170529082931.ocoatlnpl7fvtgfu@flea.lan>
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
Hi Maxime,
On Mon, May 29, 2017 at 10:29:31AM +0200, Maxime Ripard wrote:
> On Mon, May 29, 2017 at 10:09:44AM +0200, Antoine Tenart wrote:
> > > Which speed are the SS clocks ?
> >
> > The AHB SS clk is running at 300 MHz and the SS clk at 150 MHz. SS clk
> > is at the expected rate but the AHB SS clk has a higher rate that what's
> > expected.
> >
> > In the probing function only the SS clk rate is explicitly set. I tried
> > to set the AHB clk rate as well and removed the delays. This didn't fix
> > the framework selftests at boot time. Is there any reason the AHB SS clk
> > rate isn't explicitly set when probing the driver? (Should it?)
>
> It probably shouldn't.
>
> The AHB clock is shared by most of the drivers, some of them actually
> using that clock to generate their signals.
>
> You would have to unbreak all those drivers first, which is probably
> not needed at all. I haven't seen a case where a block had a module
> clock and did care for its AHB clock rate.
OK, makes sense.
I'll wait for Corentin to test the series, and I'll send a v2 only
fixing the typos then.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: antoine.tenart@free-electrons.com (Antoine Tenart)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 10/11] crypto: sun4i-ss: fix large block size support
Date: Mon, 29 May 2017 11:15:04 +0200 [thread overview]
Message-ID: <20170529091503.GB3169@kwain> (raw)
In-Reply-To: <20170529082931.ocoatlnpl7fvtgfu@flea.lan>
Hi Maxime,
On Mon, May 29, 2017 at 10:29:31AM +0200, Maxime Ripard wrote:
> On Mon, May 29, 2017 at 10:09:44AM +0200, Antoine Tenart wrote:
> > > Which speed are the SS clocks ?
> >
> > The AHB SS clk is running at 300 MHz and the SS clk at 150 MHz. SS clk
> > is at the expected rate but the AHB SS clk has a higher rate that what's
> > expected.
> >
> > In the probing function only the SS clk rate is explicitly set. I tried
> > to set the AHB clk rate as well and removed the delays. This didn't fix
> > the framework selftests at boot time. Is there any reason the AHB SS clk
> > rate isn't explicitly set when probing the driver? (Should it?)
>
> It probably shouldn't.
>
> The AHB clock is shared by most of the drivers, some of them actually
> using that clock to generate their signals.
>
> You would have to unbreak all those drivers first, which is probably
> not needed at all. I haven't seen a case where a block had a module
> clock and did care for its AHB clock rate.
OK, makes sense.
I'll wait for Corentin to test the series, and I'll send a v2 only
fixing the typos then.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170529/2b8c7fd5/attachment.sig>
next prev parent reply other threads:[~2017-05-29 9:15 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-24 19:06 [PATCH 00/11] ARM: sun5i: cryptographic engine support Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 01/11] crypto: sun4i-ss: group variable definitions in sun4i_hash() Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 02/11] crypto: sun4i-ss: remove conditional checks against 0 Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 03/11] crypto: sun4i-ss: use lower/upper_32_bits helpers Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 04/11] crypto: sun4i-ss: cannot use DMA is the request is 0 length Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 05/11] crypto: sun4i-ss: do not dynamically set parts of the last buffer to 0 Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 06/11] crypto: sun4i-ss: simplify the pad length calculation Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 07/11] crypto: sun4i-ss: simplify the appended bit assignment Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 08/11] crypto: sun4i-ss: use GENMASK to generate masks Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 09/11] crypto: sun4i-ss: move from ablkcipher to skcipher API Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-29 14:47 ` Corentin Labbe
2017-05-29 14:47 ` Corentin Labbe
2017-05-29 14:56 ` Antoine Tenart
2017-05-29 14:56 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 10/11] crypto: sun4i-ss: fix large block size support Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-26 14:55 ` Corentin Labbe
2017-05-26 14:55 ` Corentin Labbe
2017-05-29 8:09 ` Antoine Tenart
2017-05-29 8:09 ` Antoine Tenart
2017-05-29 8:29 ` Maxime Ripard
2017-05-29 8:29 ` Maxime Ripard
2017-05-29 9:15 ` Antoine Tenart [this message]
2017-05-29 9:15 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 11/11] ARM: sun5i: add a cryptographic engine node Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170529091503.GB3169@kwain \
--to=antoine.tenart@free-electrons.com \
--cc=clabbe.montjoie@gmail.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.