From: "Łukasz Stelmach" <l.stelmach@samsung.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: robh+dt@kernel.org, "Stephan Mueller" <smueller@chronox.de>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
"Kukjin Kim" <kgene@kernel.org>,
linux-crypto@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Bartłomiej Żołnierkiewicz" <b.zolnierkie@samsung.com>
Subject: Re: [PATCH 1/3] crypto: exynos - Support Exynos5250+ SoCs
Date: Wed, 06 Dec 2017 15:53:02 +0100 [thread overview]
Message-ID: <87374naoxd.fsf%l.stelmach@samsung.com> (raw)
In-Reply-To: <CAJKOXPfep5BeJMz=qHqF4m05c2=5DgnFjPeA21n2EMJnyXvoQA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5251 bytes --]
It was <2017-12-06 śro 15:05>, when Krzysztof Kozlowski wrote:
> On Wed, Dec 6, 2017 at 2:42 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
>> It was <2017-12-05 wto 14:34>, when Krzysztof Kozlowski wrote:
>>> On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
>>>> Add support for PRNG in Exynos5250+ SoCs.
>>>>
>>>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>>>> ---
>>>> .../bindings/crypto/samsung,exynos-rng4.txt | 4 ++-
>>>> drivers/crypto/exynos-rng.c | 36 ++++++++++++++++++++--
>>>> 2 files changed, 36 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
>>>> b/Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
>>>> index 4ca8dd4d7e66..a13fbdb4bd88 100644
>>>> --- a/Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
>>>> +++ b/Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
>>>> @@ -2,7 +2,9 @@ Exynos Pseudo Random Number Generator
>>>>
>>>> Required properties:
>>>>
>>>> -- compatible : Should be "samsung,exynos4-rng".
>>>> +- compatible : One of:
>>>> + - "samsung,exynos4-rng" for Exynos4210 and Exynos4412
>>>> + - "samsung,exynos5250-prng" for Exynos5250+
>>>> - reg : Specifies base physical address and size of the registers map.
>>>> - clocks : Phandle to clock-controller plus clock-specifier pair.
>>>> - clock-names : "secss" as a clock name.
>>>> diff --git a/drivers/crypto/exynos-rng.c b/drivers/crypto/exynos-rng.c
>>>> index 451620b475a0..894ef93ef5ec 100644
>>>> --- a/drivers/crypto/exynos-rng.c
>>>> +++ b/drivers/crypto/exynos-rng.c
>>>> @@ -22,12 +22,17 @@
>>>> #include <linux/err.h>
>>>> #include <linux/io.h>
>>>> #include <linux/module.h>
>>>> +#include <linux/of_device.h>
>>>> #include <linux/platform_device.h>
>>>>
>>>> #include <crypto/internal/rng.h>
>>>>
>>>> #define EXYNOS_RNG_CONTROL 0x0
>>>> #define EXYNOS_RNG_STATUS 0x10
>>>> +
>>>> +#define EXYNOS_RNG_SEED_CONF 0x14
>>>> +#define EXYNOS_RNG_GEN_PRNG 0x02
>>>
>>> Use BIT(1) instead.
Done.
>>>> +
>>>> #define EXYNOS_RNG_SEED_BASE 0x140
>>>> #define EXYNOS_RNG_SEED(n) (EXYNOS_RNG_SEED_BASE + (n * 0x4))
>>>> #define EXYNOS_RNG_OUT_BASE 0x160
>>>> @@ -43,6 +48,11 @@
>>>> #define EXYNOS_RNG_SEED_REGS 5
>>>> #define EXYNOS_RNG_SEED_SIZE (EXYNOS_RNG_SEED_REGS * 4)
>>>>
>>>> +enum exynos_prng_type {
>>>> + EXYNOS_PRNG_TYPE4 = 4,
>>>> + EXYNOS_PRNG_TYPE5 = 5,
>>>
>>> That's unusual numbering and naming, so just:
>>> enum exynos_prng_type {
>>> EXYNOS_PRNG_EXYNOS4,
>>> EXYNOS_PRNG_EXYNOS5,
>>> };
>>>
>>> Especially that TYPE4 and TYPE5 suggest so kind of sub-type (like
>>> versions of some IP blocks, e.g. MFC) but it is just the family of
>>> Exynos.
>>
>> Half done. I've changed TYPE to EXYNOS.
>>
>> I used explicit numbering in the enum because I want both values to act
>> same true-false-wise. If one is 0 this condition is not met.
>
> First of all - that condition cannot happen. It is not possible from
> the device-matching code.
Let me explain what I didn't want. With the enum:
enum exynos_prng_type {
EXYNOS_PRNG_EXYNOS4,
EXYNOS_PRNG_EXYNOS5,
};
and a code like this
if (rng->type) {
}
EXYNOS_PRNG_EXYNOS4 is identical to false while EXYNOS_PRNG_EXYNPOS5
evaluates as true. I think this is a bad idea. I don't want it ever to
happen. Because chips have their own numbers I thought using those
numbers would be OK.
> But if you want to indicate it explicitly
> (for code reviewing?) then how about:
> enum exynos_prng_type {
> EXYNOS_PRNG_UNKNOWN = 0,
> EXYNOS_PRNG_EXYNOS4,
> EXYNOS_PRNG_EXYNOS5,
> };
>
> In such case you have the same effect but your intentions are clear
> (you expect possibility of =0... which is not possible :) ).
Fair enough.
>>>> + dev_info(&pdev->dev,
>>>> + "Exynos Pseudo Random Number Generator (type:%d)\n",
>>>
>>> dev_dbg, this is not that important information to affect the boot time.
>>
>> Quite many devices report their presence during boot with such
>> messages. For example:
>>
>> [ 3.390247] exynos-ehci 12110000.usb: EHCI Host Controller
>> [ 3.395493] exynos-ehci 12110000.usb: new USB bus registered, assigned bus number 1
>> [ 3.403702] exynos-ehci 12110000.usb: irq 80, io mem 0x12110000
>> [ 3.431793] exynos-ehci 12110000.usb: USB 2.0 started, EHCI 1.00
>>
>> From my experience it isn't printk() itself that slows down boot but the
>> serial console.
>
> True, the console is bottleneck (not necessarily serial) [1] but that
> does not change the fact there is no need to print the type of RNG.
With values of the enum not being meaningful themselves printing the
type does not make much sense for me too. Is it ok just to print report
the device presence?
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
next prev parent reply other threads:[~2017-12-06 14:53 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20171205123601eucas1p2ef1a2fdce84dce8dc4b54c419ce566a7@eucas1p2.samsung.com>
2017-12-05 12:35 ` [PATCH 0/3] Assorted changes for Exynos PRNG driver Łukasz Stelmach
2017-12-05 12:35 ` [PATCH 1/3] crypto: exynos - Support Exynos5250+ SoCs Łukasz Stelmach
2017-12-05 13:34 ` Krzysztof Kozlowski
2017-12-06 13:42 ` Łukasz Stelmach
2017-12-06 14:05 ` Krzysztof Kozlowski
2017-12-06 14:53 ` Łukasz Stelmach [this message]
2017-12-06 15:28 ` Krzysztof Kozlowski
2017-12-07 9:20 ` Łukasz Stelmach
2017-12-06 17:56 ` Joe Perches
2017-12-05 12:35 ` [PATCH 2/3] crypto: exynos - Improve performance of PRNG Łukasz Stelmach
2017-12-05 13:49 ` Krzysztof Kozlowski
2017-12-05 13:54 ` Stephan Mueller
2017-12-05 16:43 ` Łukasz Stelmach
2017-12-05 17:53 ` Krzysztof Kozlowski
2017-12-05 18:06 ` Krzysztof Kozlowski
2017-12-06 11:32 ` Łukasz Stelmach
2017-12-06 11:37 ` Krzysztof Kozlowski
2017-12-06 13:06 ` Łukasz Stelmach
2017-12-05 12:35 ` [PATCH 3/3] crypto: exynos - Reseed PRNG after generating 2^16 random bytes Łukasz Stelmach
2017-12-05 13:52 ` Stephan Mueller
2017-12-05 13:55 ` Krzysztof Kozlowski
2017-12-11 14:06 ` [PATCH v2 0/4] Assorted changes for Exynos PRNG driver Łukasz Stelmach
2017-12-12 16:36 ` [PATCH v3 " Łukasz Stelmach
2017-12-22 9:09 ` Herbert Xu
2017-12-12 16:36 ` [PATCH v3 1/4] crypto: exynos - Support Exynos5250+ SoCs Łukasz Stelmach
2017-12-13 8:06 ` Krzysztof Kozlowski
2017-12-12 16:36 ` [PATCH v3 2/4] crypto: exynos - Improve performance of PRNG Łukasz Stelmach
2017-12-13 8:07 ` Krzysztof Kozlowski
2017-12-12 16:36 ` [PATCH v3 3/4] crypto: exynos - Reseed PRNG after generating 2^16 random bytes Łukasz Stelmach
2017-12-13 8:12 ` Krzysztof Kozlowski
2017-12-12 16:36 ` [PATCH v3 4/4] crypto: exynos - Introduce mutex to prevent concurrent access to hardware Łukasz Stelmach
2017-12-11 14:06 ` [PATCH v2 1/4] crypto: exynos - Support Exynos5250+ SoCs Łukasz Stelmach
2017-12-11 14:36 ` Krzysztof Kozlowski
2017-12-11 14:06 ` [PATCH v2 2/4] crypto: exynos - Improve performance of PRNG Łukasz Stelmach
2017-12-11 14:54 ` Krzysztof Kozlowski
2017-12-12 14:49 ` Łukasz Stelmach
2017-12-11 14:06 ` [PATCH v2 3/4] crypto: exynos - Reseed PRNG after generating 2^16 random bytes Łukasz Stelmach
2017-12-11 14:57 ` Krzysztof Kozlowski
2017-12-11 14:06 ` [PATCH v2 4/4] crypto: exynos - Introduce mutex to prevent concurrent access to hardware Łukasz Stelmach
2017-12-11 15:03 ` Krzysztof Kozlowski
2017-12-12 10:30 ` Łukasz Stelmach
2017-12-12 11:09 ` Krzysztof Kozlowski
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=87374naoxd.fsf%l.stelmach@samsung.com \
--to=l.stelmach@samsung.com \
--cc=b.zolnierkie@samsung.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=robh+dt@kernel.org \
--cc=smueller@chronox.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).