summaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/cw1200/hwbus.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* cw1200: move under st vendor directoryKalle Valo2015-11-181-33/+0
| | | | | | Part of reorganising wireless drivers directory and Kconfig. Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* Revert "cw1200: Don't perform SPI transfers in interrupt context"Solomon Peachy2013-09-261-1/+0
| | | | | | | | | | | This reverts commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35. This solution turned out to cause interrupt delivery problems, and rather than trying to fix this approach, it has been scrapped in favor of an alternative (and far simpler) implementation. Signed-off-by: Solomon Peachy <pizza@shaftnet.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* cw1200: Don't perform SPI transfers in interrupt contextSolomon Peachy2013-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | When we get an interrupt from the hardware, the first thing the driver does is tell the device to mask off the interrupt line. Unfortunately this involves a SPI transaction in interrupt context. Some (most?) SPI controllers perform the transfer asynchronously and try to sleep. This is bad, and triggers a BUG(). So, work around this by using adding a hwbus hook for the cw1200 driver core to call. The cw1200_spi driver translates this into irq_disable()/irq_enable() calls instead, which can safely be called in interrupt context. Apparently the platforms I used to develop the cw1200_spi driver used synchronous spi_sync() implementations, which is why this didn't surface until now. Many thanks to Dave Sizeburns for the inital bug report and his services as a tester. Signed-off-by: Solomon Peachy <pizza@shaftnet.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* cw1200: Rename 'sbus' to 'hwbus'Solomon Peachy2013-06-031-0/+33
This avoids problems when building on SPARC targets due to the driver calling the bus abstraction layer 'sbus'. Not that any SBUS-sporting SPARC targets are likely to have an SDIO controller, but this is the correct thing to do. See http://kisskb.ellerman.id.au/kisskb/buildresult/8846508/ Signed-off-by: Solomon Peachy <pizza@shaftnet.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>