[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87podgi97z.fsf@kamboji.qca.qualcomm.com>
Date: Tue, 04 Jul 2017 17:10:24 +0300
From: Kalle Valo <kvalo@...eaurora.org>
To: Brian Norris <briannorris@...omium.org>
Cc: Johannes Berg <johannes@...solutions.net>,
Ganapathi Bhat <gbhat@...vell.com>,
Nishant Sarmukadam <nishants@...vell.com>,
linux-kernel@...r.kernel.org,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Amitkumar Karwar <amitkarwar@...il.com>,
linux-wireless@...r.kernel.org
Subject: Re: [PATCH 05/14] mwifiex: re-register wiphy across reset
(I was on vacation and inbox exploded again)
Brian Norris <briannorris@...omium.org> writes:
> On Thu, Jun 22, 2017 at 03:02:34PM +0200, Johannes Berg wrote:
>> On Wed, 2017-06-21 at 11:27 -0700, Brian Norris wrote:
>
>> > > Without checking the code now, it seems entirely plausible that
>> > > this is
>> > > holding some lock that would lock out the control path entirely,
>> > > for
>> > > the duration until the wiphy is actually unregistered?
>> > >
>> > > Actually, you can't unregister with the relevant locks held
>> > > (without
>> > > causing deadlocks), so perhaps it's marking the wiphy as
>> > > unavailable so
>> > > that all operations fail?
>> >
>> > One of the above two sounds along the right line. But it's something
>> > I couldn't really figure out how to do quite right.
>> >
>> > Dumb question: how would I mark the wiphy as unavailable? Is there
>> > something I can do at the cfg80211 level? Or would I really have to
>> > guard all the cfg80211 entry points into mwifiex with a flag or lock?
>>
>> There isn't really a good way to do this. You can, of course, call
>> wiphy_unregister(), but if you could do that you'd already have the
>> problem solved, I think?
>
> That's probably along the right track. There are still some things we'd
> need to do properly before that though, and this is where all the
> problems are so far. (Also, this is what Kalle was already objecting to;
> he didn't think we should be unregistering/recreating the wiphy, but I
> think he ended up softening on that a bit.)
Just to clarify I was more like hoping there would be a better way to do
it, not really objecting the current method, but I didn't realise that
of course it's harder to do a transparent firmware restart with fullmac
design. And certainly what are you doing now is much much better than
doing nothing after a firmware crash.
--
Kalle Valo
Powered by blists - more mailing lists