Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 21 6月, 2012 3 次提交
  3. 20 6月, 2012 6 次提交
  5. 19 6月, 2012 1 次提交
  7. 14 6月, 2012 1 次提交
    • M
      ath9k: Fix softlockup in AR9485 · bcb7ad7b
      由 Mohammed Shafi Shajakhan 提交于 
      steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up

	Call Trace:
	[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
	[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
	[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
	[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
	[<ffffffff810744fe>] process_one_work+0x11e/0x470
	[<ffffffff8107530f>] worker_thread+0x15f/0x360
	[<ffffffff810751b0>] ? manage_workers+0x230/0x230
	[<ffffffff81079af3>] kthread+0x93/0xa0
	[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
	[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
	[<ffffffff815fd3a0>] ? gs_change+0x13/0x13

ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
is needed to recover from some rare beacon stuck during stress testing.
Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
always seem to have zero even though we had configured PLL3(0x16188) to
query about PLL's locking status. When we keep on polling infinitely PLL4's
8th bit(ie check for PLL locking measurements is done), machine hangs
due to softlockup.

fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142Reported-by: NRolf Offermanns <rolf.offermanns@gmx.net>
Cc: stable@vger.kernel.org [3.0+]
Tested-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bcb7ad7b
  9. 13 6月, 2012 1 次提交
  11. 12 6月, 2012 4 次提交
    • G
      Bluetooth: add support for atheros 0930:0219 · 6c4ae5c2
      由 Giancarlo Formicuccia 提交于 
      Add support for the AR3012 chip found on the Toshiba Sallite M840-1000-XQ.

usb-devices shows:

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0930 ProdID=0219 Rev=00.02
S:  Manufacturer=Atheros Communications
S:  Product=Bluetooth USB Host Controller
S:  SerialNumber=Alaska Day 2006
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
Signed-off-by: NGiancarlo Formicuccia <giancarlo.formicuccia@gmail.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      6c4ae5c2
    • J
      rndis_wlan: fix matching bssid check in rndis_check_bssid_list() · b0fd49b7
      由 Jussi Kivilinna 提交于 
      rndis_check_bssid_list() originally tried to check if bssid->mac and
match_bssid are equal using compare_ether_addr() when it should use
!compare_ether_addr(). This check was added by commit
b5257c95 as part of workaround for
hardware issue.

Commit 2e42e474 that replaced
compare_ether_addr with ether_addr_equal relieved that this compare
to be inverse of what it should be.

Compare was added as response to hardware bug, where bssid-list does
not contain BSSID and other information of currently connected AP
(spec insists that device must provide this information in the list
when connected). Lack bssid-data on current connection then causes
WARN_ON somewhere in cfg80211. Workaround was to check if bssid-list
returns current bssid and if it does not, manually construct bssid
information in other ways. And this workaround worked, with inverse
check. Which must mean that when hardware is experiencing the problem,
it's actually returning empty bssid-list and this check didn't make
any difference for workaround.

However inverse check causes workaround be activated when bssid-list
returns only entry, currently connected BSSID. That does not cause
problems in itself, just slightly more inaccurate information in
scan-list.

Cc: Joe Perches <joe@perches.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b0fd49b7
    • M
      ath9k: remove incompatible IBSS interface check in change_iface · a23415fd
      由 Mohammed Shafi Shajakhan 提交于 
      'cfg80211: fix interface combinations' ensures that if an interface
type is not advertised by the driver in any of the interface combinations
(via ieee80211_iface_combination) then it shall be treated as a single
incompatible interface. if there are more than one interfaces present
and changing them to incompatible interface type is not possible.
These checks will be properly handled by cfg80211_change_iface ->
cfg80211_can_change_interface.

this patch is dependent on 'cfg80211: fix interface combinations'
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a23415fd
    • M
      ath9k: Fix a WARNING on suspend/resume with IBSS · 2031b4c2
      由 Mohammed Shafi Shajakhan 提交于 
      this patch is dependent on the patch "cfg80211: fix interface
combinations"

In ath9k currently we have ADHOC interface as a single incompatible
interface. when drv_add_interface is called during resume we got to
consider number of vifs already present in addition to checking the
drivers 'opmode' information about ADHOC.  we incorrectly assume
an ADHOC interface is already present. Then we may miss some driver
specific data for the ADHOC interface after resume.

The above mentioned checks can be removed from the driver,
as the patch 'cfg80211: fix interface combinations' ensures that
if an interface type is not advertised by the driver in any of the
interface combinations(via ieee80211_iface_combination) then it shall
be treated as a single incompatible interface. Fixes the following
warning on suspend/resume with ibss interface.

        ath: phy0: Cannot create ADHOC interface when other
        interfaces already exist.
        WARNING: at net/mac80211/driver-ops.h:12
        ieee80211_reconfig+0x1882/0x1ca0 [mac80211]()
        Hardware name: 2842RK1
        wlan2:  Failed check-sdata-in-driver check, flags: 0x0

        Call Trace:
        [<c01361b2>] warn_slowpath_common+0x72/0xa0
        [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
        [mac80211]
        [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
        [mac80211]
        [<c0136283>] warn_slowpath_fmt+0x33/0x40
        [<f8aaa7c2>] ieee80211_reconfig+0x1882/0x1ca0 [mac80211]
        [<c06c1d1a>] ? mutex_lock_nested+0x23a/0x2f0
        [<f8a95097>] ieee80211_resume+0x27/0x70 [mac80211]
        [<fd177edf>] wiphy_resume+0x8f/0xa0 [cfg80211]

Cc: stable@vger.kernel.org
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2031b4c2
  13. 10 6月, 2012 1 次提交
    • M
      Bluetooth: Support AR3011 in Acer Iconia Tab W500 · 6eda541d
      由 Marek Vasut 提交于 
      Acer used this chip connected via USB:

Bus 005 Device 005: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          224 Wireless
  bDeviceSubClass         1 Radio Frequency
  bDeviceProtocol         1 Bluetooth
  bMaxPacketSize0        64
  idVendor           0x0cf3 Atheros Communications, Inc.
  idProduct          0x3005 AR3011 Bluetooth
  bcdDevice            0.01
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      6eda541d
  15. 09 6月, 2012 8 次提交
  17. 06 6月, 2012 2 次提交
  19. 05 6月, 2012 8 次提交
    • J
      iwlwifi: disable WoWLAN if !CONFIG_PM_SLEEP · fcb6ff5e
      由 Johannes Berg 提交于 
      If CONFIG_PM_SLEEP is disabled, then iwlwifi doesn't
support suspend/resume handlers and thus mac80211
(correctly) refuses advertising WoWLAN. Disable
WoWLAN in the driver in this case.

Cc: stable@kernel.org
Reported-by: NSebastian Kemper <sebastian_ml@gmx.net>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fcb6ff5e
    • S
      bcma: add ext PA workaround for BCM4331 and BCM43431 · 69aaedd3
      由 Seth Forshee 提交于 
      MacBook Pro models with BCM4331 wireless have been found to have the ext
PA lines disabled after resuming from S3 without external power attach.
This causes them to be unable to transmit. Add a workaround to ensure
that the ext PA lines are enabled on BCM4331. Also extend all handling
of ext PA line muxing to BCM43431 as is done in the Broadcom SDK.

BugLink: http://bugs.launchpad.net/bugs/925577
Cc: Arend van Spriel <arend@broadcom.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: stable@vger.kernel.org
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      69aaedd3
    • S
      rt2x00: use atomic variable for seqno · e5851dac
      由 Stanislaw Gruszka 提交于 
      Remove spinlock as atomic_t can be used instead. Note we use only 16
lower bits, upper bits are changed but we impilcilty cast to u16.

This fix possible deadlock on IBSS mode reproted by lockdep:

=================================
[ INFO: inconsistent lock state ]
3.4.0-wl+ #4 Not tainted
---------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kworker/u:2/30374 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&(&intf->seqlock)->rlock){+.?...}, at: [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
{IN-SOFTIRQ-W} state was registered at:
  [<c04978ab>] __lock_acquire+0x47b/0x1050
  [<c0498504>] lock_acquire+0x84/0xf0
  [<c0835733>] _raw_spin_lock+0x33/0x40
  [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
  [<f9979f2a>] rt2x00queue_write_tx_frame+0x1a/0x300 [rt2x00lib]
  [<f997834f>] rt2x00mac_tx+0x7f/0x380 [rt2x00lib]
  [<f98fe363>] __ieee80211_tx+0x1b3/0x300 [mac80211]
  [<f98ffdf5>] ieee80211_tx+0x105/0x130 [mac80211]
  [<f99000dd>] ieee80211_xmit+0xad/0x100 [mac80211]
  [<f9900519>] ieee80211_subif_start_xmit+0x2d9/0x930 [mac80211]
  [<c0782e87>] dev_hard_start_xmit+0x307/0x660
  [<c079bb71>] sch_direct_xmit+0xa1/0x1e0
  [<c0784bb3>] dev_queue_xmit+0x183/0x730
  [<c078c27a>] neigh_resolve_output+0xfa/0x1e0
  [<c07b436a>] ip_finish_output+0x24a/0x460
  [<c07b4897>] ip_output+0xb7/0x100
  [<c07b2d60>] ip_local_out+0x20/0x60
  [<c07e01ff>] igmpv3_sendpack+0x4f/0x60
  [<c07e108f>] igmp_ifc_timer_expire+0x29f/0x330
  [<c04520fc>] run_timer_softirq+0x15c/0x2f0
  [<c0449e3e>] __do_softirq+0xae/0x1e0
irq event stamp: 18380437
hardirqs last  enabled at (18380437): [<c0526027>] __slab_alloc.clone.3+0x67/0x5f0
hardirqs last disabled at (18380436): [<c0525ff3>] __slab_alloc.clone.3+0x33/0x5f0
softirqs last  enabled at (18377616): [<c0449eb3>] __do_softirq+0x123/0x1e0
softirqs last disabled at (18377611): [<c041278d>] do_softirq+0x9d/0xe0

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&intf->seqlock)->rlock);
  <Interrupt>
    lock(&(&intf->seqlock)->rlock);

 *** DEADLOCK ***

4 locks held by kworker/u:2/30374:
 #0:  (wiphy_name(local->hw.wiphy)){++++.+}, at: [<c045cf99>] process_one_work+0x109/0x3f0
 #1:  ((&sdata->work)){+.+.+.}, at: [<c045cf99>] process_one_work+0x109/0x3f0
 #2:  (&ifibss->mtx){+.+.+.}, at: [<f98f005b>] ieee80211_ibss_work+0x1b/0x470 [mac80211]
 #3:  (&intf->beacon_skb_mutex){+.+...}, at: [<f997a644>] rt2x00queue_update_beacon+0x24/0x50 [rt2x00lib]

stack backtrace:
Pid: 30374, comm: kworker/u:2 Not tainted 3.4.0-wl+ #4
Call Trace:
 [<c04962a6>] print_usage_bug+0x1f6/0x220
 [<c0496a12>] mark_lock+0x2c2/0x300
 [<c0495ff0>] ? check_usage_forwards+0xc0/0xc0
 [<c04978ec>] __lock_acquire+0x4bc/0x1050
 [<c0527890>] ? __kmalloc_track_caller+0x1c0/0x1d0
 [<c0777fb6>] ? copy_skb_header+0x26/0x90
 [<c0498504>] lock_acquire+0x84/0xf0
 [<f9979a20>] ? rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
 [<c0835733>] _raw_spin_lock+0x33/0x40
 [<f9979a20>] ? rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
 [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
 [<f997a5cf>] rt2x00queue_update_beacon_locked+0x5f/0xb0 [rt2x00lib]
 [<f997a64d>] rt2x00queue_update_beacon+0x2d/0x50 [rt2x00lib]
 [<f9977e3a>] rt2x00mac_bss_info_changed+0x1ca/0x200 [rt2x00lib]
 [<f9977c70>] ? rt2x00mac_remove_interface+0x70/0x70 [rt2x00lib]
 [<f98e4dd0>] ieee80211_bss_info_change_notify+0xe0/0x1d0 [mac80211]
 [<f98ef7b8>] __ieee80211_sta_join_ibss+0x3b8/0x610 [mac80211]
 [<c0496ab4>] ? mark_held_locks+0x64/0xc0
 [<c0440012>] ? virt_efi_query_capsule_caps+0x12/0x50
 [<f98efb09>] ieee80211_sta_join_ibss+0xf9/0x140 [mac80211]
 [<f98f0456>] ieee80211_ibss_work+0x416/0x470 [mac80211]
 [<c0496d8b>] ? trace_hardirqs_on+0xb/0x10
 [<c077683b>] ? skb_dequeue+0x4b/0x70
 [<f98f207f>] ieee80211_iface_work+0x13f/0x230 [mac80211]
 [<c045cf99>] ? process_one_work+0x109/0x3f0
 [<c045d015>] process_one_work+0x185/0x3f0
 [<c045cf99>] ? process_one_work+0x109/0x3f0
 [<f98f1f40>] ? ieee80211_teardown_sdata+0xa0/0xa0 [mac80211]
 [<c045ed86>] worker_thread+0x116/0x270
 [<c045ec70>] ? manage_workers+0x1e0/0x1e0
 [<c0462f64>] kthread+0x84/0x90
 [<c0462ee0>] ? __init_kthread_worker+0x60/0x60
 [<c083d382>] kernel_thread_helper+0x6/0x10

Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e5851dac
    • J
      brcmfmac: Fix likely misuse of | for & · f304a993
      由 Joe Perches 提交于 
      Using | with a constant is always true.
Likely this should have be &.
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f304a993
    • J
      mac80211_hwsim: advertise interface combinations · 1ae2fc25
      由 Johannes Berg 提交于 
      Enforcing interface combinations broke uses of hwsim
with multiple virtual interfaces. Advertise that all
combinations are possible to fix this.
Reported-by: NNirav Shah <nirav.j2.shah@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1ae2fc25
    • J
      iwlwifi: fix TX power antenna access · a5fdde28
      由 Johannes Berg 提交于 
      Since my commit
  iwlwifi: use valid TX/RX antenna from hw_params
the config values are pure overrides, not the
real values for all hardware. Therefore, the
EEPROM TX power reading code checks the wrong
values, it should check the hw_params values.

Cc: stable@kernel.org [3.4]
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a5fdde28
    • A
      mwifiex: support NL80211_HIDDEN_SSID_ZERO_LEN for uAP · 7a1c9934
      由 Avinash Patil 提交于 
      mwifiex uAP supports NL80211_HIDDEN_SSID_ZERO_LEN type of hidden
SSID only. NL80211_HIDDEN_SSID_ZERO_CONTENTS is not supported.
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NKiran Divekar <dkiran@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7a1c9934
    • A
      mwifiex: invalidate bss config before setting channel for uAP · f0e3bd23
      由 Avinash Patil 提交于 
      Mark bss_config parameters as invalid before setting AP channel.
This prevents from setting invalid parameters while setting AP
channel to FW.
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NKiran Divekar <dkiran@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f0e3bd23
  21. 03 6月, 2012 5 次提交
    • J
      dm thin: provide userspace access to pool metadata · cc8394d8
      由 Joe Thornber 提交于 
      This patch implements two new messages that can be sent to the thin
pool target allowing it to take a snapshot of the _metadata_.  This,
read-only snapshot can be accessed by userland, concurrently with the
live target.

Only one metadata snapshot can be held at a time.  The pool's status
line will give the block location for the current msnap.

Since version 0.1.5 of the userland thin provisioning tools, the
thin_dump program displays the msnap as follows:

    thin_dump -m <msnap root> <metadata dev>

Available here: https://github.com/jthornber/thin-provisioning-tools

Now that userland can access the metadata we can do various things
that have traditionally been kernel side tasks:

     i) Incremental backups.

     By using metadata snapshots we can work out what blocks have
     changed over time.  Combined with data snapshots we can ensure
     the data doesn't change while we back it up.

     A short proof of concept script can be found here:

     https://github.com/jthornber/thinp-test-suite/blob/master/incremental_backup_example.rb

     ii) Migration of thin devices from one pool to another.

     iii) Merging snapshots back into an external origin.

     iv) Asyncronous replication.
Signed-off-by: NJoe Thornber <ejt@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      cc8394d8
    • M
      dm thin: use slab mempools · a24c2569
      由 Mike Snitzer 提交于 
      Use dedicated caches prefixed with a "dm_" name rather than relying on
kmalloc mempools backed by generic slab caches so the memory usage of
thin provisioning (and any leaks) can be accounted for independently.
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      a24c2569
    • M
      dm mpath: allow ioctls to trigger pg init · 35991652
      由 Mikulas Patocka 提交于 
      After the failure of a group of paths, any alternative paths that
need initialising do not become available until further I/O is sent to
the device.  Until this has happened, ioctls return -EAGAIN.

With this patch, new paths are made available in response to an ioctl
too.  The processing of the ioctl gets delayed until this has happened.

Instead of returning an error, we submit a work item to kmultipathd
(that will potentially activate the new path) and retry in ten
milliseconds.

Note that the patch doesn't retry an ioctl if the ioctl itself fails due
to a path failure.  Such retries should be handled intelligently by the
code that generated the ioctl in the first place, noting that some SCSI
commands should not be retried because they are not idempotent (XOR write
commands).  For commands that could be retried, there is a danger that
if the device rejected the SCSI command, the path could be errorneously
marked as failed, and the request would be retried on another path which
might fail too.  It can be determined if the failure happens on the
device or on the SCSI controller, but there is no guarantee that all
SCSI drivers set these flags correctly.
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      35991652
    • M
      dm mpath: delay retry of bypassed pg · f220fd4e
      由 Mike Christie 提交于 
      If I/O needs retrying and only bypassed priority groups are available,
set the pg_init_delay_retry flag to wait before retrying.

If, for example, the reason for the bypass is that the controller is
getting reset or there is a firmware upgrade happening, retrying right
away would cause a flood of log messages and retries for what could be a
few seconds or even several minutes.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Acked-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      f220fd4e
    • M
      dm mpath: reduce size of struct multipath · 1fbdd2b3
      由 Mike Snitzer 提交于 
      Move multipath structure's 'lock' and 'queue_size' members to eliminate
two 4-byte holes.  Also use a bit within a single unsigned int for each
existing flag (saves 8-bytes).  This allows future flags to be added
without each consuming an unsigned int.
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Acked-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      1fbdd2b3