commit 392142 moved event buffer allocation out of dwc3_core_init() but
event buffer allocation uses the cached copy of hwparams to determine
the number of event buffers and the caching is done in dwc3_core_init.
So moved dwc3_cache_hwparams function before dwc3_alloc_event_buffers so
that dwc3_alloc_event_buffers sees the correct number of event buffers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The old parameter "port" is useless for phy notify, as one usb
phy is only for one usb port. New parameter "speed" stands for
the device's speed which is on the port, this "speed" parameter
is needed at some platforms which will do some phy operations
according to device's speed.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Mike Thompson <mpthompson@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

At commit 925aa46b, Richard Zhao
<richard.zhao@freescale.com> adds the phy notification callback
when port change occurs. In fact, this phy notification should
be added according to below rules:

1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
during high speed host mode.
2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
during the reset and speed negotiation period.
3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
during host suspend/resume sequence.

Please refer: i.mx23RM(page: 413) for below rules.
http://www.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf

Freescale i.MX SoC, i.mx23, i.mx28 and i.mx6(i.mx6SL does not
need to follow the 3rd rule) need to follow above rules.

Current code set connect notification (HW_USBPHY_CTRL.ENHOSTDISCONDETECT)
at hub_port_connect_change, it conflicts with above the 2th rule.

The correct notification setting method should be:
1. Set connect notify after the second bus reset.
2. Set disconnect notify after disconnection.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Mike Thompson <mpthompson@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

As phy is working, re-init phy may cause unexpected results
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The real reason causes mx23 fail are:

- Calling mxs_phy_hw_init(mxs_phy) again at connection
- Error connect/disconnect nodity at hub.c

The coming patch will fix above two problems, Mike Thompson
tested his hardware works OK after commented out this delay
setting.

This reverts commit 363366cf.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Some devices (ex Nokia C7) simply don't respond at all when data is sent
to some of their USB interfaces.  The data gets stuck in the TTYs queue
and sits there until close(2), which them blocks because closing_wait
defaults to 30 seconds (even though the fd is O_NONBLOCK).  This is
rarely desired.  Implement the standard mechanism to adjust closing_wait
and let applications handle it how they want to.

See also 02303f73 for usb_wwan.c.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Oliver Neukum <oneukum@suse.de>
Tested-by: Aleksander Morgado <aleksander@gnu.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    It looks like I've run into some inconsistency in the USB stack behavior.

    The USB stack maintains, among others, two states for the attach
USB device: authorized and owned. Authorization state is accessible to
the user space code through correspondent sysfs files, the ownership
can be set by claiming the hub's port with ioctl call. Both state may
be set before the device is attached, by access the hub settings. When
the new device is attached, both authorization and ownership prevent
the kernel USB stack from setting the newly attached device
configuration, but when the device is authorized, the ownership state
is ignored. It looks like ignoring the ownership state on
authorization make the stack behavior inconsistent; it also prevents
the user space code from completely overriding configuration
selection, important for implementing workarounds for bugs in the
device configuration selection.

   The following patch makes the stack behavior more consistent, by
moving ownership test into usb_choose_configuration - the later
function is used both by generic_probe and usb_authorize_device
Signed-off-by: Joseph Hindin <hindin@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

To facilitate upcoming cleanup in twl stack.
No functional changes.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

since commit b4036ccd (usb: gadget: add
isochronous support to gadget zero), g_zero
has learned about isochronous transfers, which
allows us to use usbtest.ko to exercise
isochronous pipes.

All we need to do to enable that functionality
on usbtest.ko, is set the "iso" to 1 on
struct usbtest_info
Signed-off-by: Boyan Nedeltchev <boyan@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch frees SPEAr ehci/ohci drivers from tension of freeing resources :)
devm_* derivatives of multiple routines are used while allocating resources,
which would be freed automatically by kernel.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We used to get clk using con-id, but now we have device struct available for
these devices as they are probed using DT. And so must get clk using dev-id.
Signed-off-by: Amardeep Rai <amardeep.rai-ext@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Since commit c73cee71 (USB: EHCI: remove ehci_port_power() routine), the
'ehci' variable is no longer used, so remove it and fix the following
build warning:

drivers/usb/host/ehci-mxc.c:41:19: warning: unused variable 'ehci' [-Wunused-variable]
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Test for tegra and hcd in tegra_ehci_remove() look like potential
NULL pointer dereference, but in fact those tests are not needed,
so remove these pointless tests entirely.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This pulls in the 3.7-rc5 branch into usb-next

Merge tag 'for-usb-next-2012-11-12' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next

XHCI patches from Sarah:

 "xHCI patches for 3.8

  Hi Greg,

  Here's some xHCI bug fixes.  There's nothing major in here that can't
  wait for 3.8.  The NULL pointer deref that commit 68e5254a fixes hasn't
  ever been reported in the three years that the xHCI driver has been
  available, so it can wait a few more weeks.

  There's two quirk updates, one for Fresco Logic (commit bba18e33) and one
  for xHCI hosts with the TI redriver (commit b0e4e606).  Commit 4525c0a1
  makes the xHCI driver work correctly on the SiBridge xHCI host (and
  perhaps other 1.0 xHCI host controllers).  Commit 392a07ae fixes a bug in
  the Intel Panther Point xHCI host bandwidth checking checking.

  Commits 2611bd1 and 77b84767 are trivial cleanup patches.

  Sarah Sharp"

that check will have to be done by all users
of xhci_suspend() so it sounds a lot better to
move the check to xhci_suspend() in order to
avoid code duplication.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

This minor patch creates a more stricter conditional for the Z1 sytems for applying
the Compliance Mode Patch, this to avoid the quirk to be applied to models that
contain a "Z1" in their dmi product string but are different from Z1 systems.

This patch should be backported to stable kernels as old as 3.2, that
contain the commit 71c731a2 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

Ali reports that plugging a device into the Fresco Logic xHCI host with
PCI device ID 1400 produces an IRQ error:

 do_IRQ: 3.176 No irq handler for vector (irq -1)

Other early Fresco Logic host revisions don't support MSI, even though
their PCI config space claims they do.  Extend the quirk to disabling
MSI to this chipset revision.  Also enable the short transfer quirk,
since it's likely this revision also has that quirk, and it should be
harmless to enable.

04:00.0 0c03: 1b73:1400 (rev 01) (prog-if 30 [XHCI])
        Subsystem: 1d5c:1000
        Physical Slot: 3
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 51
        Region 0: Memory at d4600000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000feeff00c  Data: 41b1
        Capabilities: [80] Express (v1) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Kernel driver in use: xhci_hcd

This patch should be backported to stable kernels as old as 2.6.36, that
contain the commit f5182b41 "xhci:
Disable MSI for some Fresco Logic hosts."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: A Sh <smr.ash1991@gmail.com>
Tested-by: A Sh <smr.ash1991@gmail.com>
Cc: stable@vger.kernel.org

xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
the tail to head at the end (forming a ring). When it bails out for OOM
reasons half-way through, it tries to destroy its half-built list with
xhci_free_segments_for_ring(), even though it is not a ring yet. This
causes a null-pointer dereference upon hitting the last element.

Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
the output parameters to be valid upon this kind of OOM failure, and
calls xhci_ring_free() on them. Since the (incomplete) list/ring should
already be destroyed in that case, this would lead to a use after free.

This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().

This patch should be backported to kernels as old as 2.6.31, that
contains the commit 0ebbab37 "USB: xhci:
Ring allocation and initialization."

A separate patch will need to be developed for kernels older than 3.4,
since the ring allocation code was refactored in that kernel.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB.  The TD Size value for the last TRB in a TD must
always be zero.

The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong.  First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10.  The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.

Third, it uses roundup instead of DIV_ROUND_UP.  The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up.  DIV_ROUND_UP is the right function to use
in that case.

With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0

With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0

This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f2 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org

David reports that at drivers/usb/host/xhci.c:2257:

static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
    return (ep_type == ISOC_IN_EP || ep_type != INT_IN_EP);
}

The static analyser cppcheck says

[linux-3.7-rc2/drivers/usb/host/xhci.c:2257]: (style) Redundant condition: If ep_type == 5, the comparison ep_type != 7 is always true.

Maybe the original programmer intention was something like

static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
    return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP);
}

Fix this.

This patch should be backported to stable kernels as old as 3.2, that
contain the commit 2b698999 "xhci: USB
3.0 BW checking."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: David Binderman <dcb314@hotmail.com>
Cc: stable@vger.kernel.org

Non-static xHCI driver symbols should start with the "xhci_" prefix, in
order to avoid namespace pollution.  Rename the "handshake" function to
"xhci_handshake".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Ben Hutchings <ben@decadent.org.uk>

This patch (as1633) changes slightly the way usbcore handled
submissions of URBs that are already active.  It will now return
-EBUSY rather than -EINVAL, and it will call WARN_ONCE to draw
people's attention to the bug.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1632b) fixes a bug in ehci-hcd.  The USB core uses
urb->hcpriv to determine whether or not an URB is active; host
controller drivers are supposed to set this pointer to a non-NULL
value when an URB is queued.  However ehci-hcd sets it to NULL for
isochronous URBs, which defeats the check in usbcore.

In itself this isn't a big deal.  But people have recently found that
certain sequences of actions will cause the snd-usb-audio driver to
reuse URBs without waiting for them to complete.  In the absence of
proper checking by usbcore, the URBs get added to their endpoint list
twice.  This leads to list corruption and a system freeze.

The patch makes ehci-hcd assign a meaningful value to urb->hcpriv for
isochronous URBs.  Improving robustness always helps.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Artem S. Tashkinov <t.artem@lycos.com>
Reported-by: Christof Meerwald <cmeerw@cmeerw.org>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1630) cleans up a few minor items resulting from the
split-up of the ehci-hcd driver:

	Remove the product_desc string from the ehci_driver_overrides
	structure.  All drivers will use the generic "EHCI Host
	Controller" string.  (This was requested by Felipe Balbi.)

	Allow drivers to pass a NULL pointer to ehci_init_driver()
	if they don't have to override any settings.

	Remove a #define symbol that is no longer used from the
	ChipIdea host driver.

	Rename overrides to pci_overrides in ehci-pci.c, for
	consistency with ehci-platform.c.

	Mark the *_overrides structures as __initdata.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1631) fixes a bug that shows up when a config change
fails for a device under an xHCI controller.  The controller needs to
be told to disable the endpoints that have been enabled for the new
config.  The existing code does this, but before storing the
information about which endpoints were enabled!  As a result, any
second attempt to install the new config is doomed to fail because
xhci-hcd will refuse to enable an endpoint that is already enabled.

The patch optimistically initializes the new endpoints' device
structures before asking the device to switch to the new config.  If
the request fails then the endpoint information is already stored, so
we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no
trouble.  The rest of the error path is slightly more complex now; we
have to disable the new interfaces and call put_device() rather than
simply deallocating them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Matthias Schniedermeyer <ms@citd.de>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'gadget-for-v3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next

USB gadget patches from Felipe:
"usb: gadget: patches for v3.8

renesas_usbhs implements ->pullup() method, switches over
to devm_request_irq(), adds support for DMA Engine and
got a few miscelaneous cleanups.

The NCM gadget got an endianness fix and the Ethernet
gadget a frame size fix.

We're finally removing the g_file_storage gadget and
sticking to g_mass_storage and the new tcm_usb_gadget
gadgets since that was a huge duplicaton of effort anyway.

While removing g_file_storage, we also had to fix a bunch
of defconfigs which were still pointing to the old gadget.

There's a big series getting us closer to being able to
introduce our configfs interface. The series converts
functions into loadable modules which will, eventually,
be registered to the configfs interface.

Other than that there's the usual typo fixes and miscelaneous
cleanups all over the place."

USB dwc3 patches from Felipe:

"usb: dwc3: patches for v3.8

We can finaly drop HAVE_CLK dependency from exynos glue layer
now that clk API provides no-op stubs when it's not linked
into the kernel.

We're also switching over event buffer allocation to devm_kzalloc()
and moving the allocation out of dwc3_core_init() so that can be
re-used when implementing PM support for v3.9.

After the introduction of PLATFORM_DEVID_AUTO, we can also drop the
homebrew platform device ID handling we had on dwc3 core and let
driver core take care of that for us.

Exynos glue layer learns about DeviceTree and drops platform_data
support completely."

USB musb merge from Felipe:

"usb: musb: patches for v3.8 merge window

We have here the usual set of cleanups for the MUSB driver; a
big set of patches converting platform_device_del() and
platform_device_put() into platform_device_unregister().

Another big set was applied converting to module_platform_driver()
macro in order to reduce some boilerplate code from all glue
layers.

Other than that, we had a series fixing one known silicon errata
where we couldn't read a few registers. In order to fix that
we're now using shadow variables for reads and only writing
to the registers which are known to break functionality when
read."

Pull USB phy patches from Felipe:

"usb: phy: patches for v3.8 merge window

Not too many patches this time. First two patches are only
cleanups where one of them switches over to module_platform_driver
macro and the second removes inclusion of <mach/iomap.h> and is
part of a bigger set of include cleanups from the Tegra folks.

The only substantial change here is the addition of a driver
for Renesas' R-Car USB Phy controller."

Pull networking fixes from David Miller:
 "Bug fixes galore, mostly in drivers as is often the case:

  1) USB gadget and cdc_eem drivers need adjustments to their frame size
     lengths in order to handle VLANs correctly.  From Ian Coolidge.

  2) TIPC and several network drivers erroneously call tasklet_disable
     before tasklet_kill, fix from Xiaotian Feng.

  3) r8169 driver needs to apply the WOL suspend quirk to more chipsets,
     fix from Cyril Brulebois.

  4) Fix multicast filters on RTL_GIGA_MAC_VER_35 r8169 chips, from
     Nathan Walp.

  5) FDB netlink dumps should use RTM_NEWNEIGH as the message type, not
     zero.  From John Fastabend.

  6) Fix smsc95xx tx checksum offload on big-endian, from Steve
     Glendinning.

  7) __inet_diag_dump() needs to repsect and report the error value
     returned from inet_diag_lock_handler() rather than ignore it.
     Otherwise if an inet diag handler is not available for a particular
     protocol, we essentially report success instead of giving an error
     indication.  Fix from Cyrill Gorcunov.

  8) When the QFQ packet scheduler sees TSO/GSO packets it does not
     handle things properly, and in fact ends up corrupting it's
     datastructures as well as mis-schedule packets.  Fix from Paolo
     Valente.

  9) Fix oopser in skb_loop_sk(), from Eric Leblond.

  10) CXGB4 passes partially uninitialized datastructures in to FW
      commands, fix from Vipul Pandya.

  11) When we send unsolicited ipv6 neighbour advertisements, we should
      send them to the link-local allnodes multicast address, as per
      RFC4861.  Fix from Hannes Frederic Sowa.

  12) There is some kind of bug in the usbnet's kevent deferral
      mechanism, but more immediately when it triggers an uncontrolled
      stream of kernel messages spam the log.  Rate limit the error log
      message triggered when this problem occurs, as sending thousands
      of error messages into the kernel log doesn't help matters at all,
      and in fact makes further diagnosis more difficult.

      From Steve Glendinning.

  13) Fix gianfar restore from hibernation, from Wang Dongsheng.

  14) The netlink message attribute sizes are wrong in the ipv6 GRE
      driver, it was using the size of ipv4 addresses instead of ipv6
      ones :-) Fix from Nicolas Dichtel."

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  gre6: fix rtnl dump messages
  gianfar: ethernet vanishes after restoring from hibernation
  usbnet: ratelimit kevent may have been dropped warnings
  ipv6: send unsolicited neighbour advertisements to all-nodes
  net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
  usb: gadget: g_ether: fix frame size check for 802.1Q
  cxgb4: Fix initialization of SGE_CONTROL register
  isdn: Make CONFIG_ISDN depend on CONFIG_NETDEVICES
  cxgb4: Initialize data structures before using.
  af-packet: fix oops when socket is not present
  pkt_sched: enable QFQ to support TSO/GSO
  net: inet_diag -- Return error code if protocol handler is missed
  net: bnx2x: Fix typo in bnx2x driver
  smsc95xx: fix tx checksum offload for big endian
  rtnetlink: Use nlmsg type RTM_NEWNEIGH from dflt fdb dump
  ptp: update adjfreq callback description
  r8169: allow multicast packets on sub-8168f chipset.
  r8169: Fix WoL on RTL8168d/8111d.
  drivers/net: use tasklet_kill in device remove/close process
  tipc: do not use tasklet_disable before tasklet_kill

Pull sparc fixes from David Miller:
 "Several build/bug fixes for sparc, including:

  1) Configuring a mix of static vs.  modular sparc64 crypto modules
     didn't work, remove an ill-conceived attempt to only have to build
     the device match table for these drivers once to fix the problem.

     Reported by Meelis Roos.

  2) Make the montgomery multiple/square and mpmul instructions actually
     usable in 32-bit tasks.  Essentially this involves providing 32-bit
     userspace with a way to use a 64-bit stack when it needs to.

  3) Our sparc64 atomic backoffs don't yield cpu strands properly on
     Niagara chips.  Use pause instruction when available to achieve
     this, otherwise use a benign instruction we know blocks the strand
     for some time.

  4) Wire up kcmp

  5) Fix the build of various drivers by removing the unnecessary
     blocking of OF_GPIO when SPARC.

  6) Fix unintended regression wherein of_address_to_resource stopped
     being provided.  Fix from Andreas Larsson.

  7) Fix NULL dereference in leon_handle_ext_irq(), also from Andreas
     Larsson."

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  sparc64: Fix build with mix of modular vs. non-modular crypto drivers.
  sparc: Support atomic64_dec_if_positive properly.
  of/address: sparc: Declare of_address_to_resource() as an extern function for sparc again
  sparc32, leon: Check for existent irq_map entry in leon_handle_ext_irq
  sparc: Add sparc support for platform_get_irq()
  sparc: Allow OF_GPIO on sparc.
  qlogicpti: Fix build warning.
  sparc: Wire up sys_kcmp.
  sparc64: Improvde documentation and readability of atomic backoff code.
  sparc64: Use pause instruction when available.
  sparc64: Fix cpu strand yielding.
  sparc64: Make montmul/montsqr/mpmul usable in 32-bit threads.

Pull cifs fixes from Jeff Layton.

* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: Do not lookup hashed negative dentry in cifs_atomic_open
  cifs: fix potential buffer overrun in cifs.idmap handling code

Pull arm64 fixes from Catalin Marinas:
 - correct argument type (pgprot_t) when calling __ioremap()
 - PCI_IOBASE virtual address change
 - use architected event for CPU cycle counter
 - fix ELF core dumping
 - select CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION
 - missing completion for secondary CPU boot
 - booting on systems with all memory beyond 4GB

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64:
  arm64: mm: fix booting on systems with no memory below 4GB
  arm64: smp: add missing completion for secondary boot
  arm64: compat: select CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION
  arm64: elf: fix core dumping definitions for GP and FP registers
  arm64: perf: use architected event for CPU cycle counter
  arm64: Move PCI_IOBASE closer to MODULES_VADDR
  arm64: Use pgprot_t as the last argument when invoking __ioremap()

Merge tag 'stable/for-linus-3.7-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

Pull Xen fixes from Konrad Rzeszutek Wilk:
 "There are three ARM compile fixes (we forgot to export certain
  functions and if the drivers are built as an module - we go belly-up).

  There is also an mismatch of irq_enter() / exit_idle() calls sequence
  which were fixed some time ago in other piece of codes, but failed to
  appear in the Xen code.

  Lastly a fix for to help in the field with troubleshooting in case we
  cannot get the appropriate parameter and also fallback code when
  working with very old hypervisors."

Bug-fixes:
 - Fix compile issues on ARM.
 - Fix hypercall fallback code for old hypervisors.
 - Print out which HVM parameter failed if it fails.
 - Fix idle notifier call after irq_enter.

* tag 'stable/for-linus-3.7-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen/arm: Fix compile errors when drivers are compiled as modules (export more).
  xen/arm: Fix compile errors when drivers are compiled as modules.
  xen/generic: Disable fallback build on ARM.
  xen/events: fix RCU warning, or Call idle notifier after irq_enter()
  xen/hvm: If we fail to fetch an HVM parameter print out which flag it is.
  xen/hypercall: fix hypercall fallback code for very old hypervisors

We tried linking in a single built object to hold the device table,
but only works if all of the sparc64 crypto modules get built the same
way (modular vs. non-modular).

Just include the device ID stub into each driver source file so that
the table gets compiled into the correct result in all cases.
Reported-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>

Sparc32 already supported it, as a consequence of using the
generic atomic64 implementation.  And the sparc64 implementation
is rather trivial.

This allows us to set ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE for all
of sparc, and avoid the annoying warning from lib/atomic64_test.c
Signed-off-by: David S. Miller <davem@davemloft.net>

This bug-fix makes sure that of_address_to_resource is defined extern for sparc
so that the sparc-specific implementation of of_address_to_resource() is once
again used when including include/linux/of_address.h in a sparc context. A
number of drivers in mainline relies on this function working for sparc.

The bug was introduced in a850a755, "of/address:
add empty static inlines for !CONFIG_OF". Contrary to that commit title, the
static inlines are added for !CONFIG_OF_ADDRESS, and CONFIG_OF_ADDRESS is never
defined for sparc. This is good behavior for the other functions in
include/linux/of_address.h, as the extern functions defined in
drivers/of/address.c only gets linked when OF_ADDRESS is configured. However,
for of_address_to_resource there exists a sparc-specific implementation in
arch/sparc/arch/sparc/kernel/of_device_common.c

Solution suggested by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: David S. Miller <davem@davemloft.net>