virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio block violated this
rule by calling add_disk, which causes the VQ to be used directly within
probe.

To fix, call virtio_device_ready before using VQs.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio net violated this
rule by using receive VQs within probe.

To fix, call virtio_device_ready before using VQs.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

	goto done;
done:
	return;
is ugly, it was put there to make diff review easier.
replace by open-coded return.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

config_mutex served two purposes: prevent multiple concurrent config
change handlers, and synchronize access to config_enable flag.

Since commit dbf2576e
    workqueue: make all workqueues non-reentrant
all workqueues are non-reentrant, and config_enable
is now gone.

Get rid of the unnecessary lock.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Now that virtio core ensures config changes don't arrive during probing,
drop config_enable flag in virtio net.
On removal, flush is now sufficient to guarantee that no change work is
queued.

This help simplify the driver, and will allow setting DRIVER_OK earlier
without losing config change notifications.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

config_mutex served two purposes: prevent multiple concurrent config
change handlers, and synchronize access to config_enable flag.

Since commit dbf2576e
    workqueue: make all workqueues non-reentrant
all workqueues are non-reentrant, and config_enable
is now gone.

Get rid of the unnecessary lock.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Now that virtio core ensures config changes don't
arrive during probing, drop config_enable flag
in virtio blk.
On removal, flush is now sufficient to guarantee that
no change work is queued.

This help simplify the driver, and will allow
setting DRIVER_OK earlier without losing config
change notifications.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Defer config changed notifications that arrive during
probe/scan/freeze/restore.

This will allow drivers to set DRIVER_OK earlier, without worrying about
racing with config change interrupts.

This change will also benefit old hypervisors (before 2009)
that send interrupts without checking DRIVER_OK: previously,
the callback could race with driver-specific initialization.

This will also help simplify drivers.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (cosmetic changes)

This is in preparation to extending config changed event handling
in core.
Wrapping these in an API also seems to make for a cleaner code.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Replace duplicated code in all transports with a single wrapper in
virtio.c.

The only functional change is in virtio_mmio.c: if a buggy device sends
us an interrupt before driver is set, we previously returned IRQ_NONE,
now we return IRQ_HANDLED.

As this must not happen in practice, this does not look like a big deal.

See also commit 3fff0179
	virtio-pci: do not oops on config change if driver not loaded.
for the original motivation behind the driver check.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

On restore, virtio pci does the following:
+ set features
+ init vqs etc - device can be used at this point!
+ set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits

This is in violation of the virtio spec, which
requires the following order:
- ACKNOWLEDGE
- DRIVER
- init vqs
- DRIVER_OK

This behaviour will break with hypervisors that assume spec compliant
behaviour.  It seems like a good idea to have this patch applied to
stable branches to reduce the support butden for the hypervisors.

Cc: stable@vger.kernel.org
Cc: Amit Shah <amit.shah@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

As the management counters reach a threshold they will generate an
interrupt so the value can be saved and the counter reset. The
current code does not enable this interrupt on all counters. This
can result in inaccurate statistics.

Update the code to enable all the counters to generate an interrupt
when its threshold is exceeded.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Even if the management counters are configured to be 32 bit register
values, the [rt]xoctetcount_gb and [rt]xoctetcount_g counters are
always 64 bit counter registers.  Since they are not being treated as
64 bit values, these statistics are being reported incorrectly (ifconfig,
ethtool, etc.).

Update the routines used to read the registers to access the "hi"
register (an offset of 4 from the "lo" register) to create a 64 bit
value for these 64 bit counters.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch does not affect the 10/100 GRETH MAC.

Before all GBit GRETH TX descriptor ring cleaning was done in
start_xmit(), when descriptor list became full it activated
TX interrupt to start the NAPI rx poll function to do TX ring
cleaning.

With this patch the TX descriptor ring is always cleaned from
the NAPI rx poll function, triggered via TX or RX interrupt.
Otherwise we could end up in TX frames being sent but not
reported to the stack being sent. On the 10/100 GRETH this
is not an issue since the SKB is copied&aligned into private
buffers so that the SKB can be freed directly on start_xmit()
Signed-off-by: NDaniel Hellstrom <daniel@gaisler.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The cnic module needs to ensure that if ipv6 support is compiled as a module,
then the cnic module cannot be compiled as built-in as it depends on ipv6.
Made this check cleaner via Kconfig

Use simpler IS_ENABLED for CONFIG_VLAN_8021Q check
Signed-off-by: NAnish Bhatt <anish@chelsio.com>
Acked-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ahci_xgene: Fix the link down in first attempt for the APM X-Gene SoC AHCI SATA host controller driver.

Due to HW errata the APM X-Gene AHCI SATA host controller reports link
down even if the device presence is detected. This issue is due to speed
negotiation failure. This patch implements the algorithm to retry the
COMRESET if PxSTAT register reports device presence detected but
PHY communication not established. The maximum retry attempts are 3.

This patch also fixes the code to match the algorithm for the printing
a warning message if the disparity error still exists after link up.
Signed-off-by: NLoc Ho <lho@apm.com>
Signed-off-by: NSuman Tripathi <stripathi@apm.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch implements the feature to skip the PHY and clock
initialization if it is already configured by the firmware.
Signed-off-by: NLoc Ho <lho@apm.com>
Signed-off-by: NSuman Tripathi <stripathi@apm.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

When 1G SFP RJ45 module is detected, driver must reset the Tx laser
in order to prevent link issues. As part of change, the link_attr_sync
was relocated from vars to params.
Signed-off-by: NYaniv Rosner <Yaniv.Rosner@qlogic.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This bug was reported on a very old kernel (RHEL6, 2.6.32-491.el6):

BUG: unable to handle kernel paging request at 00800000
IP: [<c04107b5>] nommu_map_page+0x15/0x110
*pdpt = 000000003454f001 *pde = 000000003f03d067
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/online
Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs p4_clockmod
ipv6 ppdev parport_pc parport microcode iTCO_wdt iTCO_vendor_support 3c59x mii
dcdbas serio_raw snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device
snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 sg lpc_ich mfd_core ext4
jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix
radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mirror dm_region_hash
dm_log dm_mod [last unloaded: mperf]

Pid: 4219, comm: nfsd Not tainted 2.6.32-491.el6.i686 #1 Dell Computer
Corporation OptiPlex GX240               /OptiPlex GX240
EIP: 0060:[<c04107b5>] EFLAGS: 00010246 CPU: 0
EIP is at nommu_map_page+0x15/0x110
EAX: 00000000 EBX: c0a83480 ECX: 00000000 EDX: 00800000
ESI: 00000000 EDI: f70e7860 EBP: e2d09b54 ESP: e2d09b24
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process nfsd (pid: 4219, ti=e2d08000 task=e2ceaaa0 task.ti=e2d08000)
Stack:
 00000056 00000000 0000000e c65efd38 00000020 00000296 00000206 00000206
<0> c050c850 c0a83480 e2cef154 00000001 e2d09ba8 f8fcd585 00000510 00000001
<0> 00000000 00000000 f5172200 f8fdac00 0039ef8c f5277020 f70e7860 00000510
Call Trace:
 [<c050c850>] ? page_address+0xd0/0xe0
 [<f8fcd585>] ? boomerang_start_xmit+0x3b5/0x520 [3c59x]
 [<c07b2975>] ? dev_hard_start_xmit+0xe5/0x400
 [<f9182b00>] ? ip6_output_finish+0x0/0xf0 [ipv6]
 [<c07ca053>] ? sch_direct_xmit+0x113/0x180
 [<c07d5588>] ? nf_hook_slow+0x68/0x120
 [<c07b2ea5>] ? dev_queue_xmit+0x1b5/0x290
 [<f9182b6d>] ? ip6_output_finish+0x6d/0xf0 [ipv6]
 [<f9184cb8>] ? ip6_xmit+0x3e8/0x490 [ipv6]
 [<f91ab9f9>] ? inet6_csk_xmit+0x289/0x2f0 [ipv6]
 [<c07f6451>] ? tcp_transmit_skb+0x431/0x7f0
 [<c07a403f>] ? __alloc_skb+0x4f/0x140
 [<c07f85a2>] ? tcp_write_xmit+0x1c2/0xa50
 [<c07f90b1>] ? __tcp_push_pending_frames+0x31/0xe0
 [<c07ea47a>] ? tcp_sendpage+0x44a/0x4b0
 [<c07ea030>] ? tcp_sendpage+0x0/0x4b0
 [<c079be1e>] ? kernel_sendpage+0x4e/0x90
 [<f8457bb9>] ? svc_send_common+0xc9/0x120 [sunrpc]
 [<f8457c85>] ? svc_sendto+0x75/0x1f0 [sunrpc]
 [<c060d0d9>] ? _atomic_dec_and_lock+0x59/0x90
 [<f87d55d0>] ? nfs3svc_encode_readres+0x0/0xc0 [nfsd]
 [<f845876d>] ? svc_authorise+0x2d/0x40 [sunrpc]
 [<f87d4410>] ? nfs3svc_release_fhandle+0x0/0x10 [nfsd]
 [<f8455721>] ? svc_process_common+0xf1/0x5a0 [sunrpc]
 [<f8457e86>] ? svc_tcp_sendto+0x36/0xa0 [sunrpc]
 [<f8461778>] ? svc_send+0x98/0xd0 [sunrpc]
 [<f87c698c>] ? nfsd+0xac/0x140 [nfsd]
 [<c04470e0>] ? complete+0x40/0x60
 [<f87c68e0>] ? nfsd+0x0/0x140 [nfsd]
 [<c04802ac>] ? kthread+0x7c/0xa0
 [<c0480230>] ? kthread+0x0/0xa0
 [<c0409f9f>] ? kernel_thread_helper+0x7/0x10
Code: 8d b6 00 00 00 00 eb f8 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5
83 ec 30 89 75 f8 31 f6 89 7d fc 89 c7 89 c8 89 5d f4 <8b> 1a 8b 4d 08 c1 eb 19
c1 e3 04 8b 9b c0 29 c7 c0 83 e3 fc 29

But the problem seems to still exist upstream.  It seems on 32 bit kernels
page_address() can reutrn a NULL value in some circumstances, and the
pci_map_single api isn't prepared to handle that (on this system it results in a
bogus pointer deference in nommu_map_page.

The fix is pretty easy, if we convert the 3c59x driver to use the more
convieient skb_frag_dma_map api we don't need to find the virtual address of the
page at all, and page gets mapped to the hardware properly.  Verified to fix the
problem as described by the reporter.

Applies to the net tree

Change Notes:

v2) Converted PCI_DMA_TODEVICE to DMA_TO_DEVICE.  Thanks Dave!

v3) Actually Run git commit after making changes to v2 :)
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: klassert@mathematik.tu-chemnitz.de
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

They are use less, and may generate compiling warnings, so remove them
(microblaze, arc, arm64, and unicore32 have already defined PCI_IOBASE).

The related warnings (with allmodconfig under microblaze):

  CC [M]  drivers/net/fddi/skfp/skfddi.o
  In file included from drivers/net/fddi/skfp/skfddi.c:95:0:
  drivers/net/fddi/skfp/h/skfbi.h:151:0: warning: "PCI_IOBASE" redefined
   #define PCI_IOBASE 0xffffff00L  /* Bit 31..8:  I/O Base address */
   ^
  In file included from include/linux/io.h:22:0,
                   from include/linux/pci.h:31,
                   from drivers/net/fddi/skfp/skfddi.c:82:
  ./arch/microblaze/include/asm/io.h:33:0: note: this is the location of the previous definition
   #define PCI_IOBASE ((void __iomem *)_IO_BASE)
   ^
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The function cleaning up an initialized event
was called from the "event_del" handler, instead
of being used as the "destroy" callback. In case of
events group allocation this caused NULL pointer
dereference (as events are added and deleted
multiple times then). Fixed now.
Signed-off-by: NPawel Moll <mail@pawelmoll.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

We should check if the map of the table actually succeeds, and also free
resources accordingly.

Version bumped to 1.2.1.0
Acked-by: NShelley Gong <shelleygong@vmware.com>
Acked-by: NBhavesh Davda <bhavesh@vmware.com>
Signed-off-by: NAndy King <acking@vmware.com>
Reported-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Keystone K2E EVM uses Marvel 0x9182 controller. This requires support
for the ID in the ahci driver.
Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: stable@vger.kernel.org

Fixes not being able to init fence subsystem when multiple boards are
present.
Reported-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This reverts commit 150b8be3.

The I2C core's per-adapter locks can't protect from IRQs, so the driver still
needs a spinlock to protect the register accesses.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: stable@vger.kernel.org # 3.16+
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

There is a following AB-BA dependency between cpu_hotplug.lock and
cpuidle_lock:

1) cpu_hotplug.lock -> cpuidle_lock
enable_nonboot_cpus()
 _cpu_up()
  cpu_hotplug_begin()
   LOCK(cpu_hotplug.lock)
 cpu_notify()
  ...
  acpi_processor_hotplug()
   cpuidle_pause_and_lock()
    LOCK(cpuidle_lock)

2) cpuidle_lock -> cpu_hotplug.lock
acpi_os_execute_deferred() workqueue
 ...
 acpi_processor_cst_has_changed()
  cpuidle_pause_and_lock()
   LOCK(cpuidle_lock)
  get_online_cpus()
   LOCK(cpu_hotplug.lock)

Fix this by reversing the order acpi_processor_cst_has_changed() does
thigs -- let it first execute the protection against CPU hotplug by
calling get_online_cpus() and obtain the cpuidle lock only after that (and
perform the symmentric change when allowing CPUs hotplug again and
dropping cpuidle lock).

Spotted by lockdep.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The _SUN device indentification object is not guaranteed to return
the same value every time it is executed, so we should not cache its
return value, but rather execute it every time as needed.  If it is
cached, an incorrect stale value may be used in some situations.

This issue was exposed by commit 202317a5 (ACPI / scan: Add
acpi_device objects for all device nodes in the namespace).  Fix it
by avoiding to cache the return value of _SUN.

Fixes: 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
[ rjw: Changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The current code just returns -EINVAL because mode can't be equal to
both 1 and 2.

Also this function is messy so I have cleaned it up:
1) Remove initializers like "int time = -1".  Initializing variables to
   garbage values turns off GCC's uninitialized variable warnings so it
   can lead to bugs.
2) Use kstrtoint() instead of sscanf().
3) Use SCI_KBD_MODE_FNZ and SCI_KBD_MODE_AUTO instead of magic numbers 1
   and 2.
4) Don't check for "mode == -1" because that can't happen.
5) Preserve the error code from toshiba_kbd_illum_status_set().
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

It should have been removed with commit d1b68485
("cpufreq / intel_pstate: Optimize intel_pstate_set_policy")
Signed-off-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Many CPUs do not support complete set of RAPL domains, as a
result this detection failed message is very misleading and
can be annoying.

 [    5.082632] intel_rapl: RAPL domain core detection failed
 [    5.088370] intel_rapl: RAPL domain uncore detection failed

So lower the warning message to info and only print out the RAPL
domains that are supported.
Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

I've confirmed that monitoring the package power usage as well as setting power
limits appear to be working as expected. Supports the package and dram domains.

Tested aginst cpu:

Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
Signed-off-by: NJason Baron <jbaron@akamai.com>
Acked-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On the Toshiba Tecra Z40, after a suspend-to-disk, some FN hotkeys
driven by toshiba_acpi are not functional.

Calling the ACPI object ENAB on resume makes them back alive.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NMatthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This is a follow-up patch to commit 49458e83 ("ideapad-laptop:
Constify DMI table and other r/o variables") to do what its commit
message says. The actual commit differs from the patch posted at
https://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg05340.html
significantly, probably due to a bad merge conflict resolution. Fix up
the mess and constify the DMI table for real and fix the bogus
double-const of ideapad_rfk_data[].
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Ike Panhc <ike.pan@canonical.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

During allocation and initialization of the network driver structures,
the wrong pointer is used to initialize a spin lock. Fix the spin lock
initialization by using the proper pointer.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some hosts can be both little and big endian.
In certain scenarios a big endian kernel can kexec a little endian kernel.

This patch fixes this case from both ends:
1) Return endianity to original values on shutdown (in case little endian kernel boots after we shutdown).
2) Do not rely on HW reset values when loading driver in little endian kernel
   but configure them explicitly (in case previous kernel was big endian and did not reset the HW).
Signed-off-by: NManish Chopra <manish.chopra@qlogic.com>
Signed-off-by: NAriel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When qeth device is queried for ethtool data, hardware operation
is performed to extract the necessary information from the card.
If the card is not online at the moment (e.g. it is undergoing
recovery), this operation produces undesired effects like
temporarily freezing the system. This patch prevents execution
of the hardware query operation when the card is not online.
In such case, ioctl() operation returns error with errno ENODEV.
Reviewed-by: NUrsula Braun <ursula.braun@de.ibm.com>
Signed-off-by: NEugene Crosser <Eugene.Crosser@ru.ibm.com>
Signed-off-by: NFrank Blaschka <blaschka@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Calxeda 1G/10G XGMAC Ethernet support should be available only on
Calxeda ECX-1000/2000 (Highbank/Midway) platforms.
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Renesas SuperH Ethernet support should be available only on
Renesas ARM SoCs and SuperH architecture.
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When a link is already up, the following sequence makes the kernel
block completely:

  ip link set dev eth0 down
  ip link set dev eth0 up

This is because on suspended phy, the following lines

  __lpc_eth_reset(pldat);
  __lpc_eth_init(pldat);

make the LPC ethernet core block (see LPC32x0 manual). The PHY needs to be
(re-)activated low-level first.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The patch fixes race conditions between PCI error recovery callbacks and
potential ifup/ifdown.

First, if ifup (tg3_open) is called between tg3_io_error_detected() and
tg3_io_resume() then tp->timer is armed twice before expiry. Once during
tg3_open() and again during tg3_io_resume(). This results in BUG
at kernel/time/timer.c:945.

Second, if ifdown (tg3_close) is called between tg3_io_error_detected()
and tg3_io_resume() then tg3_napi_disable() is called twice without
a tg3_napi_enable between. Once during tg3_io_error_detected() and again
during tg3_close(). The tg3_io_resume() then hangs on rtnl_lock().

v2: Added logging messages per Prashant's request

Cc: Prashant Sreedharan <prashant@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Acked-by: NPrashant Sreedharan <prashant@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>