usb: phy: return an error in usb_get_phy() if try_module_get() fails

In case we found a matching USB PHY in usb_get_phy() but the call to
try_module_get() fails, we shouldn't return a (probably soon dangling)
pointer but an ERR_PTR instead.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: gadget: ffs: race between ffs_epfile_io() and ffs_func_eps_disable()

ffs_epfile_io() is called from userspace, while ffs_func_eps_disable() might be
called from USB disconnect interrupt, the two functions would run in parallel
but they are not well protected, that epfile->ep would be removed by
ffs_func_eps_disable() during ffs_epfile_io() is referring this pointer, then
it leads to kernel PANIC.

The scenario is as below:

Thread 1                                 Thread 2
   |                                        |
SyS_read                             dwc3_gadget_disconnect_interrupt
   |                                        |
ffs_epfile_read                         reset_config
   |                                        |
ffs_epfile_io                       ffs_func_eps_disable
   |                                        |
 -----                      usb_ep_disable():  epfile->ep->ep->desc = NULL
   |                                        |
usb_ep_align_maybe():                     -----
it refers ep->desc->wMaxPacketSize        -----

Signed-off-by: Chao Bi <chao.bi@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
PCI: designware: Fix comment for setting number of lanes

Corrects comment for setting number of lanes.

Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
PCI: designware: Fix iATU programming for cfg1, io and mem viewport

This patch corrects iATU programming for cfg1, io and mem viewport.  Enable
ATU only after configuring it.

Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
Signed-off-by: Ajay Khandelwal <ajay.khandelwal@st.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Cc: stable@vger.kernel.org
PCI: designware: Use new OF interrupt mapping when possible

Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping.  For old
devicetrees we fall back to the previous practice.

This makes INTB, INTC, and INTD work on i.MX.

Tested-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jingoo Han <jg1.han@samsung.com>
PCI: rcar: Use new OF interrupt mapping when possible

Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping.  For old
devicetrees we fall back to the previous practice.

This allows interrupts to be remapped across bridges.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
PCI: tegra: Use new OF interrupt mapping when possible

Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping.  For old
devicetrees we fall back to the previous practice.

This allows interrupts to be remapped across bridges.

Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
ahci: do not request irq for dummy port

System may crash in ahci_hw_interrupt() or ahci_thread_fn() when
accessing the interrupt status in a port's private_data if the port is
actually a DUMMY port.

00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller

<snip console output for linux-3.15-rc1>
[    9.352080] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x1 impl SATA mode
[    9.352084] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc
[    9.368155] Console: switching to colour frame buffer device 128x48
[    9.439759] mgag200 0000:11:00.0: fb0: mgadrmfb frame buffer device
[    9.446765] mgag200 0000:11:00.0: registered panic notifier
[    9.470166] scsi1 : ahci
[    9.479166] scsi2 : ahci
[    9.488172] scsi3 : ahci
[    9.497174] scsi4 : ahci
[    9.506175] scsi5 : ahci
[    9.515174] scsi6 : ahci
[    9.518181] ata1: SATA max UDMA/133 abar m2048@0x95c00000 port 0x95c00100 irq 91
[    9.526448] ata2: DUMMY
[    9.529182] ata3: DUMMY
[    9.531916] ata4: DUMMY
[    9.534650] ata5: DUMMY
[    9.537382] ata6: DUMMY
[    9.576196] [drm] Initialized mgag200 1.0.0 20110418 for 0000:11:00.0 on minor 0
[    9.845257] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    9.865161] ata1.00: ATAPI: Optiarc DVD RW AD-7580S, FX04, max UDMA/100
[    9.891407] ata1.00: configured for UDMA/100
[    9.900525] scsi 1:0:0:0: CD-ROM            Optiarc  DVD RW AD-7580S  FX04 PQ: 0 ANSI: 5
[   10.247399] iTCO_vendor_support: vendor-support=0
[   10.261572] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   10.269764] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS
[   10.301932] sd 0:2:0:0: [sda] 570310656 512-byte logical blocks: (291 GB/271 GiB)
[   10.317085] sd 0:2:0:0: [sda] Write Protect is off
[   10.328326] sd 0:2:0:0: [sda] Write cache: disabled, read cache: disabled, supports DPO and FUA
[   10.375452] BUG: unable to handle kernel NULL pointer dereference at 000000000000003c
[   10.384217] IP: [<ffffffffa0133df0>] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.392101] PGD 0
[   10.394353] Oops: 0000 [#1] SMP
[   10.397978] Modules linked in: sr_mod(+) cdrom sd_mod iTCO_wdt crc_t10dif iTCO_vendor_support crct10dif_common ahci libahci libata lpc_ich mfd_core mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm drm i2c_core megaraid_sas dm_mirror dm_region_hash
dm_log dm_mod
[   10.426499] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1 #1
[   10.433495] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011
[   10.443886] task: ffffffff81906460 ti: ffffffff818f0000 task.ti: ffffffff818f0000
[   10.452239] RIP: 0010:[<ffffffffa0133df0>]  [<ffffffffa0133df0>] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.462838] RSP: 0018:ffff880033c03d98  EFLAGS: 00010046
[   10.468767] RAX: 0000000000a400a4 RBX: ffff880029a6bc18 RCX: 00000000fffffffa
[   10.476731] RDX: 00000000000000a4 RSI: ffff880029bb0000 RDI: ffff880029a6bc18
[   10.484696] RBP: ffff880033c03dc8 R08: 0000000000000000 R09: ffff88002f800490
[   10.492661] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000000
[   10.500625] R13: ffff880029a6bd98 R14: 0000000000000000 R15: ffffc90000194000
[   10.508590] FS:  0000000000000000(0000) GS:ffff880033c00000(0000) knlGS:0000000000000000
[   10.517623] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   10.524035] CR2: 000000000000003c CR3: 00000000328ff000 CR4: 00000000000007b0
[   10.531999] Stack:
[   10.534241]  0000000000000017 ffff880031ba7d00 000000000000005c ffff880031ba7d00
[   10.542535]  0000000000000000 000000000000005c ffff880033c03e10 ffffffff810c2a1e
[   10.550827]  ffff880031ae2900 000000008108fb4f ffff880031ae2900 ffff880031ae2984
[   10.559121] Call Trace:
[   10.561849]  <IRQ>
[   10.563994]  [<ffffffff810c2a1e>] handle_irq_event_percpu+0x3e/0x1a0
[   10.571309]  [<ffffffff810c2bbd>] handle_irq_event+0x3d/0x60
[   10.577631]  [<ffffffff810c4fdd>] try_one_irq.isra.6+0x8d/0xf0
[   10.584142]  [<ffffffff810c5313>] note_interrupt+0x173/0x1f0
[   10.590460]  [<ffffffff810c2a8e>] handle_irq_event_percpu+0xae/0x1a0
[   10.597554]  [<ffffffff810c2bbd>] handle_irq_event+0x3d/0x60
[   10.603872]  [<ffffffff810c5727>] handle_edge_irq+0x77/0x130
[   10.610199]  [<ffffffff81014b8f>] handle_irq+0xbf/0x150
[   10.616040]  [<ffffffff8109ff4e>] ? vtime_account_idle+0xe/0x50
[   10.622654]  [<ffffffff815fca1a>] ? atomic_notifier_call_chain+0x1a/0x20
[   10.630140]  [<ffffffff816038cf>] do_IRQ+0x4f/0xf0
[   10.635490]  [<ffffffff815f8aed>] common_interrupt+0x6d/0x6d
[   10.641805]  <EOI>
[   10.643950]  [<ffffffff8149ca9f>] ? cpuidle_enter_state+0x4f/0xc0
[   10.650972]  [<ffffffff8149ca98>] ? cpuidle_enter_state+0x48/0xc0
[   10.657775]  [<ffffffff8149cb47>] cpuidle_enter+0x17/0x20
[   10.663807]  [<ffffffff810b0070>] cpu_startup_entry+0x2c0/0x3d0
[   10.670423]  [<ffffffff815dfcc7>] rest_init+0x77/0x80
[   10.676065]  [<ffffffff81a60f47>] start_kernel+0x40f/0x41a
[   10.682190]  [<ffffffff81a60941>] ? repair_env_string+0x5c/0x5c
[   10.688799]  [<ffffffff81a60120>] ? early_idt_handlers+0x120/0x120
[   10.695699]  [<ffffffff81a605ee>] x86_64_start_reservations+0x2a/0x2c
[   10.702889]  [<ffffffff81a60733>] x86_64_start_kernel+0x143/0x152
[   10.709689] Code: a0 fc ff 85 c0 8b 4d d4 74 c3 48 8b 7b 08 89 ca 48 c7 c6 60 66 13 a0 31 c0 e8 9d 70 28 e1 8b 4d d4 eb aa 0f 1f 84 00 00 00 00 00 <45> 8b 64 24 3c 48 89 df e8 23 47 4c e1 41 83 fc 01 19 c0 48 83
[   10.731470] RIP  [<ffffffffa0133df0>] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.739441]  RSP <ffff880033c03d98>
[   10.743333] CR2: 000000000000003c
[   10.747032] ---[ end trace b6e82636970e2690 ]---
[   10.760190] Kernel panic - not syncing: Fatal exception in interrupt
[   10.767291] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)

Cc: Alexander Gordeev <agordeev@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-of-by: David Milburn <dmilburn@redhat.com>
Fixes: 5ca72c4f7c41 ("AHCI: Support multiple MSIs")
[IA64] Change default PSR.ac from '1' to '0' (Fix erratum #237)

April 2014 Itanium processor specification update:

http://www.intel.com/content/www/us/en/processors/itanium/itanium-specification-update.html

describes this erratum:

=========================================================================
237. Under a complex set of conditions, store to load forwarding for a
sub 8-byte load may complete incorrectly

Problem: A load instruction may complete incorrectly when a code sequence
using 4-byte or smaller load and store operations to the same address
is executed in combination with specific timing of all the following
concurrent conditions: store to load forwarding, alignment checking
enabled, a mis-predicted branch, and complex cache utilization activity.

Implication: The affected sub 8-byte instruction may complete
incorrectly resulting in unpredictable system behavior. There is an
extremely low probability of exposure due to the significant number of
complex microarchitectural concurrent conditions required to encounter
the erratum.

Workaround: Set PSR.ac = 0 to completely avoid the erratum. Disabling
Hyper-Threading will significantly reduce exposure to the conditions
that contribute to encountering the erratum.

Status: See the Summary Table of Changes for the affected steppings.
=========================================================================

[Table of changes essentially lists all models from McKinley to Tukwila]

The PSR.ac bit controls whether the processor will always generate
an unaligned reference trap (0x5a00) for a misaligned data access
(when PSR.ac=1) or if it will let the access succeed when running
on a cpu that implements logic to handle some unaligned accesses.

Way back in 2008 in commit b704882e70d87d7f56db5ff17e2253f3fa90e4f3
  [IA64] Rationalize kernel mode alignment checking
we made the decision to always enable strict checking. We were
already doing so in trap/interrupt context because the common
preamble code set this bit - but the rest of supervisor code
(and by inheritance user code) ran with PSR.ac=0.

We now reverse that decision and set PSR.ac=0 everywhere in the
kernel (also inherited by user processes). This will avoid the
erratum using the method described in the Itanium specification
update.  Net effect for users is that the processor will handle
unaligned access when it can (typically with a tiny performance
bubble in the pipeline ... but much less invasive than taking a
trap and having the OS perform the access).

Signed-off-by: Tony Luck <tony.luck@intel.com>
workqueue: fix bugs in wq_update_unbound_numa() failure path

wq_update_unbound_numa() failure path has the following two bugs.

- alloc_unbound_pwq() is called without holding wq->mutex; however, if
  the allocation fails, it jumps to out_unlock which tries to unlock
  wq->mutex.

- The function should switch to dfl_pwq on failure but didn't do so
  after alloc_unbound_pwq() failure.

Fix it by regrabbing wq->mutex and jumping to use_dfl_pwq on
alloc_unbound_pwq() failure.

Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
Acked-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Fixes: 4c16bd327c74 ("workqueue: implement NUMA affinity for unbound workqueues")
aio: block io_destroy() until all context requests are completed

deletes aio context and all resources related to. It makes sense that
no IO operations connected to the context should be running after the context
is destroyed. As we removed io_context we have no chance to
get requests status or call io_getevents().

man page for io_destroy says that this function may block until
all context's requests are completed. Before kernel 3.11 io_destroy()
blocked indeed, but since aio refactoring in 3.11 it is not true anymore.

Here is a pseudo-code that shows a testcase for a race condition discovered
in 3.11:

  initialize io_context
  io_submit(read to buffer)
  io_destroy()

  // context is destroyed so we can free the resources
  free(buffers);

  // if the buffer is allocated by some other user he'll be surprised
  // to learn that the buffer still filled by an outstanding operation
  // from the destroyed io_context

The fix is straight-forward - add a completion struct and wait on it
in io_destroy, complete() should be called when number of in-fligh requests
reaches zero.

If two or more io_destroy() called for the same context simultaneously then
only the first one waits for IO completion, other calls behaviour is undefined.

Tested: ran http://pastebin.com/LrPsQ4RL testcase for several hours and
  do not see the race condition anymore.

Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Merge tag 'please-pull-ia64-erratum' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux

Pull itanium erratum fix from Tony Luck:
 "Small workaround for a rare, but annoying, erratum #237"

* tag 'please-pull-ia64-erratum' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
  [IA64] Change default PSR.ac from '1' to '0' (Fix erratum #237)
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

Pull s390 patches from Martin Schwidefsky:
 "An update to the oops output with additional information about the
  crash.  The renameat2 system call is enabled.  Two patches in regard
  to the PTR_ERR_OR_ZERO cleanup.  And a bunch of bug fixes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/sclp_cmd: replace PTR_RET with PTR_ERR_OR_ZERO
  s390/sclp: replace PTR_RET with PTR_ERR_OR_ZERO
  s390/sclp_vt220: Fix kernel panic due to early terminal input
  s390/compat: fix typo
  s390/uaccess: fix possible register corruption in strnlen_user_srst()
  s390: add 31 bit warning message
  s390: wire up sys_renameat2
  s390: show_registers() should not map user space addresses to kernel symbols
  s390/mm: print control registers and page table walk on crash
  s390/smp: fix smp_stop_cpu() for !CONFIG_SMP
  s390: fix control register update
sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)

When an MCDI command times out (whether or not we find it
completed when we poll), call efx_mcdi_abandon(), which tells
all subsequent MCDI calls to fail-fast, and queues up an FLR.

Because an FLR doesn't lead to receiving any reboot even from
the MC (unlike most other types of reset), we have to call
efx_ef10_reset_mc_allocations.
In efx_start_all(), if a reset (of any kind) is pending, we
bail out.
Without this, attempts to reconfigure (e.g. change mtu) can
cause driver/mc state inconsistency if the first MCDI call
triggers an FLR.

For similar reasons, on EF10, in
efx_reset_down(method=RESET_TYPE_MCDI_TIMEOUT), set the number
of active queues to zero before calling efx_stop_all().
And, on farch, in efx_reset_up(method=RESET_TYPE_MCDI_TIMEOUT),
set active_queues and flushes pending & outstanding to zero.

efx_mcdi_mode_{poll,event}() should not take us out of fail-fast
 mode. Instead, this is done by efx_mcdi_reset() after the FLR
completes.

The new FLR reset_type RESET_TYPE_MCDI_TIMEOUT doesn't really
fit into the hierarchy of reset 'scopes' whereby efx_reset()
decides some resets subsume others.  Thus, it uses separate logic.

Also, fixed up some inconsistency around RESET_TYPE_MC_BIST,
which was in the wrong place in that hierarchy.

Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
staging: delete rtl8187se wireless driver

There is a "real" driver for this hardware now in drivers/net/ so remove
the staging version as it's not needed anymore.

Reported-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: phy: add minimal support for QSGMII PHY

This commit adds the necessary definitions for the PHY layer to
recognize "qsgmii" as a valid PHY interface. A QSMII interface, as
defined at
http://en.wikipedia.org/wiki/Media_Independent_Interface#Quad_Serial_Gigabit_Media_Independent_Interface,
is "is a method of combining four SGMII lines into a 5Gbit/s
interface. QSGMII, like SGMII, uses LVDS signalling for the TX and RX
data and a single LVDS clock signal. QSGMII uses significantly fewer
signal lines than four SGMII busses."

This type of MAC <-> PHY connection might require special handling on
the MAC driver side, so it should be possible to express this type of
MAC <-> PHY connection, for example in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree@vger.kernel.org
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: mvneta: properly configure the MAC <-> PHY connection in all situations

Commit 5445eaf309ff ('mvneta: Try to fix mvneta when compiled as
module') fixed the mvneta driver to make it work properly when loaded
as a module in SGMII configuration, which was tested successful by the
author on the Armada XP OpenBlocks AX3, which uses SGMII.

However, some other platforms, namely the Armada XP GP don't use
SGMII, but a QSGMII connection between the MAC and the PHY, and this
case was not supported by the mvneta driver, which was relying on
configuration put in place by the bootloader. While this works when
the mvneta driver is built-in (because clocks are not gated), it
breaks when mvneta is built as a module, because the clock is gated
(all configuration is lost) and then re-enabled when the mvneta driver
is loaded.

In order to support all of RGMII, SGMII and QSGMII, this commit
reworks how the PHY interface configuration is done, and simplifies
it: it removes the mvneta_port_sgmii_config() and
mvneta_gmac_rgmii_set() functions, which were strange because
mvneta_gmac_rgmii_set() was called in all cases, even for SGMII
configurations. Also, the mvneta_gmac_rgmii_set() function was taking
a boolean as argument, which was always true.

Instead, all the PHY interface configuration logic is moved into the
mvneta_port_power_up() function, in a much simpler 'switch' construct,
with four cases:

 - QSGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
   the SERDES is configured in QSGMII. Technically speaking,
   configuring the SERDES of the first port would be sufficient, but
   it is simpler to do it on all ports.

 - SGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
   the SERDES is configured as SGMII.

 - RGMII: the RGMIIEn bit in GMAC_CTRL_2 is set. The PCSEn bit is kept
   cleared, and no SERDES configuration is done, because RGMII is not
   using SERDES lanes.

 - other: an error is returned. For this reason, the
   mvneta_port_power_up() now returns an int instead of nothing, and
   the return value is checked by mvneta_probe().

This has been successfully tested on:

 * Armada XP DB, which has two RGMII and two SGMII connections
 * Armada XP GP, which uses QSGMII for its four interfaces
 * Armada 370 Mirabox, which has two RGMII connections

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge branch 'mvneta_qsgmii'

Thomas Petazzoni says:

====================
net: mvneta: fix usage as a module, and support QSGMII properly

This set of patches is a new attempt at fixing the operation of the
mvneta driver when built as a module. For the record, the previous
attempt, merged in commit e3a8786c10e75903f1269474e21fe8cb49c3a670
('net: mvneta: fix usage as a module on RGMII configurations') caused
problems for all RGMII configurations.

In fact, it turned out that the MAC to PHY connection on the Armada XP
GP, which was described as using RGMII-ID according to its Device
Tree, is in fact a QSGMII connection. And the RGMII and QSGMII
configurations have to be handled in a different way in the driver,
because the SERDES configuration is different in those two cases.

So, this patch series fixes that by:

 * Adding minimal handling of a "qsgmii" connection type in the PHY
   layer. Mainly to make sure that a "qsgmii" phy-mode in the Device
   Tree is recognized, and handed over to the driver as
   PHY_INTERFACE_QSGMII.

 * Changing the mvneta driver to properly configure the RGMIIEn and
   PCSEn bits in the GMAC_CTRL_2 register, and configure the SERDES
   register, in the three possible cases: RGMII, SGMII and QSGMII.

 * Updating the Device Tree of the Armada XP GP board to reflect the
   fact that it uses a QSGMII MAC/PHY connection.

PATCH 1 and 2 would be merged by David Miller, through the net tree,
while PATCH 3 would be merged by the mach-mvebu maintainers, through
their tree and arm-soc.

This set of patches has been tested on:

 * Armada XP GP (four QSGMII interfaces)
 * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
 * Armada 370 Mirabox (two RGMII interfaces)

I've tested both the driver built-in, and compiled as a module.

Since the last attempt at fixing this was quite a fiasco, I'd like
this new attempt to be tested more widely before being applied. I'll
try to do some testing on other Armada boards I have, but independent
testing from other persons would also be appreciated.

Note that these patches apply after reverting the previous attempt,
obviously.
====================

Tested-by: Arnaud Ebalard <arno@natisbad.org>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
staging: goldfish: Call free_irq in error path

If misc_register failed in goldfish_audio_probe, the already requested
IRQ wouldn't get freed. Add a call to free_irq() like there is in
goldfish_audio_remove().

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: speakup: fix misuse of kstrtol() in handle_goto()

A string of goto_buf has a number followed by x or y.
e.g. "3x" means move 3 lines down.
The kstrtol() returns an error(-EINVAL) with this string so
go_pos has unsigned a value of that error.
And also "*cp" has not expected value.

And fix sparse warnings:
 drivers/staging/speakup/main.c:1901 handle_goto() warn: unsigned '(speakup_console[vc->vc_num]->go_pos)' is never less than zero.
 drivers/staging/speakup/main.c:1911 handle_goto() warn: unsigned '(speakup_console[vc->vc_num]->go_pos)' is never less than zero.

Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>