M. Warner Losh wrote: > In message: <57AF36D8-0F83-4DF8-BEAA-CF3B59EAA361_at_rabson.org> > Doug Rabson <dfr_at_rabson.org> writes: > : > : On 4 Mar 2008, at 15:36, M. Warner Losh wrote: > : > : > In message: <9299FBBE-F58A-4107-991D-1C851EB8802C_at_rabson.org> > : > Doug Rabson <dfr_at_rabson.org> writes: > : > : I can't see the code which adds this device on a first look. Can you > : > : tell me the filename and I'll take a quick look at it. > : > > : > The problem actually turns out to be in how the powerpc nexus does > : > things. It does them in a very un-nexus-like way. The nexus attached > : > drivers ask for hardware details, which isn't done elsewhere. This > : > means when you mix and match the ones that expect to be explicitly set > : > and the ones that don't that you run into trouble. > : > > : > This needs to be reworked. > : > : Perhaps the crypto stuff should add itself to root0 instead of nexus. > > I think that would cause other problems... OK, since nobody seems to be interested enough to fix the issue in question I have spent some time to dig out what's going on. Disclaimer: it's my first serious encounter with newbus, so that I might be wrong somewhere. Apparently the issue in hand is caused by superposition of three facts: 1. The nexus/powerpc code creates bunch of children devices using information from the OF in the probe routine (should be probably attach routine), with NULL devclass. 2. The opencrypto creates fake "cryptosoft" device and adds it as a child to the newbus. It doesn't provide any actual probe code in the driver to check that the offered device is in fact one that has been created earlier. 3. The newbus code for some not very clear to me reason offers devices in the NULL devclass to every driver registered in the system. As a result of (1), (2) and (3) as well as current phase of the moon, the bunch of OF-devices created in (1) are offered to the "cryptosoft" driver before powerpc drivers and since there is no probe routine the "cryptosoft" driver attaches to all of them. This could be fixed by either altering probe in the "cryptosoft" to check that the device offered is in fact one that has been created earlier, or changing nexus/powerpc code to assign non-NULL devclass to child devices that it has generated from OF to match devclass of the relevant drivers (pcib, unin are the most important ones). The following patch uses the second approach. It would be nice if somebody with more newbus clue can review/comment. The patch also moves relevant code from nexus_probe() into nexus_attach(). http://sobomax.homeunix.org/~sobomax/powerpc_crypto.diff -MaximReceived on Wed Mar 05 2008 - 00:01:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:28 UTC