framework. There is no need to waste the space if you are only using
algoritms provided by hardware accelerators. To get the software
implementations, add "pseudo-device swcr" to your kernel config.
- Lazily initialize the opencrypto framework when crypto drivers
(either hardware or swcr) register themselves with the framework.
expensive, and pointless. As elsewhere in the kernel (and as approved
under FIPS-140-2 by multiple test labs, incidentally) we use arc4 to
generate IVs here; there is no benefit to their being cryptographically
strong so long as there is a sufficient Hamming distance between them.
and 795x. This was present in the driver before, but disabled due to
problems with the actual randomness of generated numbers on the
ubiquitious 7900-series parts. The code here is far, far more
conservative than anyone else's driver for this RNG is -- but I
believe that conservatism is called for, because the 79xx RNG
design is missing a number of pieces from Hifn's "reference" 6500
RNG, and thus the numbers it generates must be treated with some
care.
Support for the 7811 RNG (which is a full-fledged 6500 type
generator) is pretty much the same here as in other variants of
this driver, except that it uses Hifn's "worst case" estimate of
actual entropy per output bit, so it will accumulate bits much
more slowly. The 7811 support is untested.
Not tested on 795[56], but compiles and matches FreeBSD-tested diffs.
Suggested by Sam Leffler <sam@errno.com>, as imported into FreeBSD by Sam.
Submitted to FreeBSD by Rajesh Vaidyanath <RVaidyanath@hifn.com>.
Replace with a new from-scratch port of recent OpenBSD hifn7751 source,
with changes to the crypto-framework calls to fit Sam Leffler's rework.
(Some of the attach-time changes from the previous driver were carried over).
Many thanks to Quentin Garnier (cube@cubidou.net) for testing an pre-release
of the driver and finding a couple of missing initializations.
Note that RNG support is temporarily disabled, until a potential issue
with RNG quality is investigated and resolved.
pci_attach_args *" instead of from four separate parameters which in
all cases were extracted from the same "struct pci_attach_args".
This both simplifies the driver api, and allows for alternate PCI
interrupt mapping schemes, such as one using the tables described in
the Intel Multiprocessor Spec which describe interrupt wirings for
devices behind pci-pci bridges based on the device's location rather
the bridge's location.
Tested on alpha and i386; welcome to 1.5Q
does nothing useful at this moment - initailize the chip, that's all.
TODO: crypto logic framework in kernel (see openbsd sys/crypto)
TODO: ipsec frontend (need major rework in ipsec tree - should start with busywait)
TODO: character device frontend
