This reverts commit 5808544690.
To quote Richard:
I don't think this should be mainlined. It was a
misunderstanding on my part. If you see all the other hdc
drivers in the same location, they all do the same thing (i.e.
clear the interrupt status first, then do the work) that
"glitch" I think I saw was actually two back-to-back
interrupts.
Sebastian (the original author of isp1760) explained it to me a
few days after my submission.
sorry for the confusion
Cc: Richard Retanubun <RichardRetanubun@ruggedcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are optional bits that may complement a personality ID. It is
therefore wrong to simply test against the absolute current->personality
value to determine the effective personality. The PER_LINUX_32BIT is
itself just PER_LINUX with one of those optional bits set.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Our SET_PERSONALITY() implementation was overwriting all existing
personality flags, including ADDR_NO_RANDOMIZE, making them unavailable
to processes being exec'd after a call to personality() in user space.
This prevents the gdb test suite from running successfully.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This config option isn't actually used anywhere and can be safely
removed. The last user was traps.c before commit 082f47a ([ARM]
always allow dump_stack() to produce a backtrace, 2007-07-05).
Reviewed-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
USB tethering does not work anymore since 2.6.39-rc2, but it's okay in
-rc1. The root cause is the new added mask code 'FLAG_POINTTOPOINT'
overlaps 'FLAG_MULTI_PACKET' in include/linux/usb/usbnet.h, this
causes logic issue in rx_process(). This patch cleans up the overlap.
Reported-and-Tested-by: Gottfried Haider <gottfried.haider@gmail.com>
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
s3c_pm_show_resume_irqs() is used by some s3c_pm_arch_show_resume_irqs()
implementations, which get included through mach/pm-core.h. Add __maybe_unused
to silence warnings when it isn't used (e.g. on S3C64XX platforms).
Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch fixes build error that occurs on enabling the Samsung
specific PM CRC check code. Missed removing this reference of
s3c_sleep_save_phys during move to generic cpu suspend/resume
support.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
The s3c_pm_check_resume_pin() is not being used and can be safely
removed to fix the build warning.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch disable the optional PM feature inside the Hudson3 platform under
the following conditions:
1. If an isochronous device is connected to xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
in low power state is enabled.
The PM feature needs to be disabled to eliminate PLL startup delays when the
link comes out of low power state. The performance of DMA data transfer could
be impacted if system delay were encountered and in addition to the PLL start
up delays. Disabling the PM would leave room for unpredictable system delays
in order to guarantee uninterrupted data transfer to isochronous audio or
video stream devices that require time sensitive information. If data in an
audio/video stream was interrupted then erratic audio or video performance
may be encountered.
AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
quirk code to pci-quirks.c and export them, xHCI driver can call it directly
without having the quirk implementation in itself.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
On a resume, when the power is lost during hibernate, the USB core will
call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
3.0 roothub:
[ 164.748310] usb usb1: root hub lost power or was reset
[ 164.748353] usb usb2: root hub lost power or was reset
[ 164.748487] usb usb3: root hub lost power or was reset
[ 164.748488] xhci_hcd 0000:01:00.0: Stop HCD
...
[ 164.870039] hub 4-0:1.0: hub_resume
...
[ 164.870054] hub 3-0:1.0: hub_reset_resume
This causes issues later, because the USB core assumes the USB 3.0 hub
attached to the USB 3.0 roothub is still active. It attempts to queue a
control URB for the external hub, which fails because all the device
slot contexts were released when the USB 3.0 roothub lost power:
[ 164.980044] hub 4-1:1.0: hub_resume
[ 164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
[ 164.980049] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
[ 164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
[ 164.980062] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status = 0x2e1
[ 164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status = 0x2a0
[ 164.980074] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
[ 164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980082] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
[ 164.980091] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980094] hub 4-1:1.0: activate --> -22
[ 164.980113] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980119] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980123] hub 4-1:1.0: can't resume port 4, status -22
[ 164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
[ 164.980129] usb 4-1.4: can't resume, status -22
[ 164.980131] hub 4-1:1.0: logical disconnect on port 4
This causes issues when a USB 3.0 hard drive is attached to the external
USB 3.0 hub when the system is hibernated:
[ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
[ 6249.849659] sd 8:0:0:0: [sdb] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
[ 6249.849671] end_request: I/O error, dev sdb, sector 10760
Make sure to inform the USB core that *both* xHCI roothubs lost power.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch clear PORT_POWER when suspend a USB3.0 device behind a USB3.0
external hub, so the system can suspend and resume.
Note USB3.0 device may not work after system resume and this is a temporary
workaround. The correct fix will be in future patches.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If I unplug a device while the UAS driver is loaded, I get an oops
in usb_free_streams(). This is because usb_unbind_interface() calls
usb_disable_interface() which calls usb_disable_endpoint() which sets
ep_out and ep_in to NULL. Then the UAS driver calls usb_pipe_endpoint()
which returns a NULL pointer and passes an array of NULL pointers to
usb_free_streams().
I think the correct fix for this is to check for the NULL pointer
in usb_free_streams() rather than making the driver check for this
situation. My original patch for this checked for dev->state ==
USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is
conditional, so not all drivers would want this check.
Note from Sarah Sharp: This patch does avoid a potential dereference,
but the real fix (which will be implemented later) is to set the
.soft_unbind flag in the usb_driver structure for the UAS driver, and
all drivers that allocate streams. The driver should free any streams
when it is unbound from the interface. This avoids leaking stream rings
in the xHCI driver when usb_disable_interface() is called.
This should be queued for stable trees back to 2.6.35.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Currently, when resetting a device, xHCI driver disables all but one
endpoints and frees their rings, but leaves alone any streams that
might have been allocated. Later, when users try to free allocated
streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
ep->ring is NULL.
Let's free not only rings but also stream data as well, so that
calling free_streams() on a device that was reset will be safe.
This should be queued for stable trees back to 2.6.35.
Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
The recent commit (10774912647781) wasn't entirely correct. While
it fixed some issues, it introduced others. So pull in the fixes
from the public cache flush functions, and document why we need to
call things directly ourselves.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
If the period of a gptimer is fairly low, we might miss an interrupt
by acking it too late (we end up acking the new int as well).
Reported-by: Isabelle Leonardi <i.leonardi@detracom.fr>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We only want to clear the run bit for this one timer, not all status bits.
So don't read the whole reg and then write all the bits back out.
Reported-by: Isabelle Leonardi <i.leonardi@detracom.fr>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When suspending/resuming, the common task freezing code will run in
parallel and freeze processes on each core. This is because the code
uses the non-smp version of memory barriers (as well it should).
The Blackfin smp barrier logic at the moment contains the cache sync
logic, but the non-smp barriers do not. This is incorrect as Rafel
summarized:
> ...
> The existing memory barriers are SMP barriers too, but they are more
> than _just_ SMP barriers. At least that's how it is _supposed_ to be
> (eg. rmb() is supposed to be stronger than smp_rmb()).
> ...
> However, looking at the blackfin's definitions of SMP barriers I see
> that it uses extra stuff that should _also_ be used in the definitions
> of the mandatory barriers.
> ...
URL: http://lkml.org/lkml/2011/4/13/11
LKML-Reference: <BANLkTi=F-C-vwX4PGGfbkdTBw3OWL-twfg@mail.gmail.com>
Signed-off-by: Graf Yang <graf.yang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When we get a port status change event, we need to figure out what type of
port it came from: a USB 3.0 port, or a USB 2.0/1.1 port. We can't know
which usb_hcd to use until that point, so hcd will be NULL for part of the
function. Unfortunately, if any of the sanity checks fail, we'll jump to
the cleanup label before hcd is set to a valid pointer, and then we'll
attempt to tell the USB core to kick the hcd, which is NULL.
Skip kicking the roothub if the sanity checks fail.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When parsing exponent-expressed intervals we subtract 1 from the
value and then expect it to match with original + 1, which is
highly unlikely, and we end with frequent spew:
usb 3-4: ep 0x83 - rounding interval to 512 microframes
Also, parsing interval for fullspeed isochronous endpoints was
incorrect - according to USB spec they use exponent-based
intervals (but xHCI spec claims frame-based intervals). I trust
USB spec more, especially since USB core agrees with it.
This should be queued for stable kernels back to 2.6.31.
Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
The logic of the handling Missed Service Error Events was pretty
confusing as we were checking the same condition several times.
In addition, it caused compiler warning since the compiler could
not figure out that event_trb is actually unused in case we are
skipping current TD.
Fix that by rearranging "skip" condition checks, and factor out
skip_isoc_td() so that it is called explicitly.
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Remove 'inline' markings from file-local functions and let compiler
do its job and inline what makes sense for given architecture.
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
There were some places that compared port_speed == -1 where port_speed
is a u8. This doesn't work unless we cast the -1 to u8. Some places
did it correctly.
Instead of using -1 directly, I've created a DUPLICATE_ENTRY define
which does the cast and is more descriptive as well.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Macro arguments used in expressions need to be enclosed in parenthesis
to avoid unpleasant surprises.
This should be queued for kernels back to 2.6.31
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Isochronous and interrupt SuperSpeed endpoints use the same mechanisms
for decoding bInterval values as HighSpeed ones so adjust the code
accordingly.
Also bandwidth reservation for SuperSpeed matches highspeed, not
low/full speed.
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch moves the HcInterrupt register write to clear the
pending interrupt to after the isr work is done, doing this removes
glitches in the irq line.
Signed-off-by: Richard Retanubun <richardretanubun@ruggedcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The driver did not take the zero flag in the USB request. If the
request length is the same as the endpoint's maxpacket, an additional
ZLP with no data has to be transmitted.
The method used here is inspired to what is done in fsl_udc_core.c
(and pxa27x_udc.c and at91_udc.c) where this is supported.
There already was a discussion about this topic with people from
Keymile, and I propose here a better implementation:
http://thread.gmane.org/gmane.linux.usb.general/38951
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Acked-by: Li Yang <leoli@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are two -ENODEV error paths in qcprobe where the allocated private
data is not freed, this patch adds the two missing kfrees to avoid
leaking memory on the error path
Signed-off-by: Steven Hardy <shardy@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rework the qcprobe logic such that serial->private is not set when
qcprobe exits with -ENODEV, otherwise serial->private will point to freed
memory on -ENODEV
Signed-off-by: Steven Hardy <shardy@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
qcprobe function allocates serial->private but this is never freed, this
patch adds a new function qc_release() which frees serial->private, after
calling usb_wwan_release
Signed-off-by: Steven Hardy <shardy@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usb serial: ftdi_sio: add two missing USB ID's for Hameg interfaces HO720
and HO730
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bind only modem AT command endpoint to option.
Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There was an unlock missing on the error path.
Also I did a small cleanup by changing ep->dev->lock for just dev->lock.
They're the same lock, but dev->lock is shorter and that's how it is
used for the spin_unlock_irqrestore() call.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Booting latest kernel on my test machine produces a lockdep
warning from the usb_amd_find_chipset_info() function:
WARNING: at /data/lemmy/linux.trees.git/kernel/lockdep.c:2465 lockdep_trace_alloc+0x95/0xc2()
Hardware name: Snook
Modules linked in:
Pid: 959, comm: work_for_cpu Not tainted 2.6.39-rc2+ #22
Call Trace:
[<ffffffff8103c0d4>] warn_slowpath_common+0x80/0x98
[<ffffffff812387e6>] ? T.492+0x24/0x26
[<ffffffff8103c101>] warn_slowpath_null+0x15/0x17
[<ffffffff81068667>] lockdep_trace_alloc+0x95/0xc2
[<ffffffff810ed9ac>] slab_pre_alloc_hook+0x18/0x3b
[<ffffffff810ef227>] kmem_cache_alloc_trace+0x25/0xba
[<ffffffff812387e6>] T.492+0x24/0x26
[<ffffffff81238816>] pci_get_subsys+0x2e/0x73
[<ffffffff8123886c>] pci_get_device+0x11/0x13
[<ffffffff814082a9>] usb_amd_find_chipset_info+0x3f/0x18a
...
It turns out that this function calls pci_get_device under a spin_lock
with irqs disabled, but the pci_get_device function is only allowed in
preemptible context.
This patch fixes the warning by making all data-structure
modifications on temporal storage and commiting this back
into the visible structure at the end. While at it, this
patch also moves the pci_dev_put calls out of the spinlocks
because this function might sleep too.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In file included from drivers/usb/host/ohci-hcd.c:1028:0:
drivers/usb/host/ohci-au1xxx.c:36:7: warning: "__BIG_ENDIAN" is not defined
Signed-off-by: Yoichi Yuasa <yuasa@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add PID 0x0103 for serial port of the OCT DK201 docking station.
Reported-by: Jan Hoogenraad <jan@hoogenraad.net>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix build failure introduced by commit
7acc6197b7 (usb: musb: Idle path retention
and offmode support for OMAP3) when building without gadget
support.
CC drivers/usb/musb/omap2430.o
drivers/usb/musb/omap2430.c: In function ‘musb_otg_notifications’:
drivers/usb/musb/omap2430.c:262: error: ‘struct musb’ has no member named ‘gadget_driver’
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1458) fixes a problem affecting ultra-reliable systems:
When hardware failover of an EHCI controller occurs, the data
structures do not get released correctly. This is because the routine
responsible for removing unused QHs from the async schedule assumes
the controller is running properly (the frame counter is used in
determining how long the QH has been idle) -- but when a failover
causes the controller to be electronically disconnected from the PCI
bus, obviously it stops running.
The solution is simple: Allow scan_async() to remove a QH from the
async schedule if it has been idle for long enough _or_ if the
controller is stopped.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-Tested-by: Dan Duval <dan.duval@stratus.com>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
During processing of bunch of eem frames if "echo" command is found
skb is cloned and the cloned version should be used to send reply.
Unfortunately, the data of the original skb were actually used and
the cloned skb is never freed.
Using the cloned skb and freeing the skb in the completion callback
for usb request.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@nokia.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I added new ProdutIds for two devices from CTI GmbH Leipzig.
Signed-off-by: Christian Simon <simon@swine.de>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Because the disconnect function in the composite driver will call spin_lock,
this driver has to call spin_unlock before calling driver->disconnet().
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Disable USB_ARCH_HAS_EHCI in arch Kconfig and enable it in usb Kconfig
Warning log:
warning: (MICROBLAZE) selects USB_ARCH_HAS_EHCI which has unmet
direct dependencies (USB_SUPPORT)
Signed-off-by: Michal Simek <monstr@monstr.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ep_read() acquires data->lock mutex in get_ready_ep() and releases it on
all paths except for one: when usb_endpoint_xfer_isoc() failed. The
patch adds mutex_unlock(&data->lock) at that path.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix printk format build warning and grammar typo on same line.
drivers/usb/host/isp1760-hcd.c:300: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'size_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-greg' of git://gitorious.org/usb/usb:
USB: musb: blackfin: work around anomaly 05000450
usb: musb: Fix the crash issue during reboot
usb: musb: gadget: check the correct list_head
usb: musb: temporarily make it bool
USB: musb: dereferencing an iomem pointer
USB: musb: silence printk format warning
USB: musb: using 0 instead of NULL
USB: musb: add missing unlock in cppi_interrupt()
usb: musb: ux500: copy dma mask from platform device to musb device
usb: musb: clear AUTOSET while clearing DMAENAB
In the function blk_register_queue(), var _dev_ is already assigned by
disk_to_dev().So use it directly instead of calling disk_to_dev() again.
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
Modified by me to delete an empty line in the same function while
in there anyway.
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
priv->tx_power_next is not initialized to max supported power,
but instead default value is used, what cause errors like
[ 58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14.
[ 58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22).
if maximum tx power read from the eeprom is smaller than default.
In consequence card is unable to initialize properly. Fix the problem
and cleanup tx power initialization.
Reported-and-tested-by: Robin Dong <hao.bigrat@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
