Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1533542 > unrolled thread

[PATCH 0/3] Add Broadcom SPU Crypto Driver

Started byRob Rice <rob.rice@broadcom.com>
First post2016-11-30 21:10 +0100
Last post2016-12-07 17:00 +0100
Articles 4 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 0/3] Add Broadcom SPU Crypto Driver Rob Rice <rob.rice@broadcom.com> - 2016-11-30 21:10 +0100
    [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry. Rob Rice <rob.rice@broadcom.com> - 2016-11-30 21:10 +0100
    Re: [PATCH 2/3] crypto: brcm: Add Broadcom SPU driver Mark Rutland <mark.rutland@arm.com> - 2016-12-06 15:20 +0100
      Re: [PATCH 2/3] crypto: brcm: Add Broadcom SPU driver "Rob (William) Rice" <rob.rice@broadcom.com> - 2016-12-07 17:00 +0100

#1533542 — [PATCH 0/3] Add Broadcom SPU Crypto Driver

FromRob Rice <rob.rice@broadcom.com>
Date2016-11-30 21:10 +0100
Subject[PATCH 0/3] Add Broadcom SPU Crypto Driver
Message-ID<sJjmx-2cG-5@gated-at.bofh.it>
The Broadcom SPU crypto driver provides access to SPU hardware
for symmetric crypto offload. The driver supports ablkcipher,
ahash, and aead operations. The driver supports several
Broadcom SoCs with different revisions of the SPU hardware.
The driver supports SPU-M and SPU2 hardware revisions, and
a couple versions of each hw revision, each version with minor
differences.

The device tree entries for the SPU depends on device tree entries
for the Broadcom PDC driver. The PDC DT entries have been accepted
upstream, but are not yet included in the crypto repo. See commit
e79249143f468f8d3365dbbd1642c045bdcc98c5.

Rob Rice (3):
  crypto: brcm: DT documentation for Broadcom SPU driver
  crypto: brcm: Add Broadcom SPU driver
  crypto: brcm: Add Broadcom SPU driver DT entry.

 .../devicetree/bindings/crypto/brcm,spu-crypto.txt |   25 +
 arch/arm64/boot/dts/broadcom/ns2.dtsi              |   12 +
 drivers/crypto/Kconfig                             |   10 +
 drivers/crypto/Makefile                            |    1 +
 drivers/crypto/bcm/Makefile                        |   15 +
 drivers/crypto/bcm/cipher.c                        | 4943 ++++++++++++++++++++
 drivers/crypto/bcm/cipher.h                        |  472 ++
 drivers/crypto/bcm/spu.c                           | 1252 +++++
 drivers/crypto/bcm/spu.h                           |  288 ++
 drivers/crypto/bcm/spu2.c                          | 1402 ++++++
 drivers/crypto/bcm/spu2.h                          |  228 +
 drivers/crypto/bcm/spum.h                          |  174 +
 drivers/crypto/bcm/util.c                          |  584 +++
 drivers/crypto/bcm/util.h                          |  117 +
 14 files changed, 9523 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
 create mode 100644 drivers/crypto/bcm/Makefile
 create mode 100644 drivers/crypto/bcm/cipher.c
 create mode 100644 drivers/crypto/bcm/cipher.h
 create mode 100644 drivers/crypto/bcm/spu.c
 create mode 100644 drivers/crypto/bcm/spu.h
 create mode 100644 drivers/crypto/bcm/spu2.c
 create mode 100644 drivers/crypto/bcm/spu2.h
 create mode 100644 drivers/crypto/bcm/spum.h
 create mode 100644 drivers/crypto/bcm/util.c
 create mode 100644 drivers/crypto/bcm/util.h

--
2.1.0

[toc] | [next] | [standalone]


#1533543 — [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.

FromRob Rice <rob.rice@broadcom.com>
Date2016-11-30 21:10 +0100
Subject[PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.
Message-ID<sJjmx-2cG-19@gated-at.bofh.it>
In reply to#1533542
Add Northstar2 device tree entry for Broadcom Secure Processing
Unit (SPU) crypto driver.

Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
Signed-off-by: Rob Rice <rob.rice@broadcom.com>
---
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index d95dc40..8b81b0d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -191,6 +191,18 @@

 		#include "ns2-clock.dtsi"

+		spu-crypto@612d0000 {
+			compatible = "brcm,spum-crypto";
+			reg = <0x612d0000 0x900>,    /* SPU 0 control regs */
+				<0x612f0000 0x900>,  /* SPU 1 control regs */
+				<0x61310000 0x900>,  /* SPU 2 control regs */
+				<0x61330000 0x900>;  /* SPU 3 control regs */
+			mboxes = <&pdc0 0>,
+				<&pdc1 0>,
+				<&pdc2 0>,
+				<&pdc3 0>;
+		};
+
 		dma0: dma@61360000 {
 			compatible = "arm,pl330", "arm,primecell";
 			reg = <0x61360000 0x1000>;
--
2.1.0

[toc] | [prev] | [next] | [standalone]


#1537001 — Re: [PATCH 2/3] crypto: brcm: Add Broadcom SPU driver

FromMark Rutland <mark.rutland@arm.com>
Date2016-12-06 15:20 +0100
SubjectRe: [PATCH 2/3] crypto: brcm: Add Broadcom SPU driver
Message-ID<sLoL7-39C-11@gated-at.bofh.it>
In reply to#1533542
On Wed, Nov 30, 2016 at 03:07:32PM -0500, Rob Rice wrote:
> +static const struct of_device_id bcm_spu_dt_ids[] = {
> +	{
> +		.compatible = "brcm,spum-crypto",
> +		.data = &spum_ns2_types,
> +	},
> +	{
> +		.compatible = "brcm,spum-nsp-crypto",
> +		.data = &spum_nsp_types,
> +	},
> +	{
> +		.compatible = "brcm,spu2-crypto",
> +		.data = &spu2_types,
> +	},
> +	{
> +		.compatible = "brcm,spu2-v2-crypto",
> +		.data = &spu2_v2_types,
> +	},

These last two weren't in the binding document.

> +	{ /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, bcm_spu_dt_ids);
> +
> +static int spu_dt_read(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct spu_hw *spu = &iproc_priv.spu;
> +	struct device_node *dn = pdev->dev.of_node;
> +	struct resource *spu_ctrl_regs;
> +	const struct of_device_id *match;
> +	struct spu_type_subtype *matched_spu_type;
> +	void __iomem *spu_reg_vbase[MAX_SPUS];
> +	int i;
> +	int err;
> +
> +	if (!of_device_is_available(dn)) {
> +		dev_crit(dev, "SPU device not available");
> +		return -ENODEV;
> +	}

How can this happen?

> +	/* Count number of mailbox channels */
> +	spu->num_chan = of_count_phandle_with_args(dn, "mboxes", "#mbox-cells");
> +	dev_dbg(dev, "Device has %d SPU channels", spu->num_chan);
> +
> +	match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
> +	matched_spu_type = (struct spu_type_subtype *)match->data;

This cast usn't necessary.

> +	spu->spu_type = matched_spu_type->type;
> +	spu->spu_subtype = matched_spu_type->subtype;
> +
> +	/* Read registers and count number of SPUs */
> +	i = 0;
> +	while ((i < MAX_SPUS) && ((spu_ctrl_regs =
> +		platform_get_resource(pdev, IORESOURCE_MEM, i)) != NULL)) {
> +		dev_dbg(dev,
> +			"SPU %d control register region res.start = %#x, res.end = %#x",
> +			i,
> +			(unsigned int)spu_ctrl_regs->start,
> +			(unsigned int)spu_ctrl_regs->end);
> +
> +		spu_reg_vbase[i] = devm_ioremap_resource(dev, spu_ctrl_regs);
> +		if (IS_ERR(spu_reg_vbase[i])) {
> +			err = PTR_ERR(spu_reg_vbase[i]);
> +			dev_err(&pdev->dev, "Failed to map registers: %d\n",
> +				err);
> +			spu_reg_vbase[i] = NULL;
> +			return err;
> +		}
> +		i++;
> +	}

These *really* sound like independent devices. There are no shared
registers, and each has its own mbox.

Why do we group them like this?

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]


#1537869 — Re: [PATCH 2/3] crypto: brcm: Add Broadcom SPU driver

From"Rob (William) Rice" <rob.rice@broadcom.com>
Date2016-12-07 17:00 +0100
SubjectRe: [PATCH 2/3] crypto: brcm: Add Broadcom SPU driver
Message-ID<sLMNt-1Yv-39@gated-at.bofh.it>
In reply to#1537001
Mark,

Thanks for the comments. Replies below.

Rob


On 12/6/2016 9:18 AM, Mark Rutland wrote:
> On Wed, Nov 30, 2016 at 03:07:32PM -0500, Rob Rice wrote:
>> +static const struct of_device_id bcm_spu_dt_ids[] = {
>> +	{
>> +		.compatible = "brcm,spum-crypto",
>> +		.data = &spum_ns2_types,
>> +	},
>> +	{
>> +		.compatible = "brcm,spum-nsp-crypto",
>> +		.data = &spum_nsp_types,
>> +	},
>> +	{
>> +		.compatible = "brcm,spu2-crypto",
>> +		.data = &spu2_types,
>> +	},
>> +	{
>> +		.compatible = "brcm,spu2-v2-crypto",
>> +		.data = &spu2_v2_types,
>> +	},
> These last two weren't in the binding document.
yes, I'll add them.
>
>> +	{ /* sentinel */ }
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, bcm_spu_dt_ids);
>> +
>> +static int spu_dt_read(struct platform_device *pdev)
>> +{
>> +	struct device *dev = &pdev->dev;
>> +	struct spu_hw *spu = &iproc_priv.spu;
>> +	struct device_node *dn = pdev->dev.of_node;
>> +	struct resource *spu_ctrl_regs;
>> +	const struct of_device_id *match;
>> +	struct spu_type_subtype *matched_spu_type;
>> +	void __iomem *spu_reg_vbase[MAX_SPUS];
>> +	int i;
>> +	int err;
>> +
>> +	if (!of_device_is_available(dn)) {
>> +		dev_crit(dev, "SPU device not available");
>> +		return -ENODEV;
>> +	}
> How can this happen?
You are correct. This is unnecessary. I will remove.
>
>> +	/* Count number of mailbox channels */
>> +	spu->num_chan = of_count_phandle_with_args(dn, "mboxes", "#mbox-cells");
>> +	dev_dbg(dev, "Device has %d SPU channels", spu->num_chan);
>> +
>> +	match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
>> +	matched_spu_type = (struct spu_type_subtype *)match->data;
> This cast usn't necessary.
Ok, will remove.
>
>> +	spu->spu_type = matched_spu_type->type;
>> +	spu->spu_subtype = matched_spu_type->subtype;
>> +
>> +	/* Read registers and count number of SPUs */
>> +	i = 0;
>> +	while ((i < MAX_SPUS) && ((spu_ctrl_regs =
>> +		platform_get_resource(pdev, IORESOURCE_MEM, i)) != NULL)) {
>> +		dev_dbg(dev,
>> +			"SPU %d control register region res.start = %#x, res.end = %#x",
>> +			i,
>> +			(unsigned int)spu_ctrl_regs->start,
>> +			(unsigned int)spu_ctrl_regs->end);
>> +
>> +		spu_reg_vbase[i] = devm_ioremap_resource(dev, spu_ctrl_regs);
>> +		if (IS_ERR(spu_reg_vbase[i])) {
>> +			err = PTR_ERR(spu_reg_vbase[i]);
>> +			dev_err(&pdev->dev, "Failed to map registers: %d\n",
>> +				err);
>> +			spu_reg_vbase[i] = NULL;
>> +			return err;
>> +		}
>> +		i++;
>> +	}
> These *really* sound like independent devices. There are no shared
> registers, and each has its own mbox.
>
> Why do we group them like this?
As I said in the previous email, I want one instance of the driver to 
register crypto algos once with the crypto API and to distribute crypto 
requests among all available SPU hw blocks.
>
> Thanks,
> Mark.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web