On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
>
> > + }
> > +#endif
> > +
> > +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
> > + err = crypto_register_shash(&sunxi_md5_alg);
>
> Do not use shash for such device. This is clearly and ahash (and async in
> general) device. The rule of a thumb here is that you use sync algos only for
> devices which have dedicated instructions for computing the transformation. For
> devices which are attached to some kind of bus, you use async algos (ahash etc).
I'm sorry that I didn't catch this earlier but there is no such
rule.
Unless you need the async interface you should stick to the sync
interfaces for the sake of simplicity.
We have a number of existing drivers that are synchronous but
using the async interface. They should either be converted
over to the sync interface or made interrupt-driven if possible.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wednesday, July 23, 2014 at 03:57:35 PM, Herbert Xu wrote:
> On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
> > > + }
> > > +#endif
> > > +
> > > +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
> > > + err = crypto_register_shash(&sunxi_md5_alg);
> >
> > Do not use shash for such device. This is clearly and ahash (and async in
> > general) device. The rule of a thumb here is that you use sync algos only
> > for devices which have dedicated instructions for computing the
> > transformation. For devices which are attached to some kind of bus, you
> > use async algos (ahash etc).
>
> I'm sorry that I didn't catch this earlier but there is no such
> rule.
>
> Unless you need the async interface you should stick to the sync
> interfaces for the sake of simplicity.
>
> We have a number of existing drivers that are synchronous but
> using the async interface. They should either be converted
> over to the sync interface or made interrupt-driven if possible.
Sure, but this device is interrupt driven and uses DMA to feed the crypto
engine, therefore async, right ?
Best regards,
Marek Vasut
On Wed, Jul 23, 2014 at 04:07:20PM +0200, Marek Vasut wrote:
> On Wednesday, July 23, 2014 at 03:57:35 PM, Herbert Xu wrote:
> > On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
> > > > + }
> > > > +#endif
> > > > +
> > > > +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
> > > > + err = crypto_register_shash(&sunxi_md5_alg);
> > >
> > > Do not use shash for such device. This is clearly and ahash (and async in
> > > general) device. The rule of a thumb here is that you use sync algos only
> > > for devices which have dedicated instructions for computing the
> > > transformation. For devices which are attached to some kind of bus, you
> > > use async algos (ahash etc).
> >
> > I'm sorry that I didn't catch this earlier but there is no such
> > rule.
> >
> > Unless you need the async interface you should stick to the sync
> > interfaces for the sake of simplicity.
> >
> > We have a number of existing drivers that are synchronous but
> > using the async interface. They should either be converted
> > over to the sync interface or made interrupt-driven if possible.
>
> Sure, but this device is interrupt driven and uses DMA to feed the crypto
> engine, therefore async, right ?
If it's interrupt-driven, then yes it would certainly make sense to
be async. But all I see is polling in the latest posting, was the
first version different?
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wednesday, July 23, 2014 at 04:13:09 PM, Herbert Xu wrote:
> On Wed, Jul 23, 2014 at 04:07:20PM +0200, Marek Vasut wrote:
> > On Wednesday, July 23, 2014 at 03:57:35 PM, Herbert Xu wrote:
> > > On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
> > > > > + }
> > > > > +#endif
> > > > > +
> > > > > +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
> > > > > + err = crypto_register_shash(&sunxi_md5_alg);
> > > >
> > > > Do not use shash for such device. This is clearly and ahash (and
> > > > async in general) device. The rule of a thumb here is that you use
> > > > sync algos only for devices which have dedicated instructions for
> > > > computing the transformation. For devices which are attached to some
> > > > kind of bus, you use async algos (ahash etc).
> > >
> > > I'm sorry that I didn't catch this earlier but there is no such
> > > rule.
> > >
> > > Unless you need the async interface you should stick to the sync
> > > interfaces for the sake of simplicity.
> > >
> > > We have a number of existing drivers that are synchronous but
> > > using the async interface. They should either be converted
> > > over to the sync interface or made interrupt-driven if possible.
> >
> > Sure, but this device is interrupt driven and uses DMA to feed the crypto
> > engine, therefore async, right ?
>
> If it's interrupt-driven, then yes it would certainly make sense to
> be async. But all I see is polling in the latest posting, was the
> first version different?
I stand corrected then, sorry.
Is it possible to use DMA to feed the crypto accelerator, Corentin?
Best regards,
Marek Vasut
Le 23/07/2014 17:51, Marek Vasut a ?crit :
> On Wednesday, July 23, 2014 at 04:13:09 PM, Herbert Xu wrote:
>> On Wed, Jul 23, 2014 at 04:07:20PM +0200, Marek Vasut wrote:
>>> On Wednesday, July 23, 2014 at 03:57:35 PM, Herbert Xu wrote:
>>>> On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
>>>>>> + }
>>>>>> +#endif
>>>>>> +
>>>>>> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
>>>>>> + err = crypto_register_shash(&sunxi_md5_alg);
>>>>>
>>>>> Do not use shash for such device. This is clearly and ahash (and
>>>>> async in general) device. The rule of a thumb here is that you use
>>>>> sync algos only for devices which have dedicated instructions for
>>>>> computing the transformation. For devices which are attached to some
>>>>> kind of bus, you use async algos (ahash etc).
>>>>
>>>> I'm sorry that I didn't catch this earlier but there is no such
>>>> rule.
>>>>
>>>> Unless you need the async interface you should stick to the sync
>>>> interfaces for the sake of simplicity.
>>>>
>>>> We have a number of existing drivers that are synchronous but
>>>> using the async interface. They should either be converted
>>>> over to the sync interface or made interrupt-driven if possible.
>>>
>>> Sure, but this device is interrupt driven and uses DMA to feed the crypto
>>> engine, therefore async, right ?
>>
>> If it's interrupt-driven, then yes it would certainly make sense to
>> be async. But all I see is polling in the latest posting, was the
>> first version different?
>
> I stand corrected then, sorry.
>
> Is it possible to use DMA to feed the crypto accelerator, Corentin?
>
> Best regards,
> Marek Vasut
>
Yes, DMA is possible and will be implemented soon.
So if I have well understood, I keep using async interface.
On Wednesday, July 23, 2014 at 08:52:12 PM, Corentin LABBE wrote:
> Le 23/07/2014 17:51, Marek Vasut a ?crit :
> > On Wednesday, July 23, 2014 at 04:13:09 PM, Herbert Xu wrote:
> >> On Wed, Jul 23, 2014 at 04:07:20PM +0200, Marek Vasut wrote:
> >>> On Wednesday, July 23, 2014 at 03:57:35 PM, Herbert Xu wrote:
> >>>> On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
> >>>>>> + }
> >>>>>> +#endif
> >>>>>> +
> >>>>>> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
> >>>>>> + err = crypto_register_shash(&sunxi_md5_alg);
> >>>>>
> >>>>> Do not use shash for such device. This is clearly and ahash (and
> >>>>> async in general) device. The rule of a thumb here is that you use
> >>>>> sync algos only for devices which have dedicated instructions for
> >>>>> computing the transformation. For devices which are attached to some
> >>>>> kind of bus, you use async algos (ahash etc).
> >>>>
> >>>> I'm sorry that I didn't catch this earlier but there is no such
> >>>> rule.
> >>>>
> >>>> Unless you need the async interface you should stick to the sync
> >>>> interfaces for the sake of simplicity.
> >>>>
> >>>> We have a number of existing drivers that are synchronous but
> >>>> using the async interface. They should either be converted
> >>>> over to the sync interface or made interrupt-driven if possible.
> >>>
> >>> Sure, but this device is interrupt driven and uses DMA to feed the
> >>> crypto engine, therefore async, right ?
> >>
> >> If it's interrupt-driven, then yes it would certainly make sense to
> >> be async. But all I see is polling in the latest posting, was the
> >> first version different?
> >
> > I stand corrected then, sorry.
> >
> > Is it possible to use DMA to feed the crypto accelerator, Corentin?
> >
> > Best regards,
> > Marek Vasut
>
> Yes, DMA is possible and will be implemented soon.
> So if I have well understood, I keep using async interface.
Yeah, in this case, using DMA and async interface combo is the way to go.
Best regards,
Marek Vasut
On Wed, Jul 23, 2014 at 09:38:35PM +0200, Marek Vasut wrote:
> On Wednesday, July 23, 2014 at 08:52:12 PM, Corentin LABBE wrote:
> > Le 23/07/2014 17:51, Marek Vasut a ?crit :
> > > On Wednesday, July 23, 2014 at 04:13:09 PM, Herbert Xu wrote:
> > >> On Wed, Jul 23, 2014 at 04:07:20PM +0200, Marek Vasut wrote:
> > >>> On Wednesday, July 23, 2014 at 03:57:35 PM, Herbert Xu wrote:
> > >>>> On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
> > >>>>>> + }
> > >>>>>> +#endif
> > >>>>>> +
> > >>>>>> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
> > >>>>>> + err = crypto_register_shash(&sunxi_md5_alg);
> > >>>>>
> > >>>>> Do not use shash for such device. This is clearly and ahash (and
> > >>>>> async in general) device. The rule of a thumb here is that you use
> > >>>>> sync algos only for devices which have dedicated instructions for
> > >>>>> computing the transformation. For devices which are attached to some
> > >>>>> kind of bus, you use async algos (ahash etc).
> > >>>>
> > >>>> I'm sorry that I didn't catch this earlier but there is no such
> > >>>> rule.
> > >>>>
> > >>>> Unless you need the async interface you should stick to the sync
> > >>>> interfaces for the sake of simplicity.
> > >>>>
> > >>>> We have a number of existing drivers that are synchronous but
> > >>>> using the async interface. They should either be converted
> > >>>> over to the sync interface or made interrupt-driven if possible.
> > >>>
> > >>> Sure, but this device is interrupt driven and uses DMA to feed the
> > >>> crypto engine, therefore async, right ?
> > >>
> > >> If it's interrupt-driven, then yes it would certainly make sense to
> > >> be async. But all I see is polling in the latest posting, was the
> > >> first version different?
> > >
> > > I stand corrected then, sorry.
> > >
> > > Is it possible to use DMA to feed the crypto accelerator, Corentin?
> > >
> > > Best regards,
> > > Marek Vasut
> >
> > Yes, DMA is possible and will be implemented soon.
> > So if I have well understood, I keep using async interface.
>
> Yeah, in this case, using DMA and async interface combo is the way to go.
OK fair enough.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt