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.

Warner
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"