On Wed, May 15, 2013 at 10:14 PM, Fabio Baltieri
wrote:
> On Wed, May 15, 2013 at 07:18:01PM +0200, Linus Walleij wrote:
>> On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
>>
>> > For all ux500 based platforms the maximum number of end-points are used.
>> > Move this knowledge into the driver
2013/5/17 Tim Chen :
> On Thu, 2013-05-16 at 09:59 -0700, Tim Chen wrote:
>> On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
>> > On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou
>> > wrote:
>> > > --- a/crypto/Kconfig
>> > > +++ b/crypto/Kconfig
>> > > @@ -378,6 +378,7 @@ config CRYPTO_C
2013/5/16 Geert Uytterhoeven :
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou wrote:
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>>
>> config CRYPTO_CRCT10DIF
>> tristate "CRCT10DIF algorithm"
>> + depends on CRC_T10DIF
>
> This i
On Thu, 2013-05-16 at 09:59 -0700, Tim Chen wrote:
> On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
> > On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou wrote:
> > > --- a/crypto/Kconfig
> > > +++ b/crypto/Kconfig
> > > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
> > >
> > > config CR
On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou wrote:
> > --- a/crypto/Kconfig
> > +++ b/crypto/Kconfig
> > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
> >
> > config CRYPTO_CRCT10DIF
> > tristate "CRCT10DIF algorithm"
> > +
On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou wrote:
> > --- a/crypto/Kconfig
> > +++ b/crypto/Kconfig
> > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
> >
> > config CRYPTO_CRCT10DIF
> > tristate "CRCT10DIF algorithm"
> > +
Hello,
I have an encrypted disc (dm-crypt, type LUKS1, ssh256 as hash
algorithm). I have an Intel Core i5 M450 that supports ssse3. Find
below the output from netconsole with the oops. The last warning
appeared when I restart the pc using the magic sysrq key combination
REISUB. I have the same pro
By providing an OF match table with a suitable compatible string, we
can ensure the ux500-crypt driver is probed by supplying an associated
DT node in a given platform's Device Tree.
Cc: Herbert Xu
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/crypto/ux500/cryp/cryp_core
By providing an OF match table with a suitable compatible string, we
can ensure the ux500-hasht driver is probed by supplying an associated
DT node in a given platform's Device Tree.
Cc: Herbert Xu
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/crypto/ux500/hash/hash_core
On Thu, 16 May 2013, Vinod Koul wrote:
> On Thu, May 16, 2013 at 08:25:57AM +0100, Lee Jones wrote:
> > On Thu, 16 May 2013, Vinod Koul wrote:
> >
> > > On Wed, May 15, 2013 at 10:51:25AM +0100, Lee Jones wrote:
> > > > All configuration left in d40_phy_cfg() is runtime configurable and
> > > > t
On Thu, May 16, 2013 at 08:35:53AM +0100, Lee Jones wrote:
> On Thu, 16 May 2013, Vinod Koul wrote:
>
> > On Wed, May 15, 2013 at 10:51:57AM +0100, Lee Jones wrote:
> > > +u8 d40_width_to_bits(enum dma_slave_buswidth width)
> > > +{
> > > + if (width == DMA_SLAVE_BUSWIDTH_1_BYTE)
> > > + r
On Thu, May 16, 2013 at 08:25:57AM +0100, Lee Jones wrote:
> On Thu, 16 May 2013, Vinod Koul wrote:
>
> > On Wed, May 15, 2013 at 10:51:25AM +0100, Lee Jones wrote:
> > > All configuration left in d40_phy_cfg() is runtime configurable and
> > > there is already a call into it from d40_runtime_conf
On Thu, 16 May 2013, Vinod Koul wrote:
> On Wed, May 15, 2013 at 10:51:57AM +0100, Lee Jones wrote:
> > When a DMA client requests and configures a DMA channel, it requests
> > data_width in Bytes. The DMA40 driver then swiftly converts it over to
> > the necessary register bit value. Unfortunatel
On Thu, 16 May 2013, Vinod Koul wrote:
> On Wed, May 15, 2013 at 06:29:51PM +0200, Linus Walleij wrote:
> > On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> >
> > > During the initial setup of a logical channel, it is necessary to unmask
> > > the GIM in order to receive generated terminal c
On Thu, 16 May 2013, Vinod Koul wrote:
> On Wed, May 15, 2013 at 10:51:25AM +0100, Lee Jones wrote:
> > All configuration left in d40_phy_cfg() is runtime configurable and
> > there is already a call into it from d40_runtime_config(), so let's
> > rely on that.
> >
> > Acked-by: Vinod Koul
> Tha
On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou wrote:
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>
> config CRYPTO_CRCT10DIF
> tristate "CRCT10DIF algorithm"
> + depends on CRC_T10DIF
This is a library symbol, so "select CRC_T10DIF"?
On Thu, May 16, 2013 at 08:06:38AM +0100, Lee Jones wrote:
> On Thu, 16 May 2013, Vinod Koul wrote:
>
> > On Wed, May 15, 2013 at 10:51:54AM +0100, Lee Jones wrote:
> > > STEDMA40_*_TO_* direction definitions are identical in all but name to
> > > the pre-defined generic DMA_*_TO_* ones. Let's mak
On Wed, May 15, 2013 at 10:51:33AM +0100, Lee Jones wrote:
> 'struct stedma40_half_channel_info's header comment says that it's
> called 'struct stedma40_chan_cfg'. Let's straighten that out.
>
> Signed-off-by: Lee Jones
> ---
Acked-by: Vinod Koul
--
~Vinod
> include/linux/platform_data/dma-st
On Wed, May 15, 2013 at 10:51:30AM +0100, Lee Jones wrote:
> Addresses are passed in from the client's driver via the invocation of
> dmaengine_slave_config(), so there's no need to fetch them from platform
> data too, hardwired or otherwise. This is a great step forward, as it
> elevates a large b
On Wed, May 15, 2013 at 10:51:31AM +0100, Lee Jones wrote:
> Addresses are now stored in local data structures and are easy to
> obtain, thus a specialist function used to fetch them is now surplus
> to requirement.
>
> Signed-off-by: Lee Jones
> ---
Acked-by: Vinod Koul
--
~Vinod
> drivers/dm
On Wed, May 15, 2013 at 10:51:26AM +0100, Lee Jones wrote:
> Using the dmaengine API, allocating and configuring a channel are two
> separate actions. Here we're removing logical channel configuration from
> the channel allocating routines.
>
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Per Forlin
On Wed, May 15, 2013 at 10:51:25AM +0100, Lee Jones wrote:
> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
>
> Acked-by: Vinod Koul
That needs up update!
> Acked-by: Arnd Bergmann
> Signe
On Wed, May 15, 2013 at 06:29:51PM +0200, Linus Walleij wrote:
> On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
>
> > During the initial setup of a logical channel, it is necessary to unmask
> > the GIM in order to receive generated terminal count and error interrupts.
> > We're separating ou
On Wed, May 15, 2013 at 10:52:01AM +0100, Lee Jones wrote:
> Some platforms insist on obscure physical channel availability. This
> information is currently passed though platform data in internal BSP
> kernels. Once those platforms land, they'll need to configure them
> appropriately, so we may as
On Wed, May 15, 2013 at 10:51:57AM +0100, Lee Jones wrote:
> When a DMA client requests and configures a DMA channel, it requests
> data_width in Bytes. The DMA40 driver then swiftly converts it over to
> the necessary register bit value. Unfortunately, for any subsequent
> calculations we have to
On Thu, 16 May 2013, Vinod Koul wrote:
> On Wed, May 15, 2013 at 10:51:54AM +0100, Lee Jones wrote:
> > STEDMA40_*_TO_* direction definitions are identical in all but name to
> > the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not
> > duplicating such things.
> >
> > Cc: Vinod
On Wed, May 15, 2013 at 10:51:41AM +0100, Lee Jones wrote:
> The Cryp driver is currently silent and the Hash driver prints the
> name of its probe function unnecessarily. Let's just put a nice
> descriptive one-liner there instead.
>
> Cc: Herbert Xu
> Cc: David S. Miller
> Cc: Andreas Westin
On Wed, May 15, 2013 at 10:51:39AM +0100, Lee Jones wrote:
> The DMA controller currently takes configuration information from
> information passed though dma_channel_request(), but it shouldn't.
> Using the API, the DMA channel should only be configured during
> a dma_slave_config() call.
>
> Cc:
On Wed, May 15, 2013 at 10:51:38AM +0100, Lee Jones wrote:
> If we fail to prepare the ux500-cryp clock before enabling it the
> platform will fail to boot. Here we insure this happens.
>
> Cc: Herbert Xu
> Cc: David S. Miller
> Cc: Andreas Westin
> Cc: linux-crypto@vger.kernel.org
> Acked-by:
On Wed, May 15, 2013 at 10:51:36AM +0100, Lee Jones wrote:
> The DMA controller currently takes configuration information from
> information passed though dma_channel_request(), but it shouldn't.
> Using the API, the DMA channel should only be configured during
> a dma_slave_config() call.
>
> Cc:
On Thu, May 16, 2013 at 07:53:55AM +0100, Lee Jones wrote:
> On Wed, 15 May 2013, Linus Walleij wrote:
>
> > On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> >
> > > If we fail to prepare the ux500-hash clock before enabling it the
> > > platform will fail to boot. Here we insure this happen
31 matches
Mail list logo
