On Tue, Mar 4, 2008 at 4:31 PM, M. Warner Losh <imp_at_bsdimp.com> wrote: > digging deeper... > > The crypto code looks good to me. It explicitly sets the driver name. > Drivers that have a class explicitly set will have that driver's probe > called, and only that driver's probe. In arm, amd64, sparc64, i386 > and ia64, all of the devices for the nexus routine are added this way, > so there's no problem. > > I think that the real problem is that both 'real' hardware and 'fake' > hardware is being attached to the nexus driver for the AIM. The > grackle, uninorth and unin drivers all ask the nexus for their names. > That's because they really should be children of a openfirmware device > that enumerates these things. However, since there's now a 'fake' > device on nexus that doesn't ask the nexus for its name (since that's > not how children of nexus work) there's a problem. > > So the fix to the problem is to add a layer for the AIM class of > machine to attach grackle, uninorth or unin to a ofw device. > on the topic of IPSEC/Crypto/Cryptodev (soft), is anyone interested in testing pr- 120270 (feature request http://www.freebsd.org/cgi/query-pr.cgi?pr=120270 ) - because there are still some features missing like AES-192/256 hardware support C'Received on Tue Mar 04 2008 - 22:05:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:28 UTC