#
# UWB device configuration
#
menuconfig UWB
tristate "Ultra Wideband devices"
default n
help
UWB is a high-bandwidth, low-power, point-to-point radio
technology using a wide spectrum (3.1-10.6GHz). It is
optimized for in-room use (480Mbps at 2 meters, 110Mbps at
10m). It serves as the transport layer for other protocols,
such as Wireless USB (WUSB).
The topology is peer to peer; however, higher level
protocols (such as WUSB) might impose a master/slave
relationship.
Say Y here if your computer has UWB radio controllers (USB or PCI)
based. You will need to enable the radio controllers
below. It is ok to select all of them, no harm done.
For more help check the UWB and WUSB related files in
.
To compile the UWB stack as a module, choose M here.
if UWB
config UWB_HWA
tristate "UWB Radio Control driver for WUSB-compliant USB dongles (HWA)"
depends on USB
help
This driver enables the radio controller for HWA USB
devices. HWA stands for Host Wire Adapter, and it is a UWB
Radio Controller connected to your system via USB. Most of
them come with a Wireless USB host controller also.
To compile this driver select Y (built in) or M (module). It
is safe to select any even if you do not have the hardware.
config UWB_WHCI
tristate "UWB Radio Control driver for WHCI-compliant cards"
depends on PCI
help
This driver enables the radio controller for WHCI cards.
WHCI is a specification developed by Intel
(http://www.intel.com/technology/comms/wusb/whci.htm) much
in the spirit of USB's EHCI, but for UWB and Wireless USB
radio/host controllers connected via memory mapping (eg:
PCI). Most of these cards come also with a Wireless USB host
controller.
To compile this driver select Y (built in) or M (module). It
is safe to select any even if you do not have the hardware.
config UWB_I1480U
tristate "Support for Intel Wireless UWB Link 1480 HWA"
depends on UWB_HWA
select FW_LOADER
help
This driver enables support for the i1480 when connected via
USB. It consists of a firmware uploader that will enable it
to behave as an HWA device.
To compile this driver select Y (built in) or M (module). It
is safe to select any even if you do not have the hardware.
endif # UWB
ch' size='10' name='q' value=''/>
The static bug finder EBA (http://www.iagoabal.eu/eba/) reported the
following double-lock bug:
Double lock:
1. spin_lock_irqsave(pch->lock, flags) at pl330_free_chan_resources:2236;
2. call to function `pl330_release_channel' immediately after;
3. call to function `dma_pl330_rqcb' in line 1753;
4. spin_lock_irqsave(pch->lock, flags) at dma_pl330_rqcb:1505.
I have fixed it as suggested by Marek Szyprowski.
First, I have replaced `pch->lock' with `pl330->lock' in functions
`pl330_alloc_chan_resources' and `pl330_free_chan_resources'. This avoids
the double-lock by acquiring a different lock than `dma_pl330_rqcb'.
NOTE that, as a result, `pl330_free_chan_resources' executes
`list_splice_tail_init' on `pch->work_list' under lock `pl330->lock',
whereas in the rest of the code `pch->work_list' is protected by
`pch->lock'. I don't know if this may cause race conditions. Similarly
`pch->cyclic' is written by `pl330_alloc_chan_resources' under
`pl330->lock' but read by `pl330_tx_submit' under `pch->lock'.
Second, I have removed locking from `pl330_request_channel' and
`pl330_release_channel' functions. Function `pl330_request_channel' is
only called from `pl330_alloc_chan_resources', so the lock is already
held. Function `pl330_release_channel' is called from
`pl330_free_chan_resources', which already holds the lock, and from
`pl330_del'. Function `pl330_del' is called in an error path of
`pl330_probe' and at the end of `pl330_remove', but I assume that there
cannot be concurrent accesses to the protected data at those points.
Signed-off-by: Iago Abal <mail@iagoabal.eu>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>