Hi Eric,
On 06/07/2019 05:40 PM, Eric Biggers wrote:
On Fri, Jun 07, 2019 at 04:54:04PM -0500, Denis Kenzior wrote:
Hi Eric,
On 06/07/2019 04:41 PM, Eric Biggers wrote:
On Fri, Jun 07, 2019 at 04:28:59PM -0500, Denis Kenzior wrote:
Hi Eric,
On 06/07/2019 04:15 PM, Eric Biggers wrote:
On Fr
On Fri, Jun 07, 2019 at 04:54:04PM -0500, Denis Kenzior wrote:
> Hi Eric,
>
> On 06/07/2019 04:41 PM, Eric Biggers wrote:
> > On Fri, Jun 07, 2019 at 04:28:59PM -0500, Denis Kenzior wrote:
> > > Hi Eric,
> > >
> > > On 06/07/2019 04:15 PM, Eric Biggers wrote:
> > > > On Fri, Jun 07, 2019 at 03:45
Hi Eric,
On 06/07/2019 04:41 PM, Eric Biggers wrote:
On Fri, Jun 07, 2019 at 04:28:59PM -0500, Denis Kenzior wrote:
Hi Eric,
On 06/07/2019 04:15 PM, Eric Biggers wrote:
On Fri, Jun 07, 2019 at 03:45:45PM -0500, Denis Kenzior wrote:
Hi Ard,
Ah ok, good to know. That does imply that the dri
On Fri, Jun 07, 2019 at 04:28:59PM -0500, Denis Kenzior wrote:
> Hi Eric,
>
> On 06/07/2019 04:15 PM, Eric Biggers wrote:
> > On Fri, Jun 07, 2019 at 03:45:45PM -0500, Denis Kenzior wrote:
> > > Hi Ard,
> > >
> > > >
> > > > Ah ok, good to know. That does imply that the driver is not entirely
>
Hi Eric,
On 06/07/2019 04:15 PM, Eric Biggers wrote:
On Fri, Jun 07, 2019 at 03:45:45PM -0500, Denis Kenzior wrote:
Hi Ard,
Ah ok, good to know. That does imply that the driver is not entirely
broken, which is good news I suppose.
Not entirely, but we did have to resort to using multiple
On Fri, Jun 07, 2019 at 03:45:45PM -0500, Denis Kenzior wrote:
> Hi Ard,
>
> >
> > Ah ok, good to know. That does imply that the driver is not entirely
> > broken, which is good news I suppose.
> >
>
> Not entirely, but we did have to resort to using multiple sockets, otherwise
> parallel encry
Hi Ard,
Ah ok, good to know. That does imply that the driver is not entirely
broken, which is good news I suppose.
Not entirely, but we did have to resort to using multiple sockets,
otherwise parallel encrypt/decrypt operations on the socket would result
in invalid behavior. Probably due
On Fri, 7 Jun 2019 at 22:24, Marcel Holtmann wrote:
>
> Hi Eric,
>
> >> One of the issues that I would like to see addressed in the crypto API
> >> is they way the cipher abstraction is used. In general, a cipher should
> >> never be used directly, and so it would be much better to clean up the
>
Hi Eric,
>> One of the issues that I would like to see addressed in the crypto API
>> is they way the cipher abstraction is used. In general, a cipher should
>> never be used directly, and so it would be much better to clean up the
>> existing uses of ciphers outside of the crypto subsystem itself
Everyone:
Picking up where Chris left off (I chatted with him privately
beforehead), this series adds support for i.MX8MQ to CAAM driver. Just
like [v1], this series is i.MX8MQ only.
Feedback is welcome!
Thanks,
Andrey Smirnov
Changes since [v1]
- Series reworked to continuse using register b
Exactly the same code to figure out DMA mask is repeated twice in the
driver code. To avoid repetition, move that logic into a standalone
subroutine in intern.h. While at it re-shuffle the code to make it
more readable with early returns.
Signed-off-by: Andrey Smirnov
Cc: Chris Spencer
Cc: Cory
From: Chris Spencer
There are no clocks that the CAAM driver needs to initialise on the
i.MX8.
Signed-off-by: Aymen Sghaier
Signed-off-by: Chris Spencer
Signed-off-by: Andrey Smirnov
Cc: Chris Spencer
Cc: Cory Tusar
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Aymen Sghaier
Cc:
From: Chris Spencer
The i.MX8 is arm64, but its CAAM DMA address size is 32-bits.
Signed-off-by: Aymen Sghaier
Signed-off-by: Franck LENORMAND
Signed-off-by: Chris Spencer
Signed-off-by: Andrey Smirnov
Cc: Chris Spencer
Cc: Cory Tusar
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc:
Per feedback from NXP tech support the way to use register based
service interface on i.MX8MQ is to follow the same set of steps
outlined for the case when virtualization is enabled, regardless if it
is. Current version of SRM for i.MX8MQ speaks of DECO DID_MS and DECO
DID_LS registers, but apparen
On 5/10/19 10:31 AM, Florian Fainelli wrote:
> BCM7211 features a RNG200 block, document its compatible string.
>
> Signed-off-by: Florian Fainelli
Rob, does this look okay to you?
> ---
> Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt | 1 +
> 1 file changed, 1 insertion(+)
>
>
On Fri, 7 Jun 2019 at 19:59, Eric Biggers wrote:
>
> On Fri, Jun 07, 2019 at 04:49:41PM +0200, Ard Biesheuvel wrote:
> > One of the issues that I would like to see addressed in the crypto API
> > is they way the cipher abstraction is used. In general, a cipher should
> > never be used directly, an
On Fri, Jun 07, 2019 at 04:49:41PM +0200, Ard Biesheuvel wrote:
> One of the issues that I would like to see addressed in the crypto API
> is they way the cipher abstraction is used. In general, a cipher should
> never be used directly, and so it would be much better to clean up the
> existing uses
The WEP code uses the arc4 cipher interface, and invokes it byte by
byte. This is rather inefficient, and since the cipher interface in
general is not really suitable for use outside of the crypto subsystem,
move this code to use the skcipher interface instead.
Given that the only driver that prov
One of the issues that I would like to see addressed in the crypto API
is they way the cipher abstraction is used. In general, a cipher should
never be used directly, and so it would be much better to clean up the
existing uses of ciphers outside of the crypto subsystem itself, so that
we can make
The mac80211 WEP code uses the cipher interface, and invokes it byte
by byte. This is rather inefficient, and since the cipher interface in
general is not really suitable for use outside of the crypto subsystem,
move this code to use the skcipher interface instead.
Given that the only driver that
The TKIP code uses the arc4 cipher interface, and invokes it byte by
byte. This is rather inefficient, and since the cipher interface in
general is not really suitable for use outside of the crypto subsystem,
move this code to use the skcipher interface instead.
Given that the only driver that pro
On 6/5/19, 7:20 AM, "Will Deacon" wrote:
On Tue, Jun 04, 2019 at 08:30:57PM +, Ali Saidi wrote:
> AWS Graviton based systems provide an Arm SMC call in the vendor defined
> hypervisor region to read random numbers from a HW TRNG and return them
to the
> guest.
>
22 matches
Mail list logo
