[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACna6rwUMMEWRVSKtJPavV7CUycYaMqphSuG_wvah5SO5QcA2A@mail.gmail.com>
Date: Fri, 13 Jan 2012 07:57:24 +0100
From: Rafał Miłecki <zajec5@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Arend van Spriel <arend@...adcom.com>,
Larry Finger <Larry.Finger@...inger.net>,
Alwin Beukers <alwin@...adcom.com>,
Roland Vossen <rvossen@...adcom.com>,
"John W. Linville" <linville@...driver.com>,
Network Development <netdev@...r.kernel.org>,
"Franky (Zhenhui) Lin" <frankyl@...adcom.com>
Subject: Re: brcm80211 breakage..
W dniu 13 stycznia 2012 07:50 użytkownik Rafał Miłecki
<zajec5@...il.com> napisał:
> W dniu 13 stycznia 2012 06:34 użytkownik Linus Torvalds
> <torvalds@...ux-foundation.org> napisał:
>> 2012/1/12 Linus Torvalds <torvalds@...ux-foundation.org>:
>>> 2012/1/12 Linus Torvalds <torvalds@...ux-foundation.org>:
>>>>
>>>> I'm surprised it has ever worked for anybody. It certainly doesn't work for me.
>>>
>>> So I can suspend the bcma driver on its own until the cows come home.
>>>
>>> But after I have suspended the bcma driver even once, just doing a
>>> "modprobe brcmsmac" will hang the machine hard. Dunno where, but this
>>> is probably the same thing as "hangs on resume".
>>
>> Guys, has suspend/resume with the bcma interface been tested AT ALL?
>>
>> The suspend/resume fields of "struct bcma_driver" are COMPLETELY
>> UNUSED. The only place in the kernel that uses them is the brcmsmac
>> driver that does this write-only assignment:
>>
>> .suspend = brcms_suspend,
>> .resume = brcms_resume,
>>
>> nothing else uses them. NOTHING. I tested by just removing the fields
>> and compiling the bcma subsystem, just in case there was something
>> really subtle that I was missing and was hidden through some magic
>> hidden approach. But no.
>>
>> Seriously - how was something that isn't even connected ever supposed
>> to work at all? And why was the BCMA conversion of that driver sent
>> up-stream if something as fundamental as suspend/resume had never been
>> done, and didn't actually work?
>>
>> What am I missing now? How the hell can this ever have worked for
>> ANYBODY? What kind of f*&*ing sick joke is this all?
>
> The suspend&resume wasn't implemented for some time because my PC
> doesn't s&r. And I don't have access to notebook with mini PCIe slot.
>
> I've implemented support for s&r in bcma when I got to open my Sony
> VAIO to replace A/C power slot. It was one time I was able to change
> WiFi card in my notebook which has really-ugly-hidden mini PCIe slot.
>
> S&r was working fine for me with bcma&b43 after writing that patch!
> That includes suspending and resuming multiple times. And tests were
> done with the same card you're using.
>
> The lock up on (resume|loading brcmsmac) means bus wasn't initialized
> correctly after resume. It does not have to be brcmsmac bug. We're
> accessing some registers before they're ready.
>
> Linus: can you do one trivial test for me? Please simply try unloading
> bcma before suspending. Then resume and load bcma and brcmsmac. Does
> it still lockup your machine?
Actually.. I've re-read your mail and I got it wrong at first. I
though you can suspend&resume once, but then loading brcmsmac causes
lock up. I interpreted that as broken initialization after resume.
Now I see you *can't suspend for the second time*. I don't get it :/
I've no idea what wrong we may be doing in that trivial
bcma_host_pci_suspend and bcma_host_pci_resume stopping you from
suspending for the second time.
I'll take a look at that new pm ops you told me about.
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists