[PATCH 5/6] ARM: OMAP2+: Only manually add hwmod data when DT not used.
The omap_init_rng() routine in devices.c only needs to be
called when there is no device tree present.
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/mach-omap2/devices.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..afc2017 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -570,12 +570,12 @@ static int __init omap2_init_devices(void)
omap_init_mcspi();
omap_init_sham();
omap_init_aes();
+ omap_init_rng();
} else {
/* These can be removed when bindings are done */
omap_init_wl12xx_of();
}
omap_init_sti();
- omap_init_rng();
omap_init_vout();
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] hwrng: OMAP: Add device tree support
Add Device Tree suport to the omap-rng driver.
Currently, only support for OMAP2 and OMAP3 is
being added but support for OMAP4 and OMAP5 will
be added in a subsequent patch.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/char/hw_random/omap-rng.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index 5a2ab3b..3076c9d 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -24,6 +24,9 @@
#include linux/delay.h
#include linux/slab.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_address.h
#include asm/io.h
@@ -104,6 +107,14 @@ static struct hwrng omap_rng_ops = {
.data_read = omap_rng_data_read,
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_rng_of_match[] = {
+ { .compatible = ti,omap2-rng },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_rng_of_match);
+#endif
+
static int omap_rng_probe(struct platform_device *pdev)
{
struct omap_rng_private_data *priv;
@@ -197,6 +208,7 @@ static struct platform_driver omap_rng_driver = {
.name = omap_rng,
.owner = THIS_MODULE,
.pm = OMAP_RNG_PM,
+ .of_match_table = of_match_ptr(omap_rng_of_match),
},
.probe = omap_rng_probe,
.remove = __exit_p(omap_rng_remove),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] hwrng: OMAP: Use module_platform_driver macro
module_platform_driver() makes the code simpler.
Using the macro in the driver.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/char/hw_random/omap-rng.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index 6843ec8..3e9a7ec 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -198,9 +198,6 @@ static SIMPLE_DEV_PM_OPS(omap_rng_pm, omap_rng_suspend,
omap_rng_resume);
#endif
-/* work with hotplug and coldplug */
-MODULE_ALIAS(platform:omap_rng);
-
static struct platform_driver omap_rng_driver = {
.driver = {
.name = omap_rng,
@@ -211,18 +208,7 @@ static struct platform_driver omap_rng_driver = {
.remove = __exit_p(omap_rng_remove),
};
-static int __init omap_rng_init(void)
-{
- return platform_driver_register(omap_rng_driver);
-}
-
-static void __exit omap_rng_exit(void)
-{
- platform_driver_unregister(omap_rng_driver);
-}
-
-module_init(omap_rng_init);
-module_exit(omap_rng_exit);
-
+module_platform_driver(omap_rng_driver);
+MODULE_ALIAS(platform:omap_rng);
MODULE_AUTHOR(Deepak Saxena (and others));
MODULE_LICENSE(GPL);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] hwrng: OMAP: Add OMAP4 TRNG support
Add support for OMAP4 version of TRNG module
that is present on OMAP4, AM33xx and OMAP5 SoCs.
The modules have several differences including register
offsets, output size, triggering rng and how configuring
FROs. To handle these differences, a platform_data structure
is defined and contains routine pointers, register offsets. OMAP2
specific routines are prefixed with 'omap2_' and OMAP4
specific routines are prefixed with 'omap4_'.
Note: Few Hard coded values are from the TI AM33xx SDK.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/char/hw_random/Kconfig|6 +-
drivers/char/hw_random/omap-rng.c | 352 +++--
2 files changed, 305 insertions(+), 53 deletions(-)
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 40a8654..0aa9d91 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -153,12 +153,12 @@ config HW_RANDOM_IXP4XX
config HW_RANDOM_OMAP
tristate OMAP Random Number Generator support
- depends on HW_RANDOM (ARCH_OMAP16XX || ARCH_OMAP2)
+ depends on HW_RANDOM (ARCH_OMAP16XX || ARCH_OMAP2PLUS)
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
- Generator hardware found on OMAP16xx and OMAP24xx multimedia
- processors.
+ Generator hardware found on OMAP16xx, OMAP2/3/4/5 and AM33xx/AM43xx
+ multimedia processors.
To compile this driver as a module, choose M here: the
module will be called omap-rng.
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index 3076c9d..f3f7142 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -27,57 +27,138 @@
#include linux/of.h
#include linux/of_device.h
#include linux/of_address.h
+#include linux/interrupt.h
#include asm/io.h
-#define RNG_OUT_REG0x00/* Output register */
-#define RNG_STAT_REG 0x04/* Status register
- [0] = STAT_BUSY */
-#define RNG_ALARM_REG 0x24/* Alarm register
- [7:0] = ALARM_COUNTER */
-#define RNG_CONFIG_REG 0x28/* Configuration register
- [11:6] = RESET_COUNT
- [5:3] = RING2_DELAY
- [2:0] = RING1_DELAY */
-#define RNG_REV_REG0x3c/* Revision register
- [7:0] = REV_NB */
-#define RNG_MASK_REG 0x40/* Mask and reset register
- [2] = IT_EN
- [1] = SOFTRESET
- [0] = AUTOIDLE */
-#define RNG_SYSSTATUS 0x44/* System status
- [0] = RESETDONE */
+#define RNG_REG_STATUS_RDY (1 0)
+
+#define RNG_REG_INTACK_RDY_MASK(1 0)
+#define RNG_REG_INTACK_SHUTDOWN_OFLO_MASK (1 1)
+#define RNG_SHUTDOWN_OFLO_MASK (1 1)
+
+#define RNG_CONTROL_STARTUP_CYCLES_SHIFT 16
+#define RNG_CONTROL_STARTUP_CYCLES_MASK(0x 16)
+#define RNG_CONTROL_ENABLE_TRNG_SHIFT 10
+#define RNG_CONTROL_ENABLE_TRNG_MASK (1 10)
+
+#define RNG_CONFIG_MAX_REFIL_CYCLES_SHIFT 16
+#define RNG_CONFIG_MAX_REFIL_CYCLES_MASK (0x 16)
+#define RNG_CONFIG_MIN_REFIL_CYCLES_SHIFT 0
+#define RNG_CONFIG_MIN_REFIL_CYCLES_MASK (0xff 0)
+
+#define RNG_CONTROL_STARTUP_CYCLES 0xff
+#define RNG_CONFIG_MIN_REFIL_CYCLES0x21
+#define RNG_CONFIG_MAX_REFIL_CYCLES0x22
+
+#define RNG_ALARMCNT_ALARM_TH_SHIFT0x0
+#define RNG_ALARMCNT_ALARM_TH_MASK (0xff 0)
+#define RNG_ALARMCNT_SHUTDOWN_TH_SHIFT 16
+#define RNG_ALARMCNT_SHUTDOWN_TH_MASK (0x1f 16)
+#define RNG_ALARM_THRESHOLD0xff
+#define RNG_SHUTDOWN_THRESHOLD 0x4
+
+#define RNG_REG_FROENABLE_MASK 0xff
+#define RNG_REG_FRODETUNE_MASK 0xff
+
+#define OMAP2_RNG_OUTPUT_SIZE 0x4
+#define OMAP4_RNG_OUTPUT_SIZE 0x8
+
+enum {
+ RNG_OUTPUT_L_REG = 0,
+ RNG_OUTPUT_H_REG,
+ RNG_STATUS_REG,
+ RNG_INTMASK_REG,
+ RNG_INTACK_REG,
+ RNG_CONTROL_REG,
+ RNG_CONFIG_REG,
+ RNG_ALARMCNT_REG,
+ RNG_FROENABLE_REG,
+ RNG_FRODETUNE_REG,
+ RNG_ALARMMASK_REG,
+ RNG_ALARMSTOP_REG,
+ RNG_REV_REG,
+ RNG_SYSCONFIG_REG,
+};
+
+static const u16 reg_map_omap2[] = {
+
Questions about the Crypto API
Hi, I'm starting to work on some platform-specific implementations using the Crypto API. I spent some time reading the available documentation and mainly the code, but I still have some doubts on how the Crypto API works and how it should be used. My first doubt is regarding which kind of concurrency the Crypto API allows. For example, can a single `struct crypto_tfm` be used by two concurrent calls? I'm asking about that because I noticed that for blkcipher the only implementation-specific context that can be used is allocated inside the tfm struct. I'm working to fix some bugs in the NX driver (located in drivers/crypto/nx), and one issue that we are facing is that NFS when using Kerberos uses the same tfm with different kthreads. That causes concurrent accesses to the internal data stored into the context and incorrect results. So my question here is: should this type of concurrency be handled by the driver or a caller is not allowed to use the same tfm for concurrent calls? My second doubt is regarding the difference between ablkcipher and blkcipher. I do understand their difference from caller's point of view. But I'm not sure what are the consequences of implementing a driver using one or another option. For example, can a blkcipher implementation be used asynchronously and vice versa? Thanks for your help. Marcelo -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
