On Thu, 16 Sep 2010 20:40:44 +0400
Anton Vorontsov [off-list ref] wrote:

On Thu, Sep 16, 2010 at 11:14:48AM -0500, Scott Wood wrote:

quoted

quoted

quoted

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