On Thu, 16 Sep 2010 20:40:44 +0400 Anton Vorontsov <cbouatmai...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 11:14:48AM -0500, Scott Wood wrote: > > > > DEFINE_MUTEX(fsl_elbc_mutex); > > > > > > I'd place the mutex inside the fsl_lbc_ctrl_dev, > > > i.e. fsl_lbc_ctrl_dev->nand_lock. This is to avoid more > > > global variables. > > > > I wouldn't. If the lock is only meaningful to the NAND driver, it > > should be declared in the NAND driver. > > > > Besides, it's not any less of a global just because it's sitting inside > > a singleton struct. > > > > Perhaps it should be declared as a static local inside the probe > > function, if it's just to guard against this one race. > > OK, in that case better be persistent and not introduce > fsl_lbc_ctrl_dev->nand at all, as it isn't used outside > of the driver. We could, though it would be a step further away from being able to support multiple controllers if that ever does happen. Whereas sharing a mutex between multiple controllers isn't a problem (it's just init, not a performance-sensitive path where fine-grained locking is desireable). > Having fsl_lbc_ctrl_dev->nand and its lock elsewhere in > the code makes no sense. That depends on whether you see it as that field's lock or as the init code's lock, I guess. It's not that big of a deal either way. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
