On Wed, Nov 10, 2010 at 05:57:24AM -0500, Henrik Rydberg wrote: > > >> > >> mutex_destroy() is defined as a nop, so I guess the question is whether anything > >> could be holding the lock when entering a second init. There are no sysfs files > >> created at that point, so I would say no. The mutex could be put back with a > >> static initializer, if this is not satisfactory. The real reason to move it to > >> the smcreg struct was to force a rename of the mutex itself. > >> > > > > Alternatively, you could move the mutex initialization to the beginning > > of applesmc_init_smcreg() and make it > > mutex_init(&smcreg.mutex); > > > Looking at this again, it seems there are two other problems as well. Firstly, > the cache memory is not freed after probe failure, my apologies. Secondly, > execution continues after a probe failure, and the initialization is retried. I > would like to push the latter problem to some other occasion, since the whole > platform logic should be rewritten for the new interface, anyways. > I see the cache problem; this is indeed a tricky one, since it is actually not yet a problem after this patch, but will be one after patch 5. I don't understand the second problem, though. Looking into the code, the probe function will return an error if applesmc_init_smcreg() fails. Am I missing something ? What execution continues ? Thanks, Guenter _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
