| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch converts mac80211 and all drivers to have transmit
information and status in skb->cb rather than allocating extra
memory for it and copying all the data around. To make it fit,
a union is used where only data that is necessary for all steps
is kept outside of the union.
A number of fixes were done by Ivo, as well as the rt2x00 part
of this patch.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
With the pending removal of the tx_control structure
we can merge the RX and TX entry private data structure
in advance. This will temporarily increase the required
memory for the queue, but that overhead will only be limited.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
the rxdesc structure is properly memsetted before passed to
the driver. This means we don't have to reinitialize the flags
and dev_flags fields in the drivers again.
This will prevent problems when the rxdone handler is adding
flags in a earlier status and will make the code look nicer
when we are adding more read attributes in the rxdone handler
in the driver.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Split rt2x00lib_write_tx_desc() up into a TX descriptor initializor
and TX descriptor writer.
This split is required to properly allow mac80211 to move its
tx_control structure into the skb->cb array.
The rt2x00queue_create_tx_descriptor() function will read all tx control
information and convert it into a rt2x00 TX descriptor information structure.
After that function is complete, we have all information we needed from the
tx control structure and are free to start writing into the skb->cb array
for our own purposes.
rt2x00queue_write_tx_descriptor() will be in charge of really sending
the TX descriptor to the hardware and kicking the TX queue.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Due to usage of memmove() in rt2x00usb the descriptor can become
corrupted because it is being overwritten by the data part.
Overall having the descriptor in front of the frame is a bad idea,
we can however use the skb->cb array for this task, since that
contains more then enough room to hold the entire descriptor and
preserve the information long enough.
After this we can also cleanup the alignment code a bit to make it
work a bit more flexible to allow for all kinds of odd header lengths.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
feature.
With the integration of the mac80211 multiqueue patches it has become possible that the
mac80211 layer modifies the number of TX queues that is stored inside the ieee80211_hw
structure, especially when multi-queue is not selected.
The rt2x00 drivers are not well suited to handle that situation, as they allocate the
queue structures before mac80211 has modified the number of queues it is going to use,
and also expect the number of allocated queues to match the hardware implementation.
Hence, ensure that rt2x00 maintains by itself the number of queues that the hardware
supports, and, at the same time, making is not dependent on the preservation of contents
inside a mac80211 structure.
Signed-off-by: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Move the last remaining information details read from ieee80211_tx_control
in the drivers to the txentry_desc structure. After this we can
remove ieee80211_tx_control from the argument list for the callback function,
which makes it easier when the control information is moved into skb->cb
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
trying to clean up the signal/noise code. the previous code in mac80211 had
confusing names for the related variables, did not have much definition of
what units of signal and noise were provided and used implicit mechanisms from
the wireless extensions.
this patch introduces hardware capability flags to let the hardware specify
clearly if it can provide signal and noise level values and which units it can
provide. this also anticipates possible new units like RCPI in the future.
for signal:
IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
IEEE80211_HW_SIGNAL_DB - dB difference to unspecified reference point
IEEE80211_HW_SIGNAL_DBM - dBm, difference to 1mW
for noise we currently only have dBm:
IEEE80211_HW_NOISE_DBM - dBm, difference to 1mW
if IEEE80211_HW_SIGNAL_UNSPEC or IEEE80211_HW_SIGNAL_DB is used the driver has
to provide the maximum value (max_signal) it reports in order for applications
to make sense of the signal values.
i tried my best to find out for each driver what it can provide and update it
but i'm not sure (?) for some of them and used the more conservative guess in
doubt. this can be fixed easily after this patch has been merged by changing
the hardware flags of the driver.
DRIVER SIGNAL MAX NOISE QUAL
-----------------------------------------------------------------
adm8211 unspec(?) 100 n/a missing
at76_usb unspec(?) (?) unused missing
ath5k dBm dBm percent rssi
b43legacy dBm dBm percent jssi(?)
b43 dBm dBm percent jssi(?)
iwl-3945 dBm dBm percent snr+more
iwl-4965 dBm dBm percent snr+more
p54 unspec 127 n/a missing
rt2x00 dBm n/a percent rssi+tx/rx frame success
rt2400 dBm n/a
rt2500pci dBm n/a
rt2500usb dBm n/a
rt61pci dBm n/a
rt73usb dBm n/a
rtl8180 unspec(?) 65 n/a (?)
rtl8187 unspec(?) 65 (?) noise(?)
zd1211 dB(?) 100 n/a percent
drivers/net/wireless/ath5k/base.c: Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Add some helper macro's to help determining the
the timeout for USB register access.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Use the rt2x00 queue enumeration as much as possible,
removing the usage of the mac80211 queue numbering
wherever it is possible.
This makes it easier for mac80211 to change it queue
identification scheme without having to deal with
big changes in the rt2x00 code.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
There was an obvious typo in LED structure
initialization which caused the radio and quality/activity
leds to be incorrectly initialized which resulted in
the leds not being enabled.
Additionally add the rt2x00led_led_activity() handler
that will enable TX/RX activity leds when the radio
is being enabled.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Implement triggers inside rt2x00 itself based
on input from mac80211. This replaces the method
of using the mac80211 trigger events which do
not work for USB drivers due to the scheduling
requirement.
After this patch RT2500USB_LEDS and RT73USB_LEDS
no longer need to be tagged as broken since they
now support LED handling again without having to
check for in_atomic().
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The TO_DS filter does not only depend on the FIF_PROMISC_IN_BSS flag
provided by mac80211, but also on the intf_ap_count count.
This makes sense, since when Master mode is active, we should all frames
that are send to the active AP (the device itself).
This means that when an interface is added we should force the
packet filter to be updated during the next mac80211 call of
configure_filter() to make sure the intf_ap_count field is checked.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
drivers/net/usb/rndis_host.c
drivers/net/wireless/b43/dma.c
net/ipv6/ndisc.c
|
|
rt73usb and rt2500usb used in_atomic to determine
if a configuration step should be rescheduled or not.
Since in_atomic() is not a valid method to determine
if sleeping is allowed we should fix the way this is handled
by adding a new flag to rt2x00.
In addition mark LED class support for the drivers broken
since that also uses the broken in_atomic() method but
so far no solution exists to have LED triggers work only
in scheduled context.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The rxdone_entry_desc structure contains 3 fields
which are always 1 or 0. We can safe 8 bytes by
replacing them with a single dev_flags fields which
contain the flags for those settings.
Additionally we can remove the OFDM flag since it
is no longer used since the introduction of the
SIGNAL_PLCP flag.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This adds the id for Corega CG-WLUSB2GPX.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
drivers/net/wireless/rt2x00/rt2x00dev.c
net/8021q/vlan_dev.c
|
|
After sampling hundreds of RX frame descriptors,
the results were conclusive:
- The Ralink documentation regarding the SIGNAL and RSSI are wrong.
It turns out that of the 5 BBR registers, we should not use BBR0 and BBR1
for SIGNAL and RSSI respectively, but actually BBR1 and BBR2.
BBR0 does show values, but the exact meaning remains unclear,
but they cannot be translated into a SIGNAL or RSSI field.
BBR3, BBR4 and BBR5 are always 0, so their meaning is unknown.
As it turns out, the reported SIGNAL is the PLCP value, this
in contradiction to what was expected looking at rt2500pci which
only reported the PLCP values for OFDM rates and bitrate values
for CCK rates.
This means we should let the driver raise the flag about the contents
of the SIGNAL field so rt2x00lib can always do the right thing based
on what the driver reports.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Whatever mode we are in, according to the legacy drivers
we should always enable TSF ticking/counting.
We should also always enable the TBCN/TBTT field,
this field is only disabled during beacon regeneration.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Rename config_preamble() to config_erp() and cleanup argument
list by putting it all into a single structure.
This will make the function more meaningful and easier to
expand later. This second option is mostly intended to make
the patch "mac80211: proper short-slot handling" from Johannes Berg
easier to apply for rt2x00.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
rt2x00lib should filter SW diversity out before sending any configuration
changes to the driver. When rt2x00lib fails to do this, it is important
that such events are reported because it _must_ be fixed.
So upgrading the error level to a BUG_ON() which will make sure
this bug gets noticed whenever it happens.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
rt2x00lib depended on 2 crc algorithms because rt61/rt73
use a different algorithm then rt2800. This means that
even when only 1 algorithm was needed, the dependency was
still present for both.
By moving the checksum generation to the driver we can clean
up 2 annoying flags (which indicated which checksum was required)
and move the dependency to where it belongs: the driver.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Fix trivial log message.
Signed-off-by: Luis Correia <luis.f.correia@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
We should not write 0 to the beacon sync register during
config_intf() since that will clear out the beacon interval
and forces the beacon to be send out at the lowest interval.
(reported by Mattias Nissler).
The side effect of the same bug was that while working with
multiple virtual AP interfaces a change for any of those
interfaces would disable beaconing untill an beacon update
was provided.
This is resolved by only updating the TSF_SYNC value during
config_intf(). In update_beacon() we disable beaconing
temporarily to prevent fake beacons to be transmitted.
Finally kick_tx_queue() will enable beaconing again.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
rxdesc->size is unitialized before the desriptor has been read.
Move the truncation of the sk buffer to the moment all variables
have been initialized.
Signed-off-by: Mattias Nissler <mattias.nissler@gmx.de>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
skbdesc->desc_len is uninitialized at the start
of the function. So it is a _bad_ idea to use it...
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Some architectures give problems when reading
RX frame descriptor words when the descriptor
is not aligned on a 4 byte boundrary.
Due to optimalizations for the ieee80211 payload
4 byte alignment, it is no longer guarenteed
that the descriptor is placed on the 4 byte
boundrary (In fact, for rt73usb it is absolutely
never aligned to 4 bytes, for rt2500usb it depends
on the length of the payload).
This will copy the descriptor to a 4 byte aligned
location before it is read for the first time.
This will also move the payload data alignment
in rt2x00usb (instead of inside the driver) where
it has always belonged.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
On rt73 and rt61 disabling reception of multicast packets also disables
broadcast traffic which we never want to do. Therefore we should never
disable multicast.
Signed-off-by: Adam Baker <linux@baker-net.org.uk>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The async vendor requests are a ugly hack which is not working correctly.
The proper fix for the scheduling while atomic issue is finding out why
we can't use led classes for USB drivers and fix that.
Just replace all async calls with the regular ones and print an
error for the disallowed LED configuration attempts. That will
help in determining which led class is causing the problem.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Don't wildly pass any number for num_rates to rt2x00lib,
instead pass which type of rates are supported (CCK, OFDM).
Same for num_modes but then for the 2GHZ and 5GHZ band.
This makes the interface look much nicer and makes
extending it later easier.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Specifications indicate the TSF registers are read-only,
so there is no point in writing 0 to those registers.
As far as I know there isn't another way to reset the
TSF registers. So removing these callbacks will notify
mac80211 about the lack of support.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The ACK_CTS frame is a control frame, this means
dropping the frame depends on the FIF_CONTROL flag
for filtering.
This also fixes an obvious typo in register definition.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This adds a new flag for the skb_frame_desc structure which is used to tag
rts/cts frames that are generated by the driver. Through the tag we can
recognize frames we have generated ourselves, so we don't report their tx
status to mac80211.
This patch is based on the original patch by
Mattias Nissler <mattias.nissler@gmx.de>.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
mac80211 sends the txpower to use during config(),
we already store it in the rt2x00_dev structure.
When writing the descriptor correctly initialize
the txpower field with this value to make sure
all frames are send out with the correct tx power.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
skbdesc->data_len was not initialized correctly
in rt2x00pci, rt2x00usb, rt2500usb and rt73usb.
The value was set to queue->data_size which
means that the incorrect frame size was pased
to the upper layers.
Correctly base the value on either the skb->len,
or the rx frame size passed to the driver by the
device.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The second eeprom recovery message is about
the RSSI offset for ieee802.11 A.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Remove the debug messages regarding initialization from
EEPROM. The values are vendor specific, and are not really
needed for debug purposes. If they ever become usefull we
still have access to them through debugfs which also
prints the exact same values...
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Add kerneldoc for vendor request functions in rt2x00usb.
Add asynchroneous vendor request function in rt2x00usb.
With the availability of the asynchroneuous vendor request
we can now enable LED class support for rt2500usb and rt73usb.
Since LED handling is not important, it doesn't really matter
if a register call fails (This solution is better then no
LED class support at all).
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Make use of the led triggers provided by mac80211 to control
the led status. This can be enabled through a per-driver
configuration option which will automatically enable the
generic handler in rt2x00lib.
This has been enabled for rt2500usb and rt73usb for the moment
since the led class will call set_brightness in irq context which
will not work correctly with the usb drivers who need to sleep.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch creates new cfg80211 wiphy API for channel and bitrate
registration and converts mac80211 and drivers to the new API. The
old mac80211 API is completely ripped out. All drivers (except ath5k)
are updated to the new API, in many cases I expect that optimisations
can be done.
Along with the regulatory code I've also ripped out the
IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be
unnecessary if the hardware simply gives us whatever channels it wants
to support and we then enable/disable them as required, which is pretty
much required for travelling.
Additionally, the patch adds proper "basic" rate handling for STA
mode interface, AP mode interface will have to have new API added
to allow userspace to set the basic rate set, currently it'll be
empty... However, the basic rate handling will need to be moved to
the BSS conf stuff.
I do expect there to be bugs in this, especially wrt. transmit
power handling where I'm basically clueless about how it should work.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
As Johannes Berg indicated the BEACON and AFTER_BEACON
queue indeces in mac80211 should be removed because they
are too hardware specific. This patch adds the queue index
defines into rt2x00queue.h and removes the dependency of
the defines inside mac80211.h.
Also move rt2x00pci_beacon_update() into rt2400pci and
rt2500pci individually since it is no longer a generic
function since rt61 and rt2800 no longer use that.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
rt73usb doesn't have a 5th queue, correctly initialize hw->queues
rt61pci had a 5th queue but was removed recently, correctly initialize
hw->queues and remove the last remnants.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Rework the interface handling. Delete the interface structure
and replace it with a per-interface structure. This changes the
way rt2x00 handles the active interface drastically.
Copy ieee80211_bss_conf to the this rt2x00_intf structure during
the bss_info_changed() callback function. This will allow us to
reference it later, and removes the requirement for the device flag
SHORT_PREAMBLE flag which is interface specific.
Drivers receive the option to give the maximum number of virtual
interfaces the device can handle. Virtual interface support:
rt2400pci: 1 sta or 1 ap, * monitor interfaces
rt2500pci: 1 sta or 1 ap, * monitor interfaces
rt2500usb: 1 sta or 1 ap, * monitor interfaces
rt61pci: 1 sta or 4 ap, * monitor interfaces
rt73usb: 1 sta or 4 ap, * monitor interfaces
At the moment none of the drivers support AP and STA interfaces
simultaneously, this is a hardware limitation so future support
will be very unlikely.
Each interface structure receives its dedicated beacon entry,
with this we can easily work with beaconing while multiple master
mode interfaces are currently active.
The configuration handlers for the MAC, BSSID and type are
often called together since they all belong to the interface
configuration. Merge the 3 configuration calls and cleanup
the API between rt2x00lib and the drivers. While we are cleaning
up the interface configuration anyway, we might as well clean up
the configuration handler as well.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The driver should select what CRC algorithm is required
when performing a checksum on the firmware.
rt61pci & rt73usb require crc-itu-t
rt2800pci & rt2800usb require crc-ccitt
Legacy 2800pci/usb driver uses crc-itu-t + bit order reversion,
but that is just inefficient especially since the end result is
the same as a different algorithm which is also available as library. ;)
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This introduces a big queue handling overhaul, this also
renames "ring" to "queues".
Move queue handling into rt2x00queue.c and the matching header,
use Kerneldoc to improve rt2x00 library documentation.
Access to the queues is now protected under a spinlock, this
to prevent race conditions which could corrupt the indexing
system of the queue.
Each queue entry allocates x bytes for driver/device specific data,
this cleans up the queue structure significantly and improves
code readability.
rt2500usb no longer needs 2 entries in the beacon queue to correctly
send out the guardian byte. This is now handled in the entry specific
structure.
rt61 and rt73 now use the correct descriptor size for beacon frames,
since this data is written into the registers not the entire TXD
descriptor was used but instead of a subset of it named TXINFO.
Finally this also fixes numerous other bugs related to incorrect
beacon handling or beacon related code.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This adds 2 new states which both are used to toggle
the RX. These new states are required for usage
inside the link tuner thread, because the normal
RX toggling will stop the link tuner thread.
While it is possible that the link tuner thread itself
is the caller of the RX toggle (when using software
antenna diversity).
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
rt2500usb and rt73usb data and desc pointer initialization
was incorrect because it was using uninitialized variables
to determine the length.
In addition rt2500usb used skb_pull and removed the ieee80211
from each received frame instead of using skb_trim to remove
the device descriptor from the frame.
Finally this also fixes the descriptor override when 4 byte
aligning occured. We still need a completely valid descriptor
when using the TX/RX dumping capabilities in debugfs.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
