[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200809171633.41397.mb@bu3sch.de>
Date: Wed, 17 Sep 2008 16:33:41 +0200
From: Michael Buesch <mb@...sch.de>
To: "John W. Linville" <linville@...driver.com>
Cc: Henrique de Moraes Holschuh <hmh@....eng.br>,
Adel Gadllah <adel.gadllah@...il.com>,
wireless <linux-wireless@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
bcm43xx-dev@...ts.berlios.de,
Larry Finger <Larry.Finger@...inger.net>
Subject: Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f
On Wednesday 17 September 2008 16:29:31 John W. Linville wrote:
> On Wed, Sep 17, 2008 at 04:26:28PM +0200, Michael Buesch wrote:
> > On Wednesday 17 September 2008 00:37:29 Henrique de Moraes Holschuh wrote:
> > > On Tue, 16 Sep 2008, Michael Buesch wrote:
> > > > But I don't know how to tell the rfkill subsystem about the states and
> > >
> > > rfkill_force_state(). Must NOT be called from within atomic contextes,
> > > something I haven't got around to find a proper way of fixing, and nobody
> > > else seems to be on a rfkill coding frenzy right now.
> >
> > That's a showstopper for us, as we have to change the state from
> > within an interrupt tasklet.
>
> Workqueue?
Yeah, that's possible to implement yet another workaround using a workqueue.
However it would be nice to have rfkill either support atomic context
or implement the workaround in the rfkill core, as I'm sure there are more
devices that report rfkill changes via interrupt.
--
Greetings Michael.
--
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