On Tue, Jan 06, 2015 at 06:30:36PM -0800, Marcel Holtmann wrote:
>
> that is indeed true. All the crypto algorithm need to be moved as well. I
> considered that already since I had debugged the initcall order with a kernel
> without modules.
If there were a real user then I would consider it. I
Hi Herbert,
>> we can easily run them later on. However when the Bluetooth subsystem is
>> built as module, then I would prefer to have the module loading fail in case
>> one of the selftest fails. I can hack around this with a lot of ifdef config
>> magic. If we would have all crypto, cipher e
On Mon, Dec 29, 2014 at 09:03:00PM -0800, Marcel Holtmann wrote:
>
> we can easily run them later on. However when the Bluetooth subsystem is
> built as module, then I would prefer to have the module loading fail in case
> one of the selftest fails. I can hack around this with a lot of ifdef conf
Hi Herbert,
>> we wanted to add some crypto selftests to the Bluetooth subsystem that
>> checks our usage of the crypto handling we use for Bluetooth Low Energy
>> Legacy Pairing and Secure Connections.
>>
>> Since the Crypto subsystem and Bluetooth subsystem both use subsys_initcall
>> that g
On Mon, Dec 22, 2014 at 10:46:47AM -0800, Marcel Holtmann wrote:
> Hi,
>
> we wanted to add some crypto selftests to the Bluetooth subsystem that checks
> our usage of the crypto handling we use for Bluetooth Low Energy Legacy
> Pairing and Secure Connections.
>
> Since the Crypto subsystem and
Hi,
we wanted to add some crypto selftests to the Bluetooth subsystem that checks
our usage of the crypto handling we use for Bluetooth Low Energy Legacy Pairing
and Secure Connections.
Since the Crypto subsystem and Bluetooth subsystem both use subsys_initcall
that goes horrible wrong when ru
