* [PATCH 9/9] arm64: dts: marvell: add TRNG description for Armada 8K CP
From: Romain Perier @ 2016-09-06 15:38 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: <20160906153857.5503-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 8/9] hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K
From: Romain Perier @ 2016-09-06 15:38 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: <20160906153857.5503-1-romain.perier@free-electrons.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 6021 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>
---
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/omap-rng.c | 85 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 84 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 f1dcdb3..7c86c0d 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 = devm_hwrng_register(dev, &priv->rng);
if (ret)
@@ -400,6 +475,9 @@ static int omap_rng_probe(struct platform_device *pdev)
err_register:
priv->base = NULL;
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;
@@ -414,6 +492,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 7/9] hwrng: omap - Don't prefix the probe message with OMAP
From: Romain Perier @ 2016-09-06 15:38 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: <20160906153857.5503-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 6a3aaad..f1dcdb3 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 6/9] hwrng: omap - Add support for 128-bit output of data
From: Romain Perier @ 2016-09-06 15:38 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: <20160906153857.5503-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 f9a99b2..6a3aaad 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 3/9] hwrng: omap - Switch to non-obsolete read API implementation
From: Romain Perier @ 2016-09-06 15:38 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: <20160906153857.5503-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 5/9] hwrng: omap - Remove global definition of hwrng
From: Romain Perier @ 2016-09-06 15:38 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: <20160906153857.5503-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>
---
drivers/char/hw_random/omap-rng.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 171c3e8..f9a99b2 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_register;
+ }
+
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 = devm_hwrng_register(dev, &omap_rng_ops);
+ ret = devm_hwrng_register(dev, &priv->rng);
if (ret)
goto err_register;
--
2.9.3
^ permalink raw reply related
* [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration
From: Romain Perier @ 2016-09-06 15:38 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: <20160906153857.5503-1-romain.perier@free-electrons.com>
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);
--
2.9.3
^ permalink raw reply related
* [PATCH 2/9] dt-bindings: omap-rng: Document SafeXcel IP-76 device variant
From: Romain Perier @ 2016-09-06 15:38 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: <20160906153857.5503-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 1/9] dt-bindings: Add vendor prefix for INSIDE Secure
From: Romain Perier @ 2016-09-06 15:38 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: <20160906153857.5503-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 0/9] Add support for SafeXcel IP-76 to OMAP RNG
From: Romain Perier @ 2016-09-06 15:38 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 (9):
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 - Use the managed device resource API for registration
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 | 159 +++++++++++++++------
6 files changed, 145 insertions(+), 47 deletions(-)
--
2.9.3
^ permalink raw reply
* echainiv not working as supposed to be?
From: Mathias Krause @ 2016-09-06 12:24 UTC (permalink / raw)
To: Herbert Xu; +Cc: Steffen Klassert, linux-crypto@vger.kernel.org
Hi Herbert,
I'm a little bit confused on how echainiv is supposed to work. I think
it's doing a few things wrongly, I just can't decide what's actually
wrong as the intended mode of operation is unclear to me. At least,
as-is, the code isn't quite operating as advertised in the comment at
the top of the file.
So, in hope you could enlighten me, here's my understanding of the
current _implementation_ of echainiv (assuming aligned req->iv, for
simplicity):
For each request it XORs the salt into the provided IV (req->iv). For
ESP the provided IV is the sequence number or, at least, parts of it.
The thus modified IV gets written into the *destination* buffer
(req->dst) which might be a different buffer than the source buffer
(not in the ESP case, though, as it passes the same sg for src and
dst). Afterwards, the per-cpu IV gets copied over into req->iv,
effectively overwriting the generated XORed value. Then the inner
crypto request gets initiated which may finish synchronously or
asynchronously. Either way, the per-cpu IV gets updated with the new
value from subreq->iv, which should be equal to req->iv in the normal
case.
Things that are unclear to me:
1/ Why is the XORed IV written to the destination buffer and not the
source buffer? Isn't the sub-request supposed to use the IV from
either req->src or req->iv -- and especially *not* from req->dst?
2/ Why does the XORed IV gets overwritten with the per-cpu IV prior
passing it on to the sub-request, making all possible IV locations in
req->src, req->dst and req->iv *all* be different?
Moreover, the behaviour of 2/ actually leads to the fact, that the
very first IV on each CPU will be a null IV -- not a salted sequence
number. All following IVs will be the result of the (or better "some")
sub-request's IV update, stored into the per-cpu variable -- still no
salted sequence numbers, though.
That behaviour is a bug, IMHO, as this clearly differs from what is
described in the comment. However, I'm uncertain on how to fix it, as
the intended mode of operation is unclear to me... Should only the
first IV of each crypto transform be the salted sequence number and
all following the result of the sub-request's IV update, therefore not
stored in a single per-cpu variable but some echainiv context specific
one?
3/ Why is echainiv using per-cpu IVs in the first place? Shouldn't
those be crypto context specific? Currently we're happily mixing IVs
from different transforms (with possibly different IV sizes!) with
each other via the per-cpu variables. That might be an "issue" if one
echainiv user can maliciously mess with the IVs of another user, e.g.
via AF_ALG.
So, should echainiv use a per-context per-cpu array instead that --
for simplicity -- gets initialised with random bytes and will be
updated as it's now, just not with a single global per-cpu array, but
a per-context one?
That would allow us to still have a lock-less IV generator but one
that cannot be accidentally / maliciously be tampered with by other
echainiv users.
Thanks,
Mathias
^ permalink raw reply
* Re: [PATCH v2 2/2] crypto: qat - fix resource release omissions
From: Giovanni Cabiddu @ 2016-09-06 10:18 UTC (permalink / raw)
To: Quentin Lambert
Cc: Salvatore Benedetto, Herbert Xu, David S. Miller, qat-linux,
linux-crypto, linux-kernel, kernel-janitors, giovanni.cabiddu,
giovanni.cabiddu
In-Reply-To: <20160902144753.31334-3-lambert.quentin@gmail.com>
Hi Lambert,
On Fri, Sep 02, 2016 at 04:47:53PM +0200, Quentin Lambert wrote:
> In certain cases qat_uclo_parse_uof_obj used to return with an error code
> before releasing all resources. This patch add a jump to the appropriate label
> ensuring that the resources are properly released before returning.
>
> This issue was found with Hector.
Thanks for the patches. This can be easily fixed by moving the kcalloc after
the compatibility check function. What do you think?
---8<---
Subject: [PATCH] crypto: qat - fix leak on error path
Fix a memory leak in an error path in uc loader.
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/qat/qat_common/qat_uclo.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_uclo.c b/drivers/crypto/qat/qat_common/qat_uclo.c
index 9b961b3..e2454d9 100644
--- a/drivers/crypto/qat/qat_common/qat_uclo.c
+++ b/drivers/crypto/qat/qat_common/qat_uclo.c
@@ -967,10 +967,6 @@ static int qat_uclo_parse_uof_obj(struct icp_qat_fw_loader_handle *handle)
struct icp_qat_uclo_objhandle *obj_handle = handle->obj_handle;
unsigned int ae;
- obj_handle->uword_buf = kcalloc(UWORD_CPYBUF_SIZE, sizeof(uint64_t),
- GFP_KERNEL);
- if (!obj_handle->uword_buf)
- return -ENOMEM;
obj_handle->encap_uof_obj.beg_uof = obj_handle->obj_hdr->file_buff;
obj_handle->encap_uof_obj.obj_hdr = (struct icp_qat_uof_objhdr *)
obj_handle->obj_hdr->file_buff;
@@ -982,6 +978,10 @@ static int qat_uclo_parse_uof_obj(struct icp_qat_fw_loader_handle *handle)
pr_err("QAT: UOF incompatible\n");
return -EINVAL;
}
+ obj_handle->uword_buf = kcalloc(UWORD_CPYBUF_SIZE, sizeof(uint64_t),
+ GFP_KERNEL);
+ if (!obj_handle->uword_buf)
+ return -ENOMEM;
obj_handle->ustore_phy_size = ICP_QAT_UCLO_MAX_USTORE;
if (!obj_handle->obj_hdr->file_buff ||
!qat_uclo_map_str_table(obj_handle->obj_hdr, ICP_QAT_UOF_STRT,
--
^ permalink raw reply related
* [PATCH] hwrng: pasemi-rng - Use linux/io.h instead of asm/io.h
From: PrasannaKumar Muralidharan @ 2016-09-06 8:28 UTC (permalink / raw)
To: olof, linuxppc-dev, linux-crypto, herbert, mpm; +Cc: PrasannaKumar Muralidharan
Checkpatch.pl warns about usage of asm/io.h. Use linux/io.h instead.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/pasemi-rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/pasemi-rng.c b/drivers/char/hw_random/pasemi-rng.c
index b4e32f7..545df48 100644
--- a/drivers/char/hw_random/pasemi-rng.c
+++ b/drivers/char/hw_random/pasemi-rng.c
@@ -26,7 +26,7 @@
#include <linux/delay.h>
#include <linux/of_address.h>
#include <linux/of_platform.h>
-#include <asm/io.h>
+#include <linux/io.h>
#define SDCRNG_CTL_REG 0x00
#define SDCRNG_CTL_FVLD_M 0x0000f000
--
2.5.0
^ permalink raw reply related
* [PATCH][V2] s390/crypto: initialize ret to nbytes to avoid returning garbage value
From: Colin King @ 2016-09-06 7:25 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Martin Schwidefsky, Heiko Carstens,
linux-crypto, linux-s390
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Static analysis with cppcheck detected that ret is not initialized
and hence garbage is potentially being returned in the case where
prng_data->ppnows.reseed_counter <= prng_reseed_limit.
Thanks to Martin Schwidefsky for spotting a mistake in my original
fix.
Fixes: 0177db01adf26cf9 ("s390/crypto: simplify return code handling")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/s390/crypto/prng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/crypto/prng.c b/arch/s390/crypto/prng.c
index 79e3a1f..5592df9 100644
--- a/arch/s390/crypto/prng.c
+++ b/arch/s390/crypto/prng.c
@@ -412,7 +412,7 @@ static int prng_sha512_reseed(void)
static int prng_sha512_generate(u8 *buf, size_t nbytes)
{
- int ret;
+ int ret = nbytes;
/* reseed needed ? */
if (prng_data->ppnows.reseed_counter > prng_reseed_limit) {
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] s390/crypto: initialize ret to zero to avoid returning garbage value
From: Martin Schwidefsky @ 2016-09-06 7:10 UTC (permalink / raw)
To: Colin King
Cc: Herbert Xu, David S . Miller, Heiko Carstens, linux-crypto,
linux-s390, linux-kernel
In-Reply-To: <20160905162118.16510-1-colin.king@canonical.com>
On Mon, 5 Sep 2016 17:21:18 +0100
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> static analysis with cppcheck detected that ret is not initialized
> and hence garbage is potentially being returned in the case where
> prng_data->ppnows.reseed_counter <= prng_reseed_limit.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> arch/s390/crypto/prng.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/crypto/prng.c b/arch/s390/crypto/prng.c
> index 79e3a1f..a21fdf4 100644
> --- a/arch/s390/crypto/prng.c
> +++ b/arch/s390/crypto/prng.c
> @@ -412,7 +412,7 @@ static int prng_sha512_reseed(void)
>
> static int prng_sha512_generate(u8 *buf, size_t nbytes)
> {
> - int ret;
> + int ret = 0;
>
> /* reseed needed ? */
> if (prng_data->ppnows.reseed_counter > prng_reseed_limit) {
This issue has been introduced by git commit 0177db01adf26cf9
"s390/crypto: simplify return code handling" which is only on
the features branch right now. And to set ret=0 does not fix
the problem. The correct fix is to return nbytes.
Still a good catch though.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* [PATCH] s390/crypto: initialize ret to zero to avoid returning garbage value
From: Colin King @ 2016-09-05 16:21 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Martin Schwidefsky, Heiko Carstens,
linux-crypto, linux-s390
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
static analysis with cppcheck detected that ret is not initialized
and hence garbage is potentially being returned in the case where
prng_data->ppnows.reseed_counter <= prng_reseed_limit.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/s390/crypto/prng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/crypto/prng.c b/arch/s390/crypto/prng.c
index 79e3a1f..a21fdf4 100644
--- a/arch/s390/crypto/prng.c
+++ b/arch/s390/crypto/prng.c
@@ -412,7 +412,7 @@ static int prng_sha512_reseed(void)
static int prng_sha512_generate(u8 *buf, size_t nbytes)
{
- int ret;
+ int ret = 0;
/* reseed needed ? */
if (prng_data->ppnows.reseed_counter > prng_reseed_limit) {
--
2.9.3
^ permalink raw reply related
* Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs
From: Tero Kristo @ 2016-09-05 12:06 UTC (permalink / raw)
To: Herbert Xu
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <9af173f7-cc94-a92f-80ee-c746d97ab110@ti.com>
On 01/09/16 10:46, Tero Kristo wrote:
> On 01/09/16 10:31, Herbert Xu wrote:
>> On Thu, Sep 01, 2016 at 10:28:47AM +0300, Tero Kristo wrote:
>>>
>>> Yeah, the flush should do the trick now. Kind of a chicken-egg
>>> problem here. :P How do you see the situation with the above
>>> explanation?
>>
>> The export function is not allowed to sleep so you must not wait
>> for the hardware to complete in it.
>>
>> If you need to wait, then you must use the completion mechanism.
>
> I don't think export is allowed to return -EINPROGRESS either? At least
> currently the kernel pieces using this functionality won't work if I do
> that.
>
> If thats the case, I need to think of something else to handle this...
>
> -Tero
>
Hi Herbert,
Additional request, would it be possible for you to check the rest of
the series and just ignore patches #2 and #3 for now, the rest don't
have any dependencies against these and can be applied cleanly without.
I would like to see these move forward while I figure out how to handle
the buffer / export+import...
-Tero
^ permalink raw reply
* [PATCH] crypto: arm/ghash: change internal cra_name to "__ghash"
From: Ard Biesheuvel @ 2016-09-05 11:58 UTC (permalink / raw)
To: linux-crypto, herbert; +Cc: Ard Biesheuvel
The fact that the internal synchrous hash implementation is called
"ghash" like the publicly visible one is causing the testmgr code
to misidentify it as an algorithm that requires testing at boottime.
So rename it to "__ghash" to prevent this.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
Hi Herbert,
This one should be able to go on top of the 3-pieces series I sent you
last week.
Thanks,
Ard.
arch/arm/crypto/ghash-ce-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/crypto/ghash-ce-glue.c b/arch/arm/crypto/ghash-ce-glue.c
index b88364aa149a..7546b3c02466 100644
--- a/arch/arm/crypto/ghash-ce-glue.c
+++ b/arch/arm/crypto/ghash-ce-glue.c
@@ -138,7 +138,7 @@ static struct shash_alg ghash_alg = {
.setkey = ghash_setkey,
.descsize = sizeof(struct ghash_desc_ctx),
.base = {
- .cra_name = "ghash",
+ .cra_name = "__ghash",
.cra_driver_name = "__driver-ghash-ce",
.cra_priority = 0,
.cra_flags = CRYPTO_ALG_TYPE_SHASH | CRYPTO_ALG_INTERNAL,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] crypto: arm/ghash-ce - add missing async import/export
From: Herbert Xu @ 2016-09-05 9:41 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <CAKv+Gu8yEDbQS651Q3-GbQw+AwJfqvH1WHKa-LUE4=43NwyWSw@mail.gmail.com>
On Thu, Sep 01, 2016 at 04:14:22PM +0100, Ard Biesheuvel wrote:
>
> The culprit appears to be that the .cra_name of the internal shash is
> "ghash", (and not "__ghash" like in the x86 case) which causes the
> test code to run the test on not only the public ahash, but also on
> the internal cryptd() encapsulated shash, and also on the internal
> shash itself.
Hmm that's not good. The test code is not meant to process these
internal algorithms. I recently added a check to automatically
filter out internal algorithms when testing. But we should still
change its name to __ghash just to avoid confusion.
> However, that does not answer the question whether .init() must be
> called before .import() [which the test code does not do]. If not,
> then please disregard my v2, and I will followup with a patch that
> renames ghash to __ghash (but .import() will still require the .init()
> bits as well). Given that these internal shashes/ahashes are in fact
> callable, and calling .import() will result in a crash, I suppose
> duplicating some of the init() code in .import() makes sense
> regardless.
Right. This is definitely a bug and I will take your patches.
Thanks,
--
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: Crypto Fixes for 4.8
From: Herbert Xu @ 2016-09-05 9:33 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160801095821.GA1260@gondor.apana.org.au>
Hi Linus:
This push fixes a regression in the cryptd code that breaks certain
accelerated AED algorithms as well as an older regression in the
caam driver that breaks IPsec.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Herbert Xu (1):
crypto: cryptd - Use correct tfm object for AEAD tracking
Horia Geantă (1):
crypto: caam - fix IV loading for authenc (giv)decryption
crypto/cryptd.c | 3 +-
drivers/crypto/caam/caamalg.c | 77 ++++++++++++++++++++---------------------
2 files changed, 39 insertions(+), 41 deletions(-)
Thanks,
--
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: [cryptodev:master 65/80] drivers/pci/quirks.c:843:6: error: 'struct pci_dev' has no member named 'sriov'
From: Herbert Xu @ 2016-09-05 9:12 UTC (permalink / raw)
To: Ananth Jasty
Cc: kbuild test robot, Ananth Jasty, kbuild-all, linux-crypto,
Omer Khaliq, Bjorn Helgaas, Linux Kernel Mailing List
In-Reply-To: <59722569-EC4C-4A31-AB54-B6BF9B8B7A5C@caviumnetworks.com>
On Sat, Sep 03, 2016 at 06:40:27PM -0700, Ananth Jasty wrote:
> As this fix is purely SRIOV related, an ifdef guard for SRIOV support should be sufficient to prevent this header dependency.
Please don't top-post.
> On Sep 3, 2016, at 5:16 PM, kbuild test robot <fengguang.wu@intel.com> wrote:
>
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> > head: 10faa8c0d6c3b22466f97713a9533824a2ea1c57
> > commit: 21b5b8eebbae427d7d890b7dd1e43a63aca7c26c [65/80] PCI: quirk fixup for cavium invalid sriov link value.
> > config: arm64-kexec_dev_defconfig (attached as .config)
> > compiler: aarch64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
> > reproduce:
> > wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout 21b5b8eebbae427d7d890b7dd1e43a63aca7c26c
> > # save the attached .config to linux build tree
> > make.cross ARCH=arm64
> >
> > All errors (new ones prefixed by >>):
> >
> > drivers/pci/quirks.c: In function 'quirk_cavium_sriov_rnm_link':
> >>> drivers/pci/quirks.c:843:6: error: 'struct pci_dev' has no member named 'sriov'
> > dev->sriov->link = dev->devfn;
> > ^
> >
> > vim +843 drivers/pci/quirks.c
> >
> > 837 #ifdef CONFIG_ARM64
> > 838
> > 839 static void quirk_cavium_sriov_rnm_link(struct pci_dev *dev)
> > 840 {
> > 841 /* Fix for improper SRIOV configuration on Cavium cn88xx RNM device */
> > 842 if (dev->subsystem_device == 0xa118)
> >> 843 dev->sriov->link = dev->devfn;
> > 844 }
> > 845 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, 0xa018, quirk_cavium_sriov_rnm_link);
> > 846 #endif
---8<---
Subject: PCI: Fix cavium quirk compile failure with PCI_ATS off
The newly added quirk_cavium_sriov_rnm_link doesn't compile if
PCI_ATS is off. This patch adds a check for PCI_ATS.
Fixes: 21b5b8eebbae ("PCI: quirk fixup for cavium invalid sriov...")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 5980aae..7060823 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -834,7 +834,7 @@ static void quirk_amd_ioapic(struct pci_dev *dev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_VIPER_7410, quirk_amd_ioapic);
#endif /* CONFIG_X86_IO_APIC */
-#ifdef CONFIG_ARM64
+#if defined(CONFIG_ARM64) && defined(CONFIG_PCI_ATS)
static void quirk_cavium_sriov_rnm_link(struct pci_dev *dev)
{
--
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 related
* Re: algif_akcipher
From: Herbert Xu @ 2016-09-05 8:57 UTC (permalink / raw)
To: Stephan Mueller; +Cc: dhowells, linux-crypto, keyrings
In-Reply-To: <1708704.H7uTHYKb98@positron.chronox.de>
On Sun, Sep 04, 2016 at 04:06:43PM +0200, Stephan Mueller wrote:
> Hi Herbert, David,
>
> may I inquire for the plans with algif_akcipher? The reason I am asking is
> whether this interface may be accepted or whether a key rings based solution
> is used and whether I can leave or remove the akcipher related API from my
> libkcapi.
I do plan to add something like this eventually. However, at this
point in time I'd like to see akcipher itself mature a bit before
we set it in stone with a user-space interface.
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
* [PATCH v2] hwrng: pasemi_rng.c: Migrate to managed API
From: PrasannaKumar Muralidharan @ 2016-09-04 18:13 UTC (permalink / raw)
To: olof, mpm, herbert, linuxppc-dev, linux-crypto, darren,
clabbe.montjoie
Cc: PrasannaKumar Muralidharan
Use devm_ioremap and devm_hwrng_register instead of ioremap and
hwrng_register. This removes unregistering and error handling code.
Changes in v2:
Remove hardcoded resource size in ioremap, use resource struct obtained
by calling platform_get_resource.
Removing hardcoded resource size was suggested by LABBE Corentin.
CC: Darren Stevens <darren@stevens-zone.net>
Suggested-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/pasemi-rng.c | 37 +++++++------------------------------
1 file changed, 7 insertions(+), 30 deletions(-)
diff --git a/drivers/char/hw_random/pasemi-rng.c b/drivers/char/hw_random/pasemi-rng.c
index 699b725..b4e32f7 100644
--- a/drivers/char/hw_random/pasemi-rng.c
+++ b/drivers/char/hw_random/pasemi-rng.c
@@ -95,42 +95,20 @@ static struct hwrng pasemi_rng = {
.data_read = pasemi_rng_data_read,
};
-static int rng_probe(struct platform_device *ofdev)
+static int rng_probe(struct platform_device *pdev)
{
void __iomem *rng_regs;
- struct device_node *rng_np = ofdev->dev.of_node;
- struct resource res;
- int err = 0;
+ struct resource *res;
- err = of_address_to_resource(rng_np, 0, &res);
- if (err)
- return -ENODEV;
-
- rng_regs = ioremap(res.start, 0x100);
-
- if (!rng_regs)
- return -ENOMEM;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ rng_regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(rng_regs))
+ return PTR_ERR(rng_regs);
pasemi_rng.priv = (unsigned long)rng_regs;
pr_info("Registering PA Semi RNG\n");
-
- err = hwrng_register(&pasemi_rng);
-
- if (err)
- iounmap(rng_regs);
-
- return err;
-}
-
-static int rng_remove(struct platform_device *dev)
-{
- void __iomem *rng_regs = (void __iomem *)pasemi_rng.priv;
-
- hwrng_unregister(&pasemi_rng);
- iounmap(rng_regs);
-
- return 0;
+ return devm_hwrng_register(&pdev->dev, &pasemi_rng);
}
static const struct of_device_id rng_match[] = {
@@ -146,7 +124,6 @@ static struct platform_driver rng_driver = {
.of_match_table = rng_match,
},
.probe = rng_probe,
- .remove = rng_remove,
};
module_platform_driver(rng_driver);
--
2.5.0
^ permalink raw reply related
* algif_akcipher
From: Stephan Mueller @ 2016-09-04 14:06 UTC (permalink / raw)
To: herbert, dhowells; +Cc: linux-crypto, keyrings
Hi Herbert, David,
may I inquire for the plans with algif_akcipher? The reason I am asking is
whether this interface may be accepted or whether a key rings based solution
is used and whether I can leave or remove the akcipher related API from my
libkcapi.
Thanks a lot
Stephan
^ permalink raw reply
* [PATCH] hwrng: core - Allocate memory during module init
From: PrasannaKumar Muralidharan @ 2016-09-04 8:29 UTC (permalink / raw)
To: mpm, herbert, jslaby, peter, lee.jones, linux-crypto; +Cc: prasannatsmkumar
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.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/core.c | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 9203f2d..ec6846b 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,6 +557,17 @@ EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
static int __init hwrng_modinit(void)
{
+ /* 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;
+ }
+
return register_miscdev();
}
--
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