lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 13 Jan 2012 07:57:24 +0100
From:	Rafał Miłecki <>
To:	Linus Torvalds <>
Cc:	Arend van Spriel <>,
	Larry Finger <>,
	Alwin Beukers <>,
	Roland Vossen <>,
	"John W. Linville" <>,
	Network Development <>,
	"Franky (Zhenhui) Lin" <>
Subject: Re: brcm80211 breakage..

W dniu 13 stycznia 2012 07:50 użytkownik Rafał Miłecki
<> napisał:
> W dniu 13 stycznia 2012 06:34 użytkownik Linus Torvalds
> <> napisał:
>> 2012/1/12 Linus Torvalds <>:
>>> 2012/1/12 Linus Torvalds <>:
>>>> 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.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists