SDIO ID 0271:0418
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Bugzilla-ID: https://bugzilla.kernel.org/show_bug.cgi?id=67921Reviewed-by: NSteve deRosier <steve.derosier@lairdtech.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This reverts commit 171f6402 ("ath9k_hw: implement temperature compensation
support for AR9003+"). Some users report that this commit causes a regression
in performance under some conditions.

Fixes: 171f6402 ("ath9k_hw: implement temperature compensation support for AR9003+")
Cc: <stable@vger.kernel.org> # 4.8
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Commit 0b8e3c4c ("ath10k: move cal data len to hw_params") broke retrieving
the calibration data from cal_data debugfs file. The length of file was always
zero. The reason is:

    static ssize_t ath10k_debug_cal_data_read(struct file *file,
                                          char __user *user_buf,
                                          size_t count, loff_t *ppos)
    {
        struct ath10k *ar = file->private_data;
        void *buf = file->private_data;

This is obviously bogus, private_data cannot contain both struct ath10k and the
buffer. Fix it by caching calibration data to ar->debug.cal_data. This also
allows it to be accessed when the device is not active (interface is down).

The cal_data buffer is fixed size because during the first firmware probe we
don't yet know what will be the lenght of the calibration data. It was simplest
just to use a fixed length. There's a WARN_ON() in
ath10k_debug_cal_data_fetch() if the buffer is too small.

Tested with qca988x and firmware 10.2.4.70.56.
Reported-by: NNikolay Martynov <mar.kolya@gmail.com>
Fixes: 0b8e3c4c ("ath10k: move cal data len to hw_params")
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: NMarty Faltesek <mfaltesek@google.com>
[kvalo@qca.qualcomm.com: improve commit log and minor other changes]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

In commit d86e6476 ("rtlwifi: rtl818x: constify local structures"),
the configuration struct for most of the drivers was changed to be
constant. The problem is that five of the modified drivers need to be
able to update the firmware name based on the exact model of the card.
As the file names were stored in one of the members of that struct,
these drivers would fail with a kernel BUG splat when they tried to
update the firmware name.

Rather than reverting the previous commit, I used a suggestion by
Johannes Berg and made the firmware file name pointers be local to
the routines that update the software variables.

The configuration struct of rtl8192cu, which was not touched in the
previous patch, is now constantfied.

Fixes: d86e6476 ("rtlwifi: rtl818x: constify local structures")
Suggested-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.8
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The 8192eu suffered from two issues when reloading the driver.

The same problems as with the 8723bu where REG_RX_WAIT_CCA bits 22 and
23 didn't get set in rtl8192e_enable_rf().

In addition it also seems prone to issues when setting REG_RF_CTRL to
0 intead of just disabling the RF_ENABLE bit. Similar to what was
causing issues with the 8188eu.

With this patch I can successfully reload the driver and reassociate
to an APi with an 8192eu dongle.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The generic disable_rf() function clears bits 22 and 23 in
REG_RX_WAIT_CCA, however we did not re-enable them again in
rtl8723b_enable_rf()

This resolves the problem for me with 8723bu devices not working again
after reloading the driver.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The full RX descriptor is converted so converting tsfl again would
return it to it's original endian value.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

A device running without RX package aggregation could return more data
in the USB packet than the actual network packet. In this case we
could would clone the skb but then determine that that there was no
packet to handle and exit without freeing the cloned skb first.

This has so far only been observed with 8188eu devices, but could
affect others.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

It's not necessary to free memory allocated with devm_kzalloc
and using kfree leads to a double free.

Fixes: d776fc86 ("wlcore: sdio: Populate config firmware data")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

In order to specify that the mlxsw switchx2 driver needs additional
headroom for packets, there have been use of the hard_header_len field of
the netdevice struct.

This commit changes that to use needed_headroom instead, as this is the
correct way to do that.

Fixes: 31557f0f ("mlxsw: Introduce Mellanox SwitchX-2 ASIC support")
Signed-off-by: NYotam Gigi <yotamg@mellanox.com>
Acked-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In order to specify that the mlxsw spectrum driver needs additional
headroom for packets, there have been use of the hard_header_len field of
the netdevice struct.

This commit changes that to use needed_headroom instead, as this is the
correct way to do that.

Fixes: 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
Signed-off-by: NYotam Gigi <yotamg@mellanox.com>
Acked-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This stops NCSI device when closing the network device so that the
NCSI device can be reenabled later.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Edge-rate:
As system and networking speeds increase, a signal's output transition,
also know as the edge rate or slew rate (V/ns), takes on greater importance
because high-speed signals come with a price. That price is an assortment of
interference problems like ringing on the line, signal overshoot and
undershoot, extended signal settling times, crosstalk noise, transmission
line reflections, false signal detection by the receiving device and
electromagnetic interference (EMI) -- all of which can negate the potential
gains designers are seeking when they try to increase system speeds through
the use of higher performance logic devices. The fact is, faster signaling
edge rates can cause a higher level of electrical noise or other type of
interference that can actually lead to slower line speeds and lower maximum
system frequencies. This parameter allow the board designers to change the
driving strange, and thereby change the EMI behavioral.

Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.

Tested on Beaglebone Black with VSC 8531 PHY.
Signed-off-by: NRaju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

vmxnet3_reset_work() expects tx queues to be stopped (via
vmxnet3_quiesce_dev -> netif_tx_disable). However, this races with the
netif_wake_queue() call in netif_tx_timeout() such that the driver's
start_xmit routine may be called unexpectedly, triggering one of the BUG_ON
in vmxnet3_map_pkt with a stack trace like this:

RIP: 0010:[<ffffffffa00cf4bc>] vmxnet3_map_pkt+0x3ac/0x4c0 [vmxnet3]
 [<ffffffffa00cf7e0>] vmxnet3_tq_xmit+0x210/0x4e0 [vmxnet3]
 [<ffffffff813ab144>] dev_hard_start_xmit+0x2e4/0x4c0
 [<ffffffff813c956e>] sch_direct_xmit+0x17e/0x1e0
 [<ffffffff813c96a7>] __qdisc_run+0xd7/0x130
 [<ffffffff813a6a7a>] net_tx_action+0x10a/0x200
 [<ffffffff810691df>] __do_softirq+0x11f/0x260
 [<ffffffff81472fdc>] call_softirq+0x1c/0x30
 [<ffffffff81004695>] do_softirq+0x65/0xa0
 [<ffffffff81069b89>] local_bh_enable_ip+0x99/0xa0
 [<ffffffffa031ff36>] destroy_conntrack+0x96/0x110 [nf_conntrack]
 [<ffffffff813d65e2>] nf_conntrack_destroy+0x12/0x20
 [<ffffffff8139c6d5>] skb_release_head_state+0xb5/0xf0
 [<ffffffff8139d299>] skb_release_all+0x9/0x20
 [<ffffffff8139cfe9>] __kfree_skb+0x9/0x90
 [<ffffffffa00d0069>] vmxnet3_quiesce_dev+0x209/0x340 [vmxnet3]
 [<ffffffffa00d020a>] vmxnet3_reset_work+0x6a/0xa0 [vmxnet3]
 [<ffffffff8107d7cc>] process_one_work+0x16c/0x350
 [<ffffffff810804fa>] worker_thread+0x17a/0x410
 [<ffffffff810848c6>] kthread+0x96/0xa0
 [<ffffffff81472ee4>] kernel_thread_helper+0x4/0x10
Signed-off-by: NBenjamin Poirier <bpoirier@suse.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Although rare, it's possible to hit PCI error early on device
probe, meaning possibly some structs are not entirely initialized,
and some might even be completely uninitialized, leading to NULL
pointer dereference.

The i40e driver currently presents a "bad" behavior if device hits
such early PCI error: firstly, the struct i40e_pf might not be
attached to pci_dev yet, leading to a NULL pointer dereference on
access to pf->state.

Even checking if the struct is NULL and avoiding the access in that
case isn't enough, since the driver cannot recover from PCI error
that early; in our experiments we saw multiple failures on kernel
log, like:

  [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15
  [549.664] i40e: probe of 0007:01:00.1 failed with error -15
  [...]
  [871.644] i40e 0007:01:00.1: The driver for the device stopped because the
  device firmware failed to init. Try updating your NVM image.
  [871.644] i40e: probe of 0007:01:00.1 failed with error -32
  [...]
  [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored

Between the first probe failure (error -15) and the second (error -32)
another PCI error happened due to the first bad probe. Also, driver
started to flood console with those ARQ event messages.

This patch will prevent these issues by allowing error recovery
mechanism to remove the failed device from the system instead of
trying to recover from early PCI errors during device probe.

CC: <stable@vger.kernel.org>
Signed-off-by: NGuilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
Acked-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add the RoCE-specific LL2 logic [as well as GSI support] over
the 'generic' LL2 interface.
Signed-off-by: NRam Amrani <Ram.Amrani@caviumnetworks.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add slowpath configuration support for user, dma and memory
regions registration.
Signed-off-by: NRam Amrani <Ram.Amrani@caviumnetworks.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for the slowpath configurations of Queue Pair verbs
which adds, deletes, modifies and queries Queue Pairs.
Signed-off-by: NRam Amrani <Ram.Amrani@caviumnetworks.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for the configurations of the protection domain and
completion queues.
Signed-off-by: NRam Amrani <Ram.Amrani@caviumnetworks.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This adds the backbone required for the various HW initalizations
which are necessary for the qedr driver - FW notification, resource
initializations, etc.
Signed-off-by: NRam Amrani <Ram.Amrani@caviumnetworks.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Adds a skeletal implementation of the qede RoCE driver -
The qedr has some dependencies of the state of the underlying base
interface. This adds some logic required with mutual registrations
and the ability to pass updates on 'intresting' events.
Signed-off-by: NRam Amrani <Ram.Amrani@caviumnetworks.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Other protocols beside the networking driver need the ability
of passing some L2 traffic, usually [although not limited] for the
purpose of some management traffic.
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NRam Amrani <Ram.Amrani@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently if the MSI-X vector limit is reached the sideband flow
director gets disabled. A bit too early to make that decision, as
vectors may get re-distributed. So move the check further back.
Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

The driver allocates 1 vector per CPU thread and the current hardware
limit for vectors is 129 per PF. On systems with 128 or more threads
this currently means all vectors are used by the PF leaving no room for
additional features like VMDq, iWARP, etc...
The code that should redistribute the vectors in this case is broken and
never triggers. Fixed the code so that it actually triggers if the
hardware limit is reached and adjust the number of queue pairs
accordingly.
Also the number of initially requested iWARP vectors was not properly
saved when the vector limit was reached, and therefore always zero.

Comparison with debug statement.
Before:
i40e 0000:2d:00.0: VMDq disabled, not enough MSI-X vectors
i40e 0000:2d:00.0: IWARP disabled, not enough MSI-X vectors
i40e 00.0 MSI-X vector distribution: PF 128, VMDq 0, FDSB 0, iWARP 0
After:
i40e 0000:2d:00.0: MSI-X vector limit reached, attempting to redistribute vectors
i40e 00.0 MSI-X vector distribution: PF 78, VMDq 8, FDSB 0, iWARP 42
Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

During MSI-X vector allocation for VMDq, a check for "no vectors left"
was missing, add it. This prevents more vectors to be allocated than
available.
Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

A call to 'ida_simple_remove()' is missing in the error handling path.

This as been spotted with the following coccinelle script which tries to
detect missing 'ida_simple_remove()' call in error handling paths.

///////////////
@@
expression x;
identifier l;
@@

*   x = ida_simple_get(...);
    ...
    if (...) {
    ...
    }
    ...
    if (...) {
       ...
       goto l;
    }
    ...
*   l: ... when != ida_simple_remove(...);
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In case of error, the function ioremap() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.

Also add check for return value of platform_get_resource().

Fixes: 54e19bc7 ("net: qcom/emac: do not use devm on internal
phy pdev")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Acked-by: NTimur Tabi <timur@codeaurora.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Trivial change here to cleanup a checkpatch.pl warning that got
introduced when changing to alloc_workqueue.
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NKrishneil Singh <Krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

There is no need to clk_disable_unprepare(dev->clk)
before it was initialized.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If fi->fib_nhs is zero, the router interface pointer is uninitialized, as shown by
this warning:

drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c: In function 'mlxsw_sp_router_fib_event':
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:1674:21: error: 'r' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:1643:23: note: 'r' was declared here

This changes the loop so we handle the case the same way as finding no router
interface pointer attached to one of the nexthops to ensure we always
trap here instead of using uninitialized data.

Fixes: b45f64d1 ("mlxsw: spectrum_router: Use FIB notifications instead of switchdev calls")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Build-testing this driver with -Wmaybe-uninitialized gives a new false-positive
warning that I can't really explain:

drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function 'mlx5e_configure_flower':
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:509:3: error: 'old_attr' may be used uninitialized in this function [-Werror=maybe-uninitialized]

It's obvious from the code that 'old_attr' is initialized whenever 'old'
is non-NULL here. The warning appears with all versions I tested from gcc-4.7
through gcc-6.1, and I could not come up with a way to rewrite the function
in a more readable way that avoids the warning, so I'm adding another
initialization to shut it up.

Fixes: 8b32580d ("net/mlx5e: Add TC vlan action for SRIOV offloads")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This generic callback is for drivers which have software Tx timestamp
support enabled. Without this, PTP applications requesting software
timestamps may complain that the requested mode is not supported.
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NKrishneil Singh <Krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

A recent cleanup marked cxgb4_dcb_enabled as 'static', which is correct, but this ignored
how the symbol is also exported. In addition, the export can be compiled out when modules
are disabled, causing a harmless compiler warning in configurations for which it is not
used at all:

drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:282:12: error: 'cxgb4_dcb_enabled' defined but not used [-Werror=unused-function]

This removes the export and moves the function into the correct #ifdef so we only build
it when there are users.

Fixes: 50935857 ("cxgb4: mark symbols static where possible")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the mac address origin is not dt, you can only safely assign a mac
address after "link up" of the device. If the link is off the clocks are
disabled and because of issues assigning registers when clocks are off the
new mac address cannot be written in .ndo_set_mac_address() on some soc's.
This fix sets the mac address unconditionally in fec_restart(...) and
ensures consistency between fec registers and the network layer.
Signed-off-by: NGavin Schenk <g.schenk@eckelmann.de>
Acked-by: NFugang Duan <fugang.duan@nxp.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 9638d19e ("net: fec: add netif status check before set mac address")
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We get 2 warnings when building kernel with W=1:
drivers/net/ethernet/mediatek/mtk_eth_soc.c:2041:5: warning: no previous prototype for 'mtk_get_link_ksettings' [-Wmissing-prototypes]
drivers/net/ethernet/mediatek/mtk_eth_soc.c:2052:5: warning: no previous prototype for 'mtk_set_link_ksettings' [-Wmissing-prototypes]

In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We get 1 warning when building kernel with W=1:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2715:5: warning: no previous prototype for 'cxgb_setup_tc' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
so this patch marks this function with 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This implements ndo_poll_controller in net_device_ops callbacks for mlx5,
which is necessary to use netconsole with this driver.
Acked-By: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NCalvin Owens <calvinowens@fb.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Set upper 32 bits of destination register to zeros after
load from the context structure.
Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This also can address following UBSAN warnings:
[   36.640343] ================================================================================
[   36.648772] UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx4/fw.c:857:26
[   36.656853] shift exponent 64 is too large for 32-bit type 'int'
[   36.663348] ================================================================================
[   36.671783] ================================================================================
[   36.680213] UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx4/fw.c:861:27
[   36.688297] shift exponent 35 is too large for 32-bit type 'int'
[   36.694702] ================================================================================

Tested:
  reboot with UBSAN, no warning.
Signed-off-by: NDavid Decotigny <decot@googlers.com>
Acked-by: NEric Dumazet <edumazet@google.com>
Reviewed-by: NTariq Toukan <tariqt@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

While the driver is probing the adapter, an error may occur before the
netdev structure is allocated and attached to pci_dev. In this case,
not only netdev isn't available, but the tg3 private structure is also
not available as it is just math from the NULL pointer, so dereferences
must be skipped.

The following trace is seen when the error is triggered:

  [1.402247] Unable to handle kernel paging request for data at address 0x00001a99
  [1.402410] Faulting instruction address: 0xc0000000007e33f8
  [1.402450] Oops: Kernel access of bad area, sig: 11 [#1]
  [1.402481] SMP NR_CPUS=2048 NUMA PowerNV
  [1.402513] Modules linked in:
  [1.402545] CPU: 0 PID: 651 Comm: eehd Not tainted 4.4.0-36-generic #55-Ubuntu
  [1.402591] task: c000001fe4e42a20 ti: c000001fe4e88000 task.ti: c000001fe4e88000
  [1.402742] NIP: c0000000007e33f8 LR: c0000000007e3164 CTR: c000000000595ea0
  [1.402787] REGS: c000001fe4e8b790 TRAP: 0300   Not tainted  (4.4.0-36-generic)
  [1.402832] MSR: 9000000100009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 28000422  XER: 20000000
  [1.403058] CFAR: c000000000008468 DAR: 0000000000001a99 DSISR: 42000000 SOFTE: 1
  GPR00: c0000000007e3164 c000001fe4e8ba10 c0000000015c5e00 0000000000000000
  GPR04: 0000000000000001 0000000000000000 0000000000000039 0000000000000299
  GPR08: 0000000000000000 0000000000000001 c000001fe4e88000 0000000000000006
  GPR12: 0000000000000000 c00000000fb40000 c0000000000e6558 c000003ca1bffd00
  GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  GPR20: 0000000000000000 0000000000000000 0000000000000000 c000000000d52768
  GPR24: c000000000d52740 0000000000000100 c000003ca1b52000 0000000000000002
  GPR28: 0000000000000900 0000000000000000 c00000000152a0c0 c000003ca1b52000
  [1.404226] NIP [c0000000007e33f8] tg3_io_error_detected+0x308/0x340
  [1.404265] LR [c0000000007e3164] tg3_io_error_detected+0x74/0x340

This patch avoids the NULL pointer dereference by moving the access after
the netdev NULL pointer check on tg3_io_error_detected(). Also, we add a
check for netdev being NULL on tg3_io_resume() [suggested by Michael Chan].

Fixes: 0486a063 ("tg3: prevent ifup/ifdown during PCI error recovery")
Fixes: dfc8f370 ("net/tg3: Release IRQs on permanent error")
Tested-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: NMilton Miller <miltonm@us.ibm.com>
Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Acked-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>