* [PATCH] hwrng: amd-rng - Migrate to managed API
From: PrasannaKumar Muralidharan @ 2016-09-09 7:58 UTC (permalink / raw)
To: mpm, herbert, clabbe.montjoie, linux-crypto; +Cc: PrasannaKumar Muralidharan
Managed API eliminates error handling code, thus reduces several lines
of code.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/amd-rng.c | 48 +++++++++-------------------------------
1 file changed, 11 insertions(+), 37 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 9959c76..4dbc5aa 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -55,7 +55,6 @@ MODULE_DEVICE_TABLE(pci, pci_tbl);
struct amd768_priv {
void __iomem *iobase;
struct pci_dev *pcidev;
- u32 pmbase;
};
static int amd_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
@@ -149,58 +148,33 @@ found:
if (pmbase == 0)
return -EIO;
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (IS_ERR(priv))
+ return PTR_ERR(priv);
- if (!request_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE, DRV_NAME)) {
+ if (!devm_request_region(&pdev->dev, pmbase + PMBASE_OFFSET,
+ PMBASE_SIZE, DRV_NAME)) {
dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
pmbase + 0xF0);
- err = -EBUSY;
- goto out;
+ return -EBUSY;
}
- priv->iobase = ioport_map(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
- if (!priv->iobase) {
+ priv->iobase = devm_ioport_map(&pdev->dev, pmbase + PMBASE_OFFSET,
+ PMBASE_SIZE);
+ if (IS_ERR(priv->iobase)) {
pr_err(DRV_NAME "Cannot map ioport\n");
- err = -EINVAL;
- goto err_iomap;
+ return PTR_ERR(priv->iobase);
}
amd_rng.priv = (unsigned long)priv;
- priv->pmbase = pmbase;
priv->pcidev = pdev;
pr_info(DRV_NAME " detected\n");
- err = hwrng_register(&amd_rng);
- if (err) {
- pr_err(DRV_NAME " registering failed (%d)\n", err);
- goto err_hwrng;
- }
- return 0;
-
-err_hwrng:
- ioport_unmap(priv->iobase);
-err_iomap:
- release_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
-out:
- kfree(priv);
- return err;
+ return devm_hwrng_register(&pdev->dev, &amd_rng);
}
static void __exit mod_exit(void)
{
- struct amd768_priv *priv;
-
- priv = (struct amd768_priv *)amd_rng.priv;
-
- hwrng_unregister(&amd_rng);
-
- ioport_unmap(priv->iobase);
-
- release_region(priv->pmbase + PMBASE_OFFSET, PMBASE_SIZE);
-
- kfree(priv);
}
module_init(mod_init);
--
2.5.0
^ permalink raw reply related
* Re: Kernel panic - encryption/decryption failed when open file on Arm64
From: xiakaixu @ 2016-09-09 4:08 UTC (permalink / raw)
To: Herbert Xu
Cc: davem, tytso, jaegeuk, nhorman, ard.biesheuvel, mh1, linux-crypto,
linux-kernel, Bintian, liushuoran, Huxinwei, zhangzhibin.zhang
In-Reply-To: <20160908124709.GA26586@gondor.apana.org.au>
Sorry for resend this email, just add the linux-crypto@vger.kernel.org
and linux-kernel@vger.kernel.org.
Hi,
Firstly, thanks for your reply!
To reproduce this kernel panic, I test the encryption/decryption feature
on arm64 board with more memory. Just add the following
change:
diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index 0122bec..10ef3f4 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -240,6 +240,7 @@ static int blkcipher_walk_next(struct
blkcipher_desc *desc,
walk->flags |= BLKCIPHER_WALK_COPY;
if (!walk->page) {
walk->page = (void
*)__get_free_page(GFP_ATOMIC);
+ walk->page = NULL;
if (!walk->page)
n = 0;
}
This change just set the walk->page to NULL manually.
I get the same crash when open file with the above change log. So I
think this NULL page failure is not be handled correctly in current code.
Regards
Kaixu Xia
> On Thu, Sep 08, 2016 at 08:38:43PM +0800, xiakaixu wrote:
>> Hi,
>>
>> I am using the encryption/decryption feature on arm64 board and a kernel
>> panic occurs just when open a file. As the memory size of the board
>> is limited
>> and there are some page allocation failures before the panic.
>>
>> Seems it is a kernel bug from the call trace log.
>>
>> ...
>> - fscrypt_get_encryption_info
>> - get_crypt_info.part.1
>> - validate_user_key.isra.0
>> - derive_aes_gcm_key
>> - crypto_gcm_decrypt
>> - ablk_decrypt
>> - ctr_encrypt
>> - blkcipher_walk_done
>> - blkcipher_walk_next
>> - __get_free_pages
>> ----------------------------------> page allocation failure
>> ...
>> - aes_ctr_encrypt
>> -----------------------------------------> the input parameter is
>> NULL pointer as the page allocation failure
>>
>>
>> The input parameter of function aes_ctr_encrypt() comes from the
>> /struct blkcipher_walk//
>> //walk/, and this variable /walk /is allocated by the function
>> __get_free_pages(). So if this
>> page allocate failed, the input parameter of function
>> aes_ctr_encrypt() will be NULL. The
>> panic will occurs if we don't check the input parameter.
>>
>> Not sure about this and wish to get your opinions!
>
> If the page allocation fails in blkcipher_walk_next it'll simply
> switch over to processing it block by block. so I don't think the
> warning is related to the crash.
>
> Cheers,
>
^ permalink raw reply
* test
From: xiakaixu @ 2016-09-09 3:47 UTC (permalink / raw)
To: linux-kernel, linux-crypto
Sorry for noise!
--
Regards
Kaixu Xia
^ permalink raw reply
* Re: [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration
From: Herbert Xu @ 2016-09-08 17:02 UTC (permalink / raw)
To: Romain Perier
Cc: PrasannaKumar Muralidharan, dsaxena, mpm, Gregory Clement,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas, linux-crypto
In-Reply-To: <57D18801.5050901@free-electrons.com>
On Thu, Sep 08, 2016 at 05:47:13PM +0200, Romain Perier wrote:
>
> I was wondering something. hwrng_unregister does not check the kref
> reference counter of the object... so technically if the current
> rng_device is in use, with or without devm... calling
> platform->remove will break the driver anyway because
> hwrng_unregister will unbind the device from /dev/hwrng. What I mean
> is that I think that we had this issue even without
> devm_hwrng_register.
>
> Herbert, could you confirm ?
Right. remove can happen at any time and the driver needs to
cope with it by returning an error from data_read if the hardware
disappears in the middle of an operation.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: BUG in recvmsg using io_submit
From: Stephan Mueller @ 2016-09-08 15:50 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
In-Reply-To: <2637498.CLV37KecV5@positron.chronox.de>
Am Donnerstag, 8. September 2016, 04:52:08 CEST schrieb Stephan Mueller:
Hi,
> Hi Herbert,
>
> another one, different than the first report
Please note that the error seems to be triggered due to a bad use of the user
space interface: When submitting the iov, I told the kernel that iovlen is the
size of the buffer instead of the number of iovs.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration
From: Romain Perier @ 2016-09-08 15:47 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: dsaxena, mpm, Herbert Xu, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas,
linux-crypto
In-Reply-To: <CANc+2y5yzMNeHEgf6FfQHiN=-528YZgB3JwVcqa3C-s8s_RCfA@mail.gmail.com>
Le 07/09/2016 16:45, PrasannaKumar Muralidharan a écrit :
> On 7 September 2016 at 19:53, Romain Perier
> <romain.perier@free-electrons.com> wrote:
>> Hello,
>>
>>
>> Le 06/09/2016 18:31, PrasannaKumar Muralidharan a écrit :
>>>>
>>>> Use devm_hwrng_register instead of hwrng_register. It avoids the need
>>>> to handle unregistration explicitly from the remove function.
>>>>
>>>> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
>>>> ---
>>>> drivers/char/hw_random/omap-rng.c | 4 +---
>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/char/hw_random/omap-rng.c
>>>> b/drivers/char/hw_random/omap-rng.c
>>>> index d47b24d..171c3e8 100644
>>>> --- a/drivers/char/hw_random/omap-rng.c
>>>> +++ b/drivers/char/hw_random/omap-rng.c
>>>> @@ -381,7 +381,7 @@ static int omap_rng_probe(struct platform_device
>>>> *pdev)
>>>> if (ret)
>>>> goto err_ioremap;
>>>>
>>>> - ret = hwrng_register(&omap_rng_ops);
>>>> + ret = devm_hwrng_register(dev, &omap_rng_ops);
>>>> if (ret)
>>>> goto err_register;
>>>>
>>>> @@ -402,8 +402,6 @@ static int omap_rng_remove(struct platform_device
>>>> *pdev)
>>>> {
>>>> struct omap_rng_dev *priv = platform_get_drvdata(pdev);
>>>>
>>>> - hwrng_unregister(&omap_rng_ops);
>>>> -
>>>> priv->pdata->cleanup(priv);
>>>>
>>>> pm_runtime_put_sync(&pdev->dev);
>>>> --
>>>
>>>
>>> If devm_hwrng_register is used hwrng_unregister will be called after
>>> pm_runtime_disable is called. If RNG device is in use calling
>>> omap_rng_remove may not work properly.
>>>
>>
>> The case where the remove function is called is if you unbind the driver by
>> hand or you call rmmod while the RNG device is used.
>> I don't think that the kernel will call platform->remove is the device is in
>> use (so /dev/hwrng). I mean the argument that the unregister function is
>> called after pm_runtime_disable is correct, but I don't think that the
>> remove function might be called while the device is in use. There is
>> necessarily a mutual exclusive case between "use the device" and "call the
>> remove function of the device". However, I am open to suggestions.
>
> The way you explained is good :D. Good point too. But the device is
> created by hw_random core (hwrng_modinit in core.c) so the device can
> be in use when omap-rng module is removed. Please feel free to correct
> me if I am wrong.
>
> Cheers,
> PrasannaKumar
>
Hi,
I was wondering something. hwrng_unregister does not check the kref
reference counter of the object... so technically if the current
rng_device is in use, with or without devm... calling platform->remove
will break the driver anyway because hwrng_unregister will unbind the
device from /dev/hwrng. What I mean is that I think that we had this
issue even without devm_hwrng_register.
Herbert, could you confirm ?
Romain
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] crypto: engine: fix linux-next merge conflict
From: Arnd Bergmann @ 2016-09-08 13:57 UTC (permalink / raw)
To: Andrew Morton
Cc: Petr Mladek, Corentin Labbe, Herbert Xu, Stephen Rothwell,
Arnd Bergmann, David S. Miller, linux-crypto, linux-kernel
A merge conflict between the akpm-current tree and the crypto tree
caused a build failure in ARM allmodconfig today:
crypto/crypto_engine.c: In function 'crypto_transfer_hash_request':
crypto/crypto_engine.c:234:3: error: implicit declaration of function 'queue_kthread_work' [-Werror=implicit-function-declaration]
This adapts the crypto code to the API change.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 4cba7cf025f3 ("crypto: engine - permit to enqueue ashash_request")
Fixes: 8ca76638a2d0 ("kthread: kthread worker API cleanup")
---
crypto/crypto_engine.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
index 64fcd9ee3e2e..6989ba0046df 100644
--- a/crypto/crypto_engine.c
+++ b/crypto/crypto_engine.c
@@ -231,7 +231,7 @@ int crypto_transfer_hash_request(struct crypto_engine *engine,
ret = ahash_enqueue_request(&engine->queue, req);
if (!engine->busy && need_pump)
- queue_kthread_work(&engine->kworker, &engine->pump_requests);
+ kthread_queue_work(&engine->kworker, &engine->pump_requests);
spin_unlock_irqrestore(&engine->queue_lock, flags);
return ret;
@@ -284,7 +284,7 @@ void crypto_finalize_cipher_request(struct crypto_engine *engine,
req->base.complete(&req->base, err);
- queue_kthread_work(&engine->kworker, &engine->pump_requests);
+ kthread_queue_work(&engine->kworker, &engine->pump_requests);
}
EXPORT_SYMBOL_GPL(crypto_finalize_cipher_request);
--
2.9.0
^ permalink raw reply related
* Re: Kernel panic - encryption/decryption failed when open file on Arm64
From: Herbert Xu @ 2016-09-08 12:47 UTC (permalink / raw)
To: xiakaixu
Cc: davem, tytso, jaegeuk, nhorman, ard.biesheuvel, mh1, linux-crypto,
linux-kernel, Bintian, liushuoran, Huxinwei, zhangzhibin.zhang
In-Reply-To: <57D15BD3.40903@huawei.com>
On Thu, Sep 08, 2016 at 08:38:43PM +0800, xiakaixu wrote:
> Hi,
>
> I am using the encryption/decryption feature on arm64 board and a kernel
> panic occurs just when open a file. As the memory size of the board
> is limited
> and there are some page allocation failures before the panic.
>
> Seems it is a kernel bug from the call trace log.
>
> ...
> - fscrypt_get_encryption_info
> - get_crypt_info.part.1
> - validate_user_key.isra.0
> - derive_aes_gcm_key
> - crypto_gcm_decrypt
> - ablk_decrypt
> - ctr_encrypt
> - blkcipher_walk_done
> - blkcipher_walk_next
> - __get_free_pages
> ----------------------------------> page allocation failure
> ...
> - aes_ctr_encrypt
> -----------------------------------------> the input parameter is
> NULL pointer as the page allocation failure
>
>
> The input parameter of function aes_ctr_encrypt() comes from the
> /struct blkcipher_walk//
> //walk/, and this variable /walk /is allocated by the function
> __get_free_pages(). So if this
> page allocate failed, the input parameter of function
> aes_ctr_encrypt() will be NULL. The
> panic will occurs if we don't check the input parameter.
>
> Not sure about this and wish to get your opinions!
If the page allocation fails in blkcipher_walk_next it'll simply
switch over to processing it block by block. so I don't think the
warning is related to the crash.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: rmmod crypto driver when ipsec is in use
From: Herbert Xu @ 2016-09-08 11:19 UTC (permalink / raw)
To: Harsh Jain; +Cc: linux-crypto, Stephan Mueller
In-Reply-To: <CAFXBA==cKF9DgBtMSEK42D-ukw4VX6NRVXgCAbiLf-XqMUAGOA@mail.gmail.com>
On Thu, Sep 08, 2016 at 03:17:46PM +0530, Harsh Jain wrote:
> Hi,
>
> What is the expected behavior when driver is unregistered(Rmmod ) with
> active ipsec session.?
> I am getting stacktrace(BUG_ON in crypto_unregister_alg) instead of
> "module in use".
The driver is supposed to set cra_module to itself. If it doesn't
then it's buggy.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* rmmod crypto driver when ipsec is in use
From: Harsh Jain @ 2016-09-08 9:47 UTC (permalink / raw)
To: linux-crypto, Herbert Xu, Stephan Mueller
Hi,
What is the expected behavior when driver is unregistered(Rmmod ) with
active ipsec session.?
I am getting stacktrace(BUG_ON in crypto_unregister_alg) instead of
"module in use".
Regards
Harsh Jain
^ permalink raw reply
* BUG in recvmsg using io_submit
From: Stephan Mueller @ 2016-09-08 2:52 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
Hi Herbert,
another one, different than the first report
[71972.773115] page:ffffea0001fabf40 count:0 mapcount:0 mapping: (null) index:0x0
[71972.773118] flags: 0x1ffffc00000000()
[71972.773119] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
[71972.773140] ------------[ cut here ]------------
[71972.774961] kernel BUG at include/linux/mm.h:420!
[71972.776738] invalid opcode: 0000 [#4] SMP
[71972.778521] Modules linked in: serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 serpent_generic loop crypto_user vhost_net vhost macvtap macvlan rfcomm xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_security ip6table_mangle ip6table_raw ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 iptable_security iptable_mangle iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables bnep nls_utf8 hfsplus intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel brcmfmac kvm joydev iTCO_wdt iTCO_vendor_support applesmc irqbypass input_polldev brcmutil intel_cstate inte
l_uncore cfg80211
[71972.782836] btusb intel_rapl_perf snd_hda_codec_hdmi snd_hda_codec_cirrus snd_hda_codec_generic btrtl btbcm snd_hda_intel snd_hda_codec btintel bluetooth snd_hda_core snd_hwdep mmc_core snd_seq i2c_i801 intel_pch_thermal snd_seq_device thunderbolt snd_pcm rfkill bcm5974 snd_timer mei_me snd lpc_ich mei shpchp dw_dmac_pci soundcore spi_pxa2xx_pci acpi_als kfifo_buf industrialio spi_pxa2xx_platform sbs apple_bl tpm_tis sbshc tpm nfsd auth_rpcgss binfmt_misc nfs_acl lockd grace sunrpc dm_crypt hid_apple i915 crct10dif_pclmul crc32_pclmul crc32c_intel i2c_algo_bit drm_kms_helper uas usb_storage ghash_clmulni_intel drm fjes video
[71972.789497] CPU: 3 PID: 26006 Comm: kcapi Tainted: G D 4.7.2-201.fc24.x86_64 #1
[71972.792255] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B17.1606231721 06/23/2016
[71972.794492] task: ffff8803fe6e1e80 ti: ffff880046c40000 task.ti: ffff880046c40000
[71972.796679] RIP: 0010:[<ffffffff8139957e>] [<ffffffff8139957e>] skcipher_free_async_sgls+0xde/0x120
[71972.798884] RSP: 0018:ffff880046c43bd8 EFLAGS: 00010246
[71972.801085] RAX: 000000000000003e RBX: ffffea0001fabf40 RCX: 0000000000000006
[71972.803300] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88046ecce060
[71972.805478] RBP: ffff880046c43c00 R08: 000000000000097d R09: 0000000000000005
[71972.807592] R10: ffff88041fcbccc0 R11: ffffffff81f3edad R12: 0000000000000000
[71972.809670] R13: ffff88041fcba000 R14: 0000000000000001 R15: ffff88041128cf40
[71972.811749] FS: 00007fd2fc61e700(0000) GS:ffff88046ecc0000(0000) knlGS:0000000000000000
[71972.813839] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[71972.815931] CR2: 00007fd2fc649000 CR3: 000000007ead7000 CR4: 00000000003406e0
[71972.817978] Stack:
[71972.819968] ffff88022e035da8 0000000000000010 ffff88041fcba000 0000000000000000
[71972.822444] 0000000000000001 ffff880046c43ca0 ffffffff81399b07 ffff88041fcba3d8
[71972.825780] ffff88041fcba2b0 ffff88041fcba008 0000000000000000 0000000000000000
[71972.828995] Call Trace:
[71972.832162] [<ffffffff81399b07>] skcipher_recvmsg+0x547/0x720
[71972.834912] [<ffffffff816ae640>] ? sock_recvmsg+0x50/0x50
[71972.837625] [<ffffffff816ae62d>] sock_recvmsg+0x3d/0x50
[71972.840318] [<ffffffff816ae6d0>] sock_read_iter+0x90/0xe0
[71972.842997] [<ffffffff8129677b>] aio_run_iocb+0x12b/0x2d0
[71972.845696] [<ffffffff812976c6>] ? do_io_submit+0x196/0x550
[71972.845698] [<ffffffff81264b53>] ? __fdget+0x13/0x20
[71972.845699] [<ffffffff812977c1>] do_io_submit+0x291/0x550
[71972.845701] [<ffffffff81297a90>] SyS_io_submit+0x10/0x20
[71972.845703] [<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4
[71972.845721] Code: 49 8b 1f 48 83 e3 fc 48 8b 43 20 48 8d 50 ff a8 01 48 0f 45 da 8b 43 1c 85 c0 75 bb 48 c7 c6 68 46 a1 81 48 89 df e8 b2 d9 e4 ff <0f> 0b 48 89 df e8 58 e4 e2 ff 48 8b 03 48 c1 e8 34 83 e0 07 83
[71972.845724] RIP [<ffffffff8139957e>] skcipher_free_async_sgls+0xde/0x120
[71972.845724] RSP <ffff880046c43bd8>
[71972.845762] ---[ end trace e16e0f71a7a79254 ]---
Ciao
Stephan
^ permalink raw reply
* BUG while working on algif_skcipher AIO support
From: Stephan Mueller @ 2016-09-08 2:23 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
Hi Herbert,
here is a reliably producable bug that I triggered while educating my libkcapi
about AIO support.
[70129.671557] page:ffffea0001361d80 count:0 mapcount:0 mapping:
(null) index:0x0
[70129.671560] flags: 0x1ffffc00000000()
[70129.671562] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
[70129.671581] ------------[ cut here ]------------
[70129.671599] kernel BUG at include/linux/mm.h:420!
[70129.671612] invalid opcode: 0000 [#2] SMP
[70129.671623] Modules linked in: serpent_avx2 serpent_avx_x86_64
serpent_sse2_x86_64 serpent_generic loop crypto_user vhost_net vhost macvtap
macvlan rfcomm xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun
ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter xt_conntrack ip_set nfnetlink
ebtable_nat ebtable_broute bridge stp llc ip6table_security ip6table_mangle
ip6table_raw ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
iptable_security iptable_mangle iptable_raw iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ebtable_filter ebtables
ip6table_filter ip6_tables bnep nls_utf8 hfsplus intel_rapl
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel brcmfmac kvm joydev
iTCO_wdt iTCO_vendor_support applesmc irqbypass input_polldev brcmutil
intel_cstate intel_uncore cfg80211
[70129.671875] btusb intel_rapl_perf snd_hda_codec_hdmi snd_hda_codec_cirrus
snd_hda_codec_generic btrtl btbcm snd_hda_intel snd_hda_codec btintel
bluetooth snd_hda_core snd_hwdep mmc_core snd_seq i2c_i801 intel_pch_thermal
snd_seq_device thunderbolt snd_pcm rfkill bcm5974 snd_timer mei_me snd lpc_ich
mei shpchp dw_dmac_pci soundcore spi_pxa2xx_pci acpi_als kfifo_buf
industrialio spi_pxa2xx_platform sbs apple_bl tpm_tis sbshc tpm nfsd
auth_rpcgss binfmt_misc nfs_acl lockd grace sunrpc dm_crypt hid_apple i915
crct10dif_pclmul crc32_pclmul crc32c_intel i2c_algo_bit drm_kms_helper uas
usb_storage ghash_clmulni_intel drm fjes video
[70129.672075] CPU: 2 PID: 24751 Comm: kcapi Tainted: G D
4.7.2-201.fc24.x86_64 #1
[70129.672095] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6,
BIOS MBP121.88Z.0167.B17.1606231721 06/23/2016
[70129.672120] task: ffff8801f2f53d00 ti: ffff88004f5c4000 task.ti:
ffff88004f5c4000
[70129.672138] RIP: 0010:[<ffffffff81398811>] [<ffffffff81398811>]
skcipher_pull_sgl+0x171/0x180
[70129.672163] RSP: 0018:ffff88004f5c7d38 EFLAGS: 00010246
[70129.672176] RAX: 000000000000003e RBX: ffff880228ae1018 RCX:
0000000000000006
[70129.672193] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffff88046ec8e060
[70129.672210] RBP: ffff88004f5c7d80 R08: 0000000000000922 R09:
0000000000000005
[70129.672227] R10: ffff8803fc90efb0 R11: ffffffff81f3edad R12:
0000000000000001
[70129.672244] R13: 0000000000000000 R14: 0000000000000000 R15:
ffff88044a671800
[70129.672262] FS: 00007f99962aa700(0000) GS:ffff88046ec80000(0000) knlGS:
0000000000000000
[70129.672281] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[70129.672296] CR2: 000000000170e1d8 CR3: 00000000250b0000 CR4:
00000000003406e0
[70129.672313] Stack:
[70129.672318] ffff88044a677800 ffff8803fc90e1d0 ffff8803fc90e0b0
ffff8803fc90e1d0
[70129.672340] ffff88044a677ac8 ffff88044a671800 ffff88044a677800
ffff88044a4a6ba8
[70129.672361] ffff88020f5ae900 ffff88004f5c7db0 ffffffff8139889a
ffff88044a677ac8
[70129.672382] Call Trace:
[70129.672390] [<ffffffff8139889a>] skcipher_sock_destruct+0x7a/0xc0
[70129.672406] [<ffffffff816b2746>] __sk_destruct+0x26/0x140
[70129.672420] [<ffffffff816b42a0>] sk_destruct+0x20/0x30
[70129.672434] [<ffffffff816b42f3>] __sk_free+0x43/0xa0
[70129.672447] [<ffffffff816b4368>] sk_free+0x18/0x20
[70129.672460] [<ffffffff81397963>] af_alg_release+0x23/0x30
[70129.672474] [<ffffffff816ad79f>] sock_release+0x1f/0x80
[70129.672488] [<ffffffff816ad812>] sock_close+0x12/0x20
[70129.672502] [<ffffffff812481df>] __fput+0xdf/0x1f0
[70129.672514] [<ffffffff8124832e>] ____fput+0xe/0x10
[70129.672527] [<ffffffff810bd923>] task_work_run+0x83/0xb0
[70129.672542] [<ffffffff81003342>] exit_to_usermode_loop+0xc2/0xd0
[70129.672557] [<ffffffff81003ce1>] syscall_return_slowpath+0xa1/0xb0
[70129.672574] [<ffffffff817eb8fa>] entry_SYSCALL_64_fastpath+0xa2/0xa4
[70129.672589] Code: 00 00 00 75 08 41 c6 87 fd 02 00 00 00 48 83 c4 20 5b 41
5c 41 5d 41 5e 41 5f 5d c3 48 c7 c6 68 46 a1 81 48 89 c7 e8 1f e7 e4 ff <0f>
0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55
[70129.672692] RIP [<ffffffff81398811>] skcipher_pull_sgl+0x171/0x180
[70129.672709] RSP <ffff88004f5c7d38>
[70129.672726] ---[ end trace e16e0f71a7a79252 ]---
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] crypto: qce: Initialize core src clock @100Mhz
From: Iaroslav Gridin @ 2016-09-07 17:25 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: herbert, davem, linux-crypto, linux-kernel, andy.gross,
david.brown, linux-arm-msm, linux-soc
In-Reply-To: <4e509050-6e8e-069c-f00d-eca9a0f3b33d@mm-sol.com>
> > + ret = clk_set_rate(qce->core_src, 100000000);
>
> Could you point me from where you got this number?
I got it from codeaurora qce driver:
https://android.googlesource.com/kernel/msm/+/android-msm-hammerhead-3.4-kk-r1/drivers/crypto/msm/qce50.c#3386
^ permalink raw reply
* Re: [PATCH] crypto: qce: Initialize core src clock @100Mhz
From: Iaroslav Gridin @ 2016-09-07 16:13 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: herbert, davem, linux-crypto, linux-kernel, andy.gross,
david.brown, linux-arm-msm, linux-soc
In-Reply-To: <4e509050-6e8e-069c-f00d-eca9a0f3b33d@mm-sol.com>
On Wed, Sep 07, 2016 at 04:04:01PM +0300, Stanimir Varbanov wrote:
> Hi Iaroslav,
>
> On 09/03/2016 07:45 PM, Iaroslav Gridin wrote:
> > Without that, QCE performance is about 2x less.
>
> On which platform? The clock rates are per SoC.
Dragonboard 8074. Should clock rate be moved to its DT?
> >
> > Signed-off-by: Iaroslav Gridin <voker57@gmail.com>
> > ---
> > drivers/crypto/qce/core.c | 18 +++++++++++++++++-
> > drivers/crypto/qce/core.h | 2 +-
> > 2 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
> > index 0cde513..657354c 100644
> > --- a/drivers/crypto/qce/core.c
> > +++ b/drivers/crypto/qce/core.c
> > @@ -193,6 +193,10 @@ static int qce_crypto_probe(struct platform_device *pdev)
> > if (ret < 0)
> > return ret;
> >
> > + qce->core_src = devm_clk_get(qce->dev, "core_src");
> > + if (IS_ERR(qce->core_src))
> > + return PTR_ERR(qce->core_src);
> > +
> > qce->core = devm_clk_get(qce->dev, "core");
> > if (IS_ERR(qce->core))
> > return PTR_ERR(qce->core);
> > @@ -205,10 +209,20 @@ static int qce_crypto_probe(struct platform_device *pdev)
> > if (IS_ERR(qce->bus))
> > return PTR_ERR(qce->bus);
> >
> > - ret = clk_prepare_enable(qce->core);
> > + ret = clk_prepare_enable(qce->core_src);
> > if (ret)
> > return ret;
> >
> > + ret = clk_set_rate(qce->core_src, 100000000);
>
> Could you point me from where you got this number? Also I think you
> shouldn't be requesting "core_src" it should be a parent of "core" clock
> in the clock tree. Did you tried to set rate on "core" clock?
Tried it, helps with speed as well.
^ permalink raw reply
* [PATCH v2 8/8] arm64: dts: marvell: add TRNG description for Armada 8K CP
From: Romain Perier @ 2016-09-07 15:57 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160907155743.6403-1-romain.perier@free-electrons.com>
This commits adds the devicetree description of the SafeXcel IP-76 TRNG
found in the two Armada CP110.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 8 ++++++++
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 8 ++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index da31bbb..aaffa24 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -164,6 +164,14 @@
clocks = <&cpm_syscon0 1 21>;
status = "disabled";
};
+
+ cpm_trng: trng@760000 {
+ compatible = "marvell,armada-8k-rng", "inside-secure,safexcel-eip76";
+ reg = <0x760000 0x7d>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpm_syscon0 1 25>;
+ status = "okay";
+ };
};
cpm_pcie0: pcie@f2600000 {
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 6ff1201..216de12 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -164,6 +164,14 @@
clocks = <&cps_syscon0 1 21>;
status = "disabled";
};
+
+ cps_trng: trng@760000 {
+ compatible = "marvell,armada-8k-rng", "inside-secure,safexcel-eip76";
+ reg = <0x760000 0x7d>;
+ interrupts = <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cps_syscon0 1 25>;
+ status = "okay";
+ };
};
cps_pcie0: pcie@f4600000 {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 7/8] hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K
From: Romain Perier @ 2016-09-07 15:57 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160907155743.6403-1-romain.perier@free-electrons.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 6241 bytes --]
This commits adds a device variant for Safexcel,EIP76 found in Marvell
Armada 8k. It defines registers mapping with the good offset and add a
specific initialization function.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v2:
- Call pm_runtime_put_sync from the label err_register. When there is an
EPROBE_DEFER, strange errors can happen because the call to pm_runtime_*
is not well balanced.
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/omap-rng.c | 86 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 85 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 56ad5a5..aea3613 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -168,7 +168,7 @@ config HW_RANDOM_IXP4XX
config HW_RANDOM_OMAP
tristate "OMAP Random Number Generator support"
- depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
+ depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS || ARCH_MVEBU
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 861145e..215c23a 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -28,6 +28,7 @@
#include <linux/of_device.h>
#include <linux/of_address.h>
#include <linux/interrupt.h>
+#include <linux/clk.h>
#include <asm/io.h>
@@ -63,6 +64,7 @@
#define OMAP2_RNG_OUTPUT_SIZE 0x4
#define OMAP4_RNG_OUTPUT_SIZE 0x8
+#define EIP76_RNG_OUTPUT_SIZE 0x10
enum {
RNG_OUTPUT_0_REG = 0,
@@ -108,6 +110,23 @@ static const u16 reg_map_omap4[] = {
[RNG_SYSCONFIG_REG] = 0x1FE4,
};
+static const u16 reg_map_eip76[] = {
+ [RNG_OUTPUT_0_REG] = 0x0,
+ [RNG_OUTPUT_1_REG] = 0x4,
+ [RNG_OUTPUT_2_REG] = 0x8,
+ [RNG_OUTPUT_3_REG] = 0xc,
+ [RNG_STATUS_REG] = 0x10,
+ [RNG_INTACK_REG] = 0x10,
+ [RNG_CONTROL_REG] = 0x14,
+ [RNG_CONFIG_REG] = 0x18,
+ [RNG_ALARMCNT_REG] = 0x1c,
+ [RNG_FROENABLE_REG] = 0x20,
+ [RNG_FRODETUNE_REG] = 0x24,
+ [RNG_ALARMMASK_REG] = 0x28,
+ [RNG_ALARMSTOP_REG] = 0x2c,
+ [RNG_REV_REG] = 0x7c,
+};
+
struct omap_rng_dev;
/**
* struct omap_rng_pdata - RNG IP block-specific data
@@ -130,6 +149,7 @@ struct omap_rng_dev {
struct device *dev;
const struct omap_rng_pdata *pdata;
struct hwrng rng;
+ struct clk *clk;
};
static inline u32 omap_rng_read(struct omap_rng_dev *priv, u16 reg)
@@ -213,6 +233,38 @@ static inline u32 omap4_rng_data_present(struct omap_rng_dev *priv)
return omap_rng_read(priv, RNG_STATUS_REG) & RNG_REG_STATUS_RDY;
}
+static int eip76_rng_init(struct omap_rng_dev *priv)
+{
+ u32 val;
+
+ /* Return if RNG is already running. */
+ if (omap_rng_read(priv, RNG_CONTROL_REG) & RNG_CONTROL_ENABLE_TRNG_MASK)
+ return 0;
+
+ /* Number of 512 bit blocks of raw Noise Source output data that must
+ * be processed by either the Conditioning Function or the
+ * SP 800-90 DRBG ‘BC_DF’ functionality to yield a ‘full entropy’
+ * output value.
+ */
+ val = 0x5 << RNG_CONFIG_MIN_REFIL_CYCLES_SHIFT;
+
+ /* Number of FRO samples that are XOR-ed together into one bit to be
+ * shifted into the main shift register
+ */
+ val |= RNG_CONFIG_MAX_REFIL_CYCLES << RNG_CONFIG_MAX_REFIL_CYCLES_SHIFT;
+ omap_rng_write(priv, RNG_CONFIG_REG, val);
+
+ /* Enable all available FROs */
+ omap_rng_write(priv, RNG_FRODETUNE_REG, 0x0);
+ omap_rng_write(priv, RNG_FROENABLE_REG, RNG_REG_FROENABLE_MASK);
+
+ /* Enable TRNG */
+ val = RNG_CONTROL_ENABLE_TRNG_MASK;
+ omap_rng_write(priv, RNG_CONTROL_REG, val);
+
+ return 0;
+}
+
static int omap4_rng_init(struct omap_rng_dev *priv)
{
u32 val;
@@ -282,6 +334,14 @@ static struct omap_rng_pdata omap4_rng_pdata = {
.cleanup = omap4_rng_cleanup,
};
+static struct omap_rng_pdata eip76_rng_pdata = {
+ .regs = (u16 *)reg_map_eip76,
+ .data_size = EIP76_RNG_OUTPUT_SIZE,
+ .data_present = omap4_rng_data_present,
+ .init = eip76_rng_init,
+ .cleanup = omap4_rng_cleanup,
+};
+
static const struct of_device_id omap_rng_of_match[] = {
{
.compatible = "ti,omap2-rng",
@@ -291,6 +351,10 @@ static const struct of_device_id omap_rng_of_match[] = {
.compatible = "ti,omap4-rng",
.data = &omap4_rng_pdata,
},
+ {
+ .compatible = "inside-secure,safexcel-eip76",
+ .data = &eip76_rng_pdata,
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rng_of_match);
@@ -309,7 +373,8 @@ static int of_get_omap_rng_device_details(struct omap_rng_dev *priv,
}
priv->pdata = match->data;
- if (of_device_is_compatible(dev->of_node, "ti,omap4-rng")) {
+ if (of_device_is_compatible(dev->of_node, "ti,omap4-rng") ||
+ of_device_is_compatible(dev->of_node, "inside-secure,safexcel-eip76")) {
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "%s: error getting IRQ resource - %d\n",
@@ -325,6 +390,16 @@ static int of_get_omap_rng_device_details(struct omap_rng_dev *priv,
return err;
}
omap_rng_write(priv, RNG_INTMASK_REG, RNG_SHUTDOWN_OFLO_MASK);
+
+ priv->clk = of_clk_get(pdev->dev.of_node, 0);
+ if (IS_ERR(priv->clk) && PTR_ERR(priv->clk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ if (!IS_ERR(priv->clk)) {
+ err = clk_prepare_enable(priv->clk);
+ if (err)
+ dev_err(&pdev->dev, "unable to enable the clk, "
+ "err = %d\n", err);
+ }
}
return 0;
}
@@ -386,7 +461,7 @@ static int omap_rng_probe(struct platform_device *pdev)
ret = (dev->of_node) ? of_get_omap_rng_device_details(priv, pdev) :
get_omap_rng_device_details(priv);
if (ret)
- goto err_ioremap;
+ goto err_register;
ret = hwrng_register(&priv->rng);
if (ret)
@@ -399,7 +474,11 @@ static int omap_rng_probe(struct platform_device *pdev)
err_register:
priv->base = NULL;
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+
+ if (!IS_ERR(priv->clk))
+ clk_disable_unprepare(priv->clk);
err_ioremap:
dev_err(dev, "initialization failed.\n");
return ret;
@@ -416,6 +495,9 @@ static int omap_rng_remove(struct platform_device *pdev)
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ if (!IS_ERR(priv->clk))
+ clk_disable_unprepare(priv->clk);
+
return 0;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/8] hwrng: omap - Don't prefix the probe message with OMAP
From: Romain Perier @ 2016-09-07 15:57 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160907155743.6403-1-romain.perier@free-electrons.com>
So far, this driver was only used for OMAP SoCs. However, if a device
variant is added for an IP block that has nothing to do with the OMAP
platform, the message "OMAP Random Number Generator Ver" is displayed
anyway. Instead of hardcoding "OMAP" into this message, we decide to
only display "Random Number Generator". As dev_info is already
pre-pending the message with the name of the device, we have enough
informations.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/char/hw_random/omap-rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 6924da57..861145e 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -392,7 +392,7 @@ static int omap_rng_probe(struct platform_device *pdev)
if (ret)
goto err_register;
- dev_info(&pdev->dev, "OMAP Random Number Generator ver. %02x\n",
+ dev_info(&pdev->dev, "Random Number Generator ver. %02x\n",
omap_rng_read(priv, RNG_REV_REG));
return 0;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/8] hwrng: omap - Add support for 128-bit output of data
From: Romain Perier @ 2016-09-07 15:57 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160907155743.6403-1-romain.perier@free-electrons.com>
So far, this driver only supports up to 64 bits of output data generated
by an RNG. Some IP blocks, like the SafeXcel IP-76 supports up to 128
bits of output data. This commits renames registers descriptions
OUTPUT_L_REG and OUTPUT_H_REG to OUTPUT_0_REG and OUPUT_1_REG,
respectively. It also adds two new values to the enumeration of existing
registers: OUTPUT_2_REG and OUTPUT_3_REG.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/char/hw_random/omap-rng.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index b20e8d7..6924da57 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -65,8 +65,10 @@
#define OMAP4_RNG_OUTPUT_SIZE 0x8
enum {
- RNG_OUTPUT_L_REG = 0,
- RNG_OUTPUT_H_REG,
+ RNG_OUTPUT_0_REG = 0,
+ RNG_OUTPUT_1_REG,
+ RNG_OUTPUT_2_REG,
+ RNG_OUTPUT_3_REG,
RNG_STATUS_REG,
RNG_INTMASK_REG,
RNG_INTACK_REG,
@@ -82,7 +84,7 @@ enum {
};
static const u16 reg_map_omap2[] = {
- [RNG_OUTPUT_L_REG] = 0x0,
+ [RNG_OUTPUT_0_REG] = 0x0,
[RNG_STATUS_REG] = 0x4,
[RNG_CONFIG_REG] = 0x28,
[RNG_REV_REG] = 0x3c,
@@ -90,8 +92,8 @@ static const u16 reg_map_omap2[] = {
};
static const u16 reg_map_omap4[] = {
- [RNG_OUTPUT_L_REG] = 0x0,
- [RNG_OUTPUT_H_REG] = 0x4,
+ [RNG_OUTPUT_0_REG] = 0x0,
+ [RNG_OUTPUT_1_REG] = 0x4,
[RNG_STATUS_REG] = 0x8,
[RNG_INTMASK_REG] = 0xc,
[RNG_INTACK_REG] = 0x10,
@@ -155,7 +157,7 @@ static int omap_rng_do_read(struct hwrng *rng, void *data, size_t max,
if (!priv->pdata->data_present(priv))
return 0;
- memcpy_fromio(data, priv->base + priv->pdata->regs[RNG_OUTPUT_L_REG],
+ memcpy_fromio(data, priv->base + priv->pdata->regs[RNG_OUTPUT_0_REG],
priv->pdata->data_size);
if (priv->pdata->regs[RNG_INTACK_REG])
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/8] hwrng: omap - Remove global definition of hwrng
From: Romain Perier @ 2016-09-07 15:57 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160907155743.6403-1-romain.perier@free-electrons.com>
The omap-rng driver currently assumes that there will only ever be a
single instance of an RNG device. For this reason, there is a statically
allocated struct hwrng, with a fixed name. However, registering two
struct hwrng with the same isn't accepted by the RNG framework, so we
need to switch to a dynamically allocated struct hwrng, each using a
different name. Then, we define the name of this hwrng to "dev_name(dev)",
so the name of the data structure is unique per device.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v2:
- Fix the goto label used when there is an error for devm_kstrdup
drivers/char/hw_random/omap-rng.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index d47b24d..b20e8d7 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -127,6 +127,7 @@ struct omap_rng_dev {
void __iomem *base;
struct device *dev;
const struct omap_rng_pdata *pdata;
+ struct hwrng rng;
};
static inline u32 omap_rng_read(struct omap_rng_dev *priv, u16 reg)
@@ -179,12 +180,6 @@ static void omap_rng_cleanup(struct hwrng *rng)
priv->pdata->cleanup(priv);
}
-static struct hwrng omap_rng_ops = {
- .name = "omap",
- .read = omap_rng_do_read,
- .init = omap_rng_init,
- .cleanup = omap_rng_cleanup,
-};
static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
{
@@ -357,7 +352,11 @@ static int omap_rng_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
- omap_rng_ops.priv = (unsigned long)priv;
+ priv->rng.read = omap_rng_do_read;
+ priv->rng.init = omap_rng_init;
+ priv->rng.cleanup = omap_rng_cleanup;
+
+ priv->rng.priv = (unsigned long)priv;
platform_set_drvdata(pdev, priv);
priv->dev = dev;
@@ -368,6 +367,12 @@ static int omap_rng_probe(struct platform_device *pdev)
goto err_ioremap;
}
+ priv->rng.name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
+ if (!priv->rng.name) {
+ ret = -ENOMEM;
+ goto err_ioremap;
+ }
+
pm_runtime_enable(&pdev->dev);
ret = pm_runtime_get_sync(&pdev->dev);
if (ret) {
@@ -381,7 +386,7 @@ static int omap_rng_probe(struct platform_device *pdev)
if (ret)
goto err_ioremap;
- ret = hwrng_register(&omap_rng_ops);
+ ret = hwrng_register(&priv->rng);
if (ret)
goto err_register;
@@ -402,7 +407,7 @@ static int omap_rng_remove(struct platform_device *pdev)
{
struct omap_rng_dev *priv = platform_get_drvdata(pdev);
- hwrng_unregister(&omap_rng_ops);
+ hwrng_unregister(&priv->rng);
priv->pdata->cleanup(priv);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/8] hwrng: omap - Switch to non-obsolete read API implementation
From: Romain Perier @ 2016-09-07 15:57 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160907155743.6403-1-romain.perier@free-electrons.com>
The ".data_present" and ".data_read" operations are marked as
OBSOLETE in the hwrng API. We have to use the ".read" operation instead.
It makes the driver simpler and removes the need to do a busy loop to
wait until enough data is generated by the IP. We simplify this step by
only checking the status of the engine, if there is data, we copy the
data to the output buffer and the amout of copied data is returned to the
caller, otherwise zero is returned. The hwrng core will re-call the read
operation as many times as required until enough data has been copied.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/char/hw_random/omap-rng.c | 39 ++++++++++++---------------------------
1 file changed, 12 insertions(+), 27 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 01d4be2..d47b24d 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -140,41 +140,27 @@ static inline void omap_rng_write(struct omap_rng_dev *priv, u16 reg,
__raw_writel(val, priv->base + priv->pdata->regs[reg]);
}
-static int omap_rng_data_present(struct hwrng *rng, int wait)
+
+static int omap_rng_do_read(struct hwrng *rng, void *data, size_t max,
+ bool wait)
{
struct omap_rng_dev *priv;
- int data, i;
priv = (struct omap_rng_dev *)rng->priv;
- for (i = 0; i < 20; i++) {
- data = priv->pdata->data_present(priv);
- if (data || !wait)
- break;
- /* RNG produces data fast enough (2+ MBit/sec, even
- * during "rngtest" loads, that these delays don't
- * seem to trigger. We *could* use the RNG IRQ, but
- * that'd be higher overhead ... so why bother?
- */
- udelay(10);
- }
- return data;
-}
-
-static int omap_rng_data_read(struct hwrng *rng, u32 *data)
-{
- struct omap_rng_dev *priv;
- u32 data_size, i;
+ if (max < priv->pdata->data_size)
+ return 0;
- priv = (struct omap_rng_dev *)rng->priv;
- data_size = priv->pdata->data_size;
+ if (!priv->pdata->data_present(priv))
+ return 0;
- for (i = 0; i < data_size / sizeof(u32); i++)
- data[i] = omap_rng_read(priv, RNG_OUTPUT_L_REG + i);
+ memcpy_fromio(data, priv->base + priv->pdata->regs[RNG_OUTPUT_L_REG],
+ priv->pdata->data_size);
if (priv->pdata->regs[RNG_INTACK_REG])
omap_rng_write(priv, RNG_INTACK_REG, RNG_REG_INTACK_RDY_MASK);
- return data_size;
+
+ return priv->pdata->data_size;
}
static int omap_rng_init(struct hwrng *rng)
@@ -195,8 +181,7 @@ static void omap_rng_cleanup(struct hwrng *rng)
static struct hwrng omap_rng_ops = {
.name = "omap",
- .data_present = omap_rng_data_present,
- .data_read = omap_rng_data_read,
+ .read = omap_rng_do_read,
.init = omap_rng_init,
.cleanup = omap_rng_cleanup,
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/8] dt-bindings: Add vendor prefix for INSIDE Secure
From: Romain Perier @ 2016-09-07 15:57 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160907155743.6403-1-romain.perier@free-electrons.com>
This commits adds a vendor for the company INSIDE Secure.
See https://www.insidesecure.com, for more details.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa9..6a5e872 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -132,6 +132,7 @@ infineon Infineon Technologies
inforce Inforce Computing
ingenic Ingenic Semiconductor
innolux Innolux Corporation
+inside-secure INSIDE Secure
intel Intel Corporation
intercontrol Inter Control Group
invensense InvenSense Inc.
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/8] dt-bindings: omap-rng: Document SafeXcel IP-76 device variant
From: Romain Perier @ 2016-09-07 15:57 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160907155743.6403-1-romain.perier@free-electrons.com>
This commits add missing fields in the documentation that are used
by the new device variant. It also includes DT example to show how
the variant should be used.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Documentation/devicetree/bindings/rng/omap_rng.txt | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/rng/omap_rng.txt b/Documentation/devicetree/bindings/rng/omap_rng.txt
index 6a62acd..4714772 100644
--- a/Documentation/devicetree/bindings/rng/omap_rng.txt
+++ b/Documentation/devicetree/bindings/rng/omap_rng.txt
@@ -1,4 +1,4 @@
-OMAP SoC HWRNG Module
+OMAP SoC and Inside-Secure HWRNG Module
Required properties:
@@ -6,11 +6,13 @@ Required properties:
RNG versions:
- "ti,omap2-rng" for OMAP2.
- "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
+ - "inside-secure,safexcel-eip76" for SoCs with EIP76 IP block
Note that these two versions are incompatible.
- ti,hwmods: Name of the hwmod associated with the RNG module
- reg : Offset and length of the register set for the module
- interrupts : the interrupt number for the RNG module.
- Only used for "ti,omap4-rng".
+ Used for "ti,omap4-rng" and "inside-secure,safexcel-eip76"
+- clocks: the trng clock source
Example:
/* AM335x */
@@ -20,3 +22,11 @@ rng: rng@48310000 {
reg = <0x48310000 0x2000>;
interrupts = <111>;
};
+
+/* SafeXcel IP-76 */
+trng: rng@f2760000 {
+ compatible = "inside-secure,safexcel-eip76";
+ reg = <0xf2760000 0x7d>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpm_syscon0 1 25>;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/8] Add support for SafeXcel IP-76 to OMAP RNG
From: Romain Perier @ 2016-09-07 15:57 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
The driver omap-rng has a lot of similarity with the IP block SafeXcel
IP-76. A lot of registers are the same and the way that the driver works
is very closed the description of the TRNG EIP76 in its datasheet.
This series refactorize the driver, add support for generating bigger
output random data and add a device variant for SafeXcel IP-76, found
in Armada 8K.
Romain Perier (8):
dt-bindings: Add vendor prefix for INSIDE Secure
dt-bindings: omap-rng: Document SafeXcel IP-76 device variant
hwrng: omap - Switch to non-obsolete read API implementation
hwrng: omap - Remove global definition of hwrng
hwrng: omap - Add support for 128-bit output of data
hwrng: omap - Don't prefix the probe message with OMAP
hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K
arm64: dts: marvell: add TRNG description for Armada 8K CP
Documentation/devicetree/bindings/rng/omap_rng.txt | 14 +-
.../devicetree/bindings/vendor-prefixes.txt | 1 +
.../boot/dts/marvell/armada-cp110-master.dtsi | 8 ++
.../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 8 ++
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/omap-rng.c | 160 +++++++++++++++------
6 files changed, 147 insertions(+), 46 deletions(-)
--
Changes in v2:
- Removed the patch introducing device resources managed API for registration
2.9.3
^ permalink raw reply
* Re: [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration
From: Romain Perier @ 2016-09-07 15:38 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: dsaxena, mpm, Herbert Xu, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas,
linux-crypto
In-Reply-To: <CANc+2y5yzMNeHEgf6FfQHiN=-528YZgB3JwVcqa3C-s8s_RCfA@mail.gmail.com>
Le 07/09/2016 16:45, PrasannaKumar Muralidharan a écrit :
> On 7 September 2016 at 19:53, Romain Perier
> <romain.perier@free-electrons.com> wrote:
>> Hello,
>>
>>
>> Le 06/09/2016 18:31, PrasannaKumar Muralidharan a écrit :
>>>>
>>>> Use devm_hwrng_register instead of hwrng_register. It avoids the need
>>>> to handle unregistration explicitly from the remove function.
>>>>
>>>> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
>>>> ---
>>>> drivers/char/hw_random/omap-rng.c | 4 +---
>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/char/hw_random/omap-rng.c
>>>> b/drivers/char/hw_random/omap-rng.c
>>>> index d47b24d..171c3e8 100644
>>>> --- a/drivers/char/hw_random/omap-rng.c
>>>> +++ b/drivers/char/hw_random/omap-rng.c
>>>> @@ -381,7 +381,7 @@ static int omap_rng_probe(struct platform_device
>>>> *pdev)
>>>> if (ret)
>>>> goto err_ioremap;
>>>>
>>>> - ret = hwrng_register(&omap_rng_ops);
>>>> + ret = devm_hwrng_register(dev, &omap_rng_ops);
>>>> if (ret)
>>>> goto err_register;
>>>>
>>>> @@ -402,8 +402,6 @@ static int omap_rng_remove(struct platform_device
>>>> *pdev)
>>>> {
>>>> struct omap_rng_dev *priv = platform_get_drvdata(pdev);
>>>>
>>>> - hwrng_unregister(&omap_rng_ops);
>>>> -
>>>> priv->pdata->cleanup(priv);
>>>>
>>>> pm_runtime_put_sync(&pdev->dev);
>>>> --
>>>
>>>
>>> If devm_hwrng_register is used hwrng_unregister will be called after
>>> pm_runtime_disable is called. If RNG device is in use calling
>>> omap_rng_remove may not work properly.
>>>
>>
>> The case where the remove function is called is if you unbind the driver by
>> hand or you call rmmod while the RNG device is used.
>> I don't think that the kernel will call platform->remove is the device is in
>> use (so /dev/hwrng). I mean the argument that the unregister function is
>> called after pm_runtime_disable is correct, but I don't think that the
>> remove function might be called while the device is in use. There is
>> necessarily a mutual exclusive case between "use the device" and "call the
>> remove function of the device". However, I am open to suggestions.
>
> The way you explained is good :D. Good point too. But the device is
> created by hw_random core (hwrng_modinit in core.c) so the device can
> be in use when omap-rng module is removed. Please feel free to correct
> me if I am wrong.
Mhhh, I think that I understood what you meant. The node /dev/hwrng is
managed by hw_random core, a read might happen on this node while
platform->remove is called... However, if hwrng_unregister is the first
function called from platform->remove, the driver is unbinded from the
hw_random core atomically (unregister and read cannot happen in the same
time because there is a mutex), so the problem does not happen.
I propose to remove this patch from the series.
Thanks!
Romain
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] hwrng: core - Allocate memory during module init
From: PrasannaKumar Muralidharan @ 2016-09-07 14:48 UTC (permalink / raw)
To: mpm, herbert, lee.jones, jslaby, peter, linux-crypto
Cc: PrasannaKumar Muralidharan
In core rng_buffer and rng_fillbuf is allocated in hwrng_register only
once and it is freed during module exit. This patch moves allocating
rng_buffer and rng_fillbuf from hwrng_register to rng core's init. This
avoids checking whether rng_buffer and rng_fillbuf was allocated from
every hwrng_register call. Also moving them to module init makes it
explicit that it is freed in module exit.
Change in v2:
Fix memory leak when register_miscdev fails.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/core.c | 37 ++++++++++++++++++++-----------------
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 9203f2d..4827945 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -449,22 +449,6 @@ int hwrng_register(struct hwrng *rng)
goto out;
mutex_lock(&rng_mutex);
-
- /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
- err = -ENOMEM;
- if (!rng_buffer) {
- rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
- if (!rng_buffer)
- goto out_unlock;
- }
- if (!rng_fillbuf) {
- rng_fillbuf = kmalloc(rng_buffer_size(), GFP_KERNEL);
- if (!rng_fillbuf) {
- kfree(rng_buffer);
- goto out_unlock;
- }
- }
-
/* Must not register two RNGs with the same name. */
err = -EEXIST;
list_for_each_entry(tmp, &rng_list, list) {
@@ -573,7 +557,26 @@ EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
static int __init hwrng_modinit(void)
{
- return register_miscdev();
+ int ret = -ENOMEM;
+
+ /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
+ rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
+ if (!rng_buffer)
+ return -ENOMEM;
+
+ rng_fillbuf = kmalloc(rng_buffer_size(), GFP_KERNEL);
+ if (!rng_fillbuf) {
+ kfree(rng_buffer);
+ return -ENOMEM;
+ }
+
+ ret = register_miscdev();
+ if (ret) {
+ kfree(rng_fillbuf);
+ kfree(rng_buffer);
+ }
+
+ return ret;
}
static void __exit hwrng_modexit(void)
--
2.5.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox