When implementing the RefId feature, it was missed that id_tables can be
NULL under special circumstances. Bail out in that case.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Do not decrement resp_count if it's already 0.

We set resp_count to 0 when the device is closed.  The next open and
read will try to clear the WDM_READ flag if there was leftover data
in the read buffer. This fix is necessary to prevent resubmitting
the read URB in a tight loop because resp_count becomes negative.

The bug can easily be triggered from userspace by not reading all
data in the read buffer, and then closing and reopening the chardev.

Fixes: 8dd5cd53 ("usb: cdc-wdm: avoid hanging on zero length reads")
Cc: <stable@vger.kernel.org> # 3.13
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If users use the new RefId feature of new_id, give them an error message
if they provided an unknown reference. That helps detecting typos.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Often, usb drivers need some driver_info to get a device to work. To
have access to driver_info when using new_id, allow to pass a reference
vendor:product tuple from which new_id will inherit driver_info.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Check if that field is actually used and if so, bail out if it exeeds a
u8. Make it also future-proof by not requiring "exactly three"
parameters in new_id, but simply "more than two".
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>.  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When we are doing compliance test with xHCI, we found that if we
enable CONFIG_USB_SUSPEND and plug in a bad device which causes
over-current condition to the root port, software will not be noticed.
The reason is that current code don't set hub->change_bits in
hub_activate() when over-current happens, and then hub_events() will
not check the port status because it thinks nothing changed.
If CONFIG_USB_SUSPEND is disabled, the interrupt pipe of the hub will
report the change and set hub->event_bits, and then hub_events() will
check what events happened.In this case over-current can be detected.
Signed-off-by: NShen Guang <shenguang10@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 30666249, as it
depended on a previous patch that I rejected, causing a build error
here.  Sorry about that.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Cc: Peter Chen <peter.chen@freescale.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'for-usb-next-2014-01-08' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next

Sarah writes:

xhci: Urgent bug fixes for usb-next and 3.14.

Hi Greg,

Please queue these two patches to usb-next for 3.14.

An xHCI driver fix for USB ethernet devices that went into 3.13 and 3.12
stable is causing usb-storage to go into an infinite loop, and these two
patches fix the issue.  I would like these to get into 3.14-rc1 so we
can avoid any potential data corruption for users.

Sarah Sharp

Commit 35773dac "usb: xhci: Link TRB
must not occur within a USB payload burst" attempted to fix an issue
found with USB ethernet adapters, and inadvertently broke USB storage
devices.  The patch attempts to ensure that transfers never span a
segment, and rejects transfers that have more than 63 entries (or
possibly less, if some entries cross 64KB boundaries).

usb-storage limits the maximum transfer size to 120K, and we had assumed
the block layer would pass a scatter-gather list of 4K entries,
resulting in no more than 31 sglist entries:

http://marc.info/?l=linux-usb&m=138498190419312&w=2

That assumption was wrong, since we've seen the driver reject a write
that was 218 sectors long (of probably 512 bytes each):

Jan  1 07:04:49 jidanni5 kernel: [  559.624704] xhci_hcd 0000:00:14.0: Too many fragments 79, max 63
...
Jan  1 07:04:58 jidanni5 kernel: [  568.622583] Write(10): 2a 00 00 06 85 0e 00 00 da 00

Limit the number of scatter-gather entries to half a ring segment.  That
should be margin enough in case some entries cross 64KB boundaries.
Increase the number of TRBs per segment from 64 to 256, which should
result in ring segments fitting on a 4K page.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: jidanni@jidanni.org
References: http://bugs.debian.org/733907
Fixes: 35773dac ('usb: xhci: Link TRB must not occur within a USB payload burst')
Cc: stable <stable@vger.kernel.org> # 3.12

Currently prepare_ring() returns -ENOMEM if the urb won't fit into a
single ring segment.  usb_sg_wait() treats this error as a temporary
condition and will keep retrying until something else goes wrong.

The number of retries should be limited in usb_sg_wait(), but also
prepare_ring() should not return an error code that suggests it might
be worth retrying.  Change it to -EINVAL.

