[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFx4Xuai3wS1Jk09mNeO7gVYqzTyX5ev_9oRxCyNdBrEaw@mail.gmail.com>
Date: Thu, 12 Jan 2012 21:34:22 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Rafał Miłecki <zajec5@...il.com>,
Arend van Spriel <arend@...adcom.com>
Cc: 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..
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?
Linus
--
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