On 7/18/2013 6:57 PM, Cristian Stoica wrote:
This patch removes redundant execution of the same test suite in cases
where alg and driver variables are the same (e.g. when alg_test is
called from tcrypt_test)
Signed-off-by: Cristian Stoica cristian.sto...@freescale.com
Reviewed-by: Horia
On Thursday, July 18, 2013 04:44:20 PM H. Peter Anvin wrote:
On 07/18/2013 03:17 PM, Rafael J. Wysocki wrote:
alias x86cpu:vendor:*:family:*:model:*:feature:*0081* crct10dif_pclmul
This should cause udev to load the crct10dif_pclml module when cpu
support the PCLMULQDQ (feature code
On Fri, 2013-07-19 at 16:49 +0200, Rafael J. Wysocki wrote:
This should cause udev to load the crct10dif_pclml module when cpu
support the PCLMULQDQ (feature code 0081). I did my testing during
development on 3.10 and the module was indeed loaded.
However, I found that
On Friday, July 19, 2013 11:08:49 AM Tim Chen wrote:
On Fri, 2013-07-19 at 16:49 +0200, Rafael J. Wysocki wrote:
This should cause udev to load the crct10dif_pclml module when cpu
support the PCLMULQDQ (feature code 0081). I did my testing during
development on 3.10 and the
On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
Alas, this is not the one I'd like to apply.
With that patch applied, new device objects are created to avoid binding the
processor driver directly to the cpu system device objects, because that
apparently confuses udev and
On 07/19/2013 04:16 PM, Greg Kroah-Hartman wrote:
udev isn't doing any module loading, 'modprobe' is just being called for
any new module alias that shows up in the system, and all of the drivers
that match it then get loaded.
How is it a problem if a module is attempted to be loaded that
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
On 07/19/2013 04:16 PM, Greg Kroah-Hartman wrote:
udev isn't doing any module loading, 'modprobe' is just being called for
any new module alias that shows up in the system, and all of the drivers
that match it then get
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
The issue here seems to be the dynamic binding nature of the crypto
subsystem. When something needs crypto, it will request the appropriate
crypto module (e.g. crct10dif), which may race with detecting a specific
hardware
On 07/19/2013 04:26 PM, Greg Kroah-Hartman wrote:
RAID has effectively the same issue, and we just solved it by
compiling in all the accelerators into the top-level module.
Then there's nothing to be done in udev or kmod, right?
I don't know.
-hpa
--
To unsubscribe from this
On Sat, 2013-07-20 at 09:24 +1000, Herbert Xu wrote:
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
The issue here seems to be the dynamic binding nature of the crypto
subsystem. When something needs crypto, it will request the appropriate
crypto module (e.g. crct10dif),
On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
Alas, this is not the one I'd like to apply.
With that patch applied, new device objects are created to avoid binding the
processor driver directly to the cpu
On Fri, 2013-07-19 at 16:37 -0700, Tim Chen wrote:
On Sat, 2013-07-20 at 09:24 +1000, Herbert Xu wrote:
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
The issue here seems to be the dynamic binding nature of the crypto
subsystem. When something needs crypto, it will
Tim Chen wrote:
On Fri, 2013-07-19 at 16:37 -0700, Tim Chen wrote:
Herbert,
I've tried the module alias approach (see my earlier mail with patch)
but it didn't seem to load things properly. Can you check to see if
there's anything I did incorrectly.
Tim
I fixed a missing
On Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
Alas, this is not the one I'd like to apply.
With that patch applied, new device objects
On Fri, Jul 19, 2013 at 06:31:04PM -0700, Tim Chen wrote:
However, when I have the library and generic algorithm compiled in,
I do not see the PCLMULQDQ version loaded.
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRC_T10DIF=y
That is completely expected. I don't
Herbert Xu wrote:
On Fri, Jul 19, 2013 at 06:31:04PM -0700, Tim Chen wrote:
However, when I have the library and generic algorithm compiled in,
I do not see the PCLMULQDQ version loaded.
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRC_T10DIF=y
That is
16 matches
Mail list logo
