SDIO works (more or less), so remove the BROKEN dependency and
let people test it.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix the following build error when CONFIG_B43_LEDS is not selected:
drivers/net/wireless/b43/main.c: In function 'b43_remove':
drivers/net/wireless/b43/main.c:4990: error: 'struct b43_leds' has no member named 'stop'
drivers/net/wireless/b43/main.c:4991: error: 'struct b43_leds' has no member named 'work'
make[4]: *** [drivers/net/wireless/b43/main.o] Error 1
Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Don't abuse wl->current_dev in the LED work for checking whether we're
going down. Add an explicit variable.
This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
in various other places of the driver.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The current verison of b43 uses "b43_phyop_switch_analog_generic" for A,
G and LP phys.
According to the spec, this is the wrong behaviour for the LP PHY
(see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore )
While no problems on the x86 plattform where seen, this leads to a crash
on the BCM5354 SoC (MIPS 32 LE plattform).
This patch implements the analog switch for LP PHYs according to the
specs. It fixes the crash
signed-off-by: Thomas Ilnseher <illth@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reduces IRQ pressure by about one third on a saturated link
by disabling the PMQ mechanism. We currently don't use that mechanism.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds support for verbose runtime statistics.
It defaults to off and must be enabled in debugfs, if desired.
The first measurement may be incorrect, because statistics are not cleared
after they got enabled through debugfs.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
synchronize_irq is meaningless for SDIO. sdio_release_irq will
sync the IRQ thread for us.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We need to release the SDIO host before locking the driver mutex.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds support for Soft-MAC SDIO devices to b43.
The driver still lacks some fixes for SDIO devices, so it's currently
marked as BROKEN.
Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This removes most of the b43 suspend/resume code (it's handled by mac80211)
and moves the registration of devices to the attachment phase. This is
required, because we must not register/unregister devices on suspend/resume.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix printk format warnings:
drivers/ssb/sdio.c:336: warning: format '%u' expects type 'unsigned int', but argument 7 has type 'size_t'
drivers/ssb/sdio.c:443: warning: format '%u' expects type 'unsigned int', but argument 7 has type 'size_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When an SPROM revision is not recognized, the code falls back to a V1
SPROM; however, that revision is not forced in the appropriate structure.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's a bug in 4965 powersave that appears to
be related to the way it keeps track of its data
during sleep, but we haven't found it yet. Due to
that, using powersave may spontaneously cause the
device to SYSASSERT when transitioning from sleep
to wake. Therefore, disable powersave for 4965,
until (if ever, unfortunately) we can identify
and fix the problem.
Cf. http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1982
which was closed, but now has re-appeared with
IDLE mode, which probably means we never really
fixed it.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We can not assume antenna "A" is the first valid anttena for
all the NIC. Need to make sure choice the correct antenna based on
h/w configuration for transmit to avoid sending frame on invalid
antenna
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
RX handling maintains a few lists that keep track of the RX buffers.
Buffers move from one list to the other as they are used, replenished, and
again made available for usage. In one such instance, when a buffer is used
it enters the "rx_used" list. When buffers are replenished an skb is
attached to the buffer and it is moved to the "rx_free" list. The problem
here is that the buffer is first removed from the "rx_used" list _before_ the
skb is allocated. Thus, if the skb allocation fails this buffer remains
removed from the "rx_used" list and is thus lost for future usage.
Fix this by first allocating the skb before trying to attach it to a list.
We add an additional check to not do this unnecessarily.
Reported-by: Rick Farrington <rickdic@hotmail.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we cleaned up the driver to properly tell mac80211 about HT rates
("iwlwifi: use iwl_hwrate_get_mac80211_idx where appropriate"), we broke
internal rate indexing in 2.4 GHz band.
Signed-off-by: Daniel C Halperin <daniel.c.halperin@intel.com>
Tested-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes a resume failure where a signal is pending on resume
so the firmware upload fails.
This removes the interruptible sleep, because we don't really need it.
In the worst case (with broken firmware) the sleep loop will take 1 second.
In the common case (working firmware), it will only take a few milliseconds.
So we don't really need to be interruptible.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When processing MIB interrupts, OFDM and CCK error
handling routines for low RSSI values have to be invoked
only when the channel mode is 11G/11B. Since HT channels
will also fall under the bands 2Ghz/5Ghz, check appropriately.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Force wake the mac80211 queues on init.
Under rare circumstances they may be stopped, if a DMA error or
something else causes a device reset while a queue was stopped.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As the hostap driver was converted to use net_device_ops, a mistake was
made in hostap_main.c (commit 5ae4efbcd2).
Originally, the tx_queue_len was set to 0 for every other interface than
HOSTAP_INTERFACE_MASTER, but the new fragment of code sets tx_queue_len to
0 only for HOSTAP_INTERFACE_MASTER. The opposite of the previous
behavior makes the driver to drop all packets in AP mode.
Change the way 0 is assigned to tx_queue_len according to the original
logic.
Signed-off-by: Martin Decky <martin@decky.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fixes `s3c_fb_remove' referenced in section `.data' of
drivers/built-in.o: defined in discarded section `.devexit.text' of
drivers/built-in.o
With CONFIG_HOTPLUG=n, functions marked with __devexit gets removed,
so make sure we use __devexit_p when referencing pointers to them.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Acked-by: Ben Dooks <ben-linux@fluff.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/video/tmiofb.c: In function 'tmiofb_resume':
drivers/video/tmiofb.c:977: warning: 'retval' may be used uninitialized in this function
Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fbcon makes the (reasonable) assumption that it only needs to program the
hardware once, when fbcon_init() is called for the foreground console.
This doesn't always play well with vgacon because vgacon_deinit() is only
doing its job when the last console it owns is closed (when switching from
vgacon to fbcon, that's usually *after* fbcon_init() has set the new
mode).
Depending on the hardware this can cause the wrong framebuffer location to
be scanned out (e.g. reproduced on nv05 with the nouveau framebuffer
driver).
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Attempting to unload a framebuffer module calls unregister_framebuffer()
which in turn gets fbcon to release it. If fbcon has no framebuffers
linked to a console, it will also unbind itself from the console driver.
However, if fbcon never registered itself as a console driver, the unbind
will fail causing the framebuffer device entry to persist. In most cases
this failure will result in an oops when attempting to access the now
non-existent device.
This patch ensures that the fbcon unbind request will succeed even if a
bind was never done. It tracks if a successful bind ever occurred & will
only attempt to unbind if needed. If there never was a bind, it simply
returns with no error.
Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I would like to get rid of option CONFIG_FB_MATROX_MULTIHEAD and just
always enable it. There are many reasons for doing this:
* CONFIG_FB_MATROX_MULTIHEAD=y is what all x86 distributions do, so it
definitely works or we would know by now.
* Building the matroxfb driver with CONFIG_FB_MATROX_MULTIHEAD not set
results in the following build warning:
drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_open':
drivers/video/matrox/matroxfb_crtc2.c:265: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true'
drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_release':
drivers/video/matrox/matroxfb_crtc2.c:285: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true'
This is nothing to be worried about, the driver will work fine, but build
warnings are still annoying.
* The trick to get multihead support without CONFIG_FB_MATROX_MULTIHEAD,
which is described in the config help text, no longer works: you can't
load the same kernel module more than once.
* I fail to see how CONFIG_FB_MATROX_MULTIHEAD=y would make the code
significantly slower, contrary to what the help text says. A few extra
parameters on the stack here and there can't really slow things down in
comaprison to the rest of the code, and register access.
* The driver built without CONFIG_FB_MATROX_MULTIHEAD is larger than the
driver build with CONFIG_FB_MATROX_MULTIHEAD=y by 8%.
* One less configuration option makes things simpler. We add options
all the time, being able to remove one for once is nice. It improves
testing coverage. And I don't think the Matrox adapters are still
popular enough to warrant overdetailed configuration settings.
* We should be able to unobfuscate the driver code quite a bit after
this change (patches follow.)
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
At the moment about half of the framebuffer drivers can return an error
code in fb_set_par. Until now it would be silently ignored by fbmem.c
and fbcon.c. This patch fixes fbmem.c to return the error code and
restore var on error.
But it is not clear in which video mode the device is when fb_set_par
fails. It would be good and reasonable if it were in the old state but
there is no guarantee that this is true for all existing drivers.
Additionally print a message if a failing fb_set_par is detected in
fbmem.c or fbcon.c.
Although most errors should be caught by the previous fb_check_var some
errors can't as they are dynamic (memory allocations, ...) and can only be
detected while performing the operations which is forbidden in
fb_check_var.
This patch shouldn't have a negative impact on normal operation as all
drivers return 0 on success. The impact in case of error depends heavily
on the driver and caller but it's expected to be better than before.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In the final part of the calculation for the tft display clockrate we
divide the output pf s3c2410fb_calc_pixclk() by 2 which leaves us with a
rounding error if the result is odd.
Change to using DIV_ROUND_UP() to ensure that we always choose a higher
divisor and thus a lower frequency.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix the range check for panning. The current code fails to detect some
invalid values (very high ones that can occur if an app tries to move
further up/left than 0,0) as the check uses the unknown values for
calculation so that an overflow can occur.
To fix this it is sufficient to move the calculation to the right side to
use only trusted values.
Kai Jiang detected this problem and proposed an initial patch.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Kai Jiang <b18973@freescale.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Check that the result of kmalloc is not NULL before passing it to other
functions.
The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
expression *x;
identifier f;
constant char *C;
@@
x = \(kmalloc\|kcalloc\|kzalloc\)(...);
... when != x == NULL
when != x != NULL
when != (x || ...)
(
kfree(x)
|
f(...,C,...,x,...)
|
*f(...,x,...)
|
*x->f
)
// </smpl>
[akpm@linux-foundation.org: convert to kstrdup() as well]
Signed-off-by: Julia Lawall <julia@diku.dk>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The main motivation of this patch was to merge the three initialization
functions in one and clean it up. However as some changes in other code
areas where needed to do it right some small other changes were made.
Changes to viafb_par:
io_virt renamed as engine_mmio and moved to shared
VQ_start renamed as vq_vram_addr and moved to shared
VQ_end removed as it is easily recalculatable
vq_vram_addr is not strictly needed but keep it to track where we
allocated video memory. The memory allocated for the virtual queue was
shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to
be honest I don't have the faintest idea what virtual queues are for in
the graphic hardware and whether the driver needs them in any way. I only
know that they aren't directly accessed by the driver and so the only
potential current use would be as hardware internal buffers. For now keep
them to avoid regressions and only remove the double cursor allocation.
The most changes were caused by renames and the mentioned structure
changes so the chance of regressions is pretty low. The meaning of
viafb_accel changed slightly as previously it was changed back and forth
in the code and allowed to enable the hardware acceleration by software if
previously disabled. The new behaviour is that viafb_accel=0 always
prevents hardware acceleration. With viafb_accel!=0 the acceleration can
be freely choosen by set_var. This means viafb_accel is a diagnostic tool
and if someone has to use viafb_accel=0 the driver needs to be fixed.
As this is mostly a code cleanup no regressions beside the slightly change
of viafb_accel is expected.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Harald Welte <laforge@gnumonks.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Split the pitch handling up and replaces the calculation from virtual xres
and bpp with fix.line_length which already contains the pitch and does not
add any constrains for the virtual resolution.
Also add a bit to the second pitch which the documentation mentions but
which was ignored by the driver.
Although it is a bit unclear what the right pitch for some LCD modes is
this patch should have no negative runtime impact.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Harald Welte <laforge@gnumonks.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Clean the hardware cursor handling up.
The most notable change is that it no longer buffers the values in
viacursor but uses the ones in cursor instead as they are guaranteed to be
always valid.
Furthermore it uses local instead global variables where possible, moves
the cursor variable in shared as only one hardware cursor is supported and
returns an error if memory allocation fails. Last but not least it fixes
a too small buffer (as u32 has only 4 and not 32 bytes) but this did not
produce any known problems.
This is mostly a code cleanup, no negative runtime changes are expected.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Harald Welte <laforge@gnumonks.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
