On Saturday, July 20, 2013 05:06:29 AM Rafael J. Wysocki wrote:
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
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
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
On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
Tim Chen wrote:
Your approach is quite complicated. I think something simpler like the
following will work:
We cannot benefit from PCLMULQDQ. Is it acceptable for you?
The following code in crct10dif-pclmul_glue.c
On Fri, 2013-07-19 at 00:17 +0200, Rafael J. Wysocki wrote:
On 7/18/2013 11:00 PM, Tim Chen wrote:
On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
Tim Chen wrote:
Your approach is quite complicated. I think something simpler like the
following will work:
We cannot benefit from
Tim Chen wrote:
Your approach is quite complicated. I think something simpler like the
following will work:
We cannot benefit from PCLMULQDQ. Is it acceptable for you?
The following code in crct10dif-pclmul_glue.c
static const struct x86_cpu_id crct10dif_cpu_id[] = {
17 matches
Mail list logo