Reported-by: jidanni@jidanni.org
References: http://bugs.debian.org/733907
Fixes: 35773dac ('usb: xhci: Link TRB must not occur within a USB payload burst')
Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The variable 'dev' is initialized but never used
otherwise, so remove the unused variable.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove duplicated include.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Genuine FTDI chips support only CS7/8. A previous fix in commit
8704211f ("USB: ftdi_sio: fixed handling of unsupported CSIZE
setting") enforced this limitation and reported it back to userspace.

However, certain types of smartcard readers depend on specific
driver behaviour that requests 0 data bits (not 5) to change into a
different operating mode if CS5 has been set.

This patch reenables this behaviour for all FTDI devices.

Tagged to be added to stable, because it affects a lot of users of
embedded systems which rely on these readers to work properly.

Cc: stable <stable@vger.kernel.org>
Reported-by: NHeinrich Siebmanns <H.Siebmanns@t-online.de>
Tested-by: NHeinrich Siebmanns <H.Siebmanns@t-online.de>
Signed-off-by: NColin Leitner <colin.leitner@gmail.com>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Due to imx28 needs ARM swp instruction for writing, we set
CI_HDRC_IMX28_WRITE_FIX for imx28.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Tested-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We have already renamed the file name, change doc name at this
patch.

Cc: devicetree@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch makes the controller register map ci_regs_nolpm and ci_regs_lpm as
"const". Further, as all offset fit into a single byte, the type is changed
from uintptr_t to u8.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Without this patch a seperate chunk of memory is allocated for the regmap
array. As the regmap is always used it makes no sense to allocate a seperate
memory block for it, this patch moves the regmap array directly into the struct
hw_bank.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

CONFIG_USB_DEBUG is going away, and all of the other USB drivers no
longer rely on "debug" module parameters for debugging lines, so move
the pcwd_usb driver to use the dynamic debug infrastructure to be more
in line with the rest of the kernel.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Wim Van Sebroeck <wim@iguana.be>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>

This fixes the following warning:

  BUG: sleeping function called from invalid context at mm/slub.c:940
  in_atomic(): 1, irqs_disabled(): 1, pid: 17, name: khubd
  CPU: 0 PID: 17 Comm: khubd Not tainted 3.12.0-00004-g938dd60-dirty #1

   __might_sleep+0xbe/0xc0
   kmem_cache_alloc_trace+0x36/0x170
   c67x00_urb_enqueue+0x5c/0x254
   usb_hcd_submit_urb+0x66e/0x724
   usb_submit_urb+0x2ac/0x308
   usb_start_wait_urb+0x2c/0xb8
   usb_control_msg+0x8c/0xa8
   hub_port_init+0x191/0x718
   hub_thread+0x804/0xe14
   kthread+0x72/0x78
   ret_from_kernel_thread+0x8/0xc
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Acked-by: NPeter Korsgaard <peter@korsgaard.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

According to CY7C67300 specification HPI read and write cycle duration
Tcyc must be at least 6T long, where T is 1/48MHz, which is 125ns.
Without this delay fast host processor cannot write to chip registers.
Add proper ndelay to hpi_{read,write}_reg.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Acked-by: NPeter Korsgaard <peter@korsgaard.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a race in the hub driver between hub_disconnect() and
recursively_mark_NOTATTACHED().  This race can be triggered if the
driver is unbound from a device at the same time as the bus's root hub
is removed.  When the race occurs, it can cause an oops:

BUG: unable to handle kernel NULL pointer dereference at 0000015c
IP: [<c16d5fb0>] recursively_mark_NOTATTACHED+0x20/0x60
Call Trace:
 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60
 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60
 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60
 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60
 [<c16d6082>] usb_set_device_state+0x92/0x120
 [<c16d862b>] usb_disconnect+0x2b/0x1a0
 [<c16dd4c0>] usb_remove_hcd+0xb0/0x160
 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50
 [<c1704efc>] ehci_mid_remove+0x1c/0x30
 [<c1704f26>] ehci_mid_stop_host+0x16/0x30
 [<c16f7698>] penwell_otg_work+0xd28/0x3520
 [<c19c945b>] ? __schedule+0x39b/0x7f0
 [<c19cdb9d>] ? sub_preempt_count+0x3d/0x50
 [<c125e97d>] process_one_work+0x11d/0x3d0
 [<c19c7f4d>] ? mutex_unlock+0xd/0x10
 [<c125e0e5>] ? manage_workers.isra.24+0x1b5/0x270
 [<c125f009>] worker_thread+0xf9/0x320
 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50
 [<c125ef10>] ? rescuer_thread+0x2b0/0x2b0
 [<c1264ac4>] kthread+0x94/0xa0
 [<c19d0f77>] ret_from_kernel_thread+0x1b/0x28
 [<c1264a30>] ? kthread_create_on_node+0xc0/0xc0

One problem is that recursively_mark_NOTATTACHED() uses the intfdata
value and hub->hdev->maxchild while hub_disconnect() is clearing them.
Another problem is that it uses hub->ports[i] while the port device is
being released.

To fix this race, we need to hold the device_state_lock while
hub_disconnect() changes the values.  (Note that usb_disconnect()
and hub_port_connect_change() already acquire this lock at similar
critical times during a USB device's life cycle.)  We also need to
remove the port devices after maxchild has been set to 0, instead of
before.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: N"Du, Changbin" <changbinx.du@intel.com>
Tested-by: N"Du, Changbin" <changbinx.du@intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After commit 99f14bd4 "Merge 3.13-rc5 into usb-next" (in linux-next as of
today), I'm getting this error building any at91 kernel:

drivers/usb/host/ohci-at91.c: In function 'usb_hcd_at91_probe':
drivers/usb/host/ohci-at91.c:190:4: error: label 'err' used but not defined
    goto err;
    ^
drivers/usb/host/ohci-at91.c: At top level:
drivers/usb/host/ohci-at91.c:206:2: warning: data definition has no type or storage class [enabled by default]
  at91_stop_hc(pdev);
  ^
...

The problem is obviously a mismerge between two unrelated changes that
resulted in missing opening braces.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NBoris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Switch to the generic TIOCMIWAIT implementation.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Only wake up MSR wait queue on actual modem-status changes.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Clean up interrupt completion handler somewhat.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Switch to the generic TIOCMIWAIT implementation which does not suffer
from the races involved when using the deprecated sleep_on functions.
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Only wake up MSR wait queue on actual modem-status changes.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure the TIOCMIWAIT mask is always honoured.

The CH341 interrupt status has a multiple-status changed flag which
indicates that multiple status changes has occurred since last interrupt
event. Unfortunately, if the final status is the same, there appears to
be no way to determine which signal(s) has changed (an even number of
times).

This means that the multiple-status flag should not be used in
TIOCMIWAIT as it leads to the signal mask argument being ignored (e.g.
TIOCMIWAIT could return if DSR changes twice, even though the user only
cares about carrier changes).
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>