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. WarnerReceived on Tue Mar 04 2008 - 14:34:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:28 UTC