Searched hist:210312 (Results 1 - 7 of 7) sorted by relevance
| /freebsd-10.2-release/sys/mips/cavium/cryptocteon/ | ||
| H A D | cavium_crypto.c | 210312 Tue Jul 20 19:43:55 MDT 2010 jmallett o) Add the "octusb" controller which supports the first port of the Octeon on-board USB controller. It is not currently enabled because there are known problems with device communication and until those are fixed I am not certain that it won't destabilize the system. [1] o) Add the "cryptocteon" opencrypto device based on the OCF device written by David McCullough. It is not currently enabled because until support for saving/restoring coprocessor 2 state on context switch is available, it runs with interrupts disabled, which tends to pessimize performance over using a software crypto facility. Tests using this driver which are not negatively affected by it running with interrupts disabled show it to be substantially faster than software for large blocks. Submitted by: hps [1] |
| H A D | cryptocteon.c | 210312 Tue Jul 20 19:43:55 MDT 2010 jmallett o) Add the "octusb" controller which supports the first port of the Octeon on-board USB controller. It is not currently enabled because there are known problems with device communication and until those are fixed I am not certain that it won't destabilize the system. [1] o) Add the "cryptocteon" opencrypto device based on the OCF device written by David McCullough. It is not currently enabled because until support for saving/restoring coprocessor 2 state on context switch is available, it runs with interrupts disabled, which tends to pessimize performance over using a software crypto facility. Tests using this driver which are not negatively affected by it running with interrupts disabled show it to be substantially faster than software for large blocks. Submitted by: hps [1] |
| H A D | cryptocteonvar.h | 210312 Tue Jul 20 19:43:55 MDT 2010 jmallett o) Add the "octusb" controller which supports the first port of the Octeon on-board USB controller. It is not currently enabled because there are known problems with device communication and until those are fixed I am not certain that it won't destabilize the system. [1] o) Add the "cryptocteon" opencrypto device based on the OCF device written by David McCullough. It is not currently enabled because until support for saving/restoring coprocessor 2 state on context switch is available, it runs with interrupts disabled, which tends to pessimize performance over using a software crypto facility. Tests using this driver which are not negatively affected by it running with interrupts disabled show it to be substantially faster than software for large blocks. Submitted by: hps [1] |
| /freebsd-10.2-release/sys/mips/cavium/usb/ | ||
| H A D | octusb.h | 210312 Tue Jul 20 19:43:55 MDT 2010 jmallett o) Add the "octusb" controller which supports the first port of the Octeon on-board USB controller. It is not currently enabled because there are known problems with device communication and until those are fixed I am not certain that it won't destabilize the system. [1] o) Add the "cryptocteon" opencrypto device based on the OCF device written by David McCullough. It is not currently enabled because until support for saving/restoring coprocessor 2 state on context switch is available, it runs with interrupts disabled, which tends to pessimize performance over using a software crypto facility. Tests using this driver which are not negatively affected by it running with interrupts disabled show it to be substantially faster than software for large blocks. Submitted by: hps [1] |
| H A D | octusb.c | 210312 Tue Jul 20 19:43:55 MDT 2010 jmallett o) Add the "octusb" controller which supports the first port of the Octeon on-board USB controller. It is not currently enabled because there are known problems with device communication and until those are fixed I am not certain that it won't destabilize the system. [1] o) Add the "cryptocteon" opencrypto device based on the OCF device written by David McCullough. It is not currently enabled because until support for saving/restoring coprocessor 2 state on context switch is available, it runs with interrupts disabled, which tends to pessimize performance over using a software crypto facility. Tests using this driver which are not negatively affected by it running with interrupts disabled show it to be substantially faster than software for large blocks. Submitted by: hps [1] |
| H A D | octusb_octeon.c | 210312 Tue Jul 20 19:43:55 MDT 2010 jmallett o) Add the "octusb" controller which supports the first port of the Octeon on-board USB controller. It is not currently enabled because there are known problems with device communication and until those are fixed I am not certain that it won't destabilize the system. [1] o) Add the "cryptocteon" opencrypto device based on the OCF device written by David McCullough. It is not currently enabled because until support for saving/restoring coprocessor 2 state on context switch is available, it runs with interrupts disabled, which tends to pessimize performance over using a software crypto facility. Tests using this driver which are not negatively affected by it running with interrupts disabled show it to be substantially faster than software for large blocks. Submitted by: hps [1] |
| /freebsd-10.2-release/sys/mips/cavium/ | ||
| H A D | files.octeon1 | diff 210312 Tue Jul 20 19:43:55 MDT 2010 jmallett o) Add the "octusb" controller which supports the first port of the Octeon on-board USB controller. It is not currently enabled because there are known problems with device communication and until those are fixed I am not certain that it won't destabilize the system. [1] o) Add the "cryptocteon" opencrypto device based on the OCF device written by David McCullough. It is not currently enabled because until support for saving/restoring coprocessor 2 state on context switch is available, it runs with interrupts disabled, which tends to pessimize performance over using a software crypto facility. Tests using this driver which are not negatively affected by it running with interrupts disabled show it to be substantially faster than software for large blocks. Submitted by: hps [1] |
Completed in 78 milliseconds