Use DMA_BIT_MASK instead of plain values.
Signed-off-by: NDenis Kirjanov <kirjanov@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When the device is reset during MTU change, ring size change, or self
test, etc, the cnic status block needs to be properly initialized if
cnic is registered.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are BUGs "scheduling while atomic" triggered by the timer
rhine_tx_timeout(). They are caused by calling napi_disable() (with
msleep()). This patch fixes it by moving most of the timer content to
the workqueue function (similarly to other drivers, like tg3), with
spin_lock() changed to BH version.

Additionally, there is spin_lock_irq() moved in rhine_close() to
exclude napi_disable() etc., also tg3's way.
Reported-by: NAndrey Rahmatullin <wrar@altlinux.org>
Tested-by: NAndrey Rahmatullin <wrar@altlinux.org>
Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds a pci_save_state() call in ixgbe_resume() after
pci_restore_state(). A similar change was made in ixgbe_io_slot_reset()
that accommodates pci_restore_state() new behavior. This change makes
pci_restore_state() clear the saved_state flag This is necessary due
to a resent kernel change to pci_restore_state() so that it now clears
the saved_state flag of the device right after the device.s standard
configuration registers have been poplulated with the previously saved
values.
Signed-off-by: NDon Skidmore <donald.c.skidmore@intel.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Changes to return correct values for transceiver and supported in
ethtool get_settings function.
Signed-off-by: NSarveshwar Bandi <sarveshwarb@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

