Re: [PATCH v2 1/2] drm: bridge: sil902x
Hi Archit, On Thu, 7 Jan 2016 11:12:47 +0530 Archit Taneja <arch...@codeaurora.org> wrote: > > > On 01/06/2016 05:55 PM, Boris Brezillon wrote: > > Add basic support for the sil902x RGB -> HDMI bridge. > > This driver does not support audio output yet. > > > > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com> > > --- > > Hello, > > > > This patch is only adding basic support for the sil9022 chip. > > As stated in the commit log, there's no audio support, but the > > driver also hardcodes a lot of things (like the RGB input format to > > use). > > There are two reasons for this: > > 1/ the DRM framework does not allow for advanced link description > > between an encoder and a bridge (that's for the RGB format > > limitation). Any idea how this should be described? > > The adv7511 driver uses a DT param "input_colorspace" to chose between > RGB or YUV. I don't think DT is the best idea, but I don't know of a > better way either. Yes, maybe not the best place, but I must admit that's a convenient way to set the link format. > > The connector's display_info.color_formats field gives us some info > about the color formats supported by the monitor, but I guess that > isn't sufficient data to know what format the encoder is pushing out. I created the ->bus_formats field in drm_display_info exactly for this purpose (it's used to detect the appropriate output format when connecting panels), but as you said, this is only describing the link between the connector and the display, not the link between the encoder and the bridge. I'm currently abusing this field (setting bus_formats to RGB888 in the sii902x driver), but that would be better to have this description at the encoder/bridge level. > > We get around this problem in case the case of DSI encoders by using > the mipi_dsi_device api, where a DSI based bridge or panel can pass > color format/lane info to the DSI host (i.e, encoder) by using > mipi_dsi_attach(). Yep, that's also an approach I considered a while ago: creating a DPI bus layer (not sure DPI is the correct name here), and implementing a DPI driver in atmel_hlcdc drivers and using DPI APIs on the slave side (panels and bridges/encoders). But I never had any feedback. > > > > > > 2/ I don't have the datasheet of this HDMI encoder, and all logic > > has been extracted from those two drivers [1][2], which means > > I may miss some important things in my encoder setup. > > > > Another thing I find weird in the drm_bridge interface is the fact > > that we have a ->attach() method, but no ->detach(), which can be > > a problem if we allow drm bridges and KMS drivers to be compiled as > > modules. Any reason for that? > > I guess the drm_bridge_add/remove ops make can ensure that the bridge > driver itself can be compiled as a module. However, you're right that > we would need a bridge detach op that the kms driver should call > before it is removed (to unregister the connector we created). > > Someone would still need to make sure about the order in which the > modules are removed. If the bridge driver is removed first, then > it would really mess up the kms driver using the bridge. Yes, the remove order is another problem we have to deal with > > > Would the kms driver using this chip really have an encoder? No, I have to create an encoder of type NONE to make everybody happy (we need an encoder + a connector to attach to a panel), but as I understand, when the KMS device outputs the pixel stream in raw RGB it's not considered as an encoder (which IMO is not such a good idea, because I have no way to represent my raw RGB connector :-/). > Since the chip takes in RGB input, I'm assuming that the encoder in > the kms driver would more or less be nop funcs, giving their way to > bridge ops. Exactly, that's a nop unless you have a panel connected to it. In the case it calls the drm_panel_xxx() functions. > > In such cases, I think the bridge still doesn't fit in so well. The > best fit here is how the current tda998x driver is modeled. It adds > itself as a component that creates both an encoder and connector, > which the kms driver can use directly. This approach, of course, > prevents us using tda998x in kms drivers that don't accept any > encoders that it didn't create itself. Actually that's what I did first [1], but I asked for some advice to other DRM developers, and they suggested to expose it as a drm_bridge. Now, I don't know what's the best option: I heard that some work was being done to merge the encoder slave and bridge concepts. I just thought external encoders were falling in that case too. And BTW, the different between all those compone
[PATCH 1/2] drm: bridge: sil902x
Add basic support for the sil902x RGB -> HDMI bridge. This driver does not support audio output yet. Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com> --- Hello, This patch is only adding basic support for the sil9022 chip. As stated in the commit log, there's no audio support, but the driver also hardcodes a lot of things (like the RGB input format to use). There are two reasons for this: 1/ the DRM framework does not allow for advanced link description between an encoder and a bridge (that's for the RGB format limitation). Any idea how this should be described? 2/ I don't have the datasheet of this HDMI encoder, and all logic has been extracted from those two drivers [1][2], which means I may miss some important things in my encoder setup. Another thing I find weird in the drm_bridge interface is the fact that we have a ->attach() method, but no ->detach(), which can be a problem if we allow drm bridges and KMS drivers to be compiled as modules. Any reason for that? That's all for the questions part :-). Best Regards, Boris --- drivers/gpu/drm/bridge/Kconfig | 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/sil902x.c | 491 +++ 3 files changed, 500 insertions(+) create mode 100644 drivers/gpu/drm/bridge/sil902x.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 27e2022..9701fd2 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -40,4 +40,12 @@ config DRM_PARADE_PS8622 ---help--- Parade eDP-LVDS bridge chip driver. +config DRM_SIL902X + tristate "Silicon Image sil902x RGB/HDMI bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + ---help--- + Silicon Image sil902x bridge chip driver. + endmenu diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index f13c33d..a689aad 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o +obj-$(CONFIG_DRM_SIL902X) += sil902x.o diff --git a/drivers/gpu/drm/bridge/sil902x.c b/drivers/gpu/drm/bridge/sil902x.c new file mode 100644 index 000..230732d --- /dev/null +++ b/drivers/gpu/drm/bridge/sil902x.c @@ -0,0 +1,491 @@ +/* + * Copyright (C) 2014 Atmel + * Bo Shen <voice.s...@atmel.com> + * + * Authors: Bo Shen <voice.s...@atmel.com> + * Boris Brezillon <boris.brezil...@free-electrons.com> + * Wu, Songjun <songjun...@atmel.com> + * + * + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#define SIL902X_TPI_VIDEO_DATA 0x0 + +#define SIL902X_TPI_PIXEL_REPETITION 0x8 +#define SIL902X_TPI_AVI_PIXEL_REP_BUS_24BIT BIT(5) +#define SIL902X_TPI_AVI_PIXEL_REP_RISING_EDGE BIT(4) +#define SIL902X_TPI_AVI_PIXEL_REP_4X 3 +#define SIL902X_TPI_AVI_PIXEL_REP_2X 1 +#define SIL902X_TPI_AVI_PIXEL_REP_NONE 0 +#define SIL902X_TPI_CLK_RATIO_HALF (0 << 6) +#define SIL902X_TPI_CLK_RATIO_1X (1 << 6) +#define SIL902X_TPI_CLK_RATIO_2X (2 << 6) +#define SIL902X_TPI_CLK_RATIO_4X (3 << 6) + +#define SIL902X_TPI_AVI_IN_FORMAT 0x9 +#define SIL902X_TPI_AVI_INPUT_BITMODE_12BITBIT(7) +#define SIL902X_TPI_AVI_INPUT_DITHER BIT(6) +#define SIL902X_TPI_AVI_INPUT_RANGE_LIMITED(2 << 2) +#define SIL902X_TPI_AVI_INPUT_RANGE_FULL (1 << 2) +#define SIL902X_TPI_AVI_INPUT_RANGE_AUTO (0 << 2) +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_BLACK (3 << 0) +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV422(2 << 0) +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV444(1 << 0) +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_RGB (0 << 0) + +#define SIL902X_TPI_AVI_INFOFRAME 0x0c + +#define SIL902X_SYS_CTRL_DATA 0x1a +#define SIL902X_SYS_CTRL_PWR_DWN BIT(4) +#d
[PATCH 2/2] drm: bridge: add sil902x DT bindings doc
Add Sil9022 DT bindings description.
Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
.../devicetree/bindings/display/bridge/sil902x.txt | 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/sil902x.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/sil902x.txt
b/Documentation/devicetree/bindings/display/bridge/sil902x.txt
new file mode 100644
index 000..7f1339f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sil902x.txt
@@ -0,0 +1,31 @@
+sil902x HDMI bridge bindings
+
+Required properties:
+ - compatible: "sil,sil9022"
+ - reg: i2c address of the bridge
+ - reset-gpios: OF device-tree gpio specification for RST_N pin.
+
+Optional properties:
+ - interrupts-extended or interrupt-parent + interrupts: describe
+ the interrupt line used to inform the host about hotplug events.
+
+Optional subnodes:
+ - video input: Device node can contain video input port node to
+ connect the bridge to a display controller output (See this
+ documentation [1]).
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+ hdmi-bridge@39 {
+ compatible = "sil,sil9022";
+ reg = <0x39>;
+ reset-gpios = < 5 1 0 0>;
+ ports {
+ port@0 {
+ bridge_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] drm: bridge: sil902x
Add basic support for the sil902x RGB -> HDMI bridge. This driver does not support audio output yet. Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com> --- Hello, This patch is only adding basic support for the sil9022 chip. As stated in the commit log, there's no audio support, but the driver also hardcodes a lot of things (like the RGB input format to use). There are two reasons for this: 1/ the DRM framework does not allow for advanced link description between an encoder and a bridge (that's for the RGB format limitation). Any idea how this should be described? 2/ I don't have the datasheet of this HDMI encoder, and all logic has been extracted from those two drivers [1][2], which means I may miss some important things in my encoder setup. Another thing I find weird in the drm_bridge interface is the fact that we have a ->attach() method, but no ->detach(), which can be a problem if we allow drm bridges and KMS drivers to be compiled as modules. Any reason for that? That's all for the questions part :-). Best Regards, Boris Changes in v2: - fix errors reported by kbuild test robot --- drivers/gpu/drm/bridge/Kconfig | 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/sil902x.c | 491 +++ 3 files changed, 500 insertions(+) create mode 100644 drivers/gpu/drm/bridge/sil902x.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 27e2022..9701fd2 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -40,4 +40,12 @@ config DRM_PARADE_PS8622 ---help--- Parade eDP-LVDS bridge chip driver. +config DRM_SIL902X + tristate "Silicon Image sil902x RGB/HDMI bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + ---help--- + Silicon Image sil902x bridge chip driver. + endmenu diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index f13c33d..a689aad 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o +obj-$(CONFIG_DRM_SIL902X) += sil902x.o diff --git a/drivers/gpu/drm/bridge/sil902x.c b/drivers/gpu/drm/bridge/sil902x.c new file mode 100644 index 000..2657031 --- /dev/null +++ b/drivers/gpu/drm/bridge/sil902x.c @@ -0,0 +1,491 @@ +/* + * Copyright (C) 2014 Atmel + * Bo Shen <voice.s...@atmel.com> + * + * Authors: Bo Shen <voice.s...@atmel.com> + * Boris Brezillon <boris.brezil...@free-electrons.com> + * Wu, Songjun <songjun...@atmel.com> + * + * + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#define SIL902X_TPI_VIDEO_DATA 0x0 + +#define SIL902X_TPI_PIXEL_REPETITION 0x8 +#define SIL902X_TPI_AVI_PIXEL_REP_BUS_24BIT BIT(5) +#define SIL902X_TPI_AVI_PIXEL_REP_RISING_EDGE BIT(4) +#define SIL902X_TPI_AVI_PIXEL_REP_4X 3 +#define SIL902X_TPI_AVI_PIXEL_REP_2X 1 +#define SIL902X_TPI_AVI_PIXEL_REP_NONE 0 +#define SIL902X_TPI_CLK_RATIO_HALF (0 << 6) +#define SIL902X_TPI_CLK_RATIO_1X (1 << 6) +#define SIL902X_TPI_CLK_RATIO_2X (2 << 6) +#define SIL902X_TPI_CLK_RATIO_4X (3 << 6) + +#define SIL902X_TPI_AVI_IN_FORMAT 0x9 +#define SIL902X_TPI_AVI_INPUT_BITMODE_12BITBIT(7) +#define SIL902X_TPI_AVI_INPUT_DITHER BIT(6) +#define SIL902X_TPI_AVI_INPUT_RANGE_LIMITED(2 << 2) +#define SIL902X_TPI_AVI_INPUT_RANGE_FULL (1 << 2) +#define SIL902X_TPI_AVI_INPUT_RANGE_AUTO (0 << 2) +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_BLACK (3 << 0) +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV422(2 << 0) +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV444(1 << 0) +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_RGB (0 << 0) + +#define SIL902X_TPI_AVI_INFOFRAME 0x0c + +#define SIL902X_SYS_CTRL_DATA 0x1a +#d
Re: [PATCH 2/2] drm: bridge: add sil902x DT bindings doc
Hi Rob,
On Wed, 6 Jan 2016 07:19:59 -0600
Rob Herring <r...@kernel.org> wrote:
> On Wed, Jan 06, 2016 at 12:25:51PM +0100, Boris Brezillon wrote:
> > Add Sil9022 DT bindings description.
> >
> > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > ---
> > .../devicetree/bindings/display/bridge/sil902x.txt | 31
> > ++
> > 1 file changed, 31 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/sil902x.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/sil902x.txt
> > b/Documentation/devicetree/bindings/display/bridge/sil902x.txt
> > new file mode 100644
> > index 000..7f1339f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/sil902x.txt
> > @@ -0,0 +1,31 @@
> > +sil902x HDMI bridge bindings
> > +
> > +Required properties:
> > + - compatible: "sil,sil9022"
> > + - reg: i2c address of the bridge
> > + - reset-gpios: OF device-tree gpio specification for RST_N pin.
> > +
> > +Optional properties:
> > + - interrupts-extended or interrupt-parent + interrupts: describe
> > + the interrupt line used to inform the host about hotplug events.
> > +
> > +Optional subnodes:
> > + - video input: Device node can contain video input port node to
> > + connect the bridge to a display controller output (See this
> > + documentation [1]).
> > +
> > +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> > +
> > +Example:
> > + hdmi-bridge@39 {
> > + compatible = "sil,sil9022";
> > + reg = <0x39>;
> > + reset-gpios = < 5 1 0 0>;
>
> 4 GPIO cells? Valid, but unusual.
Hehe, I blindly copied nxp,ptn3460 doc, which is defining such GPIO
descriptors :-). I can change that if you want.
>
> > + ports {
> > + port@0 {
>
> Either need a reg property here or drop the unit address. You could
> remove ports as well.
Actually we'll likely define a 2nd port for the audio input, so I'd
prefer keeping the ports and @0 suffix and adding a reg property rather
than just defining port { ... };
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] drm: bridge: sil902x
Hi Sascha, On Wed, 6 Jan 2016 14:47:36 +0100 Sascha Hauer <s.ha...@pengutronix.de> wrote: > Hi Boris, > > On Wed, Jan 06, 2016 at 12:25:50PM +0100, Boris Brezillon wrote: > > Add basic support for the sil902x RGB -> HDMI bridge. > > This driver does not support audio output yet. > > > > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com> > > --- > > Hello, > > > > This patch is only adding basic support for the sil9022 chip. > > This thing is a SiI9022 for camel case "Silicon Image" with a capital 'I', > not a small 'l'. Oh, my bad, I'll fix that, but the vendor prefix defined in Documentation/devicetree/bindings/vendor-prefixes.txt is not helping in getting this right. Should I also change the driver name? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] dt/bindings: qcom_nandc: Add DT bindings
Hi Archit,
On Tue, 5 Jan 2016 10:55:01 +0530
Archit Taneja <arch...@codeaurora.org> wrote:
> Add DT bindings document for the Qualcomm NAND controller driver.
>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <r...@kernel.org>
> Signed-off-by: Archit Taneja <arch...@codeaurora.org>
> ---
> v5:
> - Make changes to incorporate chip select sub nodes (brcmnand taken as
> reference)
>
> v3:
> - Don't use '0x' when specifying nand controller address space
> - Add optional property for on-flash bbt usage
>
> .../devicetree/bindings/mtd/qcom_nandc.txt | 84
> ++
> 1 file changed, 84 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> new file mode 100644
> index 000..b2cf2d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> @@ -0,0 +1,84 @@
> +* Qualcomm NAND controller
> +
> +Required properties:
> +- compatible:should be "qcom,ebi2-nand" for IPQ806x
> +- reg: MMIO address range
> +- clocks:must contain core clock and always on clock
> +- clock-names: must contain "core" for the core clock and
> "aon" for the
> + always on clock
> +- dmas: DMA specifier, consisting of a phandle to the
> ADM DMA
> + controller node and the channel number to be used for
> + NAND. Refer to dma.txt and qcom_adm.txt for more details
> +- dma-names: must be "rxtx"
> +- qcom,cmd-crci: must contain the ADM command type CRCI block instance
> + number specified for the NAND controller on the given
> + platform
> +- qcom,data-crci:must contain the ADM data type CRCI block instance
> + number specified for the NAND controller on the given
> + platform
> +- #address-cells:<1> - subnodes give the chip-select number
> +- #size-cells: <0>
> +
> +* NAND chip-select
> +
> +Each controller may contain one or more subnodes to represent enabled
> +chip-selects which (may) contain NAND flash chips. Their properties are as
> +follows.
> +
> +Required properties:
> +- compatible:should contain "qcom,nandcs"
> +- reg: a single integer representing the chip-select
> + number (e.g., 0, 1, 2, etc.)
> +- #address-cells:see partition.txt
> +- #size-cells: see partition.txt
> +- nand-ecc-strength: number of bits to correct per ECC step. Must be 4 or 8
> + bits.
> +- nand-ecc-step-size:bytes of data per ECC step. Must be 512.
> +
> +Optional properties:
> +- nand-bus-width:bus width. Must be 8 or 16. If not present, 8 is chosen
> + as default
You should probably reference
Documentation/devicetree/bindings/mtd/nand.txt which is documenting
generic nand-xxx properties.
> +
> +Each nandcs device node may optionally contain sub-nodes describing the flash
> +partition mapping. See partition.txt for more detail.
> +
> +Example:
> +
> +nand@1ac0 {
> + compatible = "qcom,ebi2-nandc";
> + reg = <0x1ac0 0x800>;
> +
> + clocks = < EBI2_CLK>,
> + < EBI2_AON_CLK>;
> + clock-names = "core", "aon";
> +
> + dmas = <_dma 3>;
> + dma-names = "rxtx";
> + qcom,cmd-crci = <15>;
> + qcom,data-crci = <3>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + nandcs@0 {
> + compatible = "qcom,nandcs";
> + reg = <0>;
> +
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> + nand-bus-width = <8>;
> +
It's now recommended to define a 'partitions' subnode to store those
partition nodes.
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "boot-nand";
> + reg = <0 0x58a>;
> + };
> +
> + partition@58a {
> + label = "fs-nand";
> + reg = <0x58a 0x400>;
> + };
> + };
> +};
The rest looks good to me.
Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] dt/bindings: qcom_nandc: Add DT bindings
On Wed, 6 Jan 2016 09:14:44 -0600 Rob Herring <r...@kernel.org> wrote: > On Tue, Jan 05, 2016 at 10:55:01AM +0530, Archit Taneja wrote: > > Add DT bindings document for the Qualcomm NAND controller driver. > > > > Cc: devicetree@vger.kernel.org > > Cc: Rob Herring <r...@kernel.org> > > Signed-off-by: Archit Taneja <arch...@codeaurora.org> > > --- > > v5: > > - Make changes to incorporate chip select sub nodes (brcmnand taken as > > reference) > > > > v3: > > - Don't use '0x' when specifying nand controller address space > > - Add optional property for on-flash bbt usage > > > > .../devicetree/bindings/mtd/qcom_nandc.txt | 84 > > ++ > > 1 file changed, 84 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt > > > > diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt > > b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt > > new file mode 100644 > > index 000..b2cf2d9 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt > > @@ -0,0 +1,84 @@ > > +* Qualcomm NAND controller > > + > > +Required properties: > > +- compatible: should be "qcom,ebi2-nand" for IPQ806x > > More specific name please. > > > +- reg: MMIO address range > > +- clocks: must contain core clock and always on clock > > +- clock-names: must contain "core" for the core clock and > > "aon" for the > > + always on clock > > +- dmas:DMA specifier, consisting of a phandle to the > > ADM DMA > > + controller node and the channel number to be used for > > + NAND. Refer to dma.txt and qcom_adm.txt for more details > > +- dma-names: must be "rxtx" > > +- qcom,cmd-crci: must contain the ADM command type CRCI block instance > > + number specified for the NAND controller on the given > > + platform > > +- qcom,data-crci: must contain the ADM data type CRCI block instance > > + number specified for the NAND controller on the given > > + platform > > +- #address-cells: <1> - subnodes give the chip-select number > > +- #size-cells: <0> > > + > > +* NAND chip-select > > + > > +Each controller may contain one or more subnodes to represent enabled > > +chip-selects which (may) contain NAND flash chips. Their properties are as > > +follows. > > + > > +Required properties: > > +- compatible: should contain "qcom,nandcs" > > +- reg: a single integer representing the chip-select > > + number (e.g., 0, 1, 2, etc.) > > +- #address-cells: see partition.txt > > +- #size-cells: see partition.txt > > +- nand-ecc-strength: number of bits to correct per ECC step. Must be > > 4 or 8 > > + bits. > > +- nand-ecc-step-size: bytes of data per ECC step. Must be 512. > > + > > +Optional properties: > > +- nand-bus-width: bus width. Must be 8 or 16. If not present, 8 is chosen > > + as default > > + > > +Each nandcs device node may optionally contain sub-nodes describing the > > flash > > +partition mapping. See partition.txt for more detail. > > Can't the partitioning span across chip selects? After all, interleaving > is how you get high performance. Hm, defining aggregated mtd devices in the DT is not supported, and since, as I've been told many times ;), DT is supposed to represent the HW not what we want to do with it, I'm not sure that's such a good idea. Note that the infrastructure to concatenate several MTD devices already exists, but it's not used by the NAND layer. Also note that some NAND chips embed several dies and expose multiple CS lines. The NAND framework already supports assigning different CS lines to a single NAND device, so you could abuse this feature and expose your different NAND devices as a single one (that will only work for a cluster of identical chips connected to the same controller), but I'd really like to avoid this kind of things. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] dt/bindings: qcom_nandc: Add DT bindings
On Wed, 6 Jan 2016 10:13:57 -0600 Rob Herring <r...@kernel.org> wrote: > On Wed, Jan 6, 2016 at 9:37 AM, Boris Brezillon > <boris.brezil...@free-electrons.com> wrote: > > On Wed, 6 Jan 2016 09:14:44 -0600 > > Rob Herring <r...@kernel.org> wrote: > > > >> On Tue, Jan 05, 2016 at 10:55:01AM +0530, Archit Taneja wrote: > >> > Add DT bindings document for the Qualcomm NAND controller driver. > >> > > >> > Cc: devicetree@vger.kernel.org > >> > Cc: Rob Herring <r...@kernel.org> > >> > Signed-off-by: Archit Taneja <arch...@codeaurora.org> > >> > --- > >> > v5: > >> > - Make changes to incorporate chip select sub nodes (brcmnand taken as > >> > reference) > >> > > >> > v3: > >> > - Don't use '0x' when specifying nand controller address space > >> > - Add optional property for on-flash bbt usage > >> > > >> > .../devicetree/bindings/mtd/qcom_nandc.txt | 84 > >> > ++ > >> > 1 file changed, 84 insertions(+) > >> > create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt > >> > > >> > diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt > >> > b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt > >> > new file mode 100644 > >> > index 000..b2cf2d9 > >> > --- /dev/null > >> > +++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt > >> > @@ -0,0 +1,84 @@ > >> > +* Qualcomm NAND controller > >> > + > >> > +Required properties: > >> > +- compatible: should be "qcom,ebi2-nand" for IPQ806x > >> > >> More specific name please. > >> > >> > +- reg: MMIO address range > >> > +- clocks: must contain core clock and always on clock > >> > +- clock-names: must contain "core" for the core clock and > >> > "aon" for the > >> > + always on clock > >> > +- dmas:DMA specifier, consisting of a phandle to > >> > the ADM DMA > >> > + controller node and the channel number to be used for > >> > + NAND. Refer to dma.txt and qcom_adm.txt for more > >> > details > >> > +- dma-names: must be "rxtx" > >> > +- qcom,cmd-crci: must contain the ADM command type CRCI block instance > >> > + number specified for the NAND controller on the given > >> > + platform > >> > +- qcom,data-crci: must contain the ADM data type CRCI block instance > >> > + number specified for the NAND controller on the given > >> > + platform > >> > +- #address-cells: <1> - subnodes give the chip-select number > >> > +- #size-cells: <0> > >> > + > >> > +* NAND chip-select > >> > + > >> > +Each controller may contain one or more subnodes to represent enabled > >> > +chip-selects which (may) contain NAND flash chips. Their properties are > >> > as > >> > +follows. > >> > + > >> > +Required properties: > >> > +- compatible: should contain "qcom,nandcs" > >> > +- reg: a single integer representing the chip-select > >> > + number (e.g., 0, 1, 2, etc.) > >> > +- #address-cells: see partition.txt > >> > +- #size-cells: see partition.txt > >> > +- nand-ecc-strength: number of bits to correct per ECC step. Must > >> > be 4 or 8 > >> > + bits. > >> > +- nand-ecc-step-size: bytes of data per ECC step. Must be 512. > >> > + > >> > +Optional properties: > >> > +- nand-bus-width: bus width. Must be 8 or 16. If not present, 8 is > >> > chosen > >> > + as default > >> > + > >> > +Each nandcs device node may optionally contain sub-nodes describing the > >> > flash > >> > +partition mapping. See partition.txt for more detail. > >> > >> Can't the partitioning span across chip selects? After all, interleaving > >> is how you get high performance. > > > > Hm, defining aggregated mtd devices in the D
Re: [PATCH v10 1/3] dt-bindings: binding for jz4780-{nand,bch}
On Thu, 24 Dec 2015 12:20:13 +
Harvey Hunt <harvey.h...@imgtec.com> wrote:
> From: Alex Smith <alex.sm...@imgtec.com>
>
> Add DT bindings for NAND devices connected to the NEMC on JZ4780 SoCs,
> as well as the hardware BCH controller, used by the jz4780_{nand,bch}
> drivers.
>
> Signed-off-by: Alex Smith <alex.sm...@imgtec.com>
> Cc: Zubair Lutfullah Kakakhel <zubair.kakak...@imgtec.com>
> Cc: David Woodhouse <dw...@infradead.org>
> Cc: Brian Norris <computersforpe...@gmail.com>
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: r...@kernel.org
> Signed-off-by: Harvey Hunt <harvey.h...@imgtec.com>
> Acked-by: Rob Herring <r...@kernel.org>
Already put my Reviewed-by on the previous version, but you seem to
have forgotten it.
Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
> v9 -> v10:
> - Added Rob Herring's Acked-by.
>
> v8 -> v9:
> - Document that partitions are represented as a child node of a NAND chip.
>
> v7 -> v8:
> - Describe how NAND chips are now child nodes of the NAND controller.
>
> v6 -> v7:
> - Add nand-ecc-mode to DT bindings.
> - Add nand-on-flash-bbt to DT bindings.
>
> v5 -> v6:
> - No change.
>
> v4 -> v5:
> - Rename ingenic,bch-device to ingenic,bch-controller to fit with
>existing convention.
>
> v3 -> v4:
> - No change
>
> v2 -> v3:
> - Rebase to 4.0-rc6
> - Changed ingenic,ecc-size to common nand-ecc-step-size
> - Changed ingenic,ecc-strength to common nand-ecc-strength
> - Changed ingenic,busy-gpio to common rb-gpios
> - Changed ingenic,wp-gpio to common wp-gpios
>
> v1 -> v2:
> - Rebase to 4.0-rc3
>
> .../bindings/mtd/ingenic,jz4780-nand.txt | 86
> ++
> 1 file changed, 86 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> new file mode 100644
> index 000..29ea585
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> @@ -0,0 +1,86 @@
> +* Ingenic JZ4780 NAND/BCH
> +
> +This file documents the device tree bindings for NAND flash devices on the
> +JZ4780. NAND devices are connected to the NEMC controller (described in
> +memory-controllers/ingenic,jz4780-nemc.txt), and thus NAND device nodes must
> +be children of the NEMC node.
> +
> +Required NAND controller device properties:
> +- compatible: Should be set to "ingenic,jz4780-nand".
> +- reg: For each bank with a NAND chip attached, should specify a bank number,
> + an offset of 0 and a size of 0x100 (i.e. the whole NEMC bank).
> +
> +Optional NAND controller device properties:
> +- ingenic,bch-controller: To make use of the hardware BCH controller, this
> + property must contain a phandle for the BCH controller node. The required
> + properties for this node are described below. If this is not specified,
> + software BCH will be used instead.
> +
> +Optional children nodes:
> +- Individual NAND chips are children of the NAND controller node.
> +
> +Required children node properties:
> +- reg: An integer ranging from 1 to 6 representing the CS line to use.
> +
> +Optional children node properties:
> +- nand-ecc-step-size: ECC block size in bytes.
> +- nand-ecc-strength: ECC strength (max number of correctable bits).
> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. "hw" by default
> +- nand-on-flash-bbt: boolean to enable on flash bbt option, if not present
> false
> +- rb-gpios: GPIO specifier for the busy pin.
> +- wp-gpios: GPIO specifier for the write protect pin.
> +
> +Optional child node of NAND chip nodes:
> +- partitions: see Documentation/devicetree/bindings/mtd/partition.txt
> +
> +Example:
> +
> +nemc: nemc@1341 {
> + ...
> +
> + nandc: nand-controller@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>; /* Bank 1 */
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ingenic,bch-controller = <>;
> +
> + nand@1 {
> + reg = <1>;
> +
> + nand-ecc-step-size = <1024>;
> + nand-ecc-strength = <24>;
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + rb-gpios = < 20
Re: [PATCH v10 3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes
On Thu, 24 Dec 2015 12:20:15 +
Harvey Hunt <harvey.h...@imgtec.com> wrote:
> From: Alex Smith <alex.sm...@imgtec.com>
>
> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
> and make use of them in the Ci20 device tree to add a node for the
> board's NAND.
>
> Note that since the pinctrl driver is not yet upstream, this includes
> neither pin configuration nor busy/write-protect GPIO pins for the
> NAND. Use of the NAND relies on the boot loader to have left the pins
> configured in a usable state, which should be the case when booted
> from the NAND.
>
> Signed-off-by: Alex Smith <alex.sm...@imgtec.com>
> Cc: Zubair Lutfullah Kakakhel <zubair.kakak...@imgtec.com>
> Cc: David Woodhouse <dw...@infradead.org>
> Cc: Brian Norris <computersforpe...@gmail.com>
> Cc: Paul Burton <paul.bur...@imgtec.com>
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: r...@kernel.org
> Signed-off-by: Harvey Hunt <harvey.h...@imgtec.com>
Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
> v9 -> v10:
> - No change.
>
> v8 -> v9:
> - Represent the partition table as a subnode of a NAND chip.
>
> v7 -> v8:
> - Describe the NAND chips as children nodes of the NAND controller.
> - Remove ingenic, prefix from ECC settings.
> - Renamed some ECC settings.
>
> v6 -> v7:
> - Add nand-ecc-mode to DT.
> - Add nand-on-flash-bbt to DT.
>
> v4 -> v5:
> - New patch adding DT nodes for the NAND so that the driver can be
>tested.
>
> arch/mips/boot/dts/ingenic/ci20.dts| 63
> ++
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 ++
> 2 files changed, 89 insertions(+)
>
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..782258c 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -42,3 +42,66 @@
> {
> status = "okay";
> };
> +
> + {
> + status = "okay";
> +
> + nandc: nand-controller@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ingenic,bch-controller = <>;
> +
> + ingenic,nemc-tAS = <10>;
> + ingenic,nemc-tAH = <5>;
> + ingenic,nemc-tBP = <10>;
> + ingenic,nemc-tAW = <15>;
> + ingenic,nemc-tSTRV = <100>;
> +
> + nand@1 {
> + reg = <1>;
> +
> + nand-ecc-step-size = <1024>;
> + nand-ecc-strength = <24>;
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + partitions {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + partition@0 {
> + label = "u-boot-spl";
> + reg = <0x0 0x0 0x0 0x80>;
> + };
> +
> + partition@0x80 {
> + label = "u-boot";
> + reg = <0x0 0x80 0x0 0x20>;
> + };
> +
> + partition@0xa0 {
> + label = "u-boot-env";
> + reg = <0x0 0xa0 0x0 0x20>;
> + };
> +
> + partition@0xc0 {
> + label = "boot";
> + reg = <0x0 0xc0 0x0 0x400>;
> + };
> +
> + partition@0x8c0 {
> + label = "system";
> + reg = <0x0 0x4c0 0x1 0xfb40>;
> + };
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> index 65389f6..b868b42 100644
> --- a/arch/mips/boot
Re: [PATCH v4 3/5] dt/bindings: qcom_nandc: Add DT bindings
Hi Archit,
Sorry for the late review, but there are a few things I think should be
addressed.
On Wed, 19 Aug 2015 10:19:04 +0530
Archit Taneja <arch...@codeaurora.org> wrote:
> Add DT bindings document for the Qualcomm NAND controller driver.
>
> Cc: devicetree@vger.kernel.org
>
> v4:
> - No changes
>
> v3:
> - Don't use '0x' when specifying nand controller address space
> - Add optional property for on-flash bbt usage
>
> Acked-by: Andy Gross <agr...@codeaurora.org>
> Signed-off-by: Archit Taneja <arch...@codeaurora.org>
> ---
> .../devicetree/bindings/mtd/qcom_nandc.txt | 49
> ++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> new file mode 100644
> index 000..1de4643
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> @@ -0,0 +1,49 @@
> +* Qualcomm NAND controller
> +
> +Required properties:
> +- compatible:should be "qcom,ebi2-nand" for IPQ806x
> +- reg: MMIO address range
> +- clocks:must contain core clock and always on clock
> +- clock-names: must contain "core" for the core clock and
> "aon" for the
> + always on clock
> +- dmas: DMA specifier, consisting of a phandle to the
> ADM DMA
> + controller node and the channel number to be used for
> + NAND. Refer to dma.txt and qcom_adm.txt for more details
> +- dma-names: must be "rxtx"
> +- qcom,cmd-crci: must contain the ADM command type CRCI block instance
> + number specified for the NAND controller on the given
> + platform
> +- qcom,data-crci:must contain the ADM data type CRCI block instance
> + number specified for the NAND controller on the given
> + platform
> +
> +Optional properties:
> +- nand-bus-width:bus width. Must be 8 or 16. If not present, 8 is chosen
> + as default
> +
> +- nand-ecc-strength: number of bits to correct per ECC step. Must be 4 or 8
> + bits. If not present, 4 is chosen as default
> +- nand-on-flash-bbt: Create/use on-flash bad block table
> +
> +The device tree may optionally contain sub-nodes describing partitions of the
> +address space. See partition.txt for more detail.
> +
> +Example:
> +
> +nand@1ac0 {
> + compatible = "qcom,ebi2-nandc";
> + reg = <0x1ac0 0x800>;
> +
> + clocks = < EBI2_CLK>,
> + < EBI2_AON_CLK>;
> + clock-names = "core", "aon";
> +
> + dmas = <_dma 3>;
> + dma-names = "rxtx";
> + qcom,cmd-crci = <15>;
> + qcom,data-crci = <3>;
> +
> + partition@0 {
> + ...
> + };
> +};
According to the registers layout defined in your driver, your NAND
controller can address multiple chips (NAND_DEV_SEL register). Since DT
bindings are supposed to be as stable as possible, I would recommend
separating the NAND controller and NAND chip declaration (as done here
[1] and here [2]).
Best Regards,
Boris
[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
[2]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 1/3] dt-bindings: binding for jz4780-{nand,bch}
On Thu, 3 Dec 2015 12:02:20 +
Harvey Hunt <harvey.h...@imgtec.com> wrote:
> From: Alex Smith <alex.sm...@imgtec.com>
>
> Add DT bindings for NAND devices connected to the NEMC on JZ4780 SoCs,
> as well as the hardware BCH controller, used by the jz4780_{nand,bch}
> drivers.
>
> Signed-off-by: Alex Smith <alex.sm...@imgtec.com>
> Cc: Zubair Lutfullah Kakakhel <zubair.kakak...@imgtec.com>
> Cc: David Woodhouse <dw...@infradead.org>
> Cc: Brian Norris <computersforpe...@gmail.com>
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Harvey Hunt <harvey.h...@imgtec.com>
FWIW:
Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
> v8 -> v9:
> - Document that partitions are represented as a child node of a NAND chip.
>
> v7 -> v8:
> - Describe how NAND chips are now child nodes of the NAND controller.
>
> v6 -> v7:
> - Add nand-ecc-mode to DT bindings.
> - Add nand-on-flash-bbt to DT bindings.
>
> v5 -> v6:
> - No change.
>
> v4 -> v5:
> - Rename ingenic,bch-device to ingenic,bch-controller to fit with
>existing convention.
>
> v3 -> v4:
> - No change
>
> v2 -> v3:
> - Rebase to 4.0-rc6
> - Changed ingenic,ecc-size to common nand-ecc-step-size
> - Changed ingenic,ecc-strength to common nand-ecc-strength
> - Changed ingenic,busy-gpio to common rb-gpios
> - Changed ingenic,wp-gpio to common wp-gpios
>
> v1 -> v2:
> - Rebase to 4.0-rc3
>
> .../bindings/mtd/ingenic,jz4780-nand.txt | 86
> ++
> 1 file changed, 86 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> new file mode 100644
> index 000..29ea585
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> @@ -0,0 +1,86 @@
> +* Ingenic JZ4780 NAND/BCH
> +
> +This file documents the device tree bindings for NAND flash devices on the
> +JZ4780. NAND devices are connected to the NEMC controller (described in
> +memory-controllers/ingenic,jz4780-nemc.txt), and thus NAND device nodes must
> +be children of the NEMC node.
> +
> +Required NAND controller device properties:
> +- compatible: Should be set to "ingenic,jz4780-nand".
> +- reg: For each bank with a NAND chip attached, should specify a bank number,
> + an offset of 0 and a size of 0x100 (i.e. the whole NEMC bank).
> +
> +Optional NAND controller device properties:
> +- ingenic,bch-controller: To make use of the hardware BCH controller, this
> + property must contain a phandle for the BCH controller node. The required
> + properties for this node are described below. If this is not specified,
> + software BCH will be used instead.
> +
> +Optional children nodes:
> +- Individual NAND chips are children of the NAND controller node.
> +
> +Required children node properties:
> +- reg: An integer ranging from 1 to 6 representing the CS line to use.
> +
> +Optional children node properties:
> +- nand-ecc-step-size: ECC block size in bytes.
> +- nand-ecc-strength: ECC strength (max number of correctable bits).
> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. "hw" by default
> +- nand-on-flash-bbt: boolean to enable on flash bbt option, if not present
> false
> +- rb-gpios: GPIO specifier for the busy pin.
> +- wp-gpios: GPIO specifier for the write protect pin.
> +
> +Optional child node of NAND chip nodes:
> +- partitions: see Documentation/devicetree/bindings/mtd/partition.txt
> +
> +Example:
> +
> +nemc: nemc@1341 {
> + ...
> +
> + nandc: nand-controller@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>; /* Bank 1 */
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ingenic,bch-controller = <>;
> +
> + nand@1 {
> + reg = <1>;
> +
> + nand-ecc-step-size = <1024>;
> + nand-ecc-strength = <24>;
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + rb-gpios = < 20 GPIO_ACTIVE_LOW>;
> + wp-gpios = < 22 GPIO_ACTIVE_LOW>;
> +
> + partitions {
> + #address-cells = <2>;
> +
Re: [PATCH v9 3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes
On Thu, 3 Dec 2015 12:02:22 +
Harvey Hunt <harvey.h...@imgtec.com> wrote:
> From: Alex Smith <alex.sm...@imgtec.com>
>
> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
> and make use of them in the Ci20 device tree to add a node for the
> board's NAND.
>
> Note that since the pinctrl driver is not yet upstream, this includes
> neither pin configuration nor busy/write-protect GPIO pins for the
> NAND. Use of the NAND relies on the boot loader to have left the pins
> configured in a usable state, which should be the case when booted
> from the NAND.
>
> Signed-off-by: Alex Smith <alex.sm...@imgtec.com>
> Cc: Zubair Lutfullah Kakakhel <zubair.kakak...@imgtec.com>
> Cc: David Woodhouse <dw...@infradead.org>
> Cc: Brian Norris <computersforpe...@gmail.com>
> Cc: Paul Burton <paul.bur...@imgtec.com>
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Signed-off-by: Harvey Hunt <harvey.h...@imgtec.com>
> ---
> v8 -> v9:
> - Represent the partition table as a subnode of a NAND chip.
>
> v7 -> v8:
> - Describe the NAND chips as children nodes of the NAND controller.
> - Remove ingenic, prefix from ECC settings.
> - Renamed some ECC settings.
>
> v6 -> v7:
> - Add nand-ecc-mode to DT.
> - Add nand-on-flash-bbt to DT.
>
> v4 -> v5:
> - New patch adding DT nodes for the NAND so that the driver can be
>tested.
>
> arch/mips/boot/dts/ingenic/ci20.dts| 63
> ++
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 ++
> 2 files changed, 89 insertions(+)
>
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..782258c 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -42,3 +42,66 @@
> {
> status = "okay";
> };
> +
> + {
> + status = "okay";
> +
> + nandc: nand-controller@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ingenic,bch-controller = <>;
> +
> + ingenic,nemc-tAS = <10>;
> + ingenic,nemc-tAH = <5>;
> + ingenic,nemc-tBP = <10>;
> + ingenic,nemc-tAW = <15>;
> + ingenic,nemc-tSTRV = <100>;
I guess those are encoding controller specific timings. Maybe they
could be automatically deduced from nand_timings information (I'm not
asking to implement that right now, but keep it in the back of your
mind as possible future improvements).
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib
Hi Brian,
On Wed, 2 Dec 2015 20:45:44 -0800
Brian Norris <computersforpe...@gmail.com> wrote:
> (to be clear, this branch of discussion isn't directly regarding the TI
> changes; we can handle any generic handling afterward, as long as we get
> the DT binding right now)
>
> On Tue, Oct 27, 2015 at 09:28:32AM +0100, Boris Brezillon wrote:
> > On Mon, 26 Oct 2015 13:49:00 -0700
> > Brian Norris <computersforpe...@gmail.com> wrote:
> > > On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
> > > > @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device
> > > > *pdev)
> > > > info->reg = pdata->reg;
> > > > info->of_node = pdata->of_node;
> > > > info->ecc_opt = pdata->ecc_opt;
> > > > - info->dev_ready = pdata->dev_ready;
> > > > + if (pdata->dev_ready)
> > > > + dev_info(>dev, "pdata->dev_ready is
> > > > deprecated\n");
> > > > +
> > > > info->xfer_type = pdata->xfer_type;
> > > > info->devsize = pdata->devsize;
> > > > info->elm_of_node = pdata->elm_of_node;
> > > > @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct
> > > > platform_device *pdev)
> > > > nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
> > > > nand_chip->cmd_ctrl = omap_hwcontrol;
> > > >
> > > > + info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
> > > > + GPIOD_IN);
> > >
> > > Others have been looking at using GPIOs for the ready/busy pin too. At a
> > > minimum, we need an updated DT binding doc for this, since I see you're
> > > adding this via device tree in a later patch (I don't see any DT binding
> > > patch for this; but I could just be overlooking it). It'd also be great
> > > if this support was moved to nand_dt_init() so other platforms can
> > > benefit, but I won't require that.
> >
> > Actually I started to work on a generic solution parsing the DT and
> > creating CS, WP and RB gpios when they are provided, but I think it's a
> > bit more complicated than just moving the rb-gpios parsing into
> > nand_dt_init().
> > First you'll need something to store your gpio_desc pointers, which
> > means you'll have to allocate a table of gpio_desc pointers (or a table
> > of struct embedding a gpio_desc pointer).
>
> I'm not sure what you mean by table. It seems like we would just have a
> few gpio_desc pointers in struct nand_chip, no?
Nope, because a single nand_chip can use several CS and R/B lines,
hence the gpio_desc array.
>
> > The other blocking point is that when nand_scan_ident() is called, the
> > caller is supposed to have filled the ->dev_ready() or ->waitfunc()
> > fields, and to choose how to implement it he may need to know
> > which kind of RB handler should be used (this is the case in the sunxi
> > driver, where the user can either use a GPIO or native R/B pin directly
> > connected to the controller).
>
> Right, I was thinking about this one.
>
> > All this makes me think that maybe nand_dt_init() should be called
> > separately or in a different helper (nand_init() ?) taking care of the
> > basic nand_chip initializations/allocations without interacting with
> > the NAND itself.
>
> Yeah, I feel like there have been other good reasons for something like
> this before, and we just have worked around them so far. Maybe something
> more like the alloc/add split in many other subsystems? e.g.,
> platform_device_{alloc,add}, spi_{alloc,add}_device. Now we might want
> nand_alloc()?
>
> On a slight tangent, it seems silly that nand_scan_tail() doesn't
> register the MTD, but nand_release() unregisters it. That shouldn't be.
Yep, that's one of the things we should address too.
>
> > Another solution would be to add an ->init() function to nand_chip
> > and call it after the generic initialization has been done (but before
> > NAND chip detection). This way the NAND controller driver could adapt
> > some fields and parse controller specific properties.
>
> That could work too, I guess.
Hm, all these suggestions have been made before I started my
nand_controller/nand_chip separation work, and I think we can get
something way simpler if we switch to a model where the core
implements most of the initialization steps (including
Re: [PATCH] mtd: grab a reference to the MTD of_node before registering it
On Wed, 11 Nov 2015 16:26:04 -0800 Brian Norris <computersforpe...@gmail.com> wrote: > We now stick the device node representing the current MTD (if any) into > sysfs, so let's make sure we have a reference to it before doing that. > > Suggested-by: Boris Brezillon <boris.brezil...@free-electrons.com> > Signed-off-by: Brian Norris <computersforpe...@gmail.com> Looks good to me, Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com> > --- > drivers/mtd/mtdcore.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c > index a91cee90aef9..c393a1155376 100644 > --- a/drivers/mtd/mtdcore.c > +++ b/drivers/mtd/mtdcore.c > @@ -32,6 +32,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -454,6 +455,7 @@ int add_mtd_device(struct mtd_info *mtd) > mtd->dev.devt = MTD_DEVT(i); > dev_set_name(>dev, "mtd%d", i); > dev_set_drvdata(>dev, mtd); > + of_node_get(mtd_get_of_node(mtd)); > error = device_register(>dev); > if (error) > goto fail_added; > @@ -476,6 +478,7 @@ int add_mtd_device(struct mtd_info *mtd) > return 0; > > fail_added: > + of_node_put(mtd_get_of_node(mtd)); > idr_remove(_idr, i); > fail_locked: > mutex_unlock(_table_mutex); > @@ -517,6 +520,7 @@ int del_mtd_device(struct mtd_info *mtd) > device_unregister(>dev); > > idr_remove(_idr, mtd->index); > + of_node_put(mtd_get_of_node(mtd)); > > module_put(THIS_MODULE); > ret = 0; -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7,1/3] dt-bindings: binding for jz4780-{nand,bch}
Hi Harvey,
On Tue, 6 Oct 2015 17:27:15 +0100
Harvey Hunt <harvey.h...@imgtec.com> wrote:
> From: Alex Smith <alex.sm...@imgtec.com>
>
> Add DT bindings for NAND devices connected to the NEMC on JZ4780 SoCs,
> as well as the hardware BCH controller, used by the jz4780_{nand,bch}
> drivers.
Patch 3 does not seem to follow this binding: it still uses the
ingenic,ecc-xxx properties and defines NAND timings.
Also, as answered to patch 3, I think it would be clearer to separate
the nand controller and nand chip representation.
Best Regards,
Boris
>
> Signed-off-by: Alex Smith <alex.sm...@imgtec.com>
> Cc: Zubair Lutfullah Kakakhel <zubair.kakak...@imgtec.com>
> Cc: David Woodhouse <dw...@infradead.org>
> Cc: Brian Norris <computersforpe...@gmail.com>
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: Alex Smith <a...@alex-smith.me.uk>
> Signed-off-by: Harvey Hunt <harvey.h...@imgtec.com>
> ---
> v6 -> v7:
> - Add nand-ecc-mode to DT bindings.
> - Add nand-on-flash-bbt to DT bindings.
>
> v5 -> v6:
> - No change.
>
> v4 -> v5:
> - Rename ingenic,bch-device to ingenic,bch-controller to fit with
>existing convention.
>
> v3 -> v4:
> - No change
>
> v2 -> v3:
> - Rebase to 4.0-rc6
> - Changed ingenic,ecc-size to common nand-ecc-step-size
> - Changed ingenic,ecc-strength to common nand-ecc-strength
> - Changed ingenic,busy-gpio to common rb-gpios
> - Changed ingenic,wp-gpio to common wp-gpios
>
> v1 -> v2:
> - Rebase to 4.0-rc3
>
> .../bindings/mtd/ingenic,jz4780-nand.txt | 61
> ++
> 1 file changed, 61 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> new file mode 100644
> index 000..44a0468
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> @@ -0,0 +1,61 @@
> +* Ingenic JZ4780 NAND/BCH
> +
> +This file documents the device tree bindings for NAND flash devices on the
> +JZ4780. NAND devices are connected to the NEMC controller (described in
> +memory-controllers/ingenic,jz4780-nemc.txt), and thus NAND device nodes must
> +be children of the NEMC node.
> +
> +Required NAND device properties:
> +- compatible: Should be set to "ingenic,jz4780-nand".
> +- reg: For each bank with a NAND chip attached, should specify a bank number,
> + an offset of 0 and a size of 0x100 (i.e. the whole NEMC bank).
> +
> +Optional NAND device properties:
> +- ingenic,bch-controller: To make use of the hardware BCH controller, this
> + property must contain a phandle for the BCH controller node. The required
> + properties for this node are described below. If this is not specified,
> + software BCH will be used instead.
> +- nand-ecc-step-size: ECC block size in bytes.
> +- nand-ecc-strength: ECC strength (max number of correctable bits).
> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. "hw" by default
> +- nand-on-flash-bbt: boolean to enable on flash bbt option if not present
> false
> +- rb-gpios: GPIO specifier for the busy pin.
> +- wp-gpios: GPIO specifier for the write protect pin.
> +
> +Example:
> +
> +nemc: nemc@1341 {
> + ...
> +
> + nand: nand@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>; /* Bank 1 */
> +
> + ingenic,bch-controller = <>;
> + nand-ecc-step-size = <1024>;
> + nand-ecc-strength = <24>;
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + rb-gpios = < 20 GPIO_ACTIVE_LOW>;
> + wp-gpios = < 22 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +The BCH controller is a separate SoC component used for error correction on
> +NAND devices. The following is a description of the device properties for a
> +BCH controller.
> +
> +Required BCH properties:
> +- compatible: Should be set to "ingenic,jz4780-bch".
> +- reg: Should specify the BCH controller registers location and length.
> +- clocks: Clock for the BCH controller.
> +
> +Example:
> +
> +bch: bch@134d {
> + compatible = "ingenic,jz4780-bch";
> + reg = <0x134d 0x1>;
> +
> + clocks = < JZ4780_CLK_BCH>;
> +};
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes
Paul, Harvey,
On Fri, 16 Oct 2015 11:48:48 +0100
Paul Burton <paul.bur...@imgtec.com> wrote:
> On Fri, Oct 16, 2015 at 11:31:12AM +0100, James Hogan wrote:
> > > >> +
> > > >> + {
> > > >> + status = "okay";
> > > >> +
> > > >> + nand: nand@1 {
> > > >> + compatible = "ingenic,jz4780-nand";
> > > >
> > > > Isn't the NAND a micron part? This doesn't seem right. Is the device
> > > > driver and binding already accepted upstream with that compatible
> > > > string?
> > >
> > > This is the compatible string for the JZ4780 NAND driver, this patch
> > > is part of the series adding that. Detection of the NAND part is
> > > handled by the MTD subsystem.
> >
> > Right (didn't spot that it was part of a series).
> >
> > The node appears to describe the NAND interface itself, i.e. a part of
> > the SoC, so should be in the SoC dtsi file, with overrides in the board
> > file if necessary for it to work with a particular NAND part
> > (potentially utilising status="disabled"). Would you agree?
>
> Hi James,
>
> The "nemc" node there is for the Nand & External Memory Controller which
> is a hardware block inside the SoC. It has 6 banks (ie. 6 chip select
> pins, each associated with a different address range, that connect to
> different devices). NAND flash is one such possible device, but a board
> could connect it to any of the 6 chip selects, or banks. To represent
> that in the SoC dtsi you'd want to have 6 NAND nodes, each disabled by
> default, which doesn't make a whole lot of sense to me. Other, non-NAND
> devices can connect to the NEMC too - for example the ethernet
> controller on the CI20 is connected to one bank.
>
> The NAND device nodes are sort of a mix of describing the NAND flash
> (ie. Micron part as you point out) and its connections & properties, the
> way the NEMC should be used to interact with it alongside the BCH block,
> and the configuration for the NEMC such as timing parameters.
>
> I imagine the most semantically correct means of describing it would
> probably be for the compatible string to reflect the Micron NAND part,
> and the NEMC driver to pick up on the relevant properties of its child
> nodes for configuring timings, whether the device is NAND etc. However
> the handling of registering NAND devices with MTD would probably then
> have to be part of the NEMC driver, which feels a bit off too.
Another solution would be to describe both the NAND controller and the
NAND chip in the DT (with the NAND chip being a chip of the NAND
controller).
Actually this is already what other binding are doing [1][2]. I know
those bindings are representing NAND controllers which can interface
with more than one NAND chip, but I think that even in the 1:1 case it
would make it clearer to represent both the NAND chip and the NAND
controller.
In your case this would give the following representation
+ {
+ status = "okay";
+
+ nandc: nand-controller@1 {
+ compatible = "ingenic,jz4780-nand";
+ reg = <1 0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ingenic,bch-controller = <>;
+
+ nand@0 {
+ nand-ecc-mode = "hw";
+ nand-on-flash-bbt;
+ nand-ecc-size = <1024>;
+ nand-ecc-strength = <24>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ partition@0 {
+ label = "u-boot-spl";
+ reg = <0x0 0x0 0x0 0x80>;
+ };
+ /* ... */
+
+ };
+ };
+};
Best Regards,
Boris
[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt#L119
[2]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt#L28
>
> Thanks,
> Paul
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mtd: ofpart: drop undocumented, nonfunctional 'lock' property
Hi Brian,
On Tue, 27 Oct 2015 11:32:44 -0700
Brian Norris <computersforpe...@gmail.com> wrote:
> Hi Sascha,
>
> On Tue, Oct 27, 2015 at 08:11:06AM +0100, Sascha Hauer wrote:
> > On Mon, Oct 26, 2015 at 06:56:06PM -0700, Brian Norris wrote:
> > > The 'lock' property of a partition does nothing, because it effectively
> > > only sets the flags for the partition device, not the master device. And
> > > no MTD driver checks for MTD_POWERUP_LOCK in the partition device, only
> > > the master device.
> >
> > This is not true. The flag gets checked in add_mtd_device:
> >
> > /* Some chips always power up locked. Unlock them now */
> > if ((mtd->flags & MTD_WRITEABLE) && (mtd->flags & MTD_POWERUP_LOCK)) {
> > error = mtd_unlock(mtd, 0, mtd->size);
> > ...
> > }
> >
> > add_mtd_device() is called either for the master mtd device or for each
> > partition (if there are partitions). The flow is like that:
> >
> > - Some flash devices come up locked from power on. Drivers for these
> > devices set the MTD_POWERUP_LOCK flag (cfi_cmdset_0001.c,
> > cfi_cmdset_0002.c)
> > - The partitions inherit the flags from the master device, but not the
> > ones set in mask_flags:
> >
> > ofpart.c:
> >
> > if (of_get_property(pp, "lock", ))
> > (*pparts)[i].mask_flags |= MTD_POWERUP_LOCK;
> >
> > mtdpart.c:
> >
> > slave->mtd.flags = master->flags & ~part->mask_flags;
> >
> > - So if the lock property is not set then the MTD_POWERUP_LOCK flag is
> > still set in add_mtd_device() for the partition and the corresponding
> > partition is not unlocked. Otherwise the partition is unlocked.
>
> Wow, you're absolutely correct, and I'm not sure how I overlooked that.
> So I guess this patch [1] should be rewritten to be clearer, and the
> $subject patch dropped.
>
> > So how I see it the mechanism is still functional, except that it's
> > broken when the recently introduced option MTD_PARTITIONED_MASTER is
> > set. When it's set then add_mtd_device() is called for the master device
> > aswell and the whole device gets unlocked. When the partitions are
> > registered later then it makes no difference whether they are unlocked
> > or not, they are already unlocked anyway.
>
> It's also broken for overlapping partitions. Similarly to some previous
> proposals for per-partition ECC handling for NAND, I think.
But do we really care about this case? I mean, if someone is stupid
enough to put different values for two overlapping partitions it
won't work correctly. The only thing we could do is complain loudly
about this mismatch.
For the per-partition proposal I posted a few weeks ago I assumed
overlapping partitions with different ECC configs were valid, which
means data will only be readable from one of the partitions: the one
who last wrote data on it (note that this is not true if you're using
raw access mode).
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib
Hi Roger, On Tue, 27 Oct 2015 10:03:02 +0200 Roger Quadros <rog...@ti.com> wrote: > On 26/10/15 22:49, Brian Norris wrote: > > > > Others have been looking at using GPIOs for the ready/busy pin too. At a > > minimum, we need an updated DT binding doc for this, since I see you're > > adding this via device tree in a later patch (I don't see any DT binding > > patch for this; but I could just be overlooking it). It'd also be great > > if this support was moved to nand_dt_init() so other platforms can > > benefit, but I won't require that. > > > > Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio' > > (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't > > really care, but the name should be going into a doc, so we can choose > > the same one everywhere. > > > > EDIT: looks like the discussion was partly here [1] and it seems we're > > landing on "rb-gpios" in the latest version [2]. Can we stick with that? > > Why should it be "rb-gpios" and not "rb-gpio"? > I don't think there are multiple gpios for r/b# function. Because it's supposed to be a generic binding, and some NAND chips embed several dies, thus exposing several CS and RB pins, hence the rb-gpios name. Also, as described here [1], the convention is to name your property -gpios even if you only need one gpio. Best Regards, Boris [1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/gpio/gpio.txt#L16 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib
Hi Brian,
On Mon, 26 Oct 2015 13:49:00 -0700
Brian Norris <computersforpe...@gmail.com> wrote:
> + others
>
> A few comments below.
>
> On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
> > The GPMC WAIT pin status are now available over gpiolib.
> > Update the omap_dev_ready() function to use gpio instead of
> > directly accessing GPMC register space.
> >
> > Signed-off-by: Roger Quadros <rog...@ti.com>
> > ---
> > drivers/mtd/nand/omap2.c | 29
> > +---
> > include/linux/platform_data/mtd-nand-omap2.h | 2 +-
> > 2 files changed, 19 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> > index 228f498..d0f2620 100644
> > --- a/drivers/mtd/nand/omap2.c
> > +++ b/drivers/mtd/nand/omap2.c
> > @@ -12,6 +12,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -184,6 +185,8 @@ struct omap_nand_info {
> > /* fields specific for BCHx_HW ECC scheme */
> > struct device *elm_dev;
> > struct device_node *of_node;
> > + /* NAND ready gpio */
> > + struct gpio_desc*ready_gpiod;
> > };
> >
> > /**
> > @@ -1047,22 +1050,17 @@ static int omap_wait(struct mtd_info *mtd, struct
> > nand_chip *chip)
> > }
> >
> > /**
> > - * omap_dev_ready - calls the platform specific dev_ready function
> > + * omap_dev_ready - checks the NAND Ready GPIO line
> > * @mtd: MTD device structure
> > + *
> > + * Returns true if ready and false if busy.
> > */
> > static int omap_dev_ready(struct mtd_info *mtd)
> > {
> > - unsigned int val = 0;
> > struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
> > mtd);
> >
> > - val = readl(info->reg.gpmc_status);
> > -
> > - if ((val & 0x100) == 0x100) {
> > - return 1;
> > - } else {
> > - return 0;
> > - }
> > + return gpiod_get_value(info->ready_gpiod);
> > }
> >
> > /**
> > @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device
> > *pdev)
> > info->reg = pdata->reg;
> > info->of_node = pdata->of_node;
> > info->ecc_opt = pdata->ecc_opt;
> > - info->dev_ready = pdata->dev_ready;
> > + if (pdata->dev_ready)
> > + dev_info(>dev, "pdata->dev_ready is
> > deprecated\n");
> > +
> > info->xfer_type = pdata->xfer_type;
> > info->devsize = pdata->devsize;
> > info->elm_of_node = pdata->elm_of_node;
> > @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device
> > *pdev)
> > nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
> > nand_chip->cmd_ctrl = omap_hwcontrol;
> >
> > + info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
> > + GPIOD_IN);
>
> Others have been looking at using GPIOs for the ready/busy pin too. At a
> minimum, we need an updated DT binding doc for this, since I see you're
> adding this via device tree in a later patch (I don't see any DT binding
> patch for this; but I could just be overlooking it). It'd also be great
> if this support was moved to nand_dt_init() so other platforms can
> benefit, but I won't require that.
Actually I started to work on a generic solution parsing the DT and
creating CS, WP and RB gpios when they are provided, but I think it's a
bit more complicated than just moving the rb-gpios parsing into
nand_dt_init().
First you'll need something to store your gpio_desc pointers, which
means you'll have to allocate a table of gpio_desc pointers (or a table
of struct embedding a gpio_desc pointer).
The other blocking point is that when nand_scan_ident() is called, the
caller is supposed to have filled the ->dev_ready() or ->waitfunc()
fields, and to choose how to implement it he may need to know
which kind of RB handler should be used (this is the case in the sunxi
driver, where the user can either use a GPIO or native R/B pin directly
connected to the controller).
All this makes me think that maybe nand_dt_init() should be called
separately or in a different helper (nand_init() ?) taking care of the
basic nand_chip initializations/allocations without interacting with
the NAND itself.
Another solution would be to add an ->init() function to nand_chip
and call it after the generic initialization has been done (but before
NAND chip detection). This way the NAND controller driver could adapt
some fields and parse controller specific properties.
What do you think?
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/3] devicetree: macb: Add optional property tsu-clk
Hi Harini, On Mon, 14 Sep 2015 09:39:05 +0530 Harini Katakam <harinikatakamli...@gmail.com> wrote: > On Fri, Sep 11, 2015 at 10:22 PM, Sören Brinkmann > <soren.brinkm...@xilinx.com> wrote: > > Hi Harini, > > > > On Fri, 2015-09-11 at 01:27PM +0530, Harini Katakam wrote: > >> Add TSU clock frequency to be used for 1588 support in macb driver. > >> > >> Signed-off-by: Harini Katakam <hari...@xilinx.com> > >> --- > >> Documentation/devicetree/bindings/net/macb.txt |3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/net/macb.txt > >> b/Documentation/devicetree/bindings/net/macb.txt > >> index b5d7976..f7c0ea8 100644 > >> --- a/Documentation/devicetree/bindings/net/macb.txt > >> +++ b/Documentation/devicetree/bindings/net/macb.txt > >> @@ -19,6 +19,9 @@ Required properties: > >> Optional elements: 'tx_clk' > >> - clocks: Phandles to input clocks. > >> > >> +Optional properties: > >> +- tsu-clk: Time stamp unit clock frequency used. > > > > Why are we not using the CCF and a clk_get_rate() in the driver? > > > > If the clock source was only internal, we could use this > approach as usual. But TSU clock can be configured to > come from an external clock source or internal. How about declaring a fixed-rate clk [1] if it comes from an external clk, and using a clk driver for the internal clk case? This way you'll be able to use the clk API (including the clk_get_rate() function) instead of introducing a new way to retrieve a clk frequency. Best Regards, Boris [1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/clock/fixed-clock.txt -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 3/5] mtd: nand: vf610_nfc: add device tree bindings
Hi Bill, On Wed, 26 Aug 2015 11:26:36 -0400 Bill Pringlemeir bprin...@sympatico.ca wrote: On 25 Aug 2015, computersforpe...@gmail.com wrote: Sorry, I realized a potential issue here. On Mon, Aug 03, 2015 at 11:27:28AM +0200, Stefan Agner wrote: Signed-off-by: Bill Pringlemeir bpringlem...@nbsps.com Acked-by: Shawn Guo shawn...@kernel.org Reviewed-by: Brian Norris computersforpe...@gmail.com Signed-off-by: Stefan Agner ste...@agner.ch --- .../devicetree/bindings/mtd/vf610-nfc.txt | 45 ++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt new file mode 100644 index 000..cae5f25 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt -0,0 +1,45 @@ +- nand-bus-width: see nand.txt +- nand-ecc-mode: see nand.txt +- nand-on-flash-bbt: see nand.txt Stumbling across the multi-CS questions on the driver reminds me: it typically makes sense to define new NAND bindings using separate NAND *controller* and *flash* device nodes. The above 3 properties, at least, would apply on a per-flash basis, not per-controller typically. See sunxi-nand, for instance: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt brcmnand had a similar pattern: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt (Perhaps it's time we standardized this a little more formally...) These would apply per chip, but the controller has to be configured to support each and every one. Every time an operation was performed, we would have to check the chip type and reconfigure the controller. Currently, the driver does not support this and it would add a lot of overhead in some cases unless a register cache was used. Is the flexibility of using a system with combined 8/16bit devices really worth all the overhead? Isn't it sort of brain dead hardware not to make all of the chips similar? Why would everyone have to pay for such a crazy setup? To separate it would at least be a lie versus the code in the current form. As well, there are only a few SOC which support multiple chip selects. The 'multi-CS' register bits of this controller varies between PowerPC, 68K/Coldfire and ARM platforms. I looked briefly at the brcmnand.c and it seems that it is not supporting different ECC per chip even though the nodes are broken out this way. In fact, if some raw functions are called, I think it will put it in ECC mode even if it wasn't before? Well, I agree that this would be good generically, I think it puts a lot of effort in the drivers for not so much payoff? Hm, the sunxi driver supports it, and it does not add such a big overhead... The only thing you have to do is cache a bunch of register values per-chip and restore/apply them when the chip is selected (in your -select_chip() implementation). Anyway, even if the suggested DT representation is a lie in regards to your implementation, it's actually pretty accurate from an hardware POV, and this is exactly what DT is supposed to represent. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
Brian, Stefan,
On Tue, 25 Aug 2015 12:54:11 -0700
Brian Norris computersforpe...@gmail.com wrote:
On Mon, Aug 03, 2015 at 11:28:43AM +0200, Stefan Agner wrote:
On 2015-08-03 11:27, Stefan Agner wrote:
snip
+static inline int vf610_nfc_correct_data(struct mtd_info *mtd, uint8_t
*dat,
+ uint8_t *oob, int oob_loaded)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+ u8 ecc_status;
+ u8 ecc_count;
+ int flip;
+
+ ecc_status = __raw_readb(nfc-regs + ECC_SRAM_ADDR * 8 + ECC_OFFSET);
Why __raw_readb()? That's not normally encourage, and it has issues with
endianness. It looks like maybe this is actulaly a 32-bit register, and
you're having trouble when trying to do bytewise access? I see this
earlier:
/*
* ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
* and +7 for big-endian SoCs.
*/
#ifdef __LITTLE_ENDIAN
#define ECC_OFFSET 4
#else
#define ECC_OFFSET 7
#endif
So maybe you really just want:
#define ECC_OFFSET4
...
ecc_status = vf610_nfc_read(ECC_SRAM_ADDR * 8 + ECC_OFFSET) 0xff;
?
+ ecc_count = ecc_status ECC_ERR_COUNT;
+
+ if (!(ecc_status ECC_STATUS_MASK))
+ return ecc_count;
+
+ if (!oob_loaded)
+ vf610_nfc_read_buf(mtd, oob, mtd-oobsize);
+
+ /*
+ * On an erased page, bit count (including OOB) should be zero or
+ * at least less then half of the ECC strength.
+ */
+ flip = count_written_bits(dat, nfc-chip.ecc.size, ecc_count);
Another side note: why are you using ecc_count as a max threshold? AIUI,
an ECC algorithm doesn't really report useful error count information if
it's above the correction limit. So wouldn't we be looking to count up
to our SW threshold? i.e., ecc.strength / 2, or similar? Similar
comments below.
The exact threshold value is still something I'm not sure about, though
I'm sure it should be correlated to ecc.strength value (whether it's
directly set to ecc.strength or less than ecc.strength is something
we'll have to figure out).
+ flip += count_written_bits(oob, mtd-oobsize - nfc-chip.ecc.bytes,
+ecc_count);
With ECC the controller seems to clear the ECC bytes in SRAM buffer.
This is a dump of 64 Bit OOB with the 32-error ECC mode which requires
60 bytes of OOB for ECC:
[ 22.190273] ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Hmm, that's not really good. The point is that we need to make sure that
everything that could have been programmed (including the ECC area) was
not actually programmed. But your ECC controller is not, contrary to
MTD's expectations, dumping raw uncorrected data here.
Yep, for this test we really need the ECC bytes generated for the chunk
you're currently testing.
How to retrieve those bytes really depends on your NAND controller, but
such controllers usually provides a way to disable the ECC engine. The
only thing you'll have to do in this case is disable the ECC engine and
read the OOB data (using RNDOUT and read_buf for example).
[ 22.209698] vf610_nfc_correct_data, flips 1
Not sure if this is acceptable, but I now only count the bits in the
non-ECC area of the OOB.
That's not the intention of my suggestion. You're still missing out on a
class of patterns that might look close to all 0xff but are not
actually.
Exactly.
If the HW ECC really doesn't give you valid data+OOB at this point, then
you might have to re-read with ECC disabled. Of course, that's got a
performance cost...
As suggested above, if that's possible, reading the OOB area (or a
portion of the OOB area) with the ECC engine disabled should be enough.
Or perhaps Boris has a better suggestion? He's been surveying other NAND
drivers that need to do similar things, and he's working on providing
some support code for common design patterns.
Yep, the patch series is here in case you want to have a look [1].
Best Regards,
Boris
[1]https://patchwork.ozlabs.org/patch/509970/
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] mtd: ofpart: move ofpart partitions to a dedicated dt node
Hi Michal,
On Thu, 30 Jul 2015 12:10:42 +0200
Michal Suchanek hramr...@gmail.com wrote:
Parsing direct subnodes of a mtd device as partitions is unreliable
since the mtd device is also part of its bus subsystem and can contain
bus data in subnodes.
Move ofpart data to a subnode of its own so it is clear which data is
part of the partition layout.
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
drivers/mtd/ofpart.c | 56
+---
1 file changed, 40 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index aa26c32..2c28aaa 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -29,23 +29,33 @@ static int parse_ofpart_partitions(struct mtd_info
*master,
struct mtd_partition **pparts,
struct mtd_part_parser_data *data)
{
- struct device_node *node;
+ struct device_node *mtd_node;
+ struct device_node *ofpart_node;
const char *partname;
struct device_node *pp;
int nr_parts, i;
+ bool dedicated = true;
if (!data)
return 0;
- node = data-of_node;
- if (!node)
+ mtd_node = data-of_node;
+ if (!mtd_node)
return 0;
+ ofpart_node = of_get_child_by_name(mtd_node, ofpart);
Hm, you should use a more generic name, ofpart of the linux MTD
DT partition parser, but another operating system might decide to name
it otherwise. I think partitions is more appropriate.
+ if (!ofpart_node) {
+ pr_warn(%s: 'ofpart' subnode not found on %s. Trying to parse
direct subnodes as partitions.\n,
+ master-name, mtd_node-full_name);
Do we really want to complain here. I mean, a lot of users do not need
to define their partition in a different node.
+ ofpart_node = mtd_node;
+ dedicated = false;
+ }
+
/* First count the subnodes */
nr_parts = 0;
- for_each_child_of_node(node, pp) {
- if (node_has_compatible(pp))
+ for_each_child_of_node(ofpart_node, pp) {
+ if (!dedicated node_has_compatible(pp))
continue;
nr_parts++;
@@ -59,22 +69,36 @@ static int parse_ofpart_partitions(struct mtd_info
*master,
return -ENOMEM;
i = 0;
- for_each_child_of_node(node, pp) {
+ for_each_child_of_node(ofpart_node, pp) {
const __be32 *reg;
int len;
int a_cells, s_cells;
- if (node_has_compatible(pp))
- continue;
+ if (!dedicated node_has_compatible(pp))
+ continue;
Check your indentation (checkpatch should complain here).
reg = of_get_property(pp, reg, len);
if (!reg) {
+ if (dedicated) {
+ pr_debug(%s: ofpart partition %s (%s) missing
reg property.\n,
+ master-name, pp-full_name,
+ mtd_node-full_name);
+ goto ofpart_fail;
+ } else {
nr_parts--;
continue;
Ditto.
+ }
}
a_cells = of_n_addr_cells(pp);
s_cells = of_n_size_cells(pp);
+ if (len / 4 != a_cells + s_cells) {
+ pr_debug(%s: ofpart partition %s (%s) error parsing
reg property.\n,
+ master-name, pp-full_name,
+ mtd_node-full_name);
+ goto ofpart_fail;
+ }
+
The above changes have nothing to do with the description you gave in
your commit message.
(*pparts)[i].offset = of_read_number(reg, a_cells);
(*pparts)[i].size = of_read_number(reg + a_cells, s_cells);
@@ -92,15 +116,15 @@ static int parse_ofpart_partitions(struct mtd_info
*master,
i++;
}
- if (!i) {
- of_node_put(pp);
- pr_err(No valid partition found on %s\n, node-full_name);
- kfree(*pparts);
- *pparts = NULL;
- return -EINVAL;
- }
-
Are you sure you can safely remove this check?
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] mtd: ofpart: move ofpart partitions to a dedicated dt node
On Fri, 31 Jul 2015 18:52:01 +0200
Michal Suchanek hramr...@gmail.com wrote:
(*pparts)[i].offset = of_read_number(reg, a_cells);
(*pparts)[i].size = of_read_number(reg + a_cells, s_cells);
@@ -92,15 +116,15 @@ static int parse_ofpart_partitions(struct mtd_info
*master,
i++;
}
- if (!i) {
- of_node_put(pp);
- pr_err(No valid partition found on %s\n, node-full_name);
- kfree(*pparts);
- *pparts = NULL;
- return -EINVAL;
- }
-
Are you sure you can safely remove this check?
Yes. It was incomplete check to reject some partitioning schemes
considered invalid.
Now there is stricter checking above so this can be removed.
Indeed, I was worried about resources deallocation, but this is handle
by the caller, and if nr_parts is zero the master MTD device will
be exposed.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data
Hi Michal,
On Wed, 29 Jul 2015 12:19:57 +0200
Michal Suchanek hramr...@gmail.com wrote:
The controller-data subnode has no compatible. This can lead to other
drivers getting confused by it. Add a compatible to make devicetreee
unambiguous.
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
Documentation/devicetree/bindings/spi/spi-samsung.txt | 3 +++
drivers/spi/spi-s3c64xx.c | 4
2 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt
b/Documentation/devicetree/bindings/spi/spi-samsung.txt
index 6dbdeb3..b1e98d1 100644
--- a/Documentation/devicetree/bindings/spi/spi-samsung.txt
+++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt
@@ -92,16 +92,19 @@ Example:
spi-max-frequency = 1;
controller-data {
+ compatible = samsung,s3c-controller-data;
AFAIK compatible should (as much as possible :-)) only be used to encode
HW type, and here you're using it to expose what you want to do with
your data in Linux.
samsung,spi-feedback-delay = 0;
};
partition@0 {
+ compatible = linux,ofpart-partition;
Ditto.
Since you have to patch your DTs anyway, how about putting your
partitions in a subnode and patch the ofpart code to parse this subnode
if it is present (see the following patch).
Best Regards,
Boris
--- 8 ---
From e342860932bda3a6354a0a6e17540db5c85a14e0 Mon Sep 17 00:00:00 2001
From: Boris Brezillon boris.brezil...@free-electrons.com
Date: Thu, 30 Jul 2015 09:44:07 +0200
Subject: [PATCH] mtd: ofpart: search for a partitions node
The DT partition parser currently assumes the parition definitions are
directly stored in the MTD device node, but sometime this device node
contains other child nodes used to store device specific information.
Search for a partitions subnode containing the partition definitions,
if it is not there, parse the definitions in the device node.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/mtd/ofpart.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 8a06cfb..ba52b88 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -38,7 +38,10 @@ static int parse_ofpart_partitions(struct mtd_info *master,
if (!data)
return 0;
- node = data-of_node;
+ node = of_get_child_by_name(data-of_node, partitions);
+ if (!node)
+ node = data-of_node;
+
if (!node)
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/2] mfd: devicetree: add bindings for Atmel Flexcom
On Thu, 23 Jul 2015 18:42:55 +0200
Cyrille Pitchen cyrille.pitc...@atmel.com wrote:
This patch documents the DT bindings for the Atmel Flexcom which will be
introduced by sama5d2x SoCs. These bindings will be used by the actual
Flexcom driver to be sent in another patch.
Signed-off-by: Cyrille Pitchen cyrille.pitc...@atmel.com
---
.../devicetree/bindings/mfd/atmel-flexcom.txt | 68
++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
new file mode 100644
index ..a63226b7a9cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
@@ -0,0 +1,68 @@
+* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit)
+
+The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
+controller and an USART. Only one function can be used at a time and is
chosen
+at boot time according to the device tree.
+
+Required properties:
+- compatible:Should be atmel,sama5d2-flexcom
+- reg: Should be the pair (offset, size) for the
Flexcom
+ dedicated I/O registers (without USART, TWI or SPI
+ registers).
+- clocks:Should be the Flexcom peripheral clock from PMC.
+- #address-cells:Should be 2
+- #size-cells: Should be 1
+- ranges:Should be a list of ranges.
+ One range per peripheral wrapped by the Flexcom. So each
+ range is a triplet (child_addr, parent_addr, size). The
+ first u32 of child_addr is the value to be set in the
+ Operating Mode bitfield of the Flexcom Mode Register.
+ Then parent_addr stores the base address of the
+ corresponding peripheral in the system memory. Finally,
+ size if the size of the memory region of this
+ peripheral.
+
+Required child:
+A single available child for the serial controller to enable.
+
+Required properties of this child:
+- reg: Should be a pair (child_addr, size) with
child_addr
+ matching one of the parent ranges.
+- clocks:Should be the very same phandle as for the parent's one.
+
+Other properties remain unchanged. See documentation of the respective
device:
+- ../serial/atmel-usart.txt
+- ../spi/spi_atmel.txt
+- ../i2c/i2c-at91.txt
+
+Example:
+
+flexcom@f8034000 {
+ compatible = atmel,sama5d2-flexcom;
+ reg = 0xf8034000 0x200;
+ clocks = flx0_clk;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 1 0 0xf8034200 0x200 /* opmode 1: USART */
+ 2 0 0xf8034400 0x200 /* opmode 2: SPI */
+ 3 0 0xf8034600 0x200;/* opmode 3: I2C */
+
+ spi@f8034400 {
Should be:
spi@2,0 {
+ compatible = atmel,at91rm9200-spi;
+ reg = 2 0 0x200;
+ interrupts = 19 IRQ_TYPE_LEVEL_HIGH 7;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_flx0_default;
+ #address-cells = 1;
+ #size-cells = 0;
+ clocks = flx0_clk;
+ clock-names = spi_clk;
+ atmel,fifo-size = 32;
+
+ mtd_dataflash@0 {
+ compatible = atmel,at25f512b;
+ reg = 0;
+ spi-max-frequency = 2000;
+ };
+ };
+};
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] mfd: atmel-flexcom: add a driver for Atmel Flexible Serial Communication Unit
On Thu, 23 Jul 2015 10:13:11 +0100
Lee Jones lee.jo...@linaro.org wrote:
On Thu, 23 Jul 2015, Boris Brezillon wrote:
Hi Lee,
On Thu, 23 Jul 2015 08:32:17 +0100
Lee Jones lee.jo...@linaro.org wrote:
On Wed, 22 Jul 2015, Cyrille Pitchen wrote:
+ for_each_child_of_node(np, child) {
+ const char *compatible;
+ int cplen;
+
+ if (!of_device_is_available(child))
+ continue;
+
+ compatible = of_get_property(child, compatible,
cplen);
+ if (!compatible || strlen(compatible) cplen)
+ continue;
+
+ if (strstr(compatible, -usart)) {
+ opmode = FLEX_MR_OPMODE_USART;
+ break;
+ }
+
+ if (strstr(compatible, -spi)) {
+ opmode = FLEX_MR_OPMODE_SPI;
+ break;
+ }
+
+ if (strstr(compatible, -i2c)) {
+ opmode = FLEX_MR_OPMODE_TWI;
+ break;
+ }
+ }
From what I understand Flexcom is a wrapper which can sit above any
number of SPI, I2C and/or UART devices. Devices which you don't
really have any control over (source code wise). So wouldn't it be
better to match on the details you do have control over i.e. the node
name, rather than the compatible string?
I would personally match on of_find_node_by_name() to future-proof
your implementation.
Actually, I think using compatible strings is more future-proof than
using the node names, because nothing in the DT bindings doc enforce the
node name, and usually what we use to attach a node to a specific
driver is the compatible string (this one is specified in the bindings
doc).
I know what you're saying, but what if someone uses the Flexcom driver
to wrap a different type of SPI driver where (for instance) the
compatible string used is name-newtype. Then we'd have to keep
adding more lines here to accommodate.
Whereas if we used the child node name which only pertains to _this_
driver, we would then have full control and know that (unless it
Flexcom is used for a completely different type of serial controller)
we wouldn't have to keep expanding the code to accommodate.
You're right about the complexity implied by the compat string
maintenance, but I still think using node names to detect the mode is
a bad idea.
Let's take another example making both solution unsuitable: what if
the flexcom-v2 exposes 2 devices of the same type, they will both have
the same name and the same compatible string, and we'll have no way to
detect the appropriate mode. That's why I think none of our suggestion
is future-proof.
Regarding the implementation itself, I would match the child node with
an of_device_id table rather than trying to find a specific substring
in the compatible string, but I think that's only a matter of taste.
You mean duplicate each of the supported device's compatible strings
in this driver, then fetch the attributed of_match_device()-data
value?
Yes, and that's definitely not a good idea, but I think Cyrille has
found a better approach (I'll let him explain).
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] mfd: atmel-flexcom: add a driver for Atmel Flexible Serial Communication Unit
Hi Lee,
On Thu, 23 Jul 2015 08:32:17 +0100
Lee Jones lee.jo...@linaro.org wrote:
On Wed, 22 Jul 2015, Cyrille Pitchen wrote:
+ for_each_child_of_node(np, child) {
+ const char *compatible;
+ int cplen;
+
+ if (!of_device_is_available(child))
+ continue;
+
+ compatible = of_get_property(child, compatible, cplen);
+ if (!compatible || strlen(compatible) cplen)
+ continue;
+
+ if (strstr(compatible, -usart)) {
+ opmode = FLEX_MR_OPMODE_USART;
+ break;
+ }
+
+ if (strstr(compatible, -spi)) {
+ opmode = FLEX_MR_OPMODE_SPI;
+ break;
+ }
+
+ if (strstr(compatible, -i2c)) {
+ opmode = FLEX_MR_OPMODE_TWI;
+ break;
+ }
+ }
From what I understand Flexcom is a wrapper which can sit above any
number of SPI, I2C and/or UART devices. Devices which you don't
really have any control over (source code wise). So wouldn't it be
better to match on the details you do have control over i.e. the node
name, rather than the compatible string?
I would personally match on of_find_node_by_name() to future-proof
your implementation.
Actually, I think using compatible strings is more future-proof than
using the node names, because nothing in the DT bindings doc enforce the
node name, and usually what we use to attach a node to a specific
driver is the compatible string (this one is specified in the bindings
doc).
Regarding the implementation itself, I would match the child node with
an of_device_id table rather than trying to find a specific substring
in the compatible string, but I think that's only a matter of taste.
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] regulator: pwm-regulator: Re-write bindings
Hi Lee,
On Tue, 7 Jul 2015 16:06:50 +0100
Lee Jones lee.jo...@linaro.org wrote:
* Add support for continuous-voltage mode
* Put more meat on the bones with regards to voltage-table mode
* Sort out formatting for ease of consumption
Cc: devicetree@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
.../bindings/regulator/pwm-regulator.txt | 68
++
1 file changed, 56 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index ce91f61..892b366 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -1,27 +1,71 @@
-pwm regulator bindings
+Bindings for the Generic PWM Regulator
+==
+
+Currently supports 2 modes of operation:
+
+voltage-table: When in this mode, a voltage table (See below)
of
+ predefined voltage = duty-cycle values must be
+ provided via DT. Limitations are that the regulator can
+ only operate at the voltages supplied in the table.
+ Intermediary duty-cycle values which would normally
+ allow finer grained voltage selection are ignored and
+ rendered useless. Although more control is given to
+ the user if the assumptions made in continuous-voltage
+ mode do not reign true.
+
+continuous-voltage: This mode uses the regulator's maximum and minimum
+ supplied voltages specified in the
+ regulator-{min,max}-microvolt properties to calculate
+ appropriate duty-cycle values. This allows for a much
+ more fine grained solution when compared with
+ voltage-table mode above. This solution does make an
+ assumption that a %50 duty-cycle value will cause the
+ regulator voltage to run at half way between the
+ supplied max_uV and min_uV values.
Do we really have to specify a new property to select the mode ?
The existing DT will have to be modified anyway, so maybe we can just
add a new compatible string differentiate those two modes.
Also note that if you're doing linear interpolation between the points
specified in the voltage-table instead of doing it on the min - max
values, you wouldn't have to modify the binding.
Required properties:
-- compatible: Should be pwm-regulator
-- pwms: OF device-tree PWM specification (see PWM binding pwm.txt)
-- voltage-table: voltage and duty table, include 2 members in each set of
- brackets, first one is voltage(unit: uv), the next is duty(unit: percent)
+
+- compatible:Should be pwm-regulator
+
+- pwms: PWM specification (See: ../pwm/pwm.txt)
+
+One of these must be provided:
+- voltage-table: Voltage and Duty-Cycle table consisting of 2 cells
+ First cell is voltage in microvolts (uV)
+ Second cell is duty-cycle in percent (%)
+
+- max-duty-cycle:Maximum Duty-Cycle value -- this will normally be
+ 255 (0xff) for an 8 bit PWM device
Why are you introducing another random unit. What is max-duty-cycle
really encoding (I guess it has to do with the precision you're
expecting, but I'm not sure) ?
The PWM framework is using nanoseconds, the existing pwm-regulator
binding is using percents. Shouldn't we reuse one of them (I
guess you changed that because the percent unit was not precise
enough) ?
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/14] crypto: add a new driver for Marvell's CESA
Hi Herbert, On Sun, 21 Jun 2015 16:27:17 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Sun, Jun 21, 2015 at 10:24:18AM +0200, Boris Brezillon wrote: Indeed. Here is a patch fixing that. I think you should just kill COMPILE_TEST instead of adding ARM. The following patch is killing the COMPILE_TEST dependency. -- 8 -- From 772232fe4f5e597e45701dd9c3ab68c4a065342f Mon Sep 17 00:00:00 2001 From: Boris Brezillon boris.brezil...@free-electrons.com Date: Mon, 22 Jun 2015 09:22:14 +0200 Subject: [PATCH] crypto: marvell/CESA: remove COMPILE_TEST dependency The CESA driver calls phys_to_virt() which is not available on all architectures. Remove the depency on COMPILE_TEST to prevent building this driver on non ARM architectures. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Reported-by: Paul Gortmaker paul.gortma...@windriver.com Suggested-by: Herbert Xu herb...@gondor.apana.org.au --- drivers/crypto/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index cdca762..f965d0c 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -176,7 +176,7 @@ config CRYPTO_DEV_MV_CESA config CRYPTO_DEV_MARVELL_CESA tristate New Marvell's Cryptographic Engine driver - depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) HAS_DMA HAS_IOMEM + depends on PLAT_ORION || ARCH_MVEBU select CRYPTO_AES select CRYPTO_DES select CRYPTO_BLKCIPHER -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in
Re: [PATCH v7 00/14] crypto: add a new driver for Marvell's CESA
Hi Herbert, On Sun, 21 Jun 2015 16:27:17 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Sun, Jun 21, 2015 at 10:24:18AM +0200, Boris Brezillon wrote: Indeed. Here is a patch fixing that. I think you should just kill COMPILE_TEST instead of adding ARM. Okay, I guess I should also kill the HAS_DMA and HAS_IOMEM since PLAT_ORION and ARCH_MVEBU are guaranteed to have those options selected. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in
Re: [PATCH v7 00/14] crypto: add a new driver for Marvell's CESA
Hi Paul, On Sat, 20 Jun 2015 20:14:08 -0400 Paul Gortmaker paul.gortma...@windriver.com wrote: On Sat, Jun 20, 2015 at 4:32 PM, Paul Gortmaker paul.gortma...@windriver.com wrote: On Fri, Jun 19, 2015 at 10:24 AM, Herbert Xu herb...@gondor.apana.org.au wrote: On Thu, Jun 18, 2015 at 03:46:16PM +0200, Boris Brezillon wrote: Hello, This patch series adds a new driver supporting Marvell's CESA IP. This driver addresses some limitations of the existing one. From a performance and CPU load point of view the most important limitation in the existing driver is the lack of DMA support, thus preventing us from chaining crypto operations. All applied to cryptodev. Thanks a lot! It seems this breaks linux-next allmodconfig on i386: Similar breakage for s390 and sparc it seems: drivers/crypto/marvell/cesa.c:353:2: error: implicit declaration of function 'phys_to_dma' [-Werror=implicit-function-declaration] http://kisskb.ellerman.id.au/kisskb/buildresult/12445415/ http://kisskb.ellerman.id.au/kisskb/buildresult/12445345/ If the CESA IP is only available on a single arch then adding an arch dependency might be the easiest fix, since phys_to_dma seems sparsely implemented. Indeed. Here is a patch fixing that. Thanks, Boris --- 8 --- From 891d4e5f185c39cd34b5859a1a63850ef997514d Mon Sep 17 00:00:00 2001 From: Boris Brezillon boris.brezil...@free-electrons.com Date: Sun, 21 Jun 2015 10:17:54 +0200 Subject: [PATCH] crypto: marvell/CESA: enforce dependency on ARM The CESA driver calls phys_to_virt() which is not available on all architectures. Enforce the dependency on ARM so that other architectures won't compile the driver even if COMPILE_TEST is set. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Reported-by: Paul Gortmaker paul.gortma...@windriver.com Suggested-by: Paul Gortmaker paul.gortma...@windriver.com --- drivers/crypto/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index cdca762..b374d5d 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -176,7 +176,7 @@ config CRYPTO_DEV_MV_CESA config CRYPTO_DEV_MARVELL_CESA tristate New Marvell's Cryptographic Engine driver - depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) HAS_DMA HAS_IOMEM + depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) HAS_DMA HAS_IOMEM ARM select CRYPTO_AES select CRYPTO_DES select CRYPTO_BLKCIPHER -- 1.9.1 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in
[PATCH v7 03/14] crypto: mv_cesa: explicitly define kirkwood and dove compatible strings
We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA support on Dove and Kirkwood.
In the other hand, the migration from the old driver to the new one is not
something all people are willing to do without first auditing the new
driver.
Hence we have to support the new compatible in the mv_cesa driver so that
new platforms with updated DTs can still attach their crypto engine device
to this driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 5 -
drivers/crypto/mv_cesa.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index 13b8fc5..c0c35f0 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -1,7 +1,10 @@
Marvell Cryptographic Engines And Security Accelerator
Required properties:
-- compatible : should be marvell,orion-crypto
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
- reg: base physical address of the engine and length of memory mapped
region. Can also contain an entry for the SRAM attached to the CESA,
but this representation is deprecated and marvell,crypto-srams should
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index a4c8637..fcab963 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1034,7 +1034,7 @@ static int mv_cesa_get_sram(struct platform_device *pdev,
sram_size);
cp-sram_size = sram_size;
- cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
marvell,crypto-srams, 0);
if (cp-sram_pool) {
cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
@@ -1197,6 +1197,8 @@ static int mv_remove(struct platform_device *pdev)
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,orion-crypto, },
+ { .compatible = marvell,kirkwood-crypto, },
+ { .compatible = marvell,dove-crypto, },
{}
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 02/14] crypto: mv_cesa: use gen_pool to reserve the SRAM memory region
The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.
This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine
The last point is particularly annoying in some cases: for example on
armada 370, a small region of the crypto SRAM is used to implement the
cpuidle, which means you would not be able to enable both cpuidle and the
CESA driver.
To address that problem, we explicitly define the SRAM device in the DT
and then reference the sram node from the crypto engine node.
Also note that the old way of retrieving the SRAM memory region is still
supported, or in other words, backward compatibility is preserved.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/mv_cesa.txt | 24 ++---
drivers/crypto/Kconfig | 1 +
drivers/crypto/mv_cesa.c | 58 --
3 files changed, 60 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index eaa2873..13b8fc5 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -2,21 +2,29 @@ Marvell Cryptographic Engines And Security Accelerator
Required properties:
- compatible : should be marvell,orion-crypto
-- reg : base physical address of the engine and length of memory mapped
-region, followed by base physical address of sram and its memory
-length
-- reg-names : regs , sram;
-- interrupts : interrupt number
+- reg: base physical address of the engine and length of memory mapped
+ region. Can also contain an entry for the SRAM attached to the CESA,
+ but this representation is deprecated and marvell,crypto-srams should
+ be used instead
+- reg-names: regs. Can contain an sram entry, but this representation
+is deprecated and marvell,crypto-srams should be used instead
+- interrupts: interrupt number
- clocks: reference to the crypto engines clocks. This property is only
required for Dove platforms
+- marvell,crypto-srams: phandle to crypto SRAM definitions
+
+Optional properties:
+- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
+ specified the whole SRAM is used (2KB)
Examples:
crypto@3 {
compatible = marvell,orion-crypto;
- reg = 0x3 0x1,
- 0x400 0x800;
- reg-names = regs , sram;
+ reg = 0x3 0x1;
+ reg-names = regs;
interrupts = 22;
+ marvell,crypto-srams = crypto_sram;
+ marvell,crypto-sram-size = 0x600;
status = okay;
};
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 033c0c8..a6bbea8 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -166,6 +166,7 @@ config CRYPTO_DEV_MV_CESA
select CRYPTO_AES
select CRYPTO_BLKCIPHER2
select CRYPTO_HASH
+ select SRAM
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Marvell Orion
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 27b2373..a4c8637 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -9,6 +9,7 @@
#include crypto/aes.h
#include crypto/algapi.h
#include linux/crypto.h
+#include linux/genalloc.h
#include linux/interrupt.h
#include linux/io.h
#include linux/kthread.h
@@ -29,6 +30,8 @@
#define MAX_HW_HASH_SIZE 0x
#define MV_CESA_EXPIRE 500 /* msec */
+#define MV_CESA_DEFAULT_SRAM_SIZE 2048
+
/*
* STM:
* /---\
@@ -83,6 +86,8 @@ struct req_progress {
struct crypto_priv {
void __iomem *reg;
void __iomem *sram;
+ struct gen_pool *sram_pool;
+ dma_addr_t sram_dma;
int irq;
struct clk *clk;
struct task_struct *queue_th;
@@ -1019,6 +1024,39 @@ static struct ahash_alg mv_hmac_sha1_alg = {
}
};
+static int mv_cesa_get_sram(struct platform_device *pdev,
+ struct crypto_priv *cp)
+{
+ struct resource *res;
+ u32 sram_size = MV_CESA_DEFAULT_SRAM_SIZE;
+
+ of_property_read_u32(pdev-dev.of_node, marvell,crypto-sram-size,
+sram_size);
+
+ cp-sram_size = sram_size;
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ marvell,crypto-srams, 0);
+ if (cp-sram_pool) {
+ cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
+ cp-sram_dma);
+ if (cp-sram
[PATCH v7 04/14] crypto: add a new driver for Marvell's CESA
The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.
This commit introduce the base infrastructure allowing us to add support
for DMA optimization.
It also includes support for one hash (SHA1) and one cipher (AES)
algorithm, and enable those features on the Armada 370 SoC.
Other algorithms and platforms will be added later on.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 15 +
drivers/crypto/Makefile | 1 +
drivers/crypto/marvell/Makefile | 2 +
drivers/crypto/marvell/cesa.c | 417 +++
drivers/crypto/marvell/cesa.h | 554 +++
drivers/crypto/marvell/cipher.c | 331 ++
drivers/crypto/marvell/hash.c | 720
7 files changed, 2040 insertions(+)
create mode 100644 drivers/crypto/marvell/Makefile
create mode 100644 drivers/crypto/marvell/cesa.c
create mode 100644 drivers/crypto/marvell/cesa.h
create mode 100644 drivers/crypto/marvell/cipher.c
create mode 100644 drivers/crypto/marvell/hash.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index a6bbea8..cbc3d3d 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -174,6 +174,21 @@ config CRYPTO_DEV_MV_CESA
Currently the driver supports AES in ECB and CBC mode without DMA.
+config CRYPTO_DEV_MARVELL_CESA
+ tristate New Marvell's Cryptographic Engine driver
+ depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) HAS_DMA
HAS_IOMEM
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_HASH
+ select SRAM
+ help
+ This driver allows you to utilize the Cryptographic Engines and
+ Security Accelerator (CESA) which can be found on the Armada 370.
+
+ This driver is aimed at replacing the mv_cesa driver. This will only
+ happen once it has received proper testing.
+
config CRYPTO_DEV_NIAGARA2
tristate Niagara2 Stream Processing Unit driver
select CRYPTO_DES
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index fb84be7..e35c07a 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell/
obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
obj-$(CONFIG_CRYPTO_DEV_NIAGARA2) += n2_crypto.o
n2_crypto-y := n2_core.o n2_asm.o
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
new file mode 100644
index 000..68d0982
--- /dev/null
+++ b/drivers/crypto/marvell/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
+marvell-cesa-objs := cesa.o cipher.o hash.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
new file mode 100644
index 000..76a6943
--- /dev/null
+++ b/drivers/crypto/marvell/cesa.c
@@ -0,0 +1,417 @@
+/*
+ * Support for Marvell's Cryptographic Engine and Security Accelerator (CESA)
+ * that can be found on the following platform: Orion, Kirkwood, Armada. This
+ * driver supports the TDMA engine on platforms on which it is available.
+ *
+ * Author: Boris Brezillon boris.brezil...@free-electrons.com
+ * Author: Arnaud Ebalard a...@natisbad.org
+ *
+ * This work is based on an initial version written by
+ * Sebastian Andrzej Siewior sebastian at breakpoint dot cc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/genalloc.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kthread.h
+#include linux/mbus.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/of_irq.h
+
+#include cesa.h
+
+struct mv_cesa_dev *cesa_dev;
+
+static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine)
+{
+ struct crypto_async_request *req, *backlog;
+ struct mv_cesa_ctx *ctx;
+
+ spin_lock_bh(cesa_dev-lock);
+ backlog = crypto_get_backlog(cesa_dev-queue);
+ req = crypto_dequeue_request(cesa_dev-queue);
+ engine-req = req;
+ spin_unlock_bh(cesa_dev-lock);
+
+ if (!req)
+ return;
+
+ if (backlog)
+ backlog-complete(backlog, -EINPROGRESS);
+
+ ctx
[PATCH v7 00/14] crypto: add a new driver for Marvell's CESA
Hello, This patch series adds a new driver supporting Marvell's CESA IP. This driver addresses some limitations of the existing one. From a performance and CPU load point of view the most important limitation in the existing driver is the lack of DMA support, thus preventing us from chaining crypto operations. I know we usually try to adapt existing drivers instead of replacing them by new ones, but after trying to refactor the mv_cesa driver I realized it would take longer than writing an new one from scratch. Here are the main features brought by this new driver: - support for armada SoCs (up to 38x) while keeping support for older ones (Orion and Kirkwood). Note that old DT bindings (those used on Orion and Kirkwood platforms) are supported, or IOTW, old DTs are compatible with this new driver. - DMA mode to offload the CPU in case of intensive crypto usage - new algorithms: SHA256, DES and 3DES I'd like to thank Arnaud, who has carefully reviewed several iterations of this driver, helped me improved my implementation, provided support for several crypto algorithms, provided support for armada-370 and tested the driver on different platforms, hence the SoB and dual MODULE_AUTHOR in the driver code. In this version I dropped the DT changes, but you'll find them in my cesa-v7 branch [1]. In this branch you'll find everything you need to test on all Marvell platforms (including the old ones). I'll post a series updating all the DTs once this driver has been merged. Best Regards, Boris [1]https://github.com/bbrezillon/linux-marvell/tree/cesa-v7 Changes since v6: - do not store dma_map_sg() return value - use sg_dma_len() and sg_dma_address() - test for req-src != req-dst to choose the dma mapping method Changes since v5: - fix the dma_map_sg return code check (again) - fix select entries in the Kconfig option Changes since v4: - fix the dma_map_sg return code check - add import/export functions to all HMAC algos - update the passed IV when handling cipher requests - properly handle requests in the crypto queue backlog - use sg_nents_for_len Changes since v3: - add import functions for hash algorithms - patch mv_cesa driver to support the new DT bindings - few fixes in the documentation - replace mv_mbus_dram_info() call by mv_mbus_dram_info_nooverlap() - remove DT updates from the series Changes since v2: - fixes in the cipher code (-dst_nents was assigned the -src_nents value and CBC state was overwritten by the IV after each chunk operation) - spit the code as suggested by Sebastian Changes since v1: - (suggested by Jason) kept the existing CESA driver and added a mechanism to prevent the new driver from probing devices handled my the existing one (Orion and Kirkwood platforms) - (reported by Paul) addressed a few Kconfig and module definition issues - (suggested by Andrew) added DT changes to the series Arnaud Ebalard (4): crypto: marvell/CESA: add Triple-DES support crypto: marvell/CESA: add MD5 support crypto: marvell/CESA: add SHA256 support crypto: marvell/CESA: add support for Kirkwood and Dove SoCs Boris Brezillon (10): crypto: mv_cesa: document the clocks property crypto: mv_cesa: use gen_pool to reserve the SRAM memory region crypto: mv_cesa: explicitly define kirkwood and dove compatible strings crypto: add a new driver for Marvell's CESA crypto: marvell/CESA: add TDMA support crypto: marvell/CESA: add DES support crypto: marvell/CESA: add support for all armada SoCs crypto: marvell/CESA: add allhwsupport module parameter crypto: marvell/CESA: add support for Orion SoCs crypto: marvell/CESA: add DT bindings documentation .../devicetree/bindings/crypto/marvell-cesa.txt| 45 + .../devicetree/bindings/crypto/mv_cesa.txt | 31 +- drivers/crypto/Kconfig | 17 + drivers/crypto/Makefile|1 + drivers/crypto/marvell/Makefile|2 + drivers/crypto/marvell/cesa.c | 548 drivers/crypto/marvell/cesa.h | 791 +++ drivers/crypto/marvell/cipher.c| 797 +++ drivers/crypto/marvell/hash.c | 1441 drivers/crypto/marvell/tdma.c | 224 +++ drivers/crypto/mv_cesa.c | 60 +- 11 files changed, 3933 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt create mode 100644 drivers/crypto/marvell/Makefile create mode 100644 drivers/crypto/marvell/cesa.c create mode 100644 drivers/crypto/marvell/cesa.h create mode 100644 drivers/crypto/marvell/cipher.c create mode 100644 drivers/crypto/marvell/hash.c create mode 100644 drivers/crypto/marvell/tdma.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http
Re: [PATCH v2 0/2] mfd: flexcom: add a driver for Flexcom
On Thu, 18 Jun 2015 15:05:08 +0200 Cyrille Pitchen cyrille.pitc...@atmel.com wrote: ChangeLog v2: - enhance the documentation of DT bindings and change the way the ranges property is used. - replace __raw_readl() and __raw_writel() by readl() and writel(). - change the module license to GPL for v2 or later - print the selected flexcom mode after the hardware version v1: This series of patches a support to the Atmel Flexcom, a wrapper which integrates an USART, a SPI controller and a TWI controller. Only one peripheral can be used at a time. The active function is selected though the Flexcom Mode Register. For the whole series, Acked-by: Boris Brezillon boris.brezil...@free-electrons.com Cyrille Pitchen (2): mfd: devicetree: add bindings for Atmel Flexcom mfd: flexcom: add a driver for Atmel Flexible Serial Communication Unit .../devicetree/bindings/mfd/atmel-flexcom.txt | 58 + drivers/mfd/Kconfig| 11 +++ drivers/mfd/Makefile | 1 + drivers/mfd/atmel-flexcom.c| 97 ++ 4 files changed, 167 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt create mode 100644 drivers/mfd/atmel-flexcom.c -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 05/14] crypto: marvell/CESA: add TDMA support
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not retrieved through DMA yet),
thus reducing the involvement of the CPU and providing better performances
in most cases (for small requests, the cost of DMA preparation might
exceed the performance gain).
Note that some CESA IPs do not embed this dedicated DMA, hence the
activation of this feature on a per platform basis.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 1 +
drivers/crypto/marvell/Makefile | 2 +-
drivers/crypto/marvell/cesa.c | 68 +++
drivers/crypto/marvell/cesa.h | 229 ++
drivers/crypto/marvell/cipher.c | 179 -
drivers/crypto/marvell/hash.c | 414 +++-
drivers/crypto/marvell/tdma.c | 224 ++
7 files changed, 1101 insertions(+), 16 deletions(-)
create mode 100644 drivers/crypto/marvell/tdma.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index cbc3d3d..cdca762 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -185,6 +185,7 @@ config CRYPTO_DEV_MARVELL_CESA
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Armada 370.
+ This driver supports CPU offload through DMA transfers.
This driver is aimed at replacing the mv_cesa driver. This will only
happen once it has received proper testing.
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
index 68d0982..0c12b13 100644
--- a/drivers/crypto/marvell/Makefile
+++ b/drivers/crypto/marvell/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
-marvell-cesa-objs := cesa.o cipher.o hash.o
+marvell-cesa-objs := cesa.o cipher.o hash.o tdma.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 76a6943..986f024 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -184,6 +184,7 @@ static const struct mv_cesa_caps armada_370_caps = {
.ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
.ahash_algs = armada_370_ahash_algs,
.nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
};
static const struct of_device_id mv_cesa_of_match_table[] = {
@@ -192,6 +193,66 @@ static const struct of_device_id mv_cesa_of_match_table[]
= {
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
+static void
+mv_cesa_conf_mbus_windows(struct mv_cesa_engine *engine,
+ const struct mbus_dram_target_info *dram)
+{
+ void __iomem *iobase = engine-regs;
+ int i;
+
+ for (i = 0; i 4; i++) {
+ writel(0, iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(0, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+
+ for (i = 0; i dram-num_cs; i++) {
+ const struct mbus_dram_window *cs = dram-cs + i;
+
+ writel(((cs-size - 1) 0x) |
+ (cs-mbus_attr 8) |
+ (dram-mbus_dram_target_id 4) | 1,
+ iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(cs-base, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+}
+
+static int mv_cesa_dev_dma_init(struct mv_cesa_dev *cesa)
+{
+ struct device *dev = cesa-dev;
+ struct mv_cesa_dev_dma *dma;
+
+ if (!cesa-caps-has_tdma)
+ return 0;
+
+ dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
+ if (!dma)
+ return -ENOMEM;
+
+ dma-tdma_desc_pool = dmam_pool_create(tdma_desc, dev,
+ sizeof(struct mv_cesa_tdma_desc),
+ 16, 0);
+ if (!dma-tdma_desc_pool)
+ return -ENOMEM;
+
+ dma-op_pool = dmam_pool_create(cesa_op, dev,
+ sizeof(struct mv_cesa_op_ctx), 16, 0);
+ if (!dma-op_pool)
+ return -ENOMEM;
+
+ dma-cache_pool = dmam_pool_create(cesa_cache, dev,
+ CESA_MAX_HASH_BLOCK_SIZE, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ dma-padding_pool = dmam_pool_create(cesa_padding, dev, 72, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ cesa-dma = dma;
+
+ return 0;
+}
+
static int mv_cesa_get_sram(struct platform_device *pdev, int idx)
{
struct mv_cesa_dev *cesa = platform_get_drvdata(pdev);
@@ -299,6 +360,10 @@ static int mv_cesa_probe(struct platform_device *pdev)
if (IS_ERR(cesa-regs))
return -ENOMEM
[PATCH v7 13/14] crypto: marvell/CESA: add support for Kirkwood and Dove SoCs
From: Arnaud Ebalard a...@natisbad.org
Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport
module parameter to avoid probing the CESA IP when the old CESA driver is
enabled (unless it is explicitly requested to do so).
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 8e5ea72..a432633 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -215,6 +215,15 @@ static const struct mv_cesa_caps orion_caps = {
.has_tdma = false,
};
+static const struct mv_cesa_caps kirkwood_caps = {
+ .nengines = 1,
+ .cipher_algs = orion_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(orion_cipher_algs),
+ .ahash_algs = orion_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(orion_ahash_algs),
+ .has_tdma = true,
+};
+
static const struct mv_cesa_caps armada_370_caps = {
.nengines = 1,
.cipher_algs = armada_370_cipher_algs,
@@ -235,6 +244,8 @@ static const struct mv_cesa_caps armada_xp_caps = {
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,orion-crypto, .data = orion_caps },
+ { .compatible = marvell,kirkwood-crypto, .data = kirkwood_caps },
+ { .compatible = marvell,dove-crypto, .data = kirkwood_caps },
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
{ .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
{ .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
@@ -383,7 +394,7 @@ static int mv_cesa_probe(struct platform_device *pdev)
caps = match-data;
}
- if (caps == orion_caps !allhwsupport)
+ if ((caps == orion_caps || caps == kirkwood_caps) !allhwsupport)
return -ENOTSUPP;
cesa = devm_kzalloc(dev, sizeof(*cesa), GFP_KERNEL);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 12/14] crypto: marvell/CESA: add support for Orion SoCs
Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.
Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is explicitly requested to do
so).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 42 +++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index a05b5cb..8e5ea72 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -172,6 +172,22 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
crypto_unregister_alg(cesa-caps-cipher_algs[i]);
}
+static struct crypto_alg *orion_cipher_algs[] = {
+ mv_cesa_ecb_des_alg,
+ mv_cesa_cbc_des_alg,
+ mv_cesa_ecb_des3_ede_alg,
+ mv_cesa_cbc_des3_ede_alg,
+ mv_cesa_ecb_aes_alg,
+ mv_cesa_cbc_aes_alg,
+};
+
+static struct ahash_alg *orion_ahash_algs[] = {
+ mv_md5_alg,
+ mv_sha1_alg,
+ mv_ahmac_md5_alg,
+ mv_ahmac_sha1_alg,
+};
+
static struct crypto_alg *armada_370_cipher_algs[] = {
mv_cesa_ecb_des_alg,
mv_cesa_cbc_des_alg,
@@ -190,6 +206,15 @@ static struct ahash_alg *armada_370_ahash_algs[] = {
mv_ahmac_sha256_alg,
};
+static const struct mv_cesa_caps orion_caps = {
+ .nengines = 1,
+ .cipher_algs = orion_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(orion_cipher_algs),
+ .ahash_algs = orion_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(orion_ahash_algs),
+ .has_tdma = false,
+};
+
static const struct mv_cesa_caps armada_370_caps = {
.nengines = 1,
.cipher_algs = armada_370_cipher_algs,
@@ -209,6 +234,7 @@ static const struct mv_cesa_caps armada_xp_caps = {
};
static const struct of_device_id mv_cesa_of_match_table[] = {
+ { .compatible = marvell,orion-crypto, .data = orion_caps },
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
{ .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
{ .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
@@ -334,7 +360,7 @@ static void mv_cesa_put_sram(struct platform_device *pdev,
int idx)
static int mv_cesa_probe(struct platform_device *pdev)
{
- const struct mv_cesa_caps *caps = NULL;
+ const struct mv_cesa_caps *caps = orion_caps;
const struct mbus_dram_target_info *dram;
const struct of_device_id *match;
struct device *dev = pdev-dev;
@@ -349,14 +375,16 @@ static int mv_cesa_probe(struct platform_device *pdev)
return -EEXIST;
}
- if (!dev-of_node)
- return -ENOTSUPP;
+ if (dev-of_node) {
+ match = of_match_node(mv_cesa_of_match_table, dev-of_node);
+ if (!match || !match-data)
+ return -ENOTSUPP;
- match = of_match_node(mv_cesa_of_match_table, dev-of_node);
- if (!match || !match-data)
- return -ENOTSUPP;
+ caps = match-data;
+ }
- caps = match-data;
+ if (caps == orion_caps !allhwsupport)
+ return -ENOTSUPP;
cesa = devm_kzalloc(dev, sizeof(*cesa), GFP_KERNEL);
if (!cesa)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 08/14] crypto: marvell/CESA: add MD5 support
From: Arnaud Ebalard a...@natisbad.org
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 172 +-
3 files changed, 174 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index c0b1b49..047c1c0 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -178,7 +178,9 @@ static struct crypto_alg *armada_370_cipher_algs[] = {
};
static struct ahash_alg *armada_370_ahash_algs[] = {
+ mv_md5_alg,
mv_sha1_alg,
+ mv_ahmac_md5_alg,
mv_ahmac_sha1_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 1229c3d..283e322 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -774,7 +774,9 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
/* Algorithm definitions */
+extern struct ahash_alg mv_md5_alg;
extern struct ahash_alg mv_sha1_alg;
+extern struct ahash_alg mv_ahmac_md5_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 528da26..36bb756 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -12,6 +12,7 @@
* by the Free Software Foundation.
*/
+#include crypto/md5.h
#include crypto/sha.h
#include cesa.h
@@ -346,8 +347,16 @@ static int mv_cesa_ahash_process(struct
crypto_async_request *req, u32 status)
ahashreq-nbytes - creq-cache_ptr);
if (creq-last_req) {
- for (i = 0; i digsize / 4; i++)
- creq-state[i] = cpu_to_be32(creq-state[i]);
+ for (i = 0; i digsize / 4; i++) {
+ /*
+* Hardware provides MD5 digest in a different
+* endianness than SHA-1 and SHA-256 ones.
+*/
+ if (digsize == MD5_DIGEST_SIZE)
+ creq-state[i] = cpu_to_le32(creq-state[i]);
+ else
+ creq-state[i] = cpu_to_be32(creq-state[i]);
+ }
memcpy(ahashreq-result, creq-state, digsize);
}
@@ -788,6 +797,95 @@ static int mv_cesa_ahash_finup(struct ahash_request *req)
return ret;
}
+static int mv_cesa_md5_init(struct ahash_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl, CESA_SA_DESC_CFG_MACM_MD5);
+
+ mv_cesa_ahash_init(req, tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_md5_export(struct ahash_request *req, void *out)
+{
+ struct md5_state *out_state = out;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+
+ out_state-byte_count = creq-len;
+ memcpy(out_state-hash, creq-state, digsize);
+ memset(out_state-block, 0, sizeof(out_state-block));
+ if (creq-cache)
+ memcpy(out_state-block, creq-cache, creq-cache_ptr);
+
+ return 0;
+}
+
+static int mv_cesa_md5_import(struct ahash_request *req, const void *in)
+{
+ const struct md5_state *in_state = in;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+ unsigned int cache_ptr;
+ int ret;
+
+ creq-len = in_state-byte_count;
+ memcpy(creq-state, in_state-hash, digsize);
+ creq-cache_ptr = 0;
+
+ cache_ptr = creq-len % sizeof(in_state-block);
+ if (!cache_ptr)
+ return 0;
+
+ ret = mv_cesa_ahash_alloc_cache(req);
+ if (ret)
+ return ret;
+
+ memcpy(creq-cache, in_state-block, cache_ptr);
+ creq-cache_ptr = cache_ptr;
+
+ return 0;
+}
+
+static int mv_cesa_md5_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_md5_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+struct ahash_alg mv_md5_alg = {
+ .init = mv_cesa_md5_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_md5_digest,
+ .export = mv_cesa_md5_export,
+ .import = mv_cesa_md5_import,
+ .halg = {
+ .digestsize = MD5_DIGEST_SIZE,
+ .base = {
+ .cra_name = md5,
+ .cra_driver_name = mv-md5,
+ .cra_priority = 300
[PATCH v7 06/14] crypto: marvell/CESA: add DES support
Add support for DES operations.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 150
3 files changed, 154 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 986f024..212840e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -169,6 +169,8 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
}
static struct crypto_alg *armada_370_cipher_algs[] = {
+ mv_cesa_ecb_des_alg,
+ mv_cesa_cbc_des_alg,
mv_cesa_ecb_aes_alg,
mv_cesa_cbc_aes_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index f8faf26..4b07209 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -777,6 +777,8 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
extern struct ahash_alg mv_sha1_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
+extern struct crypto_alg mv_cesa_ecb_des_alg;
+extern struct crypto_alg mv_cesa_cbc_des_alg;
extern struct crypto_alg mv_cesa_ecb_aes_alg;
extern struct crypto_alg mv_cesa_cbc_aes_alg;
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index e21783b..e420ea6 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -13,9 +13,15 @@
*/
#include crypto/aes.h
+#include crypto/des.h
#include cesa.h
+struct mv_cesa_des_ctx {
+ struct mv_cesa_ctx base;
+ u8 key[DES_KEY_SIZE];
+};
+
struct mv_cesa_aes_ctx {
struct mv_cesa_ctx base;
struct crypto_aes_ctx aes;
@@ -238,6 +244,30 @@ static int mv_cesa_aes_setkey(struct crypto_ablkcipher
*cipher, const u8 *key,
return 0;
}
+static int mv_cesa_des_setkey(struct crypto_ablkcipher *cipher, const u8 *key,
+ unsigned int len)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 tmp[DES_EXPKEY_WORDS];
+ int ret;
+
+ if (len != DES_KEY_SIZE) {
+ crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+
+ ret = des_ekey(tmp, key);
+ if (!ret (tfm-crt_flags CRYPTO_TFM_REQ_WEAK_KEY)) {
+ tfm-crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
+ return -EINVAL;
+ }
+
+ memcpy(ctx-key, key, DES_KEY_SIZE);
+
+ return 0;
+}
+
static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
const struct mv_cesa_op_ctx *op_templ)
{
@@ -364,6 +394,126 @@ static int mv_cesa_ablkcipher_req_init(struct
ablkcipher_request *req,
return ret;
}
+static int mv_cesa_des_op(struct ablkcipher_request *req,
+ struct mv_cesa_op_ctx *tmpl)
+{
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(req-base.tfm);
+ int ret;
+
+ mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTM_DES,
+ CESA_SA_DESC_CFG_CRYPTM_MSK);
+
+ memcpy(tmpl-ctx.blkcipher.key, ctx-key, DES_KEY_SIZE);
+
+ ret = mv_cesa_ablkcipher_req_init(req, tmpl);
+ if (ret)
+ return ret;
+
+ ret = mv_cesa_queue_req(req-base);
+ if (ret ret != -EINPROGRESS)
+ mv_cesa_ablkcipher_cleanup(req);
+
+ return ret;
+}
+
+static int mv_cesa_ecb_des_encrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_DIR_ENC);
+
+ return mv_cesa_des_op(req, tmpl);
+}
+
+static int mv_cesa_ecb_des_decrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_DIR_DEC);
+
+ return mv_cesa_des_op(req, tmpl);
+}
+
+struct crypto_alg mv_cesa_ecb_des_alg = {
+ .cra_name = ecb(des),
+ .cra_driver_name = mv-ecb-des,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
+ .cra_blocksize = DES_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_des_ctx),
+ .cra_alignmask = 0,
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = mv_cesa_ablkcipher_cra_init,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize = DES_KEY_SIZE,
+ .max_keysize = DES_KEY_SIZE,
+ .setkey = mv_cesa_des_setkey,
+ .encrypt = mv_cesa_ecb_des_encrypt,
+ .decrypt
[PATCH v7 10/14] crypto: marvell/CESA: add support for all armada SoCs
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 9c43cd7e..af590bf 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -195,8 +195,20 @@ static const struct mv_cesa_caps armada_370_caps = {
.has_tdma = true,
};
+static const struct mv_cesa_caps armada_xp_caps = {
+ .nengines = 2,
+ .cipher_algs = armada_370_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
+ .ahash_algs = armada_370_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
+};
+
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
+ { .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
+ { .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
+ { .compatible = marvell,armada-38x-crypto, .data = armada_xp_caps },
{}
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 09/14] crypto: marvell/CESA: add SHA256 support
From: Arnaud Ebalard a...@natisbad.org
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 159 ++
3 files changed, 163 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 047c1c0..9c43cd7e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -180,8 +180,10 @@ static struct crypto_alg *armada_370_cipher_algs[] = {
static struct ahash_alg *armada_370_ahash_algs[] = {
mv_md5_alg,
mv_sha1_alg,
+ mv_sha256_alg,
mv_ahmac_md5_alg,
mv_ahmac_sha1_alg,
+ mv_ahmac_sha256_alg,
};
static const struct mv_cesa_caps armada_370_caps = {
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 283e322..b60698b 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -776,8 +776,10 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
extern struct ahash_alg mv_md5_alg;
extern struct ahash_alg mv_sha1_alg;
+extern struct ahash_alg mv_sha256_alg;
extern struct ahash_alg mv_ahmac_md5_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
+extern struct ahash_alg mv_ahmac_sha256_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
extern struct crypto_alg mv_cesa_cbc_des_alg;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 36bb756..ae9272e 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -975,6 +975,95 @@ struct ahash_alg mv_sha1_alg = {
}
};
+static int mv_cesa_sha256_init(struct ahash_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl, CESA_SA_DESC_CFG_MACM_SHA256);
+
+ mv_cesa_ahash_init(req, tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_sha256_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_sha256_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+static int mv_cesa_sha256_export(struct ahash_request *req, void *out)
+{
+ struct sha256_state *out_state = out;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int ds = crypto_ahash_digestsize(ahash);
+
+ out_state-count = creq-len;
+ memcpy(out_state-state, creq-state, ds);
+ memset(out_state-buf, 0, sizeof(out_state-buf));
+ if (creq-cache)
+ memcpy(out_state-buf, creq-cache, creq-cache_ptr);
+
+ return 0;
+}
+
+static int mv_cesa_sha256_import(struct ahash_request *req, const void *in)
+{
+ const struct sha256_state *in_state = in;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+ unsigned int cache_ptr;
+ int ret;
+
+ creq-len = in_state-count;
+ memcpy(creq-state, in_state-state, digsize);
+ creq-cache_ptr = 0;
+
+ cache_ptr = creq-len % SHA256_BLOCK_SIZE;
+ if (!cache_ptr)
+ return 0;
+
+ ret = mv_cesa_ahash_alloc_cache(req);
+ if (ret)
+ return ret;
+
+ memcpy(creq-cache, in_state-buf, cache_ptr);
+ creq-cache_ptr = cache_ptr;
+
+ return 0;
+}
+
+struct ahash_alg mv_sha256_alg = {
+ .init = mv_cesa_sha256_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_sha256_digest,
+ .export = mv_cesa_sha256_export,
+ .import = mv_cesa_sha256_import,
+ .halg = {
+ .digestsize = SHA256_DIGEST_SIZE,
+ .base = {
+ .cra_name = sha256,
+ .cra_driver_name = mv-sha256,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+CRYPTO_ALG_KERN_DRIVER_ONLY,
+ .cra_blocksize = SHA256_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_hash_ctx),
+ .cra_init = mv_cesa_ahash_cra_init,
+ .cra_module = THIS_MODULE,
+}
+ }
+};
+
struct mv_cesa_ahash_result {
struct completion completion;
int error;
@@ -1280,3 +1369,73 @@ struct ahash_alg mv_ahmac_sha1_alg = {
}
}
};
+
+static int mv_cesa_ahmac_sha256_setkey(struct crypto_ahash *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct mv_cesa_hmac_ctx *ctx = crypto_tfm_ctx(crypto_ahash_tfm(tfm));
+ struct sha256_state istate, ostate;
+ int ret, i
[PATCH v7 01/14] crypto: mv_cesa: document the clocks property
On Dove platforms, the crypto engine requires a clock. Document this clocks property in the mv_cesa bindings doc. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- Documentation/devicetree/bindings/crypto/mv_cesa.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt b/Documentation/devicetree/bindings/crypto/mv_cesa.txt index 47229b1..eaa2873 100644 --- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt @@ -7,6 +7,8 @@ Required properties: length - reg-names : regs , sram; - interrupts : interrupt number +- clocks: reference to the crypto engines clocks. This property is only + required for Dove platforms Examples: -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 14/14] crypto: marvell/CESA: add DT bindings documentation
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt
diff --git a/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
new file mode 100644
index 000..c6c6a4a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
@@ -0,0 +1,45 @@
+Marvell Cryptographic Engines And Security Accelerator
+
+Required properties:
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
+ marvell,armada-370-crypto
+ marvell,armada-xp-crypto
+ marvell,armada-375-crypto
+ marvell,armada-38x-crypto
+- reg: base physical address of the engine and length of memory mapped
+ region. Can also contain an entry for the SRAM attached to the CESA,
+ but this representation is deprecated and marvell,crypto-srams should
+ be used instead
+- reg-names: regs. Can contain an sram entry, but this representation
+is deprecated and marvell,crypto-srams should be used instead
+- interrupts: interrupt number
+- clocks: reference to the crypto engines clocks. This property is not
+ required for orion and kirkwood platforms
+- clock-names: cesaX and cesazX, X should be replaced by the crypto engine
+ id.
+ This property is not required for the orion and kirkwoord
+ platforms.
+ cesazX clocks are not required on armada-370 platforms
+- marvell,crypto-srams: phandle to crypto SRAM definitions
+
+Optional properties:
+- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
+ specified the whole SRAM is used (2KB)
+
+
+Examples:
+
+ crypto@9 {
+ compatible = marvell,armada-xp-crypto;
+ reg = 0x9 0x1;
+ reg-names = regs;
+ interrupts = 48, 49;
+ clocks = gateclk 23, gateclk 23;
+ clock-names = cesa0, cesa1;
+ marvell,crypto-srams = crypto_sram0, crypto_sram1;
+ marvell,crypto-sram-size = 0x600;
+ status = okay;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 11/14] crypto: marvell/CESA: add allhwsupport module parameter
The old and new marvell CESA drivers both support Orion and Kirkwood SoCs. Add a module parameter to choose whether these SoCs should be attached to the new or the old driver. The default policy is to keep attaching those IPs to the old driver if it is enabled, until we decide the new CESA driver is stable/secure enough. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- drivers/crypto/marvell/cesa.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c index af590bf..a05b5cb 100644 --- a/drivers/crypto/marvell/cesa.c +++ b/drivers/crypto/marvell/cesa.c @@ -31,6 +31,10 @@ #include cesa.h +static int allhwsupport = !IS_ENABLED(CONFIG_CRYPTO_DEV_MV_CESA); +module_param_named(allhwsupport, allhwsupport, int, 0444); +MODULE_PARM_DESC(allhwsupport, Enable support for all hardware (even it if overlaps with the mv_cesa driver)); + struct mv_cesa_dev *cesa_dev; static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 07/14] crypto: marvell/CESA: add Triple-DES support
From: Arnaud Ebalard a...@natisbad.org
Add support for Triple-DES operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 147
3 files changed, 151 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 212840e..c0b1b49 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -171,6 +171,8 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
static struct crypto_alg *armada_370_cipher_algs[] = {
mv_cesa_ecb_des_alg,
mv_cesa_cbc_des_alg,
+ mv_cesa_ecb_des3_ede_alg,
+ mv_cesa_cbc_des3_ede_alg,
mv_cesa_ecb_aes_alg,
mv_cesa_cbc_aes_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 4b07209..1229c3d 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -779,6 +779,8 @@ extern struct ahash_alg mv_ahmac_sha1_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
extern struct crypto_alg mv_cesa_cbc_des_alg;
+extern struct crypto_alg mv_cesa_ecb_des3_ede_alg;
+extern struct crypto_alg mv_cesa_cbc_des3_ede_alg;
extern struct crypto_alg mv_cesa_ecb_aes_alg;
extern struct crypto_alg mv_cesa_cbc_aes_alg;
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index e420ea6..0745cf3 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -22,6 +22,11 @@ struct mv_cesa_des_ctx {
u8 key[DES_KEY_SIZE];
};
+struct mv_cesa_des3_ctx {
+ struct mv_cesa_ctx base;
+ u8 key[DES3_EDE_KEY_SIZE];
+};
+
struct mv_cesa_aes_ctx {
struct mv_cesa_ctx base;
struct crypto_aes_ctx aes;
@@ -268,6 +273,22 @@ static int mv_cesa_des_setkey(struct crypto_ablkcipher
*cipher, const u8 *key,
return 0;
}
+static int mv_cesa_des3_ede_setkey(struct crypto_ablkcipher *cipher,
+ const u8 *key, unsigned int len)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ if (len != DES3_EDE_KEY_SIZE) {
+ crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+
+ memcpy(ctx-key, key, DES3_EDE_KEY_SIZE);
+
+ return 0;
+}
+
static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
const struct mv_cesa_op_ctx *op_templ)
{
@@ -514,6 +535,132 @@ struct crypto_alg mv_cesa_cbc_des_alg = {
},
};
+static int mv_cesa_des3_op(struct ablkcipher_request *req,
+ struct mv_cesa_op_ctx *tmpl)
+{
+ struct mv_cesa_des3_ctx *ctx = crypto_tfm_ctx(req-base.tfm);
+ int ret;
+
+ mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTM_3DES,
+ CESA_SA_DESC_CFG_CRYPTM_MSK);
+
+ memcpy(tmpl-ctx.blkcipher.key, ctx-key, DES3_EDE_KEY_SIZE);
+
+ ret = mv_cesa_ablkcipher_req_init(req, tmpl);
+ if (ret)
+ return ret;
+
+ ret = mv_cesa_queue_req(req-base);
+ if (ret ret != -EINPROGRESS)
+ mv_cesa_ablkcipher_cleanup(req);
+
+ return ret;
+}
+
+static int mv_cesa_ecb_des3_ede_encrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_3DES_EDE |
+ CESA_SA_DESC_CFG_DIR_ENC);
+
+ return mv_cesa_des3_op(req, tmpl);
+}
+
+static int mv_cesa_ecb_des3_ede_decrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_3DES_EDE |
+ CESA_SA_DESC_CFG_DIR_DEC);
+
+ return mv_cesa_des3_op(req, tmpl);
+}
+
+struct crypto_alg mv_cesa_ecb_des3_ede_alg = {
+ .cra_name = ecb(des3_ede),
+ .cra_driver_name = mv-ecb-des3-ede,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
+ .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_des3_ctx),
+ .cra_alignmask = 0,
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = mv_cesa_ablkcipher_cra_init,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize = DES3_EDE_KEY_SIZE,
+ .max_keysize = DES3_EDE_KEY_SIZE,
+ .ivsize = DES3_EDE_BLOCK_SIZE,
+ .setkey = mv_cesa_des3_ede_setkey,
+ .encrypt
Re: [PATCH v6 06/14] crypto: marvell/CESA: add DES support
Hi Herbert, On Wed, 17 Jun 2015 09:45:34 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Add support for DES operations. The addition of DES support seems controversial. At first I thought it would be good to support all the algorithms supported by the CESA engine, but I think I'll drop it in the next iteration. Do you think Triple-DES should be dropped too ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
Hi Russel, On Thu, 18 Jun 2015 10:04:00 +0100 Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote: On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote: + ret = dma_map_sg(cesa_dev-dev, req-src, creq-src_nents, + DMA_TO_DEVICE); + if (!ret) + return -ENOMEM; + + creq-src_nents = ret; DMA-API-HOWTO says that you must retain the original nents and use it when you call dma_unmap_sg. So I'm afraid one more repost is needed :) It's worse than that... You're right on that point, but there's an additional point. If dma_map_sg() coalesces scatterlist entries, then ret will be smaller than src_nents, and ret indicates how many scatterlist entries to be walked during DMA - you should not use src_nents for that. I couldn't see where the driver used that information. In fact, the driver seems to be capable of walking more than src_nents/ret numbers of scatterlist entries: it just keeps going with sg_next() until it hits the end of the allocated scatterlist. Yes, I realized that, and I never used the value returned by dma_map_sg() to walk the scatterlist anyway: I was using the sg_next() and sg-length value (which I replaced by sg_dma_len() in v7 as suggested by Herbert). So the -src_nents assignment to dma_map_sg() return value was just a silly mistake caused by an uncareful read of the DMA-API-HOWTO. Am I missing something else ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
On Thu, 18 Jun 2015 10:48:03 +0100 Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Jun 18, 2015 at 11:33:24AM +0200, Boris Brezillon wrote: Hi Russel, On Thu, 18 Jun 2015 10:04:00 +0100 Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote: On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote: + ret = dma_map_sg(cesa_dev-dev, req-src, creq-src_nents, + DMA_TO_DEVICE); + if (!ret) + return -ENOMEM; + + creq-src_nents = ret; DMA-API-HOWTO says that you must retain the original nents and use it when you call dma_unmap_sg. So I'm afraid one more repost is needed :) It's worse than that... You're right on that point, but there's an additional point. If dma_map_sg() coalesces scatterlist entries, then ret will be smaller than src_nents, and ret indicates how many scatterlist entries to be walked during DMA - you should not use src_nents for that. I couldn't see where the driver used that information. In fact, the driver seems to be capable of walking more than src_nents/ret numbers of scatterlist entries: it just keeps going with sg_next() until it hits the end of the allocated scatterlist. Yes, I realized that, and I never used the value returned by dma_map_sg() to walk the scatterlist anyway: I was using the sg_next() and sg-length value (which I replaced by sg_dma_len() in v7 as suggested by Herbert). So the -src_nents assignment to dma_map_sg() return value was just a silly mistake caused by an uncareful read of the DMA-API-HOWTO. Am I missing something else ? Yes. 'ret' should be used to indicate the number of scatterlist entries to walk for DMA purposes after the scatterlist has been mapped. For PIO purposes, using src_nents is still acceptable. As Herbert points out, you're stopping after the sum of transferred bytes matches, so I suppose that's fine. One other point though: you should use sg_dma_address() rather than dereferencing sg-dma_address directly. Okay, I'll fix that before submitting a new version. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 04/14] crypto: add a new driver for Marvell's CESA
On Wed, 17 Jun 2015 13:58:24 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Tue, Jun 16, 2015 at 11:58:58AM +0200, Boris Brezillon wrote: +config CRYPTO_DEV_MARVELL_CESA + tristate New Marvell's Cryptographic Engine driver + depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) HAS_DMA HAS_IOMEM + select CRYPTO_ALGAPI + select CRYPTO_AES + select CRYPTO_DES + select CRYPTO_BLKCIPHER2 + select CRYPTO_HASH While you're fixing the DMA issue, could you also replace BLKCIPHER2 with BLKCIPHER and kill the select on ALGAPI? BLKCIPHER2 is internal to the crypto API and should not be used elsewhere while ALGAPI is only meant to be selected by crypto types such as BLKCIPHER. I know the existing driver does this too and I will fix that now. Fixed. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 04/14] crypto: add a new driver for Marvell's CESA
The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.
This commit introduce the base infrastructure allowing us to add support
for DMA optimization.
It also includes support for one hash (SHA1) and one cipher (AES)
algorithm, and enable those features on the Armada 370 SoC.
Other algorithms and platforms will be added later on.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 15 +
drivers/crypto/Makefile | 1 +
drivers/crypto/marvell/Makefile | 2 +
drivers/crypto/marvell/cesa.c | 417 +++
drivers/crypto/marvell/cesa.h | 554 +++
drivers/crypto/marvell/cipher.c | 331 ++
drivers/crypto/marvell/hash.c | 720
7 files changed, 2040 insertions(+)
create mode 100644 drivers/crypto/marvell/Makefile
create mode 100644 drivers/crypto/marvell/cesa.c
create mode 100644 drivers/crypto/marvell/cesa.h
create mode 100644 drivers/crypto/marvell/cipher.c
create mode 100644 drivers/crypto/marvell/hash.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index a6bbea8..cbc3d3d 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -174,6 +174,21 @@ config CRYPTO_DEV_MV_CESA
Currently the driver supports AES in ECB and CBC mode without DMA.
+config CRYPTO_DEV_MARVELL_CESA
+ tristate New Marvell's Cryptographic Engine driver
+ depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) HAS_DMA
HAS_IOMEM
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_HASH
+ select SRAM
+ help
+ This driver allows you to utilize the Cryptographic Engines and
+ Security Accelerator (CESA) which can be found on the Armada 370.
+
+ This driver is aimed at replacing the mv_cesa driver. This will only
+ happen once it has received proper testing.
+
config CRYPTO_DEV_NIAGARA2
tristate Niagara2 Stream Processing Unit driver
select CRYPTO_DES
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index fb84be7..e35c07a 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell/
obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
obj-$(CONFIG_CRYPTO_DEV_NIAGARA2) += n2_crypto.o
n2_crypto-y := n2_core.o n2_asm.o
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
new file mode 100644
index 000..68d0982
--- /dev/null
+++ b/drivers/crypto/marvell/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
+marvell-cesa-objs := cesa.o cipher.o hash.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
new file mode 100644
index 000..76a6943
--- /dev/null
+++ b/drivers/crypto/marvell/cesa.c
@@ -0,0 +1,417 @@
+/*
+ * Support for Marvell's Cryptographic Engine and Security Accelerator (CESA)
+ * that can be found on the following platform: Orion, Kirkwood, Armada. This
+ * driver supports the TDMA engine on platforms on which it is available.
+ *
+ * Author: Boris Brezillon boris.brezil...@free-electrons.com
+ * Author: Arnaud Ebalard a...@natisbad.org
+ *
+ * This work is based on an initial version written by
+ * Sebastian Andrzej Siewior sebastian at breakpoint dot cc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/genalloc.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kthread.h
+#include linux/mbus.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/of_irq.h
+
+#include cesa.h
+
+struct mv_cesa_dev *cesa_dev;
+
+static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine)
+{
+ struct crypto_async_request *req, *backlog;
+ struct mv_cesa_ctx *ctx;
+
+ spin_lock_bh(cesa_dev-lock);
+ backlog = crypto_get_backlog(cesa_dev-queue);
+ req = crypto_dequeue_request(cesa_dev-queue);
+ engine-req = req;
+ spin_unlock_bh(cesa_dev-lock);
+
+ if (!req)
+ return;
+
+ if (backlog)
+ backlog-complete(backlog, -EINPROGRESS);
+
+ ctx
[PATCH v6 06/14] crypto: marvell/CESA: add DES support
Add support for DES operations.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 150
3 files changed, 154 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 986f024..212840e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -169,6 +169,8 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
}
static struct crypto_alg *armada_370_cipher_algs[] = {
+ mv_cesa_ecb_des_alg,
+ mv_cesa_cbc_des_alg,
mv_cesa_ecb_aes_alg,
mv_cesa_cbc_aes_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 1a48323..2ee48fe 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -777,6 +777,8 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
extern struct ahash_alg mv_sha1_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
+extern struct crypto_alg mv_cesa_ecb_des_alg;
+extern struct crypto_alg mv_cesa_cbc_des_alg;
extern struct crypto_alg mv_cesa_ecb_aes_alg;
extern struct crypto_alg mv_cesa_cbc_aes_alg;
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index a1f4013..ee49f5f 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -13,9 +13,15 @@
*/
#include crypto/aes.h
+#include crypto/des.h
#include cesa.h
+struct mv_cesa_des_ctx {
+ struct mv_cesa_ctx base;
+ u8 key[DES_KEY_SIZE];
+};
+
struct mv_cesa_aes_ctx {
struct mv_cesa_ctx base;
struct crypto_aes_ctx aes;
@@ -231,6 +237,30 @@ static int mv_cesa_aes_setkey(struct crypto_ablkcipher
*cipher, const u8 *key,
return 0;
}
+static int mv_cesa_des_setkey(struct crypto_ablkcipher *cipher, const u8 *key,
+ unsigned int len)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 tmp[DES_EXPKEY_WORDS];
+ int ret;
+
+ if (len != DES_KEY_SIZE) {
+ crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+
+ ret = des_ekey(tmp, key);
+ if (!ret (tfm-crt_flags CRYPTO_TFM_REQ_WEAK_KEY)) {
+ tfm-crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
+ return -EINVAL;
+ }
+
+ memcpy(ctx-key, key, DES_KEY_SIZE);
+
+ return 0;
+}
+
static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
const struct mv_cesa_op_ctx *op_templ)
{
@@ -351,6 +381,126 @@ static int mv_cesa_ablkcipher_req_init(struct
ablkcipher_request *req,
return ret;
}
+static int mv_cesa_des_op(struct ablkcipher_request *req,
+ struct mv_cesa_op_ctx *tmpl)
+{
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(req-base.tfm);
+ int ret;
+
+ mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTM_DES,
+ CESA_SA_DESC_CFG_CRYPTM_MSK);
+
+ memcpy(tmpl-ctx.blkcipher.key, ctx-key, DES_KEY_SIZE);
+
+ ret = mv_cesa_ablkcipher_req_init(req, tmpl);
+ if (ret)
+ return ret;
+
+ ret = mv_cesa_queue_req(req-base);
+ if (ret ret != -EINPROGRESS)
+ mv_cesa_ablkcipher_cleanup(req);
+
+ return ret;
+}
+
+static int mv_cesa_ecb_des_encrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_DIR_ENC);
+
+ return mv_cesa_des_op(req, tmpl);
+}
+
+static int mv_cesa_ecb_des_decrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_DIR_DEC);
+
+ return mv_cesa_des_op(req, tmpl);
+}
+
+struct crypto_alg mv_cesa_ecb_des_alg = {
+ .cra_name = ecb(des),
+ .cra_driver_name = mv-ecb-des,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
+ .cra_blocksize = DES_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_des_ctx),
+ .cra_alignmask = 0,
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = mv_cesa_ablkcipher_cra_init,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize = DES_KEY_SIZE,
+ .max_keysize = DES_KEY_SIZE,
+ .setkey = mv_cesa_des_setkey,
+ .encrypt = mv_cesa_ecb_des_encrypt,
+ .decrypt
[PATCH v6 08/14] crypto: marvell/CESA: add MD5 support
From: Arnaud Ebalard a...@natisbad.org
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 172 +-
3 files changed, 174 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index c0b1b49..047c1c0 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -178,7 +178,9 @@ static struct crypto_alg *armada_370_cipher_algs[] = {
};
static struct ahash_alg *armada_370_ahash_algs[] = {
+ mv_md5_alg,
mv_sha1_alg,
+ mv_ahmac_md5_alg,
mv_ahmac_sha1_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 2e8b7fc..2a7e21a 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -774,7 +774,9 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
/* Algorithm definitions */
+extern struct ahash_alg mv_md5_alg;
extern struct ahash_alg mv_sha1_alg;
+extern struct ahash_alg mv_ahmac_md5_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index e7e0774..1c82d9b 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -12,6 +12,7 @@
* by the Free Software Foundation.
*/
+#include crypto/md5.h
#include crypto/sha.h
#include cesa.h
@@ -346,8 +347,16 @@ static int mv_cesa_ahash_process(struct
crypto_async_request *req, u32 status)
ahashreq-nbytes - creq-cache_ptr);
if (creq-last_req) {
- for (i = 0; i digsize / 4; i++)
- creq-state[i] = cpu_to_be32(creq-state[i]);
+ for (i = 0; i digsize / 4; i++) {
+ /*
+* Hardware provides MD5 digest in a different
+* endianness than SHA-1 and SHA-256 ones.
+*/
+ if (digsize == MD5_DIGEST_SIZE)
+ creq-state[i] = cpu_to_le32(creq-state[i]);
+ else
+ creq-state[i] = cpu_to_be32(creq-state[i]);
+ }
memcpy(ahashreq-result, creq-state, digsize);
}
@@ -790,6 +799,95 @@ static int mv_cesa_ahash_finup(struct ahash_request *req)
return ret;
}
+static int mv_cesa_md5_init(struct ahash_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl, CESA_SA_DESC_CFG_MACM_MD5);
+
+ mv_cesa_ahash_init(req, tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_md5_export(struct ahash_request *req, void *out)
+{
+ struct md5_state *out_state = out;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+
+ out_state-byte_count = creq-len;
+ memcpy(out_state-hash, creq-state, digsize);
+ memset(out_state-block, 0, sizeof(out_state-block));
+ if (creq-cache)
+ memcpy(out_state-block, creq-cache, creq-cache_ptr);
+
+ return 0;
+}
+
+static int mv_cesa_md5_import(struct ahash_request *req, const void *in)
+{
+ const struct md5_state *in_state = in;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+ unsigned int cache_ptr;
+ int ret;
+
+ creq-len = in_state-byte_count;
+ memcpy(creq-state, in_state-hash, digsize);
+ creq-cache_ptr = 0;
+
+ cache_ptr = creq-len % sizeof(in_state-block);
+ if (!cache_ptr)
+ return 0;
+
+ ret = mv_cesa_ahash_alloc_cache(req);
+ if (ret)
+ return ret;
+
+ memcpy(creq-cache, in_state-block, cache_ptr);
+ creq-cache_ptr = cache_ptr;
+
+ return 0;
+}
+
+static int mv_cesa_md5_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_md5_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+struct ahash_alg mv_md5_alg = {
+ .init = mv_cesa_md5_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_md5_digest,
+ .export = mv_cesa_md5_export,
+ .import = mv_cesa_md5_import,
+ .halg = {
+ .digestsize = MD5_DIGEST_SIZE,
+ .base = {
+ .cra_name = md5,
+ .cra_driver_name = mv-md5,
+ .cra_priority = 300
[PATCH v6 09/14] crypto: marvell/CESA: add SHA256 support
From: Arnaud Ebalard a...@natisbad.org
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 159 ++
3 files changed, 163 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 047c1c0..9c43cd7e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -180,8 +180,10 @@ static struct crypto_alg *armada_370_cipher_algs[] = {
static struct ahash_alg *armada_370_ahash_algs[] = {
mv_md5_alg,
mv_sha1_alg,
+ mv_sha256_alg,
mv_ahmac_md5_alg,
mv_ahmac_sha1_alg,
+ mv_ahmac_sha256_alg,
};
static const struct mv_cesa_caps armada_370_caps = {
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 2a7e21a..a328938 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -776,8 +776,10 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
extern struct ahash_alg mv_md5_alg;
extern struct ahash_alg mv_sha1_alg;
+extern struct ahash_alg mv_sha256_alg;
extern struct ahash_alg mv_ahmac_md5_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
+extern struct ahash_alg mv_ahmac_sha256_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
extern struct crypto_alg mv_cesa_cbc_des_alg;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 1c82d9b..f90a510 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -977,6 +977,95 @@ struct ahash_alg mv_sha1_alg = {
}
};
+static int mv_cesa_sha256_init(struct ahash_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl, CESA_SA_DESC_CFG_MACM_SHA256);
+
+ mv_cesa_ahash_init(req, tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_sha256_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_sha256_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+static int mv_cesa_sha256_export(struct ahash_request *req, void *out)
+{
+ struct sha256_state *out_state = out;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int ds = crypto_ahash_digestsize(ahash);
+
+ out_state-count = creq-len;
+ memcpy(out_state-state, creq-state, ds);
+ memset(out_state-buf, 0, sizeof(out_state-buf));
+ if (creq-cache)
+ memcpy(out_state-buf, creq-cache, creq-cache_ptr);
+
+ return 0;
+}
+
+static int mv_cesa_sha256_import(struct ahash_request *req, const void *in)
+{
+ const struct sha256_state *in_state = in;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+ unsigned int cache_ptr;
+ int ret;
+
+ creq-len = in_state-count;
+ memcpy(creq-state, in_state-state, digsize);
+ creq-cache_ptr = 0;
+
+ cache_ptr = creq-len % SHA256_BLOCK_SIZE;
+ if (!cache_ptr)
+ return 0;
+
+ ret = mv_cesa_ahash_alloc_cache(req);
+ if (ret)
+ return ret;
+
+ memcpy(creq-cache, in_state-buf, cache_ptr);
+ creq-cache_ptr = cache_ptr;
+
+ return 0;
+}
+
+struct ahash_alg mv_sha256_alg = {
+ .init = mv_cesa_sha256_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_sha256_digest,
+ .export = mv_cesa_sha256_export,
+ .import = mv_cesa_sha256_import,
+ .halg = {
+ .digestsize = SHA256_DIGEST_SIZE,
+ .base = {
+ .cra_name = sha256,
+ .cra_driver_name = mv-sha256,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+CRYPTO_ALG_KERN_DRIVER_ONLY,
+ .cra_blocksize = SHA256_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_hash_ctx),
+ .cra_init = mv_cesa_ahash_cra_init,
+ .cra_module = THIS_MODULE,
+}
+ }
+};
+
struct mv_cesa_ahash_result {
struct completion completion;
int error;
@@ -1282,3 +1371,73 @@ struct ahash_alg mv_ahmac_sha1_alg = {
}
}
};
+
+static int mv_cesa_ahmac_sha256_setkey(struct crypto_ahash *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct mv_cesa_hmac_ctx *ctx = crypto_tfm_ctx(crypto_ahash_tfm(tfm));
+ struct sha256_state istate, ostate;
+ int ret, i
Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
On Wed, 17 Jun 2015 17:50:01 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote: + ret = dma_map_sg(cesa_dev-dev, req-src, creq-src_nents, +DMA_TO_DEVICE); + if (!ret) + return -ENOMEM; + + creq-src_nents = ret; DMA-API-HOWTO says that you must retain the original nents and use it when you call dma_unmap_sg. So I'm afraid one more repost is needed :) My bad (again :-/). Actually, I think I don't need to save the dma_map_sg return val, since I'm using the sg_next function to iterate over the scatterlist. Am I right ? IOW, is the -map_sg() function (in dma_map_ops) supposed to merge the contiguous entries and then flag the unused entries with the is_chain flag ? If that's not the case, and the -map_sg() just marks the merged entries as empty (length = 0), then I'll have to rework my iterator algorithm. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 05/14] crypto: marvell/CESA: add TDMA support
On Wed, 17 Jun 2015 15:18:29 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Wed, Jun 17, 2015 at 09:15:03AM +0200, Boris Brezillon wrote: Anyway, now I'm doing the following test: if (creq-src_nents !ret) return -ENOMEM; Best not call dma_map_sg at all in the !src_nents case as I think some architectures will WARN or BUG if you give it a zero-length list. Okay, I've changed it to test for the !src_nents before calling dma_map_sg. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 05/14] crypto: marvell/CESA: add TDMA support
On Wed, 17 Jun 2015 13:56:33 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Wed, Jun 17, 2015 at 01:05:27PM +0800, Herbert Xu wrote: On Tue, Jun 16, 2015 at 11:58:59AM +0200, Boris Brezillon wrote: + ret = dma_map_sg(cesa_dev-dev, req-src, creq-src_nents, + DMA_TO_DEVICE); + if (ret != creq-src_nents) + return -ENOMEM; Hmm it doesn't quite work like that. It returns zero on error, otherwise it returns the number (n) of mapped entries which may be less than what you gave it due to merging. You're then supposed to use only the first n entries which should contain everything. Please take a look at Documentation/DMA-API-HOWTO.txt, it has everything you need to know about the dma_map_sg interface. Yep, I read it, but apparently not carefully enough ;-). I'll fix that. Note that I did not ignore your previous comment on purpose (checking for !ret to verify if the sg entries were successfully mapped), but I have a specific case in the hash code where the requested len is 0 (final request) and thus the src_nents is 0 too. Which means I'm expecting the dma_sg_map to return 0. Anyway, now I'm doing the following test: if (creq-src_nents !ret) return -ENOMEM; Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 00/14] crypto: add a new driver for Marvell's CESA
Hello, This patch series adds a new driver supporting Marvell's CESA IP. This driver addresses some limitations of the existing one. From a performance and CPU load point of view the most important limitation in the existing driver is the lack of DMA support, thus preventing us from chaining crypto operations. I know we usually try to adapt existing drivers instead of replacing them by new ones, but after trying to refactor the mv_cesa driver I realized it would take longer than writing an new one from scratch. Here are the main features brought by this new driver: - support for armada SoCs (up to 38x) while keeping support for older ones (Orion and Kirkwood). Note that old DT bindings (those used on Orion and Kirkwood platforms) are supported, or IOTW, old DTs are compatible with this new driver. - DMA mode to offload the CPU in case of intensive crypto usage - new algorithms: SHA256, DES and 3DES I'd like to thank Arnaud, who has carefully reviewed several iterations of this driver, helped me improved my implementation, provided support for several crypto algorithms, provided support for armada-370 and tested the driver on different platforms, hence the SoB and dual MODULE_AUTHOR in the driver code. In this version I dropped the DT changes, but you'll find them in my cesa-v6 branch [1]. In this branch you'll find everything you need to test on all Marvell platforms (including the old ones). I'll post a series updating all the DTs once this driver has been merged. Best Regards, Boris [1]https://github.com/bbrezillon/linux-marvell/tree/cesa-v6 Changes since v5: - fix the dma_map_sg return code check (again) - fix select entries in the Kconfig option Changes since v4: - fix the dma_map_sg return code check - add import/export functions to all HMAC algos - update the passed IV when handling cipher requests - properly handle requests in the crypto queue backlog - use sg_nents_for_len Changes since v3: - add import functions for hash algorithms - patch mv_cesa driver to support the new DT bindings - few fixes in the documentation - replace mv_mbus_dram_info() call by mv_mbus_dram_info_nooverlap() - remove DT updates from the series Changes since v2: - fixes in the cipher code (-dst_nents was assigned the -src_nents value and CBC state was overwritten by the IV after each chunk operation) - spit the code as suggested by Sebastian Changes since v1: - (suggested by Jason) kept the existing CESA driver and added a mechanism to prevent the new driver from probing devices handled my the existing one (Orion and Kirkwood platforms) - (reported by Paul) addressed a few Kconfig and module definition issues - (suggested by Andrew) added DT changes to the series Arnaud Ebalard (4): crypto: marvell/CESA: add Triple-DES support crypto: marvell/CESA: add MD5 support crypto: marvell/CESA: add SHA256 support crypto: marvell/CESA: add support for Kirkwood and Dove SoCs Boris Brezillon (10): crypto: mv_cesa: document the clocks property crypto: mv_cesa: use gen_pool to reserve the SRAM memory region crypto: mv_cesa: explicitly define kirkwood and dove compatible strings crypto: add a new driver for Marvell's CESA crypto: marvell/CESA: add TDMA support crypto: marvell/CESA: add DES support crypto: marvell/CESA: add support for all armada SoCs crypto: marvell/CESA: add allhwsupport module parameter crypto: marvell/CESA: add support for Orion SoCs crypto: marvell/CESA: add DT bindings documentation .../devicetree/bindings/crypto/marvell-cesa.txt| 45 + .../devicetree/bindings/crypto/mv_cesa.txt | 31 +- drivers/crypto/Kconfig | 17 + drivers/crypto/Makefile|1 + drivers/crypto/marvell/Makefile|2 + drivers/crypto/marvell/cesa.c | 548 drivers/crypto/marvell/cesa.h | 791 +++ drivers/crypto/marvell/cipher.c| 784 +++ drivers/crypto/marvell/hash.c | 1443 drivers/crypto/marvell/tdma.c | 224 +++ drivers/crypto/mv_cesa.c | 60 +- 11 files changed, 3922 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt create mode 100644 drivers/crypto/marvell/Makefile create mode 100644 drivers/crypto/marvell/cesa.c create mode 100644 drivers/crypto/marvell/cesa.h create mode 100644 drivers/crypto/marvell/cipher.c create mode 100644 drivers/crypto/marvell/hash.c create mode 100644 drivers/crypto/marvell/tdma.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 01/14] crypto: mv_cesa: document the clocks property
On Dove platforms, the crypto engine requires a clock. Document this clocks property in the mv_cesa bindings doc. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- Documentation/devicetree/bindings/crypto/mv_cesa.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt b/Documentation/devicetree/bindings/crypto/mv_cesa.txt index 47229b1..eaa2873 100644 --- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt @@ -7,6 +7,8 @@ Required properties: length - reg-names : regs , sram; - interrupts : interrupt number +- clocks: reference to the crypto engines clocks. This property is only + required for Dove platforms Examples: -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not retrieved through DMA yet),
thus reducing the involvement of the CPU and providing better performances
in most cases (for small requests, the cost of DMA preparation might
exceed the performance gain).
Note that some CESA IPs do not embed this dedicated DMA, hence the
activation of this feature on a per platform basis.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 1 +
drivers/crypto/marvell/Makefile | 2 +-
drivers/crypto/marvell/cesa.c | 68 +++
drivers/crypto/marvell/cesa.h | 229 ++
drivers/crypto/marvell/cipher.c | 166 +++-
drivers/crypto/marvell/hash.c | 416 +++-
drivers/crypto/marvell/tdma.c | 224 ++
7 files changed, 1090 insertions(+), 16 deletions(-)
create mode 100644 drivers/crypto/marvell/tdma.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index cbc3d3d..cdca762 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -185,6 +185,7 @@ config CRYPTO_DEV_MARVELL_CESA
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Armada 370.
+ This driver supports CPU offload through DMA transfers.
This driver is aimed at replacing the mv_cesa driver. This will only
happen once it has received proper testing.
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
index 68d0982..0c12b13 100644
--- a/drivers/crypto/marvell/Makefile
+++ b/drivers/crypto/marvell/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
-marvell-cesa-objs := cesa.o cipher.o hash.o
+marvell-cesa-objs := cesa.o cipher.o hash.o tdma.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 76a6943..986f024 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -184,6 +184,7 @@ static const struct mv_cesa_caps armada_370_caps = {
.ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
.ahash_algs = armada_370_ahash_algs,
.nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
};
static const struct of_device_id mv_cesa_of_match_table[] = {
@@ -192,6 +193,66 @@ static const struct of_device_id mv_cesa_of_match_table[]
= {
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
+static void
+mv_cesa_conf_mbus_windows(struct mv_cesa_engine *engine,
+ const struct mbus_dram_target_info *dram)
+{
+ void __iomem *iobase = engine-regs;
+ int i;
+
+ for (i = 0; i 4; i++) {
+ writel(0, iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(0, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+
+ for (i = 0; i dram-num_cs; i++) {
+ const struct mbus_dram_window *cs = dram-cs + i;
+
+ writel(((cs-size - 1) 0x) |
+ (cs-mbus_attr 8) |
+ (dram-mbus_dram_target_id 4) | 1,
+ iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(cs-base, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+}
+
+static int mv_cesa_dev_dma_init(struct mv_cesa_dev *cesa)
+{
+ struct device *dev = cesa-dev;
+ struct mv_cesa_dev_dma *dma;
+
+ if (!cesa-caps-has_tdma)
+ return 0;
+
+ dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
+ if (!dma)
+ return -ENOMEM;
+
+ dma-tdma_desc_pool = dmam_pool_create(tdma_desc, dev,
+ sizeof(struct mv_cesa_tdma_desc),
+ 16, 0);
+ if (!dma-tdma_desc_pool)
+ return -ENOMEM;
+
+ dma-op_pool = dmam_pool_create(cesa_op, dev,
+ sizeof(struct mv_cesa_op_ctx), 16, 0);
+ if (!dma-op_pool)
+ return -ENOMEM;
+
+ dma-cache_pool = dmam_pool_create(cesa_cache, dev,
+ CESA_MAX_HASH_BLOCK_SIZE, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ dma-padding_pool = dmam_pool_create(cesa_padding, dev, 72, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ cesa-dma = dma;
+
+ return 0;
+}
+
static int mv_cesa_get_sram(struct platform_device *pdev, int idx)
{
struct mv_cesa_dev *cesa = platform_get_drvdata(pdev);
@@ -299,6 +360,10 @@ static int mv_cesa_probe(struct platform_device *pdev)
if (IS_ERR(cesa-regs))
return -ENOMEM
[PATCH v6 11/14] crypto: marvell/CESA: add allhwsupport module parameter
The old and new marvell CESA drivers both support Orion and Kirkwood SoCs. Add a module parameter to choose whether these SoCs should be attached to the new or the old driver. The default policy is to keep attaching those IPs to the old driver if it is enabled, until we decide the new CESA driver is stable/secure enough. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- drivers/crypto/marvell/cesa.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c index af590bf..a05b5cb 100644 --- a/drivers/crypto/marvell/cesa.c +++ b/drivers/crypto/marvell/cesa.c @@ -31,6 +31,10 @@ #include cesa.h +static int allhwsupport = !IS_ENABLED(CONFIG_CRYPTO_DEV_MV_CESA); +module_param_named(allhwsupport, allhwsupport, int, 0444); +MODULE_PARM_DESC(allhwsupport, Enable support for all hardware (even it if overlaps with the mv_cesa driver)); + struct mv_cesa_dev *cesa_dev; static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 02/14] crypto: mv_cesa: use gen_pool to reserve the SRAM memory region
The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.
This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine
The last point is particularly annoying in some cases: for example on
armada 370, a small region of the crypto SRAM is used to implement the
cpuidle, which means you would not be able to enable both cpuidle and the
CESA driver.
To address that problem, we explicitly define the SRAM device in the DT
and then reference the sram node from the crypto engine node.
Also note that the old way of retrieving the SRAM memory region is still
supported, or in other words, backward compatibility is preserved.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/mv_cesa.txt | 24 ++---
drivers/crypto/Kconfig | 1 +
drivers/crypto/mv_cesa.c | 58 --
3 files changed, 60 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index eaa2873..13b8fc5 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -2,21 +2,29 @@ Marvell Cryptographic Engines And Security Accelerator
Required properties:
- compatible : should be marvell,orion-crypto
-- reg : base physical address of the engine and length of memory mapped
-region, followed by base physical address of sram and its memory
-length
-- reg-names : regs , sram;
-- interrupts : interrupt number
+- reg: base physical address of the engine and length of memory mapped
+ region. Can also contain an entry for the SRAM attached to the CESA,
+ but this representation is deprecated and marvell,crypto-srams should
+ be used instead
+- reg-names: regs. Can contain an sram entry, but this representation
+is deprecated and marvell,crypto-srams should be used instead
+- interrupts: interrupt number
- clocks: reference to the crypto engines clocks. This property is only
required for Dove platforms
+- marvell,crypto-srams: phandle to crypto SRAM definitions
+
+Optional properties:
+- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
+ specified the whole SRAM is used (2KB)
Examples:
crypto@3 {
compatible = marvell,orion-crypto;
- reg = 0x3 0x1,
- 0x400 0x800;
- reg-names = regs , sram;
+ reg = 0x3 0x1;
+ reg-names = regs;
interrupts = 22;
+ marvell,crypto-srams = crypto_sram;
+ marvell,crypto-sram-size = 0x600;
status = okay;
};
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 033c0c8..a6bbea8 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -166,6 +166,7 @@ config CRYPTO_DEV_MV_CESA
select CRYPTO_AES
select CRYPTO_BLKCIPHER2
select CRYPTO_HASH
+ select SRAM
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Marvell Orion
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 27b2373..a4c8637 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -9,6 +9,7 @@
#include crypto/aes.h
#include crypto/algapi.h
#include linux/crypto.h
+#include linux/genalloc.h
#include linux/interrupt.h
#include linux/io.h
#include linux/kthread.h
@@ -29,6 +30,8 @@
#define MAX_HW_HASH_SIZE 0x
#define MV_CESA_EXPIRE 500 /* msec */
+#define MV_CESA_DEFAULT_SRAM_SIZE 2048
+
/*
* STM:
* /---\
@@ -83,6 +86,8 @@ struct req_progress {
struct crypto_priv {
void __iomem *reg;
void __iomem *sram;
+ struct gen_pool *sram_pool;
+ dma_addr_t sram_dma;
int irq;
struct clk *clk;
struct task_struct *queue_th;
@@ -1019,6 +1024,39 @@ static struct ahash_alg mv_hmac_sha1_alg = {
}
};
+static int mv_cesa_get_sram(struct platform_device *pdev,
+ struct crypto_priv *cp)
+{
+ struct resource *res;
+ u32 sram_size = MV_CESA_DEFAULT_SRAM_SIZE;
+
+ of_property_read_u32(pdev-dev.of_node, marvell,crypto-sram-size,
+sram_size);
+
+ cp-sram_size = sram_size;
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ marvell,crypto-srams, 0);
+ if (cp-sram_pool) {
+ cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
+ cp-sram_dma);
+ if (cp-sram
[PATCH v6 03/14] crypto: mv_cesa: explicitly define kirkwood and dove compatible strings
We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA support on Dove and Kirkwood.
In the other hand, the migration from the old driver to the new one is not
something all people are willing to do without first auditing the new
driver.
Hence we have to support the new compatible in the mv_cesa driver so that
new platforms with updated DTs can still attach their crypto engine device
to this driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 5 -
drivers/crypto/mv_cesa.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index 13b8fc5..c0c35f0 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -1,7 +1,10 @@
Marvell Cryptographic Engines And Security Accelerator
Required properties:
-- compatible : should be marvell,orion-crypto
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
- reg: base physical address of the engine and length of memory mapped
region. Can also contain an entry for the SRAM attached to the CESA,
but this representation is deprecated and marvell,crypto-srams should
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index a4c8637..fcab963 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1034,7 +1034,7 @@ static int mv_cesa_get_sram(struct platform_device *pdev,
sram_size);
cp-sram_size = sram_size;
- cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
marvell,crypto-srams, 0);
if (cp-sram_pool) {
cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
@@ -1197,6 +1197,8 @@ static int mv_remove(struct platform_device *pdev)
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,orion-crypto, },
+ { .compatible = marvell,kirkwood-crypto, },
+ { .compatible = marvell,dove-crypto, },
{}
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 05/14] crypto: marvell/CESA: add TDMA support
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not retrieved through DMA yet),
thus reducing the involvement of the CPU and providing better performances
in most cases (for small requests, the cost of DMA preparation might
exceed the performance gain).
Note that some CESA IPs do not embed this dedicated DMA, hence the
activation of this feature on a per platform basis.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
Hi Herbert,
I send you this patch alone so that you can verify I'm now properly
manipulating the SG list. Once I have your confirmation I'll send
the whole series again and annoy all the people in Cc one more time
;-).
Best Regards,
Boris
drivers/crypto/Kconfig | 1 +
drivers/crypto/marvell/Makefile | 2 +-
drivers/crypto/marvell/cesa.c | 68 +++
drivers/crypto/marvell/cesa.h | 229 ++
drivers/crypto/marvell/cipher.c | 162 +++-
drivers/crypto/marvell/hash.c | 414 +++-
drivers/crypto/marvell/tdma.c | 224 ++
7 files changed, 1084 insertions(+), 16 deletions(-)
create mode 100644 drivers/crypto/marvell/tdma.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index cbc3d3d..cdca762 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -185,6 +185,7 @@ config CRYPTO_DEV_MARVELL_CESA
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Armada 370.
+ This driver supports CPU offload through DMA transfers.
This driver is aimed at replacing the mv_cesa driver. This will only
happen once it has received proper testing.
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
index 68d0982..0c12b13 100644
--- a/drivers/crypto/marvell/Makefile
+++ b/drivers/crypto/marvell/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
-marvell-cesa-objs := cesa.o cipher.o hash.o
+marvell-cesa-objs := cesa.o cipher.o hash.o tdma.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 76a6943..986f024 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -184,6 +184,7 @@ static const struct mv_cesa_caps armada_370_caps = {
.ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
.ahash_algs = armada_370_ahash_algs,
.nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
};
static const struct of_device_id mv_cesa_of_match_table[] = {
@@ -192,6 +193,66 @@ static const struct of_device_id mv_cesa_of_match_table[]
= {
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
+static void
+mv_cesa_conf_mbus_windows(struct mv_cesa_engine *engine,
+ const struct mbus_dram_target_info *dram)
+{
+ void __iomem *iobase = engine-regs;
+ int i;
+
+ for (i = 0; i 4; i++) {
+ writel(0, iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(0, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+
+ for (i = 0; i dram-num_cs; i++) {
+ const struct mbus_dram_window *cs = dram-cs + i;
+
+ writel(((cs-size - 1) 0x) |
+ (cs-mbus_attr 8) |
+ (dram-mbus_dram_target_id 4) | 1,
+ iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(cs-base, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+}
+
+static int mv_cesa_dev_dma_init(struct mv_cesa_dev *cesa)
+{
+ struct device *dev = cesa-dev;
+ struct mv_cesa_dev_dma *dma;
+
+ if (!cesa-caps-has_tdma)
+ return 0;
+
+ dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
+ if (!dma)
+ return -ENOMEM;
+
+ dma-tdma_desc_pool = dmam_pool_create(tdma_desc, dev,
+ sizeof(struct mv_cesa_tdma_desc),
+ 16, 0);
+ if (!dma-tdma_desc_pool)
+ return -ENOMEM;
+
+ dma-op_pool = dmam_pool_create(cesa_op, dev,
+ sizeof(struct mv_cesa_op_ctx), 16, 0);
+ if (!dma-op_pool)
+ return -ENOMEM;
+
+ dma-cache_pool = dmam_pool_create(cesa_cache, dev,
+ CESA_MAX_HASH_BLOCK_SIZE, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ dma-padding_pool = dmam_pool_create(cesa_padding, dev, 72, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ cesa-dma = dma;
+
+ return 0;
+}
+
static int mv_cesa_get_sram(struct
[PATCH v6 10/14] crypto: marvell/CESA: add support for all armada SoCs
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 9c43cd7e..af590bf 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -195,8 +195,20 @@ static const struct mv_cesa_caps armada_370_caps = {
.has_tdma = true,
};
+static const struct mv_cesa_caps armada_xp_caps = {
+ .nengines = 2,
+ .cipher_algs = armada_370_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
+ .ahash_algs = armada_370_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
+};
+
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
+ { .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
+ { .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
+ { .compatible = marvell,armada-38x-crypto, .data = armada_xp_caps },
{}
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 07/14] crypto: marvell/CESA: add Triple-DES support
From: Arnaud Ebalard a...@natisbad.org
Add support for Triple-DES operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 147
3 files changed, 151 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 212840e..c0b1b49 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -171,6 +171,8 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
static struct crypto_alg *armada_370_cipher_algs[] = {
mv_cesa_ecb_des_alg,
mv_cesa_cbc_des_alg,
+ mv_cesa_ecb_des3_ede_alg,
+ mv_cesa_cbc_des3_ede_alg,
mv_cesa_ecb_aes_alg,
mv_cesa_cbc_aes_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 2ee48fe..2e8b7fc 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -779,6 +779,8 @@ extern struct ahash_alg mv_ahmac_sha1_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
extern struct crypto_alg mv_cesa_cbc_des_alg;
+extern struct crypto_alg mv_cesa_ecb_des3_ede_alg;
+extern struct crypto_alg mv_cesa_cbc_des3_ede_alg;
extern struct crypto_alg mv_cesa_ecb_aes_alg;
extern struct crypto_alg mv_cesa_cbc_aes_alg;
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index ee49f5f..806c43a 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -22,6 +22,11 @@ struct mv_cesa_des_ctx {
u8 key[DES_KEY_SIZE];
};
+struct mv_cesa_des3_ctx {
+ struct mv_cesa_ctx base;
+ u8 key[DES3_EDE_KEY_SIZE];
+};
+
struct mv_cesa_aes_ctx {
struct mv_cesa_ctx base;
struct crypto_aes_ctx aes;
@@ -261,6 +266,22 @@ static int mv_cesa_des_setkey(struct crypto_ablkcipher
*cipher, const u8 *key,
return 0;
}
+static int mv_cesa_des3_ede_setkey(struct crypto_ablkcipher *cipher,
+ const u8 *key, unsigned int len)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ if (len != DES3_EDE_KEY_SIZE) {
+ crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+
+ memcpy(ctx-key, key, DES3_EDE_KEY_SIZE);
+
+ return 0;
+}
+
static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
const struct mv_cesa_op_ctx *op_templ)
{
@@ -501,6 +522,132 @@ struct crypto_alg mv_cesa_cbc_des_alg = {
},
};
+static int mv_cesa_des3_op(struct ablkcipher_request *req,
+ struct mv_cesa_op_ctx *tmpl)
+{
+ struct mv_cesa_des3_ctx *ctx = crypto_tfm_ctx(req-base.tfm);
+ int ret;
+
+ mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTM_3DES,
+ CESA_SA_DESC_CFG_CRYPTM_MSK);
+
+ memcpy(tmpl-ctx.blkcipher.key, ctx-key, DES3_EDE_KEY_SIZE);
+
+ ret = mv_cesa_ablkcipher_req_init(req, tmpl);
+ if (ret)
+ return ret;
+
+ ret = mv_cesa_queue_req(req-base);
+ if (ret ret != -EINPROGRESS)
+ mv_cesa_ablkcipher_cleanup(req);
+
+ return ret;
+}
+
+static int mv_cesa_ecb_des3_ede_encrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_3DES_EDE |
+ CESA_SA_DESC_CFG_DIR_ENC);
+
+ return mv_cesa_des3_op(req, tmpl);
+}
+
+static int mv_cesa_ecb_des3_ede_decrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_3DES_EDE |
+ CESA_SA_DESC_CFG_DIR_DEC);
+
+ return mv_cesa_des3_op(req, tmpl);
+}
+
+struct crypto_alg mv_cesa_ecb_des3_ede_alg = {
+ .cra_name = ecb(des3_ede),
+ .cra_driver_name = mv-ecb-des3-ede,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
+ .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_des3_ctx),
+ .cra_alignmask = 0,
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = mv_cesa_ablkcipher_cra_init,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize = DES3_EDE_KEY_SIZE,
+ .max_keysize = DES3_EDE_KEY_SIZE,
+ .ivsize = DES3_EDE_BLOCK_SIZE,
+ .setkey = mv_cesa_des3_ede_setkey,
+ .encrypt
[PATCH v6 14/14] crypto: marvell/CESA: add DT bindings documentation
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt
diff --git a/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
new file mode 100644
index 000..c6c6a4a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
@@ -0,0 +1,45 @@
+Marvell Cryptographic Engines And Security Accelerator
+
+Required properties:
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
+ marvell,armada-370-crypto
+ marvell,armada-xp-crypto
+ marvell,armada-375-crypto
+ marvell,armada-38x-crypto
+- reg: base physical address of the engine and length of memory mapped
+ region. Can also contain an entry for the SRAM attached to the CESA,
+ but this representation is deprecated and marvell,crypto-srams should
+ be used instead
+- reg-names: regs. Can contain an sram entry, but this representation
+is deprecated and marvell,crypto-srams should be used instead
+- interrupts: interrupt number
+- clocks: reference to the crypto engines clocks. This property is not
+ required for orion and kirkwood platforms
+- clock-names: cesaX and cesazX, X should be replaced by the crypto engine
+ id.
+ This property is not required for the orion and kirkwoord
+ platforms.
+ cesazX clocks are not required on armada-370 platforms
+- marvell,crypto-srams: phandle to crypto SRAM definitions
+
+Optional properties:
+- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
+ specified the whole SRAM is used (2KB)
+
+
+Examples:
+
+ crypto@9 {
+ compatible = marvell,armada-xp-crypto;
+ reg = 0x9 0x1;
+ reg-names = regs;
+ interrupts = 48, 49;
+ clocks = gateclk 23, gateclk 23;
+ clock-names = cesa0, cesa1;
+ marvell,crypto-srams = crypto_sram0, crypto_sram1;
+ marvell,crypto-sram-size = 0x600;
+ status = okay;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 13/14] crypto: marvell/CESA: add support for Kirkwood and Dove SoCs
From: Arnaud Ebalard a...@natisbad.org
Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport
module parameter to avoid probing the CESA IP when the old CESA driver is
enabled (unless it is explicitly requested to do so).
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 8e5ea72..a432633 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -215,6 +215,15 @@ static const struct mv_cesa_caps orion_caps = {
.has_tdma = false,
};
+static const struct mv_cesa_caps kirkwood_caps = {
+ .nengines = 1,
+ .cipher_algs = orion_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(orion_cipher_algs),
+ .ahash_algs = orion_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(orion_ahash_algs),
+ .has_tdma = true,
+};
+
static const struct mv_cesa_caps armada_370_caps = {
.nengines = 1,
.cipher_algs = armada_370_cipher_algs,
@@ -235,6 +244,8 @@ static const struct mv_cesa_caps armada_xp_caps = {
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,orion-crypto, .data = orion_caps },
+ { .compatible = marvell,kirkwood-crypto, .data = kirkwood_caps },
+ { .compatible = marvell,dove-crypto, .data = kirkwood_caps },
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
{ .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
{ .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
@@ -383,7 +394,7 @@ static int mv_cesa_probe(struct platform_device *pdev)
caps = match-data;
}
- if (caps == orion_caps !allhwsupport)
+ if ((caps == orion_caps || caps == kirkwood_caps) !allhwsupport)
return -ENOTSUPP;
cesa = devm_kzalloc(dev, sizeof(*cesa), GFP_KERNEL);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 12/14] crypto: marvell/CESA: add support for Orion SoCs
Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.
Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is explicitly requested to do
so).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 42 +++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index a05b5cb..8e5ea72 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -172,6 +172,22 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
crypto_unregister_alg(cesa-caps-cipher_algs[i]);
}
+static struct crypto_alg *orion_cipher_algs[] = {
+ mv_cesa_ecb_des_alg,
+ mv_cesa_cbc_des_alg,
+ mv_cesa_ecb_des3_ede_alg,
+ mv_cesa_cbc_des3_ede_alg,
+ mv_cesa_ecb_aes_alg,
+ mv_cesa_cbc_aes_alg,
+};
+
+static struct ahash_alg *orion_ahash_algs[] = {
+ mv_md5_alg,
+ mv_sha1_alg,
+ mv_ahmac_md5_alg,
+ mv_ahmac_sha1_alg,
+};
+
static struct crypto_alg *armada_370_cipher_algs[] = {
mv_cesa_ecb_des_alg,
mv_cesa_cbc_des_alg,
@@ -190,6 +206,15 @@ static struct ahash_alg *armada_370_ahash_algs[] = {
mv_ahmac_sha256_alg,
};
+static const struct mv_cesa_caps orion_caps = {
+ .nengines = 1,
+ .cipher_algs = orion_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(orion_cipher_algs),
+ .ahash_algs = orion_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(orion_ahash_algs),
+ .has_tdma = false,
+};
+
static const struct mv_cesa_caps armada_370_caps = {
.nengines = 1,
.cipher_algs = armada_370_cipher_algs,
@@ -209,6 +234,7 @@ static const struct mv_cesa_caps armada_xp_caps = {
};
static const struct of_device_id mv_cesa_of_match_table[] = {
+ { .compatible = marvell,orion-crypto, .data = orion_caps },
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
{ .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
{ .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
@@ -334,7 +360,7 @@ static void mv_cesa_put_sram(struct platform_device *pdev,
int idx)
static int mv_cesa_probe(struct platform_device *pdev)
{
- const struct mv_cesa_caps *caps = NULL;
+ const struct mv_cesa_caps *caps = orion_caps;
const struct mbus_dram_target_info *dram;
const struct of_device_id *match;
struct device *dev = pdev-dev;
@@ -349,14 +375,16 @@ static int mv_cesa_probe(struct platform_device *pdev)
return -EEXIST;
}
- if (!dev-of_node)
- return -ENOTSUPP;
+ if (dev-of_node) {
+ match = of_match_node(mv_cesa_of_match_table, dev-of_node);
+ if (!match || !match-data)
+ return -ENOTSUPP;
- match = of_match_node(mv_cesa_of_match_table, dev-of_node);
- if (!match || !match-data)
- return -ENOTSUPP;
+ caps = match-data;
+ }
- caps = match-data;
+ if (caps == orion_caps !allhwsupport)
+ return -ENOTSUPP;
cesa = devm_kzalloc(dev, sizeof(*cesa), GFP_KERNEL);
if (!cesa)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/14] crypto: marvell/CESA: add TDMA support
On Wed, 17 Jun 2015 23:08:08 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Wed, Jun 17, 2015 at 03:32:02PM +0200, Boris Brezillon wrote: Hi Herbert, I send you this patch alone so that you can verify I'm now properly manipulating the SG list. Once I have your confirmation I'll send the whole series again and annoy all the people in Cc one more time ;-). Thanks. The only problem that I can see is the fact you're not checking for req-src == req-dst. If they're equal then you must not map it twice. Instead it should be mapped as DMA_BIDIRECTIONAL. I can check for that too, but note that it doesn't prevent one from providing different scatterlist structures pointing to the same memory region. This being said, checking for req-src == req-dst should fix the case where dst and src are pointing to the same scatterlist, which is a good start. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/14] crypto: marvell/CESA: add TDMA support
On Wed, 17 Jun 2015 17:34:02 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: On Wed, 17 Jun 2015 23:08:08 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Wed, Jun 17, 2015 at 03:32:02PM +0200, Boris Brezillon wrote: Hi Herbert, I send you this patch alone so that you can verify I'm now properly manipulating the SG list. Once I have your confirmation I'll send the whole series again and annoy all the people in Cc one more time ;-). Thanks. The only problem that I can see is the fact you're not checking for req-src == req-dst. If they're equal then you must not map it twice. Instead it should be mapped as DMA_BIDIRECTIONAL. I can check for that too, but note that it doesn't prevent one from providing different scatterlist structures pointing to the same memory region. Actually, I don't know if it's a problem or not, so if it's not, please ignore my comment. This being said, checking for req-src == req-dst should fix the case where dst and src are pointing to the same scatterlist, which is a good start. Here is an incremental patch [1], please let me know if something else is missing. Thanks, Boris [1]http://code.bulix.org/x8mz8x-88568 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 02/14] crypto: mv_cesa: use gen_pool to reserve the SRAM memory region
The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.
This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine
The last point is particularly annoying in some cases: for example on
armada 370, a small region of the crypto SRAM is used to implement the
cpuidle, which means you would not be able to enable both cpuidle and the
CESA driver.
To address that problem, we explicitly define the SRAM device in the DT
and then reference the sram node from the crypto engine node.
Also note that the old way of retrieving the SRAM memory region is still
supported, or in other words, backward compatibility is preserved.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/mv_cesa.txt | 24 ++---
drivers/crypto/Kconfig | 1 +
drivers/crypto/mv_cesa.c | 58 --
3 files changed, 60 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index eaa2873..13b8fc5 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -2,21 +2,29 @@ Marvell Cryptographic Engines And Security Accelerator
Required properties:
- compatible : should be marvell,orion-crypto
-- reg : base physical address of the engine and length of memory mapped
-region, followed by base physical address of sram and its memory
-length
-- reg-names : regs , sram;
-- interrupts : interrupt number
+- reg: base physical address of the engine and length of memory mapped
+ region. Can also contain an entry for the SRAM attached to the CESA,
+ but this representation is deprecated and marvell,crypto-srams should
+ be used instead
+- reg-names: regs. Can contain an sram entry, but this representation
+is deprecated and marvell,crypto-srams should be used instead
+- interrupts: interrupt number
- clocks: reference to the crypto engines clocks. This property is only
required for Dove platforms
+- marvell,crypto-srams: phandle to crypto SRAM definitions
+
+Optional properties:
+- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
+ specified the whole SRAM is used (2KB)
Examples:
crypto@3 {
compatible = marvell,orion-crypto;
- reg = 0x3 0x1,
- 0x400 0x800;
- reg-names = regs , sram;
+ reg = 0x3 0x1;
+ reg-names = regs;
interrupts = 22;
+ marvell,crypto-srams = crypto_sram;
+ marvell,crypto-sram-size = 0x600;
status = okay;
};
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 033c0c8..a6bbea8 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -166,6 +166,7 @@ config CRYPTO_DEV_MV_CESA
select CRYPTO_AES
select CRYPTO_BLKCIPHER2
select CRYPTO_HASH
+ select SRAM
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Marvell Orion
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 27b2373..a4c8637 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -9,6 +9,7 @@
#include crypto/aes.h
#include crypto/algapi.h
#include linux/crypto.h
+#include linux/genalloc.h
#include linux/interrupt.h
#include linux/io.h
#include linux/kthread.h
@@ -29,6 +30,8 @@
#define MAX_HW_HASH_SIZE 0x
#define MV_CESA_EXPIRE 500 /* msec */
+#define MV_CESA_DEFAULT_SRAM_SIZE 2048
+
/*
* STM:
* /---\
@@ -83,6 +86,8 @@ struct req_progress {
struct crypto_priv {
void __iomem *reg;
void __iomem *sram;
+ struct gen_pool *sram_pool;
+ dma_addr_t sram_dma;
int irq;
struct clk *clk;
struct task_struct *queue_th;
@@ -1019,6 +1024,39 @@ static struct ahash_alg mv_hmac_sha1_alg = {
}
};
+static int mv_cesa_get_sram(struct platform_device *pdev,
+ struct crypto_priv *cp)
+{
+ struct resource *res;
+ u32 sram_size = MV_CESA_DEFAULT_SRAM_SIZE;
+
+ of_property_read_u32(pdev-dev.of_node, marvell,crypto-sram-size,
+sram_size);
+
+ cp-sram_size = sram_size;
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ marvell,crypto-srams, 0);
+ if (cp-sram_pool) {
+ cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
+ cp-sram_dma);
+ if (cp-sram
[PATCH v5 14/14] crypto: marvell/CESA: add DT bindings documentation
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt
diff --git a/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
new file mode 100644
index 000..c6c6a4a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
@@ -0,0 +1,45 @@
+Marvell Cryptographic Engines And Security Accelerator
+
+Required properties:
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
+ marvell,armada-370-crypto
+ marvell,armada-xp-crypto
+ marvell,armada-375-crypto
+ marvell,armada-38x-crypto
+- reg: base physical address of the engine and length of memory mapped
+ region. Can also contain an entry for the SRAM attached to the CESA,
+ but this representation is deprecated and marvell,crypto-srams should
+ be used instead
+- reg-names: regs. Can contain an sram entry, but this representation
+is deprecated and marvell,crypto-srams should be used instead
+- interrupts: interrupt number
+- clocks: reference to the crypto engines clocks. This property is not
+ required for orion and kirkwood platforms
+- clock-names: cesaX and cesazX, X should be replaced by the crypto engine
+ id.
+ This property is not required for the orion and kirkwoord
+ platforms.
+ cesazX clocks are not required on armada-370 platforms
+- marvell,crypto-srams: phandle to crypto SRAM definitions
+
+Optional properties:
+- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
+ specified the whole SRAM is used (2KB)
+
+
+Examples:
+
+ crypto@9 {
+ compatible = marvell,armada-xp-crypto;
+ reg = 0x9 0x1;
+ reg-names = regs;
+ interrupts = 48, 49;
+ clocks = gateclk 23, gateclk 23;
+ clock-names = cesa0, cesa1;
+ marvell,crypto-srams = crypto_sram0, crypto_sram1;
+ marvell,crypto-sram-size = 0x600;
+ status = okay;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 09/14] crypto: marvell/CESA: add SHA256 support
From: Arnaud Ebalard a...@natisbad.org
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 159 ++
3 files changed, 163 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 047c1c0..9c43cd7e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -180,8 +180,10 @@ static struct crypto_alg *armada_370_cipher_algs[] = {
static struct ahash_alg *armada_370_ahash_algs[] = {
mv_md5_alg,
mv_sha1_alg,
+ mv_sha256_alg,
mv_ahmac_md5_alg,
mv_ahmac_sha1_alg,
+ mv_ahmac_sha256_alg,
};
static const struct mv_cesa_caps armada_370_caps = {
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 2a7e21a..a328938 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -776,8 +776,10 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
extern struct ahash_alg mv_md5_alg;
extern struct ahash_alg mv_sha1_alg;
+extern struct ahash_alg mv_sha256_alg;
extern struct ahash_alg mv_ahmac_md5_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
+extern struct ahash_alg mv_ahmac_sha256_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
extern struct crypto_alg mv_cesa_cbc_des_alg;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index d8555c5..73d3f6f 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -975,6 +975,95 @@ struct ahash_alg mv_sha1_alg = {
}
};
+static int mv_cesa_sha256_init(struct ahash_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl, CESA_SA_DESC_CFG_MACM_SHA256);
+
+ mv_cesa_ahash_init(req, tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_sha256_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_sha256_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+static int mv_cesa_sha256_export(struct ahash_request *req, void *out)
+{
+ struct sha256_state *out_state = out;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int ds = crypto_ahash_digestsize(ahash);
+
+ out_state-count = creq-len;
+ memcpy(out_state-state, creq-state, ds);
+ memset(out_state-buf, 0, sizeof(out_state-buf));
+ if (creq-cache)
+ memcpy(out_state-buf, creq-cache, creq-cache_ptr);
+
+ return 0;
+}
+
+static int mv_cesa_sha256_import(struct ahash_request *req, const void *in)
+{
+ const struct sha256_state *in_state = in;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+ unsigned int cache_ptr;
+ int ret;
+
+ creq-len = in_state-count;
+ memcpy(creq-state, in_state-state, digsize);
+ creq-cache_ptr = 0;
+
+ cache_ptr = creq-len % SHA256_BLOCK_SIZE;
+ if (!cache_ptr)
+ return 0;
+
+ ret = mv_cesa_ahash_alloc_cache(req);
+ if (ret)
+ return ret;
+
+ memcpy(creq-cache, in_state-buf, cache_ptr);
+ creq-cache_ptr = cache_ptr;
+
+ return 0;
+}
+
+struct ahash_alg mv_sha256_alg = {
+ .init = mv_cesa_sha256_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_sha256_digest,
+ .export = mv_cesa_sha256_export,
+ .import = mv_cesa_sha256_import,
+ .halg = {
+ .digestsize = SHA256_DIGEST_SIZE,
+ .base = {
+ .cra_name = sha256,
+ .cra_driver_name = mv-sha256,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+CRYPTO_ALG_KERN_DRIVER_ONLY,
+ .cra_blocksize = SHA256_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_hash_ctx),
+ .cra_init = mv_cesa_ahash_cra_init,
+ .cra_module = THIS_MODULE,
+}
+ }
+};
+
struct mv_cesa_ahash_result {
struct completion completion;
int error;
@@ -1280,3 +1369,73 @@ struct ahash_alg mv_ahmac_sha1_alg = {
}
}
};
+
+static int mv_cesa_ahmac_sha256_setkey(struct crypto_ahash *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct mv_cesa_hmac_ctx *ctx = crypto_tfm_ctx(crypto_ahash_tfm(tfm));
+ struct sha256_state istate, ostate;
+ int ret, i
[PATCH v5 11/14] crypto: marvell/CESA: add allhwsupport module parameter
The old and new marvell CESA drivers both support Orion and Kirkwood SoCs. Add a module parameter to choose whether these SoCs should be attached to the new or the old driver. The default policy is to keep attaching those IPs to the old driver if it is enabled, until we decide the new CESA driver is stable/secure enough. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- drivers/crypto/marvell/cesa.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c index af590bf..a05b5cb 100644 --- a/drivers/crypto/marvell/cesa.c +++ b/drivers/crypto/marvell/cesa.c @@ -31,6 +31,10 @@ #include cesa.h +static int allhwsupport = !IS_ENABLED(CONFIG_CRYPTO_DEV_MV_CESA); +module_param_named(allhwsupport, allhwsupport, int, 0444); +MODULE_PARM_DESC(allhwsupport, Enable support for all hardware (even it if overlaps with the mv_cesa driver)); + struct mv_cesa_dev *cesa_dev; static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 04/14] crypto: add a new driver for Marvell's CESA
The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.
This commit introduce the base infrastructure allowing us to add support
for DMA optimization.
It also includes support for one hash (SHA1) and one cipher (AES)
algorithm, and enable those features on the Armada 370 SoC.
Other algorithms and platforms will be added later on.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 16 +
drivers/crypto/Makefile | 1 +
drivers/crypto/marvell/Makefile | 2 +
drivers/crypto/marvell/cesa.c | 417 +++
drivers/crypto/marvell/cesa.h | 554 +++
drivers/crypto/marvell/cipher.c | 331 ++
drivers/crypto/marvell/hash.c | 720
7 files changed, 2041 insertions(+)
create mode 100644 drivers/crypto/marvell/Makefile
create mode 100644 drivers/crypto/marvell/cesa.c
create mode 100644 drivers/crypto/marvell/cesa.h
create mode 100644 drivers/crypto/marvell/cipher.c
create mode 100644 drivers/crypto/marvell/hash.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index a6bbea8..c15c5a5 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -174,6 +174,22 @@ config CRYPTO_DEV_MV_CESA
Currently the driver supports AES in ECB and CBC mode without DMA.
+config CRYPTO_DEV_MARVELL_CESA
+ tristate New Marvell's Cryptographic Engine driver
+ depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) HAS_DMA
HAS_IOMEM
+ select CRYPTO_ALGAPI
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER2
+ select CRYPTO_HASH
+ select SRAM
+ help
+ This driver allows you to utilize the Cryptographic Engines and
+ Security Accelerator (CESA) which can be found on the Armada 370.
+
+ This driver is aimed at replacing the mv_cesa driver. This will only
+ happen once it has received proper testing.
+
config CRYPTO_DEV_NIAGARA2
tristate Niagara2 Stream Processing Unit driver
select CRYPTO_DES
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index fb84be7..e35c07a 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell/
obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
obj-$(CONFIG_CRYPTO_DEV_NIAGARA2) += n2_crypto.o
n2_crypto-y := n2_core.o n2_asm.o
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
new file mode 100644
index 000..68d0982
--- /dev/null
+++ b/drivers/crypto/marvell/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
+marvell-cesa-objs := cesa.o cipher.o hash.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
new file mode 100644
index 000..76a6943
--- /dev/null
+++ b/drivers/crypto/marvell/cesa.c
@@ -0,0 +1,417 @@
+/*
+ * Support for Marvell's Cryptographic Engine and Security Accelerator (CESA)
+ * that can be found on the following platform: Orion, Kirkwood, Armada. This
+ * driver supports the TDMA engine on platforms on which it is available.
+ *
+ * Author: Boris Brezillon boris.brezil...@free-electrons.com
+ * Author: Arnaud Ebalard a...@natisbad.org
+ *
+ * This work is based on an initial version written by
+ * Sebastian Andrzej Siewior sebastian at breakpoint dot cc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/genalloc.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kthread.h
+#include linux/mbus.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/of_irq.h
+
+#include cesa.h
+
+struct mv_cesa_dev *cesa_dev;
+
+static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine)
+{
+ struct crypto_async_request *req, *backlog;
+ struct mv_cesa_ctx *ctx;
+
+ spin_lock_bh(cesa_dev-lock);
+ backlog = crypto_get_backlog(cesa_dev-queue);
+ req = crypto_dequeue_request(cesa_dev-queue);
+ engine-req = req;
+ spin_unlock_bh(cesa_dev-lock);
+
+ if (!req)
+ return;
+
+ if (backlog)
+ backlog-complete(backlog
[PATCH v5 10/14] crypto: marvell/CESA: add support for all armada SoCs
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 9c43cd7e..af590bf 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -195,8 +195,20 @@ static const struct mv_cesa_caps armada_370_caps = {
.has_tdma = true,
};
+static const struct mv_cesa_caps armada_xp_caps = {
+ .nengines = 2,
+ .cipher_algs = armada_370_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
+ .ahash_algs = armada_370_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
+};
+
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
+ { .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
+ { .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
+ { .compatible = marvell,armada-38x-crypto, .data = armada_xp_caps },
{}
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 00/14] crypto: add a new driver for Marvell's CESA
Hello, This patch series adds a new driver supporting Marvell's CESA IP. This driver addresses some limitations of the existing one. From a performance and CPU load point of view the most important limitation in the existing driver is the lack of DMA support, thus preventing us from chaining crypto operations. I know we usually try to adapt existing drivers instead of replacing them by new ones, but after trying to refactor the mv_cesa driver I realized it would take longer than writing an new one from scratch. Here are the main features brought by this new driver: - support for armada SoCs (up to 38x) while keeping support for older ones (Orion and Kirkwood). Note that old DT bindings (those used on Orion and Kirkwood platforms) are supported, or IOTW, old DTs are compatible with this new driver. - DMA mode to offload the CPU in case of intensive crypto usage - new algorithms: SHA256, DES and 3DES I'd like to thank Arnaud, who has carefully reviewed several iterations of this driver, helped me improved my implementation, provided support for several crypto algorithms, provided support for armada-370 and tested the driver on different platforms, hence the SoB and dual MODULE_AUTHOR in the driver code. In this version I dropped the DT changes, but you'll find them in my cesa-v4 branch [1]. In this branch you'll find everything you need to test on all Marvell platforms (including the old ones). I'll post a series updating all the DTs once this driver has been merged. Best Regards, Boris [1]https://github.com/bbrezillon/linux-marvell/tree/cesa-v5 Changes since v4: - fix the dma_map_sg return code check - add import/export functions to all HMAC algos - update the passed IV when handling cipher requests - properly handle requests in the crypto queue backlog - use sg_nents_for_len Changes since v3: - add import functions for hash algorithms - patch mv_cesa driver to support the new DT bindings - few fixes in the documentation - replace mv_mbus_dram_info() call by mv_mbus_dram_info_nooverlap() - remove DT updates from the series Changes since v2: - fixes in the cipher code (-dst_nents was assigned the -src_nents value and CBC state was overwritten by the IV after each chunk operation) - spit the code as suggested by Sebastian Changes since v1: - (suggested by Jason) kept the existing CESA driver and added a mechanism to prevent the new driver from probing devices handled my the existing one (Orion and Kirkwood platforms) - (reported by Paul) addressed a few Kconfig and module definition issues - (suggested by Andrew) added DT changes to the series Arnaud Ebalard (4): crypto: marvell/CESA: add Triple-DES support crypto: marvell/CESA: add MD5 support crypto: marvell/CESA: add SHA256 support crypto: marvell/CESA: add support for Kirkwood and Dove SoCs Boris Brezillon (10): crypto: mv_cesa: document the clocks property crypto: mv_cesa: use gen_pool to reserve the SRAM memory region crypto: mv_cesa: explicitly define kirkwood and dove compatible strings crypto: add a new driver for Marvell's CESA crypto: marvell/CESA: add TDMA support crypto: marvell/CESA: add DES support crypto: marvell/CESA: add support for all armada SoCs crypto: marvell/CESA: add allhwsupport module parameter crypto: marvell/CESA: add support for Orion SoCs crypto: marvell/CESA: add DT bindings documentation .../devicetree/bindings/crypto/marvell-cesa.txt| 45 + .../devicetree/bindings/crypto/mv_cesa.txt | 31 +- drivers/crypto/Kconfig | 18 + drivers/crypto/Makefile|1 + drivers/crypto/marvell/Makefile|2 + drivers/crypto/marvell/cesa.c | 548 drivers/crypto/marvell/cesa.h | 791 +++ drivers/crypto/marvell/cipher.c| 784 +++ drivers/crypto/marvell/hash.c | 1441 drivers/crypto/marvell/tdma.c | 224 +++ drivers/crypto/mv_cesa.c | 60 +- 11 files changed, 3921 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt create mode 100644 drivers/crypto/marvell/Makefile create mode 100644 drivers/crypto/marvell/cesa.c create mode 100644 drivers/crypto/marvell/cesa.h create mode 100644 drivers/crypto/marvell/cipher.c create mode 100644 drivers/crypto/marvell/hash.c create mode 100644 drivers/crypto/marvell/tdma.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 03/14] crypto: mv_cesa: explicitly define kirkwood and dove compatible strings
We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA support on Dove and Kirkwood.
In the other hand, the migration from the old driver to the new one is not
something all people are willing to do without first auditing the new
driver.
Hence we have to support the new compatible in the mv_cesa driver so that
new platforms with updated DTs can still attach their crypto engine device
to this driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 5 -
drivers/crypto/mv_cesa.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index 13b8fc5..c0c35f0 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -1,7 +1,10 @@
Marvell Cryptographic Engines And Security Accelerator
Required properties:
-- compatible : should be marvell,orion-crypto
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
- reg: base physical address of the engine and length of memory mapped
region. Can also contain an entry for the SRAM attached to the CESA,
but this representation is deprecated and marvell,crypto-srams should
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index a4c8637..fcab963 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1034,7 +1034,7 @@ static int mv_cesa_get_sram(struct platform_device *pdev,
sram_size);
cp-sram_size = sram_size;
- cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
marvell,crypto-srams, 0);
if (cp-sram_pool) {
cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
@@ -1197,6 +1197,8 @@ static int mv_remove(struct platform_device *pdev)
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,orion-crypto, },
+ { .compatible = marvell,kirkwood-crypto, },
+ { .compatible = marvell,dove-crypto, },
{}
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 01/14] crypto: mv_cesa: document the clocks property
On Dove platforms, the crypto engine requires a clock. Document this clocks property in the mv_cesa bindings doc. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- Documentation/devicetree/bindings/crypto/mv_cesa.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt b/Documentation/devicetree/bindings/crypto/mv_cesa.txt index 47229b1..eaa2873 100644 --- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt @@ -7,6 +7,8 @@ Required properties: length - reg-names : regs , sram; - interrupts : interrupt number +- clocks: reference to the crypto engines clocks. This property is only + required for Dove platforms Examples: -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 05/14] crypto: marvell/CESA: add TDMA support
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not retrieved through DMA yet),
thus reducing the involvement of the CPU and providing better performances
in most cases (for small requests, the cost of DMA preparation might
exceed the performance gain).
Note that some CESA IPs do not embed this dedicated DMA, hence the
activation of this feature on a per platform basis.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 1 +
drivers/crypto/marvell/Makefile | 2 +-
drivers/crypto/marvell/cesa.c | 68 +++
drivers/crypto/marvell/cesa.h | 229 ++
drivers/crypto/marvell/cipher.c | 166 +++-
drivers/crypto/marvell/hash.c | 414 +++-
drivers/crypto/marvell/tdma.c | 224 ++
7 files changed, 1088 insertions(+), 16 deletions(-)
create mode 100644 drivers/crypto/marvell/tdma.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index c15c5a5..cbf2957 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -186,6 +186,7 @@ config CRYPTO_DEV_MARVELL_CESA
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Armada 370.
+ This driver supports CPU offload through DMA transfers.
This driver is aimed at replacing the mv_cesa driver. This will only
happen once it has received proper testing.
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
index 68d0982..0c12b13 100644
--- a/drivers/crypto/marvell/Makefile
+++ b/drivers/crypto/marvell/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
-marvell-cesa-objs := cesa.o cipher.o hash.o
+marvell-cesa-objs := cesa.o cipher.o hash.o tdma.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 76a6943..986f024 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -184,6 +184,7 @@ static const struct mv_cesa_caps armada_370_caps = {
.ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
.ahash_algs = armada_370_ahash_algs,
.nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
};
static const struct of_device_id mv_cesa_of_match_table[] = {
@@ -192,6 +193,66 @@ static const struct of_device_id mv_cesa_of_match_table[]
= {
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
+static void
+mv_cesa_conf_mbus_windows(struct mv_cesa_engine *engine,
+ const struct mbus_dram_target_info *dram)
+{
+ void __iomem *iobase = engine-regs;
+ int i;
+
+ for (i = 0; i 4; i++) {
+ writel(0, iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(0, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+
+ for (i = 0; i dram-num_cs; i++) {
+ const struct mbus_dram_window *cs = dram-cs + i;
+
+ writel(((cs-size - 1) 0x) |
+ (cs-mbus_attr 8) |
+ (dram-mbus_dram_target_id 4) | 1,
+ iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(cs-base, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+}
+
+static int mv_cesa_dev_dma_init(struct mv_cesa_dev *cesa)
+{
+ struct device *dev = cesa-dev;
+ struct mv_cesa_dev_dma *dma;
+
+ if (!cesa-caps-has_tdma)
+ return 0;
+
+ dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
+ if (!dma)
+ return -ENOMEM;
+
+ dma-tdma_desc_pool = dmam_pool_create(tdma_desc, dev,
+ sizeof(struct mv_cesa_tdma_desc),
+ 16, 0);
+ if (!dma-tdma_desc_pool)
+ return -ENOMEM;
+
+ dma-op_pool = dmam_pool_create(cesa_op, dev,
+ sizeof(struct mv_cesa_op_ctx), 16, 0);
+ if (!dma-op_pool)
+ return -ENOMEM;
+
+ dma-cache_pool = dmam_pool_create(cesa_cache, dev,
+ CESA_MAX_HASH_BLOCK_SIZE, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ dma-padding_pool = dmam_pool_create(cesa_padding, dev, 72, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ cesa-dma = dma;
+
+ return 0;
+}
+
static int mv_cesa_get_sram(struct platform_device *pdev, int idx)
{
struct mv_cesa_dev *cesa = platform_get_drvdata(pdev);
@@ -299,6 +360,10 @@ static int mv_cesa_probe(struct platform_device *pdev)
if (IS_ERR(cesa-regs))
return -ENOMEM
[PATCH v5 12/14] crypto: marvell/CESA: add support for Orion SoCs
Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.
Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is explicitly requested to do
so).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 42 +++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index a05b5cb..8e5ea72 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -172,6 +172,22 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
crypto_unregister_alg(cesa-caps-cipher_algs[i]);
}
+static struct crypto_alg *orion_cipher_algs[] = {
+ mv_cesa_ecb_des_alg,
+ mv_cesa_cbc_des_alg,
+ mv_cesa_ecb_des3_ede_alg,
+ mv_cesa_cbc_des3_ede_alg,
+ mv_cesa_ecb_aes_alg,
+ mv_cesa_cbc_aes_alg,
+};
+
+static struct ahash_alg *orion_ahash_algs[] = {
+ mv_md5_alg,
+ mv_sha1_alg,
+ mv_ahmac_md5_alg,
+ mv_ahmac_sha1_alg,
+};
+
static struct crypto_alg *armada_370_cipher_algs[] = {
mv_cesa_ecb_des_alg,
mv_cesa_cbc_des_alg,
@@ -190,6 +206,15 @@ static struct ahash_alg *armada_370_ahash_algs[] = {
mv_ahmac_sha256_alg,
};
+static const struct mv_cesa_caps orion_caps = {
+ .nengines = 1,
+ .cipher_algs = orion_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(orion_cipher_algs),
+ .ahash_algs = orion_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(orion_ahash_algs),
+ .has_tdma = false,
+};
+
static const struct mv_cesa_caps armada_370_caps = {
.nengines = 1,
.cipher_algs = armada_370_cipher_algs,
@@ -209,6 +234,7 @@ static const struct mv_cesa_caps armada_xp_caps = {
};
static const struct of_device_id mv_cesa_of_match_table[] = {
+ { .compatible = marvell,orion-crypto, .data = orion_caps },
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
{ .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
{ .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
@@ -334,7 +360,7 @@ static void mv_cesa_put_sram(struct platform_device *pdev,
int idx)
static int mv_cesa_probe(struct platform_device *pdev)
{
- const struct mv_cesa_caps *caps = NULL;
+ const struct mv_cesa_caps *caps = orion_caps;
const struct mbus_dram_target_info *dram;
const struct of_device_id *match;
struct device *dev = pdev-dev;
@@ -349,14 +375,16 @@ static int mv_cesa_probe(struct platform_device *pdev)
return -EEXIST;
}
- if (!dev-of_node)
- return -ENOTSUPP;
+ if (dev-of_node) {
+ match = of_match_node(mv_cesa_of_match_table, dev-of_node);
+ if (!match || !match-data)
+ return -ENOTSUPP;
- match = of_match_node(mv_cesa_of_match_table, dev-of_node);
- if (!match || !match-data)
- return -ENOTSUPP;
+ caps = match-data;
+ }
- caps = match-data;
+ if (caps == orion_caps !allhwsupport)
+ return -ENOTSUPP;
cesa = devm_kzalloc(dev, sizeof(*cesa), GFP_KERNEL);
if (!cesa)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 13/14] crypto: marvell/CESA: add support for Kirkwood and Dove SoCs
From: Arnaud Ebalard a...@natisbad.org
Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport
module parameter to avoid probing the CESA IP when the old CESA driver is
enabled (unless it is explicitly requested to do so).
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 8e5ea72..a432633 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -215,6 +215,15 @@ static const struct mv_cesa_caps orion_caps = {
.has_tdma = false,
};
+static const struct mv_cesa_caps kirkwood_caps = {
+ .nengines = 1,
+ .cipher_algs = orion_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(orion_cipher_algs),
+ .ahash_algs = orion_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(orion_ahash_algs),
+ .has_tdma = true,
+};
+
static const struct mv_cesa_caps armada_370_caps = {
.nengines = 1,
.cipher_algs = armada_370_cipher_algs,
@@ -235,6 +244,8 @@ static const struct mv_cesa_caps armada_xp_caps = {
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,orion-crypto, .data = orion_caps },
+ { .compatible = marvell,kirkwood-crypto, .data = kirkwood_caps },
+ { .compatible = marvell,dove-crypto, .data = kirkwood_caps },
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
{ .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
{ .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
@@ -383,7 +394,7 @@ static int mv_cesa_probe(struct platform_device *pdev)
caps = match-data;
}
- if (caps == orion_caps !allhwsupport)
+ if ((caps == orion_caps || caps == kirkwood_caps) !allhwsupport)
return -ENOTSUPP;
cesa = devm_kzalloc(dev, sizeof(*cesa), GFP_KERNEL);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 07/14] crypto: marvell/CESA: add Triple-DES support
From: Arnaud Ebalard a...@natisbad.org
Add support for Triple-DES operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 147
3 files changed, 151 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 212840e..c0b1b49 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -171,6 +171,8 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
static struct crypto_alg *armada_370_cipher_algs[] = {
mv_cesa_ecb_des_alg,
mv_cesa_cbc_des_alg,
+ mv_cesa_ecb_des3_ede_alg,
+ mv_cesa_cbc_des3_ede_alg,
mv_cesa_ecb_aes_alg,
mv_cesa_cbc_aes_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 2ee48fe..2e8b7fc 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -779,6 +779,8 @@ extern struct ahash_alg mv_ahmac_sha1_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
extern struct crypto_alg mv_cesa_cbc_des_alg;
+extern struct crypto_alg mv_cesa_ecb_des3_ede_alg;
+extern struct crypto_alg mv_cesa_cbc_des3_ede_alg;
extern struct crypto_alg mv_cesa_ecb_aes_alg;
extern struct crypto_alg mv_cesa_cbc_aes_alg;
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index 31b9311..e65592c 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -22,6 +22,11 @@ struct mv_cesa_des_ctx {
u8 key[DES_KEY_SIZE];
};
+struct mv_cesa_des3_ctx {
+ struct mv_cesa_ctx base;
+ u8 key[DES3_EDE_KEY_SIZE];
+};
+
struct mv_cesa_aes_ctx {
struct mv_cesa_ctx base;
struct crypto_aes_ctx aes;
@@ -261,6 +266,22 @@ static int mv_cesa_des_setkey(struct crypto_ablkcipher
*cipher, const u8 *key,
return 0;
}
+static int mv_cesa_des3_ede_setkey(struct crypto_ablkcipher *cipher,
+ const u8 *key, unsigned int len)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ if (len != DES3_EDE_KEY_SIZE) {
+ crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+
+ memcpy(ctx-key, key, DES3_EDE_KEY_SIZE);
+
+ return 0;
+}
+
static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
const struct mv_cesa_op_ctx *op_templ)
{
@@ -501,6 +522,132 @@ struct crypto_alg mv_cesa_cbc_des_alg = {
},
};
+static int mv_cesa_des3_op(struct ablkcipher_request *req,
+ struct mv_cesa_op_ctx *tmpl)
+{
+ struct mv_cesa_des3_ctx *ctx = crypto_tfm_ctx(req-base.tfm);
+ int ret;
+
+ mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTM_3DES,
+ CESA_SA_DESC_CFG_CRYPTM_MSK);
+
+ memcpy(tmpl-ctx.blkcipher.key, ctx-key, DES3_EDE_KEY_SIZE);
+
+ ret = mv_cesa_ablkcipher_req_init(req, tmpl);
+ if (ret)
+ return ret;
+
+ ret = mv_cesa_queue_req(req-base);
+ if (ret ret != -EINPROGRESS)
+ mv_cesa_ablkcipher_cleanup(req);
+
+ return ret;
+}
+
+static int mv_cesa_ecb_des3_ede_encrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_3DES_EDE |
+ CESA_SA_DESC_CFG_DIR_ENC);
+
+ return mv_cesa_des3_op(req, tmpl);
+}
+
+static int mv_cesa_ecb_des3_ede_decrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_3DES_EDE |
+ CESA_SA_DESC_CFG_DIR_DEC);
+
+ return mv_cesa_des3_op(req, tmpl);
+}
+
+struct crypto_alg mv_cesa_ecb_des3_ede_alg = {
+ .cra_name = ecb(des3_ede),
+ .cra_driver_name = mv-ecb-des3-ede,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
+ .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_des3_ctx),
+ .cra_alignmask = 0,
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = mv_cesa_ablkcipher_cra_init,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize = DES3_EDE_KEY_SIZE,
+ .max_keysize = DES3_EDE_KEY_SIZE,
+ .ivsize = DES3_EDE_BLOCK_SIZE,
+ .setkey = mv_cesa_des3_ede_setkey,
+ .encrypt
[PATCH v5 06/14] crypto: marvell/CESA: add DES support
Add support for DES operations.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 150
3 files changed, 154 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 986f024..212840e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -169,6 +169,8 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
}
static struct crypto_alg *armada_370_cipher_algs[] = {
+ mv_cesa_ecb_des_alg,
+ mv_cesa_cbc_des_alg,
mv_cesa_ecb_aes_alg,
mv_cesa_cbc_aes_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 1a48323..2ee48fe 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -777,6 +777,8 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
extern struct ahash_alg mv_sha1_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
+extern struct crypto_alg mv_cesa_ecb_des_alg;
+extern struct crypto_alg mv_cesa_cbc_des_alg;
extern struct crypto_alg mv_cesa_ecb_aes_alg;
extern struct crypto_alg mv_cesa_cbc_aes_alg;
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index 233f5bf..31b9311 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -13,9 +13,15 @@
*/
#include crypto/aes.h
+#include crypto/des.h
#include cesa.h
+struct mv_cesa_des_ctx {
+ struct mv_cesa_ctx base;
+ u8 key[DES_KEY_SIZE];
+};
+
struct mv_cesa_aes_ctx {
struct mv_cesa_ctx base;
struct crypto_aes_ctx aes;
@@ -231,6 +237,30 @@ static int mv_cesa_aes_setkey(struct crypto_ablkcipher
*cipher, const u8 *key,
return 0;
}
+static int mv_cesa_des_setkey(struct crypto_ablkcipher *cipher, const u8 *key,
+ unsigned int len)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 tmp[DES_EXPKEY_WORDS];
+ int ret;
+
+ if (len != DES_KEY_SIZE) {
+ crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+
+ ret = des_ekey(tmp, key);
+ if (!ret (tfm-crt_flags CRYPTO_TFM_REQ_WEAK_KEY)) {
+ tfm-crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
+ return -EINVAL;
+ }
+
+ memcpy(ctx-key, key, DES_KEY_SIZE);
+
+ return 0;
+}
+
static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
const struct mv_cesa_op_ctx *op_templ)
{
@@ -351,6 +381,126 @@ static int mv_cesa_ablkcipher_req_init(struct
ablkcipher_request *req,
return ret;
}
+static int mv_cesa_des_op(struct ablkcipher_request *req,
+ struct mv_cesa_op_ctx *tmpl)
+{
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(req-base.tfm);
+ int ret;
+
+ mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTM_DES,
+ CESA_SA_DESC_CFG_CRYPTM_MSK);
+
+ memcpy(tmpl-ctx.blkcipher.key, ctx-key, DES_KEY_SIZE);
+
+ ret = mv_cesa_ablkcipher_req_init(req, tmpl);
+ if (ret)
+ return ret;
+
+ ret = mv_cesa_queue_req(req-base);
+ if (ret ret != -EINPROGRESS)
+ mv_cesa_ablkcipher_cleanup(req);
+
+ return ret;
+}
+
+static int mv_cesa_ecb_des_encrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_DIR_ENC);
+
+ return mv_cesa_des_op(req, tmpl);
+}
+
+static int mv_cesa_ecb_des_decrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_DIR_DEC);
+
+ return mv_cesa_des_op(req, tmpl);
+}
+
+struct crypto_alg mv_cesa_ecb_des_alg = {
+ .cra_name = ecb(des),
+ .cra_driver_name = mv-ecb-des,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
+ .cra_blocksize = DES_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_des_ctx),
+ .cra_alignmask = 0,
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = mv_cesa_ablkcipher_cra_init,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize = DES_KEY_SIZE,
+ .max_keysize = DES_KEY_SIZE,
+ .setkey = mv_cesa_des_setkey,
+ .encrypt = mv_cesa_ecb_des_encrypt,
+ .decrypt
[PATCH v5 08/14] crypto: marvell/CESA: add MD5 support
From: Arnaud Ebalard a...@natisbad.org
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 172 +-
3 files changed, 174 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index c0b1b49..047c1c0 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -178,7 +178,9 @@ static struct crypto_alg *armada_370_cipher_algs[] = {
};
static struct ahash_alg *armada_370_ahash_algs[] = {
+ mv_md5_alg,
mv_sha1_alg,
+ mv_ahmac_md5_alg,
mv_ahmac_sha1_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 2e8b7fc..2a7e21a 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -774,7 +774,9 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
/* Algorithm definitions */
+extern struct ahash_alg mv_md5_alg;
extern struct ahash_alg mv_sha1_alg;
+extern struct ahash_alg mv_ahmac_md5_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 299106f..d8555c5 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -12,6 +12,7 @@
* by the Free Software Foundation.
*/
+#include crypto/md5.h
#include crypto/sha.h
#include cesa.h
@@ -346,8 +347,16 @@ static int mv_cesa_ahash_process(struct
crypto_async_request *req, u32 status)
ahashreq-nbytes - creq-cache_ptr);
if (creq-last_req) {
- for (i = 0; i digsize / 4; i++)
- creq-state[i] = cpu_to_be32(creq-state[i]);
+ for (i = 0; i digsize / 4; i++) {
+ /*
+* Hardware provides MD5 digest in a different
+* endianness than SHA-1 and SHA-256 ones.
+*/
+ if (digsize == MD5_DIGEST_SIZE)
+ creq-state[i] = cpu_to_le32(creq-state[i]);
+ else
+ creq-state[i] = cpu_to_be32(creq-state[i]);
+ }
memcpy(ahashreq-result, creq-state, digsize);
}
@@ -788,6 +797,95 @@ static int mv_cesa_ahash_finup(struct ahash_request *req)
return ret;
}
+static int mv_cesa_md5_init(struct ahash_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl, CESA_SA_DESC_CFG_MACM_MD5);
+
+ mv_cesa_ahash_init(req, tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_md5_export(struct ahash_request *req, void *out)
+{
+ struct md5_state *out_state = out;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+
+ out_state-byte_count = creq-len;
+ memcpy(out_state-hash, creq-state, digsize);
+ memset(out_state-block, 0, sizeof(out_state-block));
+ if (creq-cache)
+ memcpy(out_state-block, creq-cache, creq-cache_ptr);
+
+ return 0;
+}
+
+static int mv_cesa_md5_import(struct ahash_request *req, const void *in)
+{
+ const struct md5_state *in_state = in;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+ unsigned int cache_ptr;
+ int ret;
+
+ creq-len = in_state-byte_count;
+ memcpy(creq-state, in_state-hash, digsize);
+ creq-cache_ptr = 0;
+
+ cache_ptr = creq-len % sizeof(in_state-block);
+ if (!cache_ptr)
+ return 0;
+
+ ret = mv_cesa_ahash_alloc_cache(req);
+ if (ret)
+ return ret;
+
+ memcpy(creq-cache, in_state-block, cache_ptr);
+ creq-cache_ptr = cache_ptr;
+
+ return 0;
+}
+
+static int mv_cesa_md5_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_md5_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+struct ahash_alg mv_md5_alg = {
+ .init = mv_cesa_md5_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_md5_digest,
+ .export = mv_cesa_md5_export,
+ .import = mv_cesa_md5_import,
+ .halg = {
+ .digestsize = MD5_DIGEST_SIZE,
+ .base = {
+ .cra_name = md5,
+ .cra_driver_name = mv-md5,
+ .cra_priority = 300
Re: [RESEND PATCH v4 04/14] crypto: add a new driver for Marvell's CESA
On Mon, 15 Jun 2015 17:59:44 +0800
Herbert Xu herb...@gondor.apana.org.au wrote:
On Fri, Jun 12, 2015 at 09:15:56AM +0200, Boris Brezillon wrote:
+struct ahash_alg mv_ahmac_sha1_alg = {
+ .init = mv_cesa_ahmac_sha1_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_ahmac_sha1_digest,
+ .setkey = mv_cesa_ahmac_sha1_setkey,
Please add import/export functions for hmac too.
Oh, that's an oversight. I'll fix that too.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v4 04/14] crypto: add a new driver for Marvell's CESA
On Mon, 15 Jun 2015 17:37:54 +0800
Herbert Xu herb...@gondor.apana.org.au wrote:
On Fri, Jun 12, 2015 at 09:15:56AM +0200, Boris Brezillon wrote:
+static inline int mv_cesa_sg_count(struct scatterlist *sg, int nbytes)
+{
+ int nents = 0;
+
+ while (nbytes 0) {
+ nents++;
+ nbytes -= sg-length;
+ sg = sg_next(sg);
+ }
+
+ return nents;
+}
Please replace this with the newly added sg_nents_for_len.
Sure, I'll use the sg_nents_for_len function.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v4 04/14] crypto: add a new driver for Marvell's CESA
On Mon, 15 Jun 2015 17:48:27 +0800
Herbert Xu herb...@gondor.apana.org.au wrote:
On Fri, Jun 12, 2015 at 09:15:56AM +0200, Boris Brezillon wrote:
+static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine)
+{
+ struct crypto_async_request *req;
+ struct mv_cesa_ctx *ctx;
+
+ spin_lock_bh(cesa_dev-lock);
+ req = crypto_dequeue_request(cesa_dev-queue);
Need to call crypto_get_backlog before this so you can do the
backlog notification afterwards.
Oh right.
I still have trouble understanding the need for the backlog concept
(maybe you can give some insight): the backlog is just another list
where we put all the requests when the queue has exceeded the limit
fixed in crypto_queue_init, but the result is pretty much the same, the
request stored in the backlog will be handled at some point, so what's
the real point of this backlog.
Anyway, this question was just for my own understanding of this thing:
I'll fix the code to notify users that their request is in progress.
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v4 05/14] crypto: marvell/CESA: add TDMA support
Hi Herbert, On Mon, 15 Jun 2015 18:09:20 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Fri, Jun 12, 2015 at 09:15:57AM +0200, Boris Brezillon wrote: + ret = dma_map_sg(cesa_dev-dev, req-src, creq-src_nents, +DMA_TO_DEVICE); + if (ret 0) This function returns zero on error, not negative. See Documentation/DMA-API-HOWTO.txt for details. Yep, I'll fix that. Thanks for pointing this out. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v4 04/14] crypto: add a new driver for Marvell's CESA
On Mon, 15 Jun 2015 17:54:21 +0800
Herbert Xu herb...@gondor.apana.org.au wrote:
On Fri, Jun 12, 2015 at 09:15:56AM +0200, Boris Brezillon wrote:
+static int mv_cesa_cbc_aes_op(struct ablkcipher_request *req,
+ struct mv_cesa_op_ctx *tmpl)
+{
+ mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTCM_CBC,
+ CESA_SA_DESC_CFG_CRYPTCM_MSK);
+ memcpy(tmpl-ctx.blkcipher.iv, req-info, 16);
You need to copy the IV back into req-info after completion.
I haven't found any driver updating the req-info field with the new
IV. Could you point me to one of them.
Incidentally we don't seem to test for output IVs in our self-
test so bugs like this can slip through until someone tries to
do chaining with it. That's something worth adding to testmgr.
Yes, that makes sense, but since a lot a drivers (if not all of them)
are not updating this field we'll break them when adding this test
unless we make it optional (with a new flag ?).
Do you have any suggestion to address this problem ?
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next 2/2] mfd: flexcom: add a driver for Atmel Flexible Serial Communication Unit
On Mon, 15 Jun 2015 18:38:05 +0200
Cyrille Pitchen cyrille.pitc...@atmel.com wrote:
This driver supports the new Atmel Flexcom. The Flexcom is a wrapper which
integrates one SPI controller, one I2C controller and one USART. Only one
function can be enabled at a time. This driver selects the function once
for all, when the Flexcom is probed, according to the value of the new
atmel,flexcom-mode device tree property.
This driver has chosen to present the Flexcom to the system as a MFD so
the implementation is seamless for the existing Atmel SPI, I2C and USART
drivers.
Also the Flexcom embeds FIFOs: the latest patches of the SPI, I2C and
USART drivers take advantage of this new feature.
Signed-off-by: Cyrille Pitchen cyrille.pitc...@atmel.com
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile| 1 +
drivers/mfd/atmel-flexcom.c | 97
+
3 files changed, 109 insertions(+)
create mode 100644 drivers/mfd/atmel-flexcom.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index aefbbbf..4aebf08 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -60,6 +60,17 @@ config MFD_AAT2870_CORE
additional drivers must be enabled in order to use the
functionality of the device.
+config MFD_ATMEL_FLEXCOM
+ tristate Atmel Flexcom (Flexible Serial Communication Unit)
+ select MFD_CORE
+ depends on OF
+ help
+ Select this to get support for Atmel Flexcom. This is a wrapper
+ which embeds a SPI controller, a I2C controller and a USART. Only
+ one function can be used at a time. The choice is done at boot time
+ by the probe function of this MFD driver according to a device tree
+ property.
+
config MFD_ATMEL_HLCDC
tristate Atmel HLCDC (High-end LCD Controller)
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index ea40e07..0705eb2 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_MFD_SPMI_PMIC) += qcom-spmi-pmic.o
obj-$(CONFIG_TPS65911_COMPARATOR)+= tps65911-comparator.o
obj-$(CONFIG_MFD_TPS65090) += tps65090.o
obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_MFD_ATMEL_FLEXCOM) += atmel-flexcom.o
obj-$(CONFIG_MFD_ATMEL_HLCDC)+= atmel-hlcdc.o
obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
obj-$(CONFIG_MFD_PALMAS) += palmas.o
diff --git a/drivers/mfd/atmel-flexcom.c b/drivers/mfd/atmel-flexcom.c
new file mode 100644
index 000..14c35e6
--- /dev/null
+++ b/drivers/mfd/atmel-flexcom.c
@@ -0,0 +1,97 @@
+/*
+ * Driver for Atmel Flexcom
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Cyrille Pitchen cyrille.pitc...@atmel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/err.h
+#include linux/io.h
+#include linux/clk.h
+
+#define FX_MR0x0
+#define FX_RHR 0x10
+#define FX_THR 0x20
+#define FX_VERSION 0xfc
+
+#define FX_MR_NO_COM 0
+#define FX_MR_USART 1
+#define FX_MR_SPI2
+#define FX_MR_TWI3
+
+
+static int atmel_flexcom_probe(struct platform_device *pdev)
+{
+ struct clk *clk;
+ struct resource *res;
+ unsigned char __iomem *map;
+ unsigned int version, mr;
+ const char *mode;
+ int err;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ map = devm_ioremap_resource(pdev-dev, res);
If you take the approach I suggested in the DT binding review,
you shouldn't reserve the whole memory region, just the flexcom
part(0x0 to 0x200).
+ if (IS_ERR(map))
+ return PTR_ERR(map);
+
+ clk = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ err = of_property_read_string(pdev-dev.of_node,
+ atmel,flexcom-mode, mode);
+ if (err)
+ return err;
+
+ if (!strcmp(mode, usart))
+ mr = FX_MR_USART;
+ else if (!strcmp(mode, spi))
+ mr = FX_MR_SPI;
+ else if (!strcmp(mode, twi) || !strcmp(mode, i2c))
+ mr = FX_MR_TWI;
+ else
+ return -EINVAL;
+
+ clk_prepare_enable(clk);
+ version = __raw_readl(map + FX_VERSION);
+ __raw_writel(mr, map + FX_MR);
+ clk_disable_unprepare(clk);
Is there a good reason to use the __raw versions of the writel/readl
functions ?
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: [PATCH linux-next 1/2] mfd: devicetree: add bindings for Atmel Flexcom
Hi Cyrille,
On Mon, 15 Jun 2015 18:38:04 +0200
Cyrille Pitchen cyrille.pitc...@atmel.com wrote:
Signed-off-by: Cyrille Pitchen cyrille.pitc...@atmel.com
---
.../devicetree/bindings/mfd/atmel-flexcom.txt | 28
++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
new file mode 100644
index 000..6b1a32e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
@@ -0,0 +1,28 @@
+* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit)
+
+The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
+controller and an USART. Only one function can be used at a time and is
chosen
+at boot time according to the device tree.
+
+Required properties:
+- compatible: atmel,sama5d2-flexcom
+- reg: shall be the offset/length value for Flexcom dedicated I/O registers
+ (without USART, TWI or SPI registers).
+- clocks: shall be the Flexcom peripheral clock from PMC.
+- #address-cells: should be 1
+- #size-cells: should be 1
+- ranges: must be present
+- atmel,flexcom-mode: shall be a string among { spi, usart, i2c, twi
}.
+ i2c and twi are synonymous.
+
+Example:
+
+flx0: flexcom@f8034000 {
+ compatible = atmel,sama5d2-flexcom;
+ reg = 0xf8034000 0x200;
+ clocks = flx0_clk;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ atmel,flexcom-mode = spi;
+};
Since the subdevices are using a set of registers contained by the
flexcom device I would define it like this:
flx0: flexcom@f8034000 {
compatible = atmel,sama5d2-flexcom;
reg = 0xf8034000 0x800;
clocks = flx0_clk;
#address-cells = 1;
#size-cells = 1;
ranges = 0x0 0xf8034000 0x800;
atmel,flexcom-mode = spi;
usart@200 {
reg = 0x200 0x100;
/* ... */
};
spi@400 {
reg = 0x400 0x100;
/* ... */
};
i2c@600 {
reg = 0x600 0x100;
/* ... */
};
};
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v4 02/14] crypto: mv_cesa: use gen_pool to reserve the SRAM memory region
The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.
This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine
The last point is particularly annoying in some cases: for example on
armada 370, a small region of the crypto SRAM is used to implement the
cpuidle, which means you would not be able to enable both cpuidle and the
CESA driver.
To address that problem, we explicitly define the SRAM device in the DT
and then reference the sram node from the crypto engine node.
Also note that the old way of retrieving the SRAM memory region is still
supported, or in other words, backward compatibility is preserved.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/mv_cesa.txt | 24 ++---
drivers/crypto/Kconfig | 1 +
drivers/crypto/mv_cesa.c | 58 --
3 files changed, 60 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index eaa2873..13b8fc5 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -2,21 +2,29 @@ Marvell Cryptographic Engines And Security Accelerator
Required properties:
- compatible : should be marvell,orion-crypto
-- reg : base physical address of the engine and length of memory mapped
-region, followed by base physical address of sram and its memory
-length
-- reg-names : regs , sram;
-- interrupts : interrupt number
+- reg: base physical address of the engine and length of memory mapped
+ region. Can also contain an entry for the SRAM attached to the CESA,
+ but this representation is deprecated and marvell,crypto-srams should
+ be used instead
+- reg-names: regs. Can contain an sram entry, but this representation
+is deprecated and marvell,crypto-srams should be used instead
+- interrupts: interrupt number
- clocks: reference to the crypto engines clocks. This property is only
required for Dove platforms
+- marvell,crypto-srams: phandle to crypto SRAM definitions
+
+Optional properties:
+- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
+ specified the whole SRAM is used (2KB)
Examples:
crypto@3 {
compatible = marvell,orion-crypto;
- reg = 0x3 0x1,
- 0x400 0x800;
- reg-names = regs , sram;
+ reg = 0x3 0x1;
+ reg-names = regs;
interrupts = 22;
+ marvell,crypto-srams = crypto_sram;
+ marvell,crypto-sram-size = 0x600;
status = okay;
};
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 033c0c8..a6bbea8 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -166,6 +166,7 @@ config CRYPTO_DEV_MV_CESA
select CRYPTO_AES
select CRYPTO_BLKCIPHER2
select CRYPTO_HASH
+ select SRAM
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Marvell Orion
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 27b2373..a4c8637 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -9,6 +9,7 @@
#include crypto/aes.h
#include crypto/algapi.h
#include linux/crypto.h
+#include linux/genalloc.h
#include linux/interrupt.h
#include linux/io.h
#include linux/kthread.h
@@ -29,6 +30,8 @@
#define MAX_HW_HASH_SIZE 0x
#define MV_CESA_EXPIRE 500 /* msec */
+#define MV_CESA_DEFAULT_SRAM_SIZE 2048
+
/*
* STM:
* /---\
@@ -83,6 +86,8 @@ struct req_progress {
struct crypto_priv {
void __iomem *reg;
void __iomem *sram;
+ struct gen_pool *sram_pool;
+ dma_addr_t sram_dma;
int irq;
struct clk *clk;
struct task_struct *queue_th;
@@ -1019,6 +1024,39 @@ static struct ahash_alg mv_hmac_sha1_alg = {
}
};
+static int mv_cesa_get_sram(struct platform_device *pdev,
+ struct crypto_priv *cp)
+{
+ struct resource *res;
+ u32 sram_size = MV_CESA_DEFAULT_SRAM_SIZE;
+
+ of_property_read_u32(pdev-dev.of_node, marvell,crypto-sram-size,
+sram_size);
+
+ cp-sram_size = sram_size;
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ marvell,crypto-srams, 0);
+ if (cp-sram_pool) {
+ cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
+ cp-sram_dma);
+ if (cp-sram
[RESEND PATCH v4 05/14] crypto: marvell/CESA: add TDMA support
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not retrieved through DMA yet),
thus reducing the involvement of the CPU and providing better performances
in most cases (for small requests, the cost of DMA preparation might
exceed the performance gain).
Note that some CESA IPs do not embed this dedicated DMA, hence the
activation of this feature on a per platform basis.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 1 +
drivers/crypto/marvell/Makefile | 2 +-
drivers/crypto/marvell/cesa.c | 68 +++
drivers/crypto/marvell/cesa.h | 229 ++
drivers/crypto/marvell/cipher.c | 167 +++-
drivers/crypto/marvell/hash.c | 412 +++-
drivers/crypto/marvell/tdma.c | 224 ++
7 files changed, 1087 insertions(+), 16 deletions(-)
create mode 100644 drivers/crypto/marvell/tdma.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index c15c5a5..cbf2957 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -186,6 +186,7 @@ config CRYPTO_DEV_MARVELL_CESA
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Armada 370.
+ This driver supports CPU offload through DMA transfers.
This driver is aimed at replacing the mv_cesa driver. This will only
happen once it has received proper testing.
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
index 68d0982..0c12b13 100644
--- a/drivers/crypto/marvell/Makefile
+++ b/drivers/crypto/marvell/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
-marvell-cesa-objs := cesa.o cipher.o hash.o
+marvell-cesa-objs := cesa.o cipher.o hash.o tdma.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 8d90e28..5a226c4 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -180,6 +180,7 @@ static const struct mv_cesa_caps armada_370_caps = {
.ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
.ahash_algs = armada_370_ahash_algs,
.nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
};
static const struct of_device_id mv_cesa_of_match_table[] = {
@@ -188,6 +189,66 @@ static const struct of_device_id mv_cesa_of_match_table[]
= {
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
+static void
+mv_cesa_conf_mbus_windows(struct mv_cesa_engine *engine,
+ const struct mbus_dram_target_info *dram)
+{
+ void __iomem *iobase = engine-regs;
+ int i;
+
+ for (i = 0; i 4; i++) {
+ writel(0, iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(0, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+
+ for (i = 0; i dram-num_cs; i++) {
+ const struct mbus_dram_window *cs = dram-cs + i;
+
+ writel(((cs-size - 1) 0x) |
+ (cs-mbus_attr 8) |
+ (dram-mbus_dram_target_id 4) | 1,
+ iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(cs-base, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+}
+
+static int mv_cesa_dev_dma_init(struct mv_cesa_dev *cesa)
+{
+ struct device *dev = cesa-dev;
+ struct mv_cesa_dev_dma *dma;
+
+ if (!cesa-caps-has_tdma)
+ return 0;
+
+ dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
+ if (!dma)
+ return -ENOMEM;
+
+ dma-tdma_desc_pool = dmam_pool_create(tdma_desc, dev,
+ sizeof(struct mv_cesa_tdma_desc),
+ 16, 0);
+ if (!dma-tdma_desc_pool)
+ return -ENOMEM;
+
+ dma-op_pool = dmam_pool_create(cesa_op, dev,
+ sizeof(struct mv_cesa_op_ctx), 16, 0);
+ if (!dma-op_pool)
+ return -ENOMEM;
+
+ dma-cache_pool = dmam_pool_create(cesa_cache, dev,
+ CESA_MAX_HASH_BLOCK_SIZE, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ dma-padding_pool = dmam_pool_create(cesa_padding, dev, 72, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ cesa-dma = dma;
+
+ return 0;
+}
+
static int mv_cesa_get_sram(struct platform_device *pdev, int idx)
{
struct mv_cesa_dev *cesa = platform_get_drvdata(pdev);
@@ -295,6 +356,10 @@ static int mv_cesa_probe(struct platform_device *pdev)
if (IS_ERR(cesa-regs))
return -ENOMEM
[RESEND PATCH v4 03/14] crypto: mv_cesa: explicitly define kirkwood and dove compatible strings
We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA support on Dove and Kirkwood.
In the other hand, the migration from the old driver to the new one is not
something all people are willing to do without first auditing the new
driver.
Hence we have to support the new compatible in the mv_cesa driver so that
new platforms with updated DTs can still attach their crypto engine device
to this driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 5 -
drivers/crypto/mv_cesa.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index 13b8fc5..c0c35f0 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -1,7 +1,10 @@
Marvell Cryptographic Engines And Security Accelerator
Required properties:
-- compatible : should be marvell,orion-crypto
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
- reg: base physical address of the engine and length of memory mapped
region. Can also contain an entry for the SRAM attached to the CESA,
but this representation is deprecated and marvell,crypto-srams should
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index a4c8637..fcab963 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1034,7 +1034,7 @@ static int mv_cesa_get_sram(struct platform_device *pdev,
sram_size);
cp-sram_size = sram_size;
- cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
marvell,crypto-srams, 0);
if (cp-sram_pool) {
cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
@@ -1197,6 +1197,8 @@ static int mv_remove(struct platform_device *pdev)
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,orion-crypto, },
+ { .compatible = marvell,kirkwood-crypto, },
+ { .compatible = marvell,dove-crypto, },
{}
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
