Hi Herbert,
[...]
> > > I can do that. I wonder if we can't agree to nuke the in-tree driver
> > > altogether instead and replace it by this one though. Does it not sound
> > > more reasonable?
> >
> > Bump?
>
> Well as it's been months and nobody has stepped up to maintain
> the in-tree driver
On Sun, Nov 10, 2013 at 06:48:11PM +0100, Marek Vasut wrote:
> Hi,
>
> > Hello Herbert,
> >
> > > On Mon, Oct 07, 2013 at 05:48:26PM +0200, Marek Vasut wrote:
> > > > Hello Christoph,
> > > >
> > > > > Hello Marek,
> > > > >
> > > > > > Marek Vasut hat am 28. September 2013 um 05:35
> > > > >
Hi,
> Hello Herbert,
>
> > On Mon, Oct 07, 2013 at 05:48:26PM +0200, Marek Vasut wrote:
> > > Hello Christoph,
> > >
> > > > Hello Marek,
> > > >
> > > > > Marek Vasut hat am 28. September 2013 um 05:35
> > > > > geschrieben: [...]
> > > > >
> > > > > > > 3) What are those ugly new IOCTLs in
Hello Herbert,
> On Mon, Oct 07, 2013 at 05:48:26PM +0200, Marek Vasut wrote:
> > Hello Christoph,
> >
> > > Hello Marek,
> > >
> > > > Marek Vasut hat am 28. September 2013 um 05:35
> > > > geschrieben: [...]
> > > >
> > > > > > 3) What are those ugly new IOCTLs in the dcp.c driver?
> > > > >
On Mon, Oct 07, 2013 at 05:48:26PM +0200, Marek Vasut wrote:
> Hello Christoph,
>
> > Hello Marek,
> >
> > > Marek Vasut hat am 28. September 2013 um 05:35
> > > geschrieben:
> > > [...]
> > >
> > > > > 3) What are those ugly new IOCTLs in the dcp.c driver?
> > > >
> > > > When I firstly poste
Hello Christoph,
> Hello Marek,
>
> > Marek Vasut hat am 28. September 2013 um 05:35 geschrieben:
> > [...]
> >
> > > > 3) What are those ugly new IOCTLs in the dcp.c driver?
> > >
> > > When I firstly posted the driver in the mailinglist, there where one
> > > person who actually used this int
Hello Marek,
> Marek Vasut hat am 28. September 2013 um 05:35 geschrieben:
> [...]
> > > 3) What are those ugly new IOCTLs in the dcp.c driver?
> >
> > When I firstly posted the driver in the mailinglist, there where one
> > person who actually used this interface (it was introduced in
> > Frees
Dear Fabio Estevam,
[...]
> > + * There can even be only one instance of the MXS DCP due to the
> > + * design of Linux Crypto API.
>
> Is this true? Usually we don't want to create a global struct.
Yeah, unfortunatelly :-(
>
> > +
> > +/* AES 128 ECB and AES 128 CBC */
> > +static struct cry
Dear Lothar Waßmann,
> Hi,
>
> Marek Vasut writes:
> > Dear Lothar Waßmann,
> >
> > > Hi Marek,
> > >
> > > some small comments below.
> > >
> > > Marek Vasut writes:
> > > > diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
> > > > new file mode 100644
> > > > index 000..c2
Hi Tobias,
> Hi,
>
> Here are some thoughts of the design decisions I made when I wrote
> the dcp.c driver. Maybe it helps.
Was the driver not rather forward-ported from some old FSL BSP kernel?
> On 2013-09-26 14:07, Marek Vasut wrote:
> > Dear Fabio Estevam,
> >
> >> Hi Marek,
> >>
> >> Why
Hi,
Here are some thoughts of the design decisions I made when I wrote
the dcp.c driver. Maybe it helps.
On 2013-09-26 14:07, Marek Vasut wrote:
Dear Fabio Estevam,
Hi Marek,
Why do we need to have two drivers for the same IP block? It looks
confusing to have both.
Sure, I agree. I reviewe
Hi,
Marek Vasut writes:
> Dear Lothar Waßmann,
>
> > Hi Marek,
> >
> > some small comments below.
> >
> > Marek Vasut writes:
> > > diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
> > > new file mode 100644
> > > index 000..c2b35c7
> > > --- /dev/null
> > > +++ b/drivers/cr
Dear Lothar Waßmann,
> Hi Marek,
>
> some small comments below.
>
> Marek Vasut writes:
> > diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
> > new file mode 100644
> > index 000..c2b35c7
> > --- /dev/null
> > +++ b/drivers/crypto/mxs-dcp.c
>
> [...]
>
> > +/* AES 128 ECB
Dear Veli-Pekka Peltola,
> Hi Marek,
>
> > + To compile this driver as a module, choose M here: the module
> > + will be called atmel-sha.
>
> This is probably wrong?
Certainly. Nice to have you back btw. ;-)
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the
On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut wrote:
> +config CRYPTO_DEV_MXS_DCP
> + tristate "Support for Freescale MXS DCP"
> + depends on ARCH_MXS
> + select CRYPTO_SHA1
> + select CRYPTO_SHA256
> + select CRYPTO_CBC
> + select CRYPTO_ECB
> + select CR
Hi Marek,
> + To compile this driver as a module, choose M here: the module
> + will be called atmel-sha.
This is probably wrong?
--
Veli-Pekka Peltola
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
Hi Marek,
some small comments below.
Marek Vasut writes:
> diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
> new file mode 100644
> index 000..c2b35c7
> --- /dev/null
> +++ b/drivers/crypto/mxs-dcp.c
[...]
> +/* AES 128 ECB and AES 128 CBC */
> +static struct crypto_alg dcp_a
Dear Fabio Estevam,
> Hi Marek,
>
> On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut wrote:
> > Add support for the MXS DCP block. The driver currently supports
> > SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard
> > CRC32 is not yet supported.
> >
> > Signed-off-by: Marek Vasut
Hi Marek,
On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut wrote:
> Add support for the MXS DCP block. The driver currently supports
> SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard
> CRC32 is not yet supported.
>
> Signed-off-by: Marek Vasut
> Cc: Herbert Xu
> Cc: David S. Mille
Add support for the MXS DCP block. The driver currently supports
SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard
CRC32 is not yet supported.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: David S. Miller
---
drivers/crypto/Kconfig | 17 +
drivers/crypto/Makefile |1 +
20 matches
Mail list logo