NIC controller has to be set to an appropriate mode before doing a loopback
test. Test will fail otherwise.
Signed-off-by: NSarveshwar Bandi <sarveshwarb@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This change ensures that loopback test command gives up after 4 seconds when
the hardware is not responsive. This could happen if the ports are connected
properly in loopback mode.
Signed-off-by: NSarveshwar Bandi <sarveshwarb@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The ethtool code for enabling Wake on Lan was not correctly checking the
status register bits so as a result ports 0 and 2 were both being allowed
to set WOL to enabled even though it is only supported on the first port
for our adapters.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The watermark values for the 82575 were not being set correctly.  As a
result the high and low watermark values were set to the same value which
can lead to excess xon/xoff packets being generated.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This change resolves an issue seen in some configurations where the link
may drop to 100Mb/s even though the link itself supports 1000Mb/s.  The
issue was root caused to the fact that we were only trying the link once.
Now instead we will try up to 5 attempts on a faulty cable before
downshifting to 100Mb/s.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We were forcing the PCS link up in error when we are in KX mode.  We should
only be disabling autoneg, not forcing the link up.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This hardware watchdog can misfire, so it does more harm than good.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some cables have EEPROMs that conflict with the PHY's on-board EEPROM
so it cannot load firmware.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The PHY's firmware very occasionally appears to lock up very early, but
with the heartbeat update still running.  Rebooting the microcontroller
core seems to be sufficient to recover.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The PHY boots in a mode which is not necessarily optimal.  This change
switches it to self-configure mode (except when in loopback, which
won't work in that mode if an SFP+ module is not present) by rebooting
the PHY's microcontroller, and replicating the sequence of configuration
writes from the boot EEPROM with the appropriate changes.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If we see the PHY remaining stuck in a link-down state due to PCS being
down while PMA/PMD is up, we briefly switch to PMA/PMD loopback and back,
which usually unsticks it.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We need buffer->len to remain valid to work out the correct address to
be unmapped.  We therefore need to clear buffer->len after the unmap
operation.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The XGXS block may not get a link immediately in XGXS or XAUI loopback
modes, so we still need to check it.  Split falcon_xaui_link_ok() into
falcon_xgxs_link_ok(), which checks only the Falcon XGXS block, and
falcon_xmac_link_ok(), which checks one or both sides of the link as
appropriate.  Also rename falcon_check_xaui_link() to
falcon_xmac_link_ok_retry().
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This prevents efx->link_advertising from being blatted during
a reset.

The phy_short_reach sysfs node is now destroyed later in the
port shutdown process, so check for STATE_RUNNING after
acquiring the rtnl_lock (just like in set_phy_flash_cfg).
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The option to support the old style PSK interface in the PS3
GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I noticed yesterday, because Jeff had noticed
a speed regression, cf. bug
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2138
that the SM PS settings for peers were wrong.
Instead of overwriting the SM PS settings with
the local bits, we need to keep the remote bits.

The bug was part of the original HT code from
over two years ago, but unfortunately nobody
noticed that it makes no sense -- we shouldn't
be overwriting the peer's setting with our own
but rather keep it intact when masking the peer
capabilities with our own.

While fixing that, I noticed that the masking of
capabilities is completely useless for most of
the bits, so also fix those other bits.

Finally, I also noticed that PSMP_SUPPORT no
longer exists in the final 802.11n version, so
also remove that.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

`queue' was unsigned so the test did not work.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Reviewed-by: NPavel Roskin <proski@gnu.org>
Acked-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The libertas driver copies the SSID buffer back to the wireless core and
appends a trailing NULL character for termination. This is

a) unnecessary because the buffer is allocated with kzalloc and is hence
   already NULLed when this function is called, and

b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
   much which causes memory corruptions.

Fix this by removing the extra write.
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: Maithili Hinge <maithili@marvell.com>
Cc: Kiran Divekar <dkiran@marvell.com>
Cc: Michael Hirsch <m.hirsch@raumfeld.com>
Cc: netdev@vger.kernel.org
Cc: libertas-dev@lists.infradead.org
Cc: linux-wireless@lists.infradead.org
Cc: stable@kernel.org
Acked-by: NHolger Schurig <holgerschurig@gmail.com>
Acked-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

drivers/net/wireless/iwlwifi/iwl-tx.c: In function `iwl_hw_txq_ctx_free':
drivers/net/wireless/iwlwifi/iwl-tx.c:410: warning: suggest explicit braces to avoid ambiguous `else'

Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The MIB counters are disabled when doing a chip reset.
Since ANI depends on the MIB registers for its operation, relying
on the contents of said registers during HW reset results in sub-optimal
performance.

Cc: stable@kernel.org
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When TX DMA termination has failed, the HW has to be reset
completely. Doing a fast channel change in this case is insufficient.
Also, change the debug level of a couple of messages to FATAL.

Cc: stable@kernel.org
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The internal, driver-specific maintenance of sequence
numbers is applicable only for HT frames.

Also, remove comments that are not relevant anymore.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix typo. The index should be multiplied by the entry size, not 'and'-ed.

Found via code-inspection.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some devices have 40MHz operation disabled entirely. Ensure that driver do
not enable 40MHz operation if a channel does not allow this.

This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2135Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

3945 updated write_ptr without regard to read_ptr on the Tx path.
This messes up our TFD on high load and result in the following:

<1>[ 7290.414172] IP: [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<4>[ 7290.414205] PGD 0
<1>[ 7290.414214] Thread overran stack, or stack corrupted
<0>[ 7290.414229] Oops: 0002 [#1] PREEMPT SMP
<0>[ 7290.414246] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
<4>[ 7290.414265] CPU 0
<4>[ 7290.414274] Modules linked in: af_packet nfsd usb_storage usb_libusual cpufreq_powersave exportfs cpufreq_conservative iwl3945 nfs cpufreq_userspace snd_hda_codec_realtek acpi_cpufreq uvcvideo lockd iwlcore snd_hda_intel joydev coretemp nfs_acl videodev snd_hda_codec mac80211 v4l1_compat snd_hwdep sbp2 v4l2_compat_ioctl32 uhci_hcd psmouse auth_rpcgss ohci1394 cfg80211 ehci_hcd video ieee1394 snd_pcm serio_raw battery ac nvidia(P) usbcore output sunrpc evdev lirc_ene0100 snd_page_alloc rfkill tg3 libphy fuse lzo lzo_decompress lzo_compress
<6>[ 7290.414486] Pid: 0, comm: swapper Tainted: P           2.6.32-rc8-wl #213 Aspire 5720
<6>[ 7290.414507] RIP: 0010:[<ffffffffa0dd53a1>]  [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<6>[ 7290.414541] RSP: 0018:ffff880002203d60  EFLAGS: 00010246
<6>[ 7290.414557] RAX: 000000000000004f RBX: ffff880064c11600 RCX: 0000000000000013
<6>[ 7290.414576] RDX: ffffffffa0ddcf20 RSI: ffff8800512b7008 RDI: 0000000000000038
<6>[ 7290.414596] RBP: ffff880002203dd0 R08: 0000000000000000 R09: 0000000000000100
<6>[ 7290.414616] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000000000a0
<6>[ 7290.414635] R13: 0000000000000002 R14: 0000000000000013 R15: 0000000000020201
<6>[ 7290.414655] FS:  0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000
<6>[ 7290.414677] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
<6>[ 7290.414693] CR2: 0000000000000041 CR3: 0000000001001000 CR4: 00000000000006f0
<6>[ 7290.414712] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<6>[ 7290.414732] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[ 7290.414752] Process swapper (pid: 0, threadinfo ffffffff81524000, task ffffffff81528b60)
<0>[ 7290.414772] Stack:
<4>[ 7290.414780]  ffff880002203da0 0000000000000046 0000000000000000 0000000000000046
<4>[ 7290.414804] <0> 0000000000000282 0000000000000282 0000000000000282 ffff880064c12010
<4>[ 7290.414830] <0> ffff880002203db0 ffff880064c11600 ffff880064c12e50 ffff8800512b7000
<0>[ 7290.414858] Call Trace:
<0>[ 7290.414867]  <IRQ>
<4>[ 7290.414884]  [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
<4>[ 7290.414910]  [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
<4>[ 7290.414931]  [<ffffffff81049a21>] tasklet_action+0x101/0x110
<4>[ 7290.414950]  [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160
<4>[ 7290.414968]  [<ffffffff8100d01c>] call_softirq+0x1c/0x30
<4>[ 7290.414986]  [<ffffffff8100eff5>] do_softirq+0x75/0xb0
<4>[ 7290.415003]  [<ffffffff81049ee5>] irq_exit+0x95/0xa0
<4>[ 7290.415020]  [<ffffffff8100e547>] do_IRQ+0x77/0xf0
<4>[ 7290.415038]  [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf
<0>[ 7290.415052]  <EOI>
<4>[ 7290.415067]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415087]  [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
<4>[ 7290.415107]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415130]  [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
<4>[ 7290.415149]  [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
<4>[ 7290.415168]  [<ffffffff8137b3d5>] ? rest_init+0x75/0x80
<4>[ 7290.415187]  [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
<4>[ 7290.415206]  [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
<4>[ 7290.415227]  [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
<0>[ 7290.415243] Code: 00 41 39 ce 0f 8d e8 01 00 00 48 8b 47 40 48 63 d2 48 69 d2 98 00 00 00 4c 8b 04 02 48 c7 c2 20 cf dd a0 49 8d 78 38 49 8d 40 4f <c6> 47 09 00 c6 47 0c 00 c6 47 0f 00 c6 47 12 00 c6 47 15 00 49
<1>[ 7290.415382] RIP  [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<4>[ 7290.415410]  RSP <ffff880002203d60>
<0>[ 7290.415421] CR2: 0000000000000041
<4>[ 7290.415436] ---[ end trace ec46807277caa515 ]---
<0>[ 7290.415450] Kernel panic - not syncing: Fatal exception in interrupt
<4>[ 7290.415468] Pid: 0, comm: swapper Tainted: P      D    2.6.32-rc8-wl #213
<4>[ 7290.415486] Call Trace:
<4>[ 7290.415495]  <IRQ>  [<ffffffff8138c040>] panic+0x7d/0x13a
<4>[ 7290.415519]  [<ffffffff8101071a>] oops_end+0xda/0xe0
<4>[ 7290.415538]  [<ffffffff8102e1ea>] no_context+0xea/0x250
<4>[ 7290.415557]  [<ffffffff81038991>] ? select_task_rq_fair+0x511/0x780
<4>[ 7290.415578]  [<ffffffff8102e475>] __bad_area_nosemaphore+0x125/0x1e0
<4>[ 7290.415597]  [<ffffffff81038d0c>] ? __enqueue_entity+0x7c/0x80
<4>[ 7290.415616]  [<ffffffff81039201>] ? enqueue_task_fair+0x111/0x150
<4>[ 7290.415636]  [<ffffffff8102e53e>] bad_area_nosemaphore+0xe/0x10
<4>[ 7290.415656]  [<ffffffff8102e8fa>] do_page_fault+0x26a/0x320
<4>[ 7290.415674]  [<ffffffff813905df>] page_fault+0x1f/0x30
<4>[ 7290.415697]  [<ffffffffa0dd53a1>] ? iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<4>[ 7290.415723]  [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
<4>[ 7290.415746]  [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
<4>[ 7290.415764]  [<ffffffff81049a21>] tasklet_action+0x101/0x110
<4>[ 7290.415783]  [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160
<4>[ 7290.415801]  [<ffffffff8100d01c>] call_softirq+0x1c/0x30
<4>[ 7290.415818]  [<ffffffff8100eff5>] do_softirq+0x75/0xb0
<4>[ 7290.415835]  [<ffffffff81049ee5>] irq_exit+0x95/0xa0
<4>[ 7290.415852]  [<ffffffff8100e547>] do_IRQ+0x77/0xf0
<4>[ 7290.415869]  [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf
<4>[ 7290.415883]  <EOI>  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415911]  [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
<4>[ 7290.415931]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415952]  [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
<4>[ 7290.415971]  [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
<4>[ 7290.415989]  [<ffffffff8137b3d5>] ? rest_init+0x75/0x80
<4>[ 7290.416007]  [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
<4>[ 7290.416026]  [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
<4>[ 7290.416047]  [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
Reported-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Tested-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Recent powersaving work resulted in power management ops being called
during EEPROM initialization. The lock used by these functions is not
initialized at this time. Ensure lock is initialized before it is used.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

we see from http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2125
that power saving does not work well on 3945. Since then power saving has
also been connected with association problems where an AP deathenticates a
3945 after it is unable to transmit data to it - this happens when 3945
enters power savings mode.

Disable power save support until issues are resolved.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I've also for a long time had a problem with the
temperature calculation code, which I had fixed
by byte-swapping the values, and now it turns out
that was the correct fix after all.

Also, any use of iwl_eeprom_query_addr() that is
for more than a u8 must be cast to little endian,
and some structs as well.

Fix all this. Again, no real impact on platforms
that already are little endian.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The construct "le16_to_cpu((__force __le16)(r >> 16))" has
always bothered me when looking through the iwlwifi code,
it shouldn't be necessary to __force anything, and before
this code, "r" was obtained with an ioread32, which swaps
each of the two u16 values in it properly when swapping the
entire u32 value. I've had arguments about this code with
people before, but always conceded they were right because
removing it only made things not work at all on big endian
platforms.

However, analysing a failure of the OTP reading code, I now
finally figured out what is going on, and why my intuition
about that code being wrong was right all along.

It turns out that the 'priv->eeprom' u8 array really wants
to have the data in it in little endian. So the force code
above and all really converts *to* little endian, not from
it. Cf., for instance, the function iwl_eeprom_query16() --
it reads two u8 values and combines them into a u16, in a
little-endian way. And considering it more, it makes sense
to have the eeprom array as on the device, after all not
all values really are 16-bit values, the MAC address for
instance is not.

Now, what this really means is that all the annotations are
completely wrong. The eeprom reading code should fill the
priv->eeprom array as a __le16 array, with __le16 values.

This also means that iwl_read_otp_word() should really have
a __le16 pointer as the data argument, since it should be
filling that in a format suitable for priv->eeprom.

Propagating these changes throughout, iwl_find_otp_image()
is found to be, now obviously visible, defective -- it uses
the data returned by iwl_read_otp_word() directly as if it
was CPU endianness. Fixing that, which is this hunk of the
patch:

-               next_link_addr = link_value * sizeof(u16);
+               next_link_addr = le16_to_cpu(link_value) * sizeof(u16);

is the only real change of this patch. Everything else is
just fixing the sparse annotations.

Also, the bug only shows up on big endian platforms with a
1000 series card. 5000 and previous series do not use OTP,
and 6000 series has shadow RAM support which means we don't
ever use the defective code on any cards but 1000.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We've had many reports of rt61pci failures with powersaving enabled.
Therefore, as a stop-gap measure, disable powersaving of the rt61pci
until we have found a proper solution.
Also disable powersaving on rt2800pci as it most probably will show
the same problem.

Cc: stable@kernel.org
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

sizeof(iv16) and sizeof(iv32) are the sizes of pointers.  Change them to
the size of the copied data.

Furthermore, iveiv_entry is a local structure that has just been
initialized and is not visible outside this function.  Thus, there would
seem to be no point to copy data into it.  The order of the arguments is
thus changed to copy the data into the parameters, which are provided as
pointers, suggesting in this case that they should be used to return values.

A simplified version of the semantic patch that finds the first problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression *x;
expression f;
type T;
@@

*f(...,(T)x,...)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

First, we copy/paste the padding stuff from ath9k_tx to ath_tx_cabq since it
needs to same kind of padding, but for internally generated beacons.
Next, software padding done on TX needs to be removed before calling
ieee80211_tx_status. The code was already there in ath_tx_complete but it
was wrong. Fix it by using ath9k_cmn_padpos. This later code has been
tested by sending packets to a monitor interface and reading packets from the
same interface.
Signed-off-by: NBenoit PAPILLAULT <benoit.papillault@free.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When trigger event log dumping from debugfs, the entire event log
should be dumped and the size should match the number of events being
dump.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Recent commits "iwlwifi: remove power-wasting calls to apm_ops.init()" and
"iwlagn: power up device before initializing EEPROM" had the goal of
reducing device power consumption from the time the module is loaded until
the interface is brought up and the device's power saving mechanisms kick
in. The idea is that once the module is loaded there is no need for the
device to consume power until the interface is brought up.

With the current solution the device is only powered up during EEPROM read,
and then so also only if the EEPROM type is OTP. We have found that on
certain platforms even non-OTP devices require power to be up during EEPROM
read. On these platforms the driver never loads and the system log contains
the following:

iwlagn 0000:03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0x080403D8

We thus now power up all devices during EEPROM read.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>