Hi,
On Mon, Nov 07, 2011 at 09:18:36AM +0000, Michael Büsch wrote:
> > On Sat, Nov 05, 2011 at 05:19:54PM +0100, Michael Büsch wrote:
> > > tahvo_write_reg() needs to take the mutex to avoid a race
> > > condition with tahvo_set_clear_reg_bits:
> > >
> > > tahvo_set_clear_reg_bits(): | tahvo_write_reg():
> > > __tahvo_read_reg() |
> > > | __tahvo_write_reg() <-- race here
> > > __tahvo_write_reg() |
> > >
> > > Signed-off-by: Michael Buesch <m...@bues.ch>
> > >
> > > ---
> > >
> > > Index: linux-3.1/drivers/cbus/tahvo.c
> > > ===================================================================
> > > --- linux-3.1.orig/drivers/cbus/tahvo.c 2011-11-05 17:03:39.598846119
> > > +0100
> > > +++ linux-3.1/drivers/cbus/tahvo.c 2011-11-05 17:04:36.274768324
> > > +0100
> > > @@ -104,7 +104,9 @@ void tahvo_write_reg(struct device *chil
> > > {
> > > struct tahvo *tahvo = dev_get_drvdata(child->parent);
> > >
> > > + mutex_lock(&tahvo->mutex);
> > > __tahvo_write_reg(tahvo, reg, val);
> > > + mutex_unlock(&tahvo->mutex);
> >
> > yeah, my bad. The same should be done with tahvo_read_reg(). Care to
> > resend this patch adding the change to tahvo_read_reg() too...
>
> I think tahvo_read_reg is fine without a lock.
> read vs write is already atomic due to the cbus lock.
>
> it's the same situation as for retu. where we also don't need the lock
> in retu_read_reg.ok then, makes sense. FWIW: Acked-by: Felipe Balbi <ba...@ti.com> -- balbi
signature.asc
Description: Digital signature
