[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100613222512.GE31045@fluff.org.uk>
Date: Sun, 13 Jun 2010 23:25:12 +0100
From: Ben Dooks <ben-linux@...ff.org>
To: Lothar Wa?mann <LW@...O-electronics.de>
Cc: Jeremy Kerr <jeremy.kerr@...onical.com>,
Ben Dooks <ben-linux@...ff.org>,
Ben Herrenchmidt <benh@...nel.crashing.org>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC,PATCH 1/2] Add a common struct clk
On Fri, Jun 11, 2010 at 10:14:35AM +0200, Lothar Wa?mann wrote:
> Hi,
>
> > > > +static inline int clk_enable(struct clk *clk)
> > > > +{
> > > > + int ret = 0;
> > > > +
> > > > + if (!clk->ops->enable)
> > > > + return 0;
> > > > +
> > > > + mutex_lock(&clk->mutex);
> > > > + if (!clk->enable_count)
> > > > + ret = clk->ops->enable(clk);
> > > > +
> > > > + if (!ret)
> > > > + clk->enable_count++;
> > > > + mutex_unlock(&clk->mutex);
> > > > +
> > > > + return ret;
> > > > +}
> > >
> Using a mutex in clk_enable()/clk_disable() is a bad idea, since that
> makes it impossible to call those functions in interrupt context.
I think that is a bad idea, unless you can provide otherwise. These
calls can sleep depending on implementation, and thus I would like to
ensure that they are marked as might-sleep.
Is there any specific reason? If so, we need to add some form of ops
where we have _nosleep specificially for this case.
--
Ben (ben@...ff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists