Given that root hub port peers are already established, external hub peer
ports can be determined by traversing the device topology:

1/ ascend to the parent hub and find the upstream port_dev

2/ walk ->peer to find the peer port

3/ descend to the peer hub via ->child

4/ find the port with the matching port id

Note that this assumes the port labeling scheme required by the
specification [1].

[1]: usb3 3.1 section 10.3.3
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Assume that the peer of a superspeed port is the port with the same id
on the shared_hcd root hub.  This identification scheme is required of
external hubs by the USB3 spec [1].  However, for root hubs, tier mismatch
may be in effect [2].  Tier mismatch can only be enumerated via platform
firmware.  For now, simply perform the nominal association.

A new lock 'usb_port_peer_mutex' is introduced to synchronize port
device add/remove with peer lookups.  It protects peering against
changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and
port_dev->child pointers.

[1]: usb 3.1 section 10.3.3
[2]: xhci 1.1 appendix D

Cc: Alan Stern <stern@rowland.harvard.edu>
[alan: usb_port_peer_mutex locking scheme]
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Once usb-acpi has set the port's connect type the usb_device's
->removable attribute can be set in the standard location
set_usb_port_removable().

This also changes behavior in the case where the firmware says that the
port connect type is unknown.  In that case just use the default setting
determined from the hub descriptor.

Note, we no longer pass udev->portnum to acpi_find_child_device() in the
root hub case since:
1/ the usb-core sets this to zero
2/ acpi always expects zero
...just pass zero.
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current port name "portX" is ambiguous.  Before adding more port
messages rename ports to "<hub-device-name>-portX"

This is an ABI change, but the suspicion is that it will go unnoticed as
the port power control implementation has been broken since its
introduction.  If however, someone was relying on the old name we can
add sysfs links from the old name to the new name.

Additionally, it unifies/simplifies port dev_printk messages and modifies
instances of:
	dev_XXX(hub->intfdev, ..."port %d"...
	dev_XXX(&hdev->dev, ..."port%d"...
into:
	dev_XXX(&port_dev->dev, ...

Now that the names are unique usb_port devices it would be nice if they
could be included in /sys/bus/usb.  However, it turns out that this
breaks 'lsusb -t'.  For now, create a dummy port driver so that print
messages are prefixed "usb 1-1-port3" rather than the
subsystem-ambiguous " 1-1-port3".

Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c.
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A hub indicates whether it supports per-port power control via the
wHubCharacteristics field in its descriptor.  If it is not supported
a hub will still emulate ClearPortPower(PORT_POWER) requests by
stopping the link state machine.  However, since this does not save
power do not bother suspending.

This also consolidates support checks into a
hub_is_port_power_switchable() helper.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The USB core doesn't properly handle mutual exclusion between
resetting a hub and changing the power states of the hub's ports.  We
need to avoid sending port-power requests to the hub while it is being
reset, because such requests cannot succeed.

This patch fixes the problem by keeping track of when a reset is in
progress.  At such times, attempts to suspend (power-off) a port will
fail immediately with -EBUSY, and calls to usb_port_runtime_resume()
will update the power_is_on flag and return immediately.  When the
reset is complete, hub_activate() will automatically restore each port
to the proper power state.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch creates a separate instance of the usb_address0 mutex for each USB
bus, and attaches it to the usb_bus device struct. This allows devices on
separate buses to be enumerated in parallel; saving time.

In the current code, there is a single, global instance of the usb_address0
mutex which is used for all devices on all buses. This isn't completely
necessary, as this mutex is only needed to prevent address0 collisions for
devices on the *same* bus (usb 2.0 spec, sec 4.6.1). This superfluous coverage
can cause additional delay in system resume on systems with multiple hosts
(up to several seconds depending on what devices are attached).
Signed-off-by: NTodd Brandt <todd.e.brandt@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since usb otg fsm implementation is not related to usb phy.
We move it from usb/phy/ to usb/common/, and rename it to
reflect its real meaning.

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since we have already removed the usage of CONFIG_USB_DEBUG, it is
meaningless that there is still a configuration entry for CONFIG_USB_DEBUG.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Pci_enable_device() will set device power state to D0,
so it's no need to do it again after call pci_enable_device().
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Save someone else the debug cycles of figuring out why a driver's
transfer request is failing or causing undefined system behavior.
Buffers submitted for dma must come from GFP allocated / DMA-able
memory.

Return -EAGAIN matching the return value for dma_mapping_error() cases.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The code in hcd-pci.c that matches up EHCI controllers with their
companion UHCI or OHCI controllers assumes that the private drvdata
fields don't get set too early.  However, it turns out that this field
gets set by usb_create_hcd(), before hcd-pci expects it, and this can
result in a crash when two controllers are probed in parallel (as can
happen when a new controller card is hotplugged).

The companions_rwsem lock was supposed to prevent this sort of thing,
but usb_create_hcd() is called outside the scope of the rwsem.

A simple solution is to check that the root-hub pointer has been
initialized as well as the drvdata field.  This doesn't happen until
usb_add_hcd() is called; that call and the check are both protected by
the rwsem.

This patch should be applied to stable kernels from 3.10 onward.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NStefani Seibold <stefani@seibold.net>
Tested-by: NStefani Seibold <stefani@seibold.net>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The USB_QUIRK_RESET flag indicates that a USB device changes its
identity in some way when it is reset.  It may lose its firmware, its
descriptors may change, or it may switch back to a default mode of
operation.

If a device does this, the kernel needs to avoid resetting it.  Resets
are likely to fail, or worse, succeed while changing the device's
state in a way the system can't detect.

This means we should disable the reset-resume mechanism whenever this
quirk flag is present.  An attempted reset-resume will fail, the
device will be logically disconnected, and later on the hub driver
will rediscover and re-enumerate the device.  This will cause the
appropriate udev events to be generated, so that userspace will have a
chance to switch the device into its normal operating mode, if
necessary.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When a driver doesn't have pre_reset, post_reset, or reset_resume
methods, the USB core unbinds that driver when its device undergoes a
reset or a reset-resume, and then rebinds it afterward.

The existing straightforward implementation can lead to problems,
because each interface gets unbound and rebound before the next
interface is handled.  If a driver claims additional interfaces, the
claim may fail because the old binding instance may still own the
additional interface when the new instance tries to claim it.

This patch fixes the problem by first unbinding all the interfaces
that are marked (i.e., their needs_binding flag is set) and then
rebinding all of them.

The patch also makes the helper functions in driver.c a little more
uniform and adjusts some out-of-date comments.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: N"Poulain, Loic" <loic.poulain@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since it is needed outside usbcore and exposed in include/linux/usb.h,
it conflicts with enum dev_state in rt2x00 wireless driver.

Mark it as usb specific to avoid conflicts in the future.
Signed-off-by: NValentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A device should not be able to be used concurrently both by
the server and the client. Claiming the port used by the
shared device ensures no interface drivers bind to it and
that it is not usable from the server.
Signed-off-by: NValentina Manea <valentina.manea.m@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The DELAY_INIT quirk only reduces the frequency of enumeration failures
with the Logitech HD Pro C920 and C930e webcams, but does not quite
eliminate them. We have found that adding a delay of 100ms between the
first and second Get Configuration request makes the device enumerate
perfectly reliable even after several weeks of extensive testing. The
reasons for that are anyone's guess, but since the DELAY_INIT quirk
already delays enumeration by a whole second, wating for another 10th of
that isn't really a big deal for the one other device that uses it, and
it will resolve the problems with these webcams.
Signed-off-by: NJulius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We've encountered a rare issue when enumerating two Logitech webcams
after a reboot that doesn't power cycle the USB ports. They are spewing
random data (possibly some leftover UVC buffers) on the second
(full-sized) Get Configuration request of the enumeration phase. Since
the data is random this can potentially cause all kinds of odd behavior,
and since it occasionally happens multiple times (after the kernel
issues another reset due to the garbled configuration descriptor), it is
not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
around the issue.
Signed-off-by: NJulius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

PREPARE_[DELAYED_]WORK() are being phased out.  They have few users
and a nasty surprise in terms of reentrancy guarantee as workqueue
considers work items to be different if they don't have the same work
function.

usb_hub->init_work is multiplexed with multiple work functions;
however, the work item is never queued while in-flight, so we can
simply use INIT_DELAYED_WORK() before each queueing.

It would probably be best to route this with other related updates
through the workqueue tree.

Lightly tested.

v2: Greg and Alan confirm that the work item is never queued while
    in-flight.  Simply use INIT_DELAYED_WORK().
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org

On disconnect USB3 protocol ports transit from U0 to SS.Inactive to Rx.Detect,
on a recoverable error, the port stays in SS.Inactive and we recover from it by
doing a warm-reset (through usb_device_reset if we have a udev for the port).

If this really is a disconnect we may end up trying the warm-reset anyways,
since khubd may run before the SS.Inactive to Rx.Detect transition, or it
may get skipped if the transition to Rx.Detect happens before khubd gets run.

With a loose connector, or in the case which actually led me to debugging this
bad ACPI firmware toggling Vbus off and on in quick succession, the port
may transition from Rx.Detect to U0 again before khubd gets run. In this case
the device state is unknown really, but khubd happily goes into the resuscitate
an existing device path, and the device driver never gets notified about the
device state being messed up.

If the above scenario happens with a streams using device, as soon as an urb
is submitted to an endpoint with streams, the following appears in dmesg:

ERROR Transfer event for disabled endpoint or incorrect stream ring
@0000000036807420 00000000 00000000 04000000 04078000

Notice how the TRB address is all zeros. I've seen this both on Intel
Pantherpoint and Nec xhci hosts.

Luckily we can detect the U0 to SS.Inactive to Rx.Detect to U0 all having
happened before khubd runs case since the C_LINK_STATE bit gets set in the
portchange bits on the U0 -> SS.Inactive change. This bit will also be set on
suspend / resume, but then it gets cleared by port_hub_init before khubd runs.

So if the C_LINK_STATE bit is set and a warm-reset is not needed, iow the port
is not still in SS.Inactive, and the port still has a connection, then the
device needs to be reset to put it back in a known state.

I've verified that doing the device reset also fixes the transfer event with
all zeros address issue.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

If streams are still allocated on device-reset or set-interface then the hcd
code implictly frees the streams. Clear host_endpoint->streams in this case
so that if a driver later tries to re-allocate them it won't run afoul of the
device already having streams check in usb_alloc_streams().

Note normally streams still being allocated at reset / set-intf  would be a
driver bug, but this can happen without it being a driver bug on reset-resume.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This allows userspace to use bulk-streams, just like in kernel drivers, see
Documentation/usb/bulk-streams.txt for details on the in kernel API. This
is exported pretty much one on one to userspace.

To use streams an app must first make a USBDEVFS_ALLOC_STREAMS ioctl,
on success this will return the number of streams available (which may be
less then requested). If there are n streams the app can then submit
usbdevfs_urb-s with their stream_id member set to 1-n to use a specific
stream. IE if USBDEVFS_ALLOC_STREAMS returns 4 then stream_id 1-4 can be
used.

When the app is done using streams it should call USBDEVFS_FREE_STREAMS

Note applications are advised to use libusb rather then using the
usbdevfs api directly. The latest version of libusb has support for streams.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch makes it possible to specify a bulk stream id when submitting
an urb using the async usbfs API. It overloads the number_of_packets
usbdevfs_urb field for this. This is not pretty, but given other
constraints it is the best we can do. The reasoning leading to this goes
as follows:

1) We want to support bulk streams in the usbfs API
2) We do not want to extend the usbdevfs_urb struct with a new member, as
   that would mean defining new ioctl numbers for all async API ioctls +
   adding compat versions for the old ones (times 2 for 32 bit support)
3) 1 + 2 means we need to re-use an existing field
4) number_of_packets is only used for isoc urbs, and streams are bulk only
   so it is the best (and only) candidate for re-using

Note that:
1) This patch only uses number_of_packets as stream_id if the app has
   actually allocated streams on the ep, so that old apps which may have
   garbage in there (as it was unused until now in the bulk case), will not
   break
2) This patch does not add support for allocating / freeing bulk-streams, that
   is done in a follow up patch
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This is a preparation patch for adding support for bulk streams.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The usb_set_interface documentation says:

 * Also, drivers must not change altsettings while urbs are scheduled for
 * endpoints in that interface; all such urbs must first be completed
 * (perhaps forced by unlinking).

For in kernel drivers we trust the drivers to get this right, but we
cannot trust userspace to get this right, so enforce it by killing any
urbs still pending on the interface.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Documentation/usb/bulk-streams.txt says:

All stream IDs will be deallocated when the driver releases the interface, to
ensure that drivers that don't support streams will be able to use the endpoint

This commit actually implements this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This is a preparation patch for adding support for bulk streams to usbfs.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

So that it can be used in other places too.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The xHCI driver currently uses a USB core internal field,
udev->lpm_capable, to indicate the xHCI driver knows how to calculate
the LPM timeout values.  If this value is set for the host controller
udev, it means Link PM can be enabled for child devices under that host.

Change the code so the xHCI driver isn't mucking with USB core internal
fields.  Instead, indicate the xHCI driver doesn't support Link PM on
this host by clearing the U1 and U2 exit latencies in the roothub
SuperSpeed Extended Capabilities BOS descriptor.

The code to check for the roothub setting U1 and U2 exit latencies to
zero will also disable LPM for external devices that do that same.  This
was already effectively done with commit
ae8963ad "usb: Don't enable LPM if the
exit latency is zero."  Leave that code in place, so that if a device
sets one exit latency value to zero, but the other is set to a valid
value, LPM is only enabled for the U1 or U2 state that had the valid
value.  This is the same behavior the code had before.

Also, change messages about missing Link PM information from warning
level to info level.  Only print a warning about the first device that
doesn't support LPM, to avoid log spam.  Further, cleanup some
unnecessary line breaks to help people to grep for the error messages.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>

Better check the correct bit on big endian systems too. Shuts
up the following sparse __CHECK_ENDIAN__ warning:

  .../hub.c:3965:32: warning: restricted __le32 degrades to integer
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This error case isn't reported during enumeration.
Signed-off-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It is an error for a driver to call usb_clear_halt() or
usb_reset_endpoint() while there are URBs queued for the endpoint,
because the end result is not well defined.  At the time the endpoint
gets reset, it may or may not be actively running.

As far as I know, no kernel drivers do this.  But some userspace
drivers do, and it seems like a good idea to bring this error to their
attention.

This patch adds a warning to the kernel log whenever a program invokes
the USBDEVFS_CLEAR_HALT or USBDEVFS_RESETEP ioctls at an inappropriate
time, and includes the name of the program.  This will make it clear
that any subsequent errors are not due to the misbehavior of a kernel
driver.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Suggested-by: NBjørn Mork <bjorn@mork.no>
CC: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A number of Kconfig entries default to (uppercase) "N". It was clearly
intended to use "default n". But since (lowercase) "n" is the default
anyway, these lines might as well be removed.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch fix spelling typo in Documentation/DocBook.
It is because .html and .xml files are generated by make htmldocs,
I have to fix a typo within the source files.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Allow the scheduler to select the best CPU to handle hub initalization
and LED blinking work. This extends idle residency times on idle CPUs
and conserves power.

This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.

[zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message.
Changed reference from system to power efficient workqueue for LEDs in
check_highspeed() and hub_port_connect_change().]
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
Cc: Julius Werner <jwerner@chromium.org>
Cc: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: Matthias Beyer <mail@beyermatthias.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NShaibal Dutta <shaibal.dutta@broadcom.com>
Signed-off-by: NZoran Markovic <zoran.markovic@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This modifies the probing order so that any matching
dynamic entry always will be used, even if the driver
has a matching static entry.

It is sometimes useful to dynamically update existing
device entries. With the new ability to set the dynamic
entry driver_info field, this can be used to test new
additions to class driver exception lists or proposed
changes to existing static per-device driver_info
entries.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This driver was previously an interface driver. Since USB/IP
exports a whole device, not just an interface, it would make
sense to be a device driver.

This patch also modifies the way userspace sees and uses a
shared device:

* the usbip_status file is no longer created for interface 0, but for
the whole device (such as
/sys/devices/pci0000:00/0000:00:01.2/usb1/1-1/usbip_status).
* per interface information, such as interface class or protocol, is
no longer sent/received; only device specific information is
transmitted.
* since the driver was moved one level below in the USB architecture,
there is no need to bind/unbind each interface, just the device as a
whole.
Signed-off-by: NValentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix a memory leak in the usb_store_new_id() error paths. When bailing out
due to sanity checks, the function left the already allocated usb_dynid
struct in place. This regression was introduced by the following commits:

c63fe8f6 (usb: core: add sanity checks when using bInterfaceClass with new_id)
1b9fb31f (usb: core: check for valid id_table when using the RefId feature)
52a6966c (usb: core: bail out if user gives an unknown RefId when using new_id)

Detected by Coverity: CID 1162604.
Signed-off-by: NChristian Engelmayer <cengelma@gmx.at>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>