* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
net: Fix FDDI and TR config checks in ipv4 arp and LLC.
IPv4: unresolved multicast route cleanup
mac80211: remove association work when processing deauth request
ar9170: wait for asynchronous firmware loading
ipv4: udp: fix short packet and bad checksum logging
phy: Fix initialization in micrel driver.
sctp: Fix a race between ICMP protocol unreachable and connect()
veth: Dont kfree_skb() after dev_forward_skb()
IPv6: fix IPV6_RECVERR handling of locally-generated errors
net/gianfar: drop recycled skbs on MTU change
iwlwifi: work around passive scan issue
Duplicate entries ended up acpisleep_dmi_table[] by accident.
They don't hurt functionality, but they are ugly, so let's get
rid of them.
Cc: stable@kernel.org
Signed-off-by: Alex Chiang <achiang@canonical.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The current code will not remove the sysfs files for fan numbers three
and up. Also, upon exit, fans one and two are removed regardless of
their existence. This patch cleans up the sysfs error handling for
the fans.
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
* Allow fan minimum RPM to be set to zero without triggering alarms.
* Fix voltage scaling arithmetic and correct scale factors.
* Correct fan1-fan4 alarm bit shifts.
* Correct register address for temp3_smoothing_enable.
* Read the alarm registers with high priority.
Signed-off-by: Ken Milmore <ken.milmore@googlemail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Commit b4fe945405 introduced 3 bugs,
fix them:
* Use the right command dword for second packet offset in
RADEON_CNTL_PAINT/BITBLT_MULTI.
* Don't leak memory if drm_buffer_copy_from_user() fails.
* Don't call drm_buffer_unprocessed() unless drm_buffer_alloc() and
drm_buffer_copy_from_user() have been called successfully first.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Pauli Nieminen <suokkos@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When CONFIG_NET is disabled, the attempt to build wext-priv.c
fails with:
net/wireless/wext-priv.c: In function 'ioctl_private_call':
net/wireless/wext-priv.c:207: error: implicit declaration of function 'call_commit_handler'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
s/X/x
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With a little bit of restructuring it isn't necessary to have special
cases in rt2x00queue_write_tx_descriptor for writing the descriptor
for beacons.
Simply split off the kicking of the TX queue to a separate function
with is only called for non-beacons.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to the Ralink vendor driver for rt2800 we don't need a full
TXD for a beacon but just a TXWI in front of the actual beacon.
Fix the rt2800pci and rt2800usb beaconing code accordingly.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Preparation to fix rt2800 beaconing.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
All of the driver's kick_tx_queue callback functions treat the TX queue
for beacons in a special manner.
Clean this up by integrating the kicking of the beacon queue into the
write_beacon callback function, and let the generic code no longer call
the kick_tx_queue callback function when updating the beacon.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
RXWI processing is exactly the same for rt2800pci and rt2800usb, so
make it common code.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
TXWI writing is exactly the same for rt2800pci and rt2800usb, so
make it common code.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We should simply follow what the hardware told us it has done.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove unused RXD_DESC_SIZE define and remove duplicated RXWI definitions
from rt2800.h.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We should take the stripping of the IV into account for the txdesc->length
field.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Tested-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are several places that use > ARRAY_SIZE() instead of
>= ARRAY_SIZE().
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I changed "> ATH9K_HTC_MAX_TID" to ">= ATH9K_HTC_MAX_TID" to avoid a
potential overflow.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is a stray null dereference. We initialize "ista" properly later on.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This mutex_unlock() has been here from the initial commit, but as nearly
as I can tell, there isn't a reason for it.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Paul Shaw <paul.shaw@atheros.com>
Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
From the original report:
"I had problems to get my rtl8185 PCI card running on Sparc64: I always
got an error about "No suitable DMA available" followed by an error
that no device could be detected. When comparing the rtl8180 driver to
others I noticed that others are mostly using DMA_BIT_MASK so I changed
the custom mask to DMA_BIT_MASK(32) which fixed my issue."
Reported-by: Tiziano Müller <tm@dev-zero.ch>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now that core network takes care of trans_start updates, dont do it
in drivers themselves, if possible. Drivers can avoid one cache miss
(on dev->trans_start) in their start_xmit() handler.
Exceptions are NETIF_F_LLTX drivers
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Get the device type from MODULE_BRINGUP_REQ command response.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Move btmrvl hdev registration code out of btmrvl_add_card().
New function btmrvl_register_hdev() is added.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The MODULE_BRINGUP_REQ command response returns success with
either 0x00 or 0x0c.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This is mostly cleanup. There is only one caller and it just checks for
non-zero return values. Still "ret" should be int because we want to return
-EINVAL on errors.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Set the proper error(ENOMEM), instead of just return 0.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
commit 672917dcc7 ("cpuidle: menu governor: reduce latency on exit")
added an optimization, where the analysis on the past idle period moved
from the end of idle, to the beginning of the new idle.
Unfortunately, this optimization had a bug where it zeroed one key
variable for new use, that is needed for the analysis. The fix is
simple, zero the variable after doing the work from the previous idle.
During the audit of the code that found this issue, another issue was
also found; the ->measured_us data structure member is never set, a
local variable is always used instead.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Cc: Corrado Zoccolo <czoccolo@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Although the usbhid driver allocates its usbhid structure in the probe
routine, several critical fields in that structure don't get
initialized until usbhid_start(). However if report descriptor
parsing fails then usbhid_start() is never called. This leads to
problems during system suspend -- the system will freeze.
This patch (as1378) fixes the bug by moving the initialization
statements up into usbhid_probe().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Bruno Prémont <bonbons@linux-vserver.org>
Tested-By: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* 'for-linus' of git://neil.brown.name/md:
md: restore ability of spare drives to spin down.
md/raid6: Fix raid-6 read-error correction in degraded state
* 'urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6:
pcmcia: fix compilation after 16bit state locking changes
pcmcia: order userspace suspend and resume requests
pcmcia: avoid pccard_validate_cis failure in resume callpath
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
blk-cgroup: Fix an RCU warning in blkiocg_create()
blk-cgroup: Fix RCU correctness warning in cfq_init_queue()
drbd: don't expose failed local READ to upper layers
Move initialization of the virtio framework before the initialization of
mtd, so that block2mtd can be used on virtio-based block devices.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15644
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPI: sleep: init_set_sci_en_on_resume for Dell Studio 155x
ACPI: fix acpi_hest_firmware_first_pci() caused oops
sbshc: acpi_device_class "smbus_host_controller" too long
power_meter: acpi_device_class "power_meter_resource" too long
acpi_pad: "processor_aggregator" name too long
PNP: don't check for conflicts with bridge windows
ACPI: DMI init_set_sci_en_on_resume for multiple Lenovo ThinkPads
PNPACPI: compute Address Space length rather than using _LEN
ACPI: silence kmemcheck false positive
* 'v4l_for_2.6.34' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6:
V4L/DVB: pxa_camera: move fifo reset direct before dma start
V4L/DVB: video: testing unsigned for less than 0
V4L/DVB: mx1-camera: compile fix
V4L/DVB: budget: Oops: "BUG: unable to handle kernel NULL pointer dereference"
V4L/DVB: ngene: Workaround for stuck DiSEqC pin
V4L/DVB: saa7146: fix regression of the av7110/budget-av driver
V4L/DVB: v4l: fix config dependencies: mxb and saa7191 are V4L2 drivers, not V4L1
V4L/DVB: feature-removal: announce videotext.h removal
V4L/DVB: V4L - vpfe capture - fix for kernel crash
V4L/DVB: gspca: make usb id 0461:0815 get handled by the right driver
V4L/DVB: gspca - stv06xx: Remove the 046d:08da from the stv06xx driver
V4L/DVB: gspca - sn9c20x: Correct onstack wait_queue_head declaration
V4L/DVB: saa7146: fix up bytesperline if it is an impossible value
V4L/DVB: V4L: vpfe_capture - free ccdc_lock when memory allocation fails
V4L/DVB: V4L - Makfile:Removed duplicate entry of davinci
V4L/DVB: omap24xxcam: potential buffer overflow
rt2800 devices use a different enumeration to specify what IFS values should
be used on frame transmission compared to the other rt2x00 devices. Hence,
create a new enum called txop that contains the valid values.
Furthermore use the appropriate txop values as found in the ralink drivers:
- TXOP_BACKOFF for management frames
- TXOP_SIFS for subsequent fragments in a burst
- TXOP_HTTXOP for all data frames
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, we configure a 128ms hang over period for the PSM entry
(the firmware will remain active for 128ms after sending the null func for
PSM and getting an ack for it.) This is a huge power consumption issue, and
appears unnecessary. So, configure the value to 1 ms.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Janne Ylalehto <janne.ylalehto@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Incresed the timeout value for command complete event waiting from 100
ms to 750 ms. In some rare cases it can take about 600 ms before
complete event for join command is received. This is most propably
caused by the firmware being busy with scanning related activities.
Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch changes the way JOIN's are performed, and channel numbers updated.
The reason for this is that the firmware JOIN command clears WPA(2) key
material, and if done while associated to a WPA(2) secured AP, will render
the data-path unusable.
While the channel is not usually changed while associated (and currently we
could not even support something like that), after performing a scan operation
while associated, mac80211 will re-set the current channel to the driver. This
caused our problem.
Also, the mac80211 is assuming that the driver channel configuration remains
persistent over periods of IDLE. Therefore remove channel resetting to zero
from the unjoin function.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reading single registers did not pay attention to data endianness. This patch
fix that.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch reads the HW PG version (along with a ROM-version, embedded in the
same value) from the wl1271 hardware and publishes the value in a sysfs -file.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Switch LED off/on when handling CONF_CHANGE_IDLE.
Not doing this would leave the radio LED on even
though the chip would be in full sleep mode.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_common (used by ath9k and ath9k_htc) trusts the frames
blessed by hardware as OK are infact correct even if the rate
seen by the driver is unrecognized. ath9k_common just treats
these frames in mac80211 as frames as frames under 1 mbps rate.
It seems this might not be the best thing to do as other parts of
the frame might not be valid so just drop these frames for now.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This has no real functional change, this just moves the setting the
the mac80211 rate index into ath9k_process_rate(). This allows us
to eventually make ath9k_process_rate() return a negative value
in case we have detected a specific case rate situation which should
have been ignored.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Device documentation suggests that hardware support for beaconing
is available. But I implemented software-based beacon generation
as an experiment and it seems better to have that working now rather
than waiting for something better to materialize.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update channel initialization for the RF3052 chipset.
According to the Ralink drivers, the rt3x array must be
used for this chipset, rather then the rt2x array.
Furthermore RF3052 supports the 5GHz band, extend
the rt3x array with the 5GHz channels, and use them
for the RF3052 chip.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The SIFS value is a constant and doesn't need to be updated on erp changes.
Furthermore the code used 10us for both, the OFDM SIFS and CCK SIFS time
which broke CTS protected 11g connections (see patch "rt2x00: rt2800: update
initial SIFS values" for details).
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
used by the Ralink driver nor specified in 802.11.
Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
11g + CTS protected connections. Add a comment to the code why we don't use 10us
for CCK SIFS value.
The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
Ralink drivers).
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The current way of managing beaconing in ad-hoc
mode has a subtle race - the beacon obtained from mac80211
is freed in the SWBA handler rather than the TX
completion routine. But transmission of beacons goes
through the normal SKB queue maintained in hif_usb,
leading to a situation where __skb_dequeue() in the TX
completion handler goes kaput.
Fix this by simply getting a beacon from mac80211 for
every SWBA and free it in its completion routine.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, when one interface switches HT mode,
all others will follow along. This is clearly
undesirable, since the new one might switch to
no-HT while another one is operating in HT.
Address this issue by keeping track of the HT
mode per interface, and allowing only changes
that are compatible, i.e. switching into HT40+
is not possible when another interface is in
HT40-, in that case the second one needs to
fall back to HT20.
Also, to allow drivers to know what's going on,
store the per-interface HT mode (channel type)
in the virtual interface's bss_conf.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
... so orinoco_usb can share some common functionality.
Handle 802.2 encapsulation and MIC calculation in that function.
The 802.3 header is prepended to the SKB. The calculated MIC is written
to a specified buffer. Also modify the transmit control word that will
be passed onto the hardware to specify whether the MIC is present, and
the key used.
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Atheros hardware supports receiving frames that span multiple
descriptors and buffers. In this case, the rx status of every
descriptor except for the last one is invalid and may contain random
data. Because the driver does not support this, it needs to drop such
frames.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch removes the incomplete AMPDU implementation in ar9170usb.
The code in question is:
* too big and complex (more than 550 SLOC.)
This is enough to qualify for a new separate code file!
* unbalanced quantity & quality
over-engineered areas like:
* xmit scheduling and queuing frames for multiple HT peers
* redundant frame sorting
are confronted by gaping holes:
* accurate transmission feedback
* firmware error-handling and device reset
* HT rate control algorithm
* error-prone
Since its inclusion, hardly anything was done to fix
any of the outlined flaws from the initial commit message.
=> This also indicates poor maintainability.
* relies heavily on several spinlocks.
As a result of this shortcomings, the code is slow and does not
even support the most basic 11n requirement: HT station mode.
Therefore, I request to purge my heap of **** from the kernel:
"ar9170: implement transmit aggregation".
The next item on the agenda is: (re-)start from scratch with
an adequate design to accommodate the special requirements
and features of the available frameworks and tools.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a regression introduced by the following patch:
"ar9170: load firmware asynchronously"
When we kick off a firmware loading request and then unbind,
or disconnect the usb device right away, we get into trouble:
> ------------[ cut here ]------------
> WARNING: at lib/kref.c:44 kref_get+0x1c/0x20()
> Hardware name: 18666GU
> Modules linked in: ar9170usb [...]
> Pid: 6588, comm: firmware/ar9170 Not tainted 2.6.34-rc5-wl #43
> Call Trace:
> [<c102b05e>] ? warn_slowpath_common+0x6e/0xb0
> [<c117c93c>] ? kref_get+0x1c/0x20
> [<c102b0b3>] ? warn_slowpath_null+0x13/0x20
> [<c117c93c>] ? kref_get+0x1c/0x20
> [<c117bb2f>] ? kobject_get+0xf/0x20
> [<c124d630>] ? get_device+0x10/0x20
> [<c124e5a0>] ? device_add+0x60/0x530
> [<c117b8b5>] ? kobject_init+0x25/0xa0
> [<c12569f9>] ? _request_firmware+0x139/0x3e0
> [<c1256cc0>] ? request_firmware_work_func+0x20/0x70
> [<c1256ca0>] ? request_firmware_work_func+0x0/0x70
> [<c103ff24>] ? kthread+0x74/0x80
> [<c103feb0>] ? kthread+0x0/0x80
> [<c1003136>] ? kernel_thread_helper+0x6/0x10
>---[ end trace 2d50bd818f64a1b7 ]---
- followed by a random Oops -
Avoid that by waiting for the firmware loading to finish
(whether successfully or not) before the unbind in
ar9170_usb_disconnect.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Bug-fixed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some time ago we stopped the clean/active metadata updates
from being written to a 'spare' device in most cases so that
it could spin down and say spun down. Device failure/removal
etc are still recorded on spares.
However commit 51d5668cb2 broke this 50% of the time,
depending on whether the event count is even or odd.
The change log entry said:
This means that the alignment between 'odd/even' and
'clean/dirty' might take a little longer to attain,
how ever the code makes no attempt to create that alignment, so it
could take arbitrarily long.
So when we find that clean/dirty is not aligned with odd/even,
force a second metadata-update immediately. There are already cases
where a second metadata-update is needed immediately (e.g. when a
device fails during the metadata update). We just piggy-back on that.
Reported-by: Joe Bryant <tenminjoe@yahoo.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Cc: stable@kernel.org
Fix: Raid-6 was not trying to correct a read-error when in
singly-degraded state and was instead dropping one more device, going to
doubly-degraded state. This patch fixes this behaviour.
Tested-by: Janos Haar <janos.haar@netcenter.hu>
Signed-off-by: Gabriele A. Trombetti <g.trombetti.lkrnl1213@logicschema.com>
Reported-by: Janos Haar <janos.haar@netcenter.hu>
Signed-off-by: NeilBrown <neilb@suse.de>
Cc: stable@kernel.org
Add prefetches of the skb and the next rx descriptor to speed up rx path.
Use prefetchw() for the skb [suggested by Eric Dumazet].
The rx descriptor is in skb->data which is mapped for streaming mode DMA.
Eric Dumazet pointed out that we should not prefetch the data before
dma_sync. So we prefetch only if dma_sync is no_op on the system.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
And turn on NETIF_F_GRO by default [requested by DaveM].
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The memory for the private data is allocated using kzalloc in
alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
set it to 0 again.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The memory for the private data is allocated using kzalloc in
alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
set it to 0 again.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The memory for the private data is allocated using kzalloc in
alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
set it to 0 again.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The memory for the private data is allocated using kzalloc in
alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
set the napi member it to 0 explicitely.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The memory for the private data is allocated using kzalloc in
alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
set it to 0 again.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The memory for the private data is allocated using kzalloc in
alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
set it to 0 again.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The memory for the private data is allocated using kzalloc in
alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
set it to 0 again.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The memory for the private data is allocated using kzalloc in
alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
set it to 0 again.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
It's unused and buggy in its current form, since it can place a bo
in the reserved state without removing it from lru lists.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Bring radeon up to speed with the async event synchronization for
drmWaitVblank. See c9a9c5e02a for
more information. Without this patch event never get delivered
to userspace client.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Move the fifo reset from pxa_camera_start_capture to pxa_camera_irq direct
before the dma start after an end of frame interrupt to prevent images from
shifting because of old data at the begin of the frame.
Signed-off-by: Stefan Herbrechtsmeier <hbmeier@hni.uni-paderborn.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
soc_mbus_bytes_per_line() returns -EINVAL on error but we store it in an
unsigned int so the test for less than zero doesn't work. I think it
always returns "small" positive values so we can just cast it to int
here.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This fixes a regression of
7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old names)
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Never call dvb_frontend_detach if we failed to attach a frontend. This fixes
the following oops, which will be triggered by a missing stv090x module:
[ 8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI)
[ 8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29
[ 8.328665] Intel ICH 0000:00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[ 8.328753] Intel ICH 0000:00:1f.5: setting latency timer to 64
[ 8.562047] DVB: Unable to find symbol stv090x_attach()
[ 8.562117] BUG: unable to handle kernel NULL pointer dereference at 000000ac
[ 8.562239] IP: [<e08b04a3>] dvb_frontend_detach+0x4/0x67 [dvb_core]
Ref http://bugs.debian.org/575207
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Send one DiSEqC byte to make sure that the pin is set to low level.
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Reviewed-by: Manu Abraham <abraham.manu@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
An earlier regression fix for the mxb driver (V4L/DVB: saa7146_vv: fix
regression where v4l2_device was registered too late) caused a new
regression in the av7110 driver.
Reverted the old fix and fixed the problem in the mxb driver instead.
Tested on mxb and budget-av cards.
The real problem is that the saa7146 framework has separate probe()
and attach() driver callbacks which should be rolled into one. This
is now done for the mxb driver, but others should do the same. Lack
of hardware makes this hard to do, though. I hope to get hold of some
hexium cards and then I can try to improve the framework to prevent
this from happening again.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As part of upstream merge, set_params() function was removed from isif.c.
This requires removal of BUG_ON() and check for set_params ptr in
vpfe_capture.c. Without this kernel crash dump is seen while bootup on DM365
Also made following changes:-
1) converted error messages to debug messages since it is not right to flood
the console with error messages for user mistakes.
2) returns -EINVAL if ioctl is not supported
Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The 0461:0815 camera is spca561 based not spca508
Signed-off-by: John Ellson <john.ellson@comcast.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The 046d:08da usb id shouldn't be associated with the stv06xx driver as they're
not compatible with each other.
This fixes a bug where Quickcam Messenger cams fail to use its proper driver
(gspca-zc3xx), rendering the camera inoperable.
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Tested-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use DECLARE_WAIT_QUEUE_HEAD_ONSTACK to make lockdep happy
Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
CC: Brian Johnson <brijohn@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
xawtv using DGA on a Radeon graphics card provides bogus
values to S_FBUF, which will then screw up overlay video:
https://bugs.launchpad.net/ubuntu/+source/xawtv/+bug/499734
This fixes the bytesperline value if it is off completely.
Signed-off-by: Michael Hunold <michael@mihu.de>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes a bug in vpfe_probe() that doesn't call mutex_unlock() if memory
allocation for ccdc_cfg fails. See also the smatch warning report from Dan
Carpenter that shows this as an issue.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The previous loop goes until last == VIDEO_MAX_FRAME, so this could
potentially go one past the end of the loop.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add Dell Studio models (1558, 1557, 1555) to the 'set_sci_en_on_resume'
list to fix hang on resume.
BugLink: http://bugs.launchpad.net/bugs/553498
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Alex Chiang <achiang@canonical.com>
Cc: stable@kernel.org
Signed-off-by: Len Brown <len.brown@intel.com>
* 'sh/for-2.6.34' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6:
sh: fix a number of Oopses and leaks in SH framebuffer driver
SH: fix error paths in DMA driver
sh: sh7751 pci controller io port fix
sh: Fix maximum number of SCIF ports in R2D defconfigs
SH: fix TS field shift calculation for DMA drivers
Missing name string in ks8001_driver, so we crash on register.
Reported-by: Ingo Molnar <mingo@elte.hu>
Tested-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the resource_size function instead of manually calculating the
resource size. This reduces the chance of introducing off-by-one
errors.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reset the PHY before first accessing it. Doing so, ensure that the PHY is
in a known good state before we read/write PHY registers. This fixes a
driver probe failure.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
