28 Jan, 2015

40 commits

  • commit d2a10a1727b3948019128e83162f22c65859f1fd upstream.

    Drop unnecessary semicolon after closing curly bracket.

    Signed-off-by: Dmitry Voytik
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Dmitry Voytik
     
  • commit 7a9f0604bd56936b2b18f49824e0e392dc7878c3 upstream.

    GPIO2_5 is the reset GPIO for the USB3317 ULPI PHY. Instead of modelling it as
    a regulator, the correct approach is to use the 'reset_gpios' property of the
    "usb-nop-xceiv" node.

    GPIO1_7 is the reset GPIO for the USB2517 USB hub. As we currently don't have
    dt bindings to describe a HUB reset, let's keep using the regulator approach.

    Rename the regulator to 'reg_hub_reset' to better describe its function and bind
    it with the USB host1 port instead.

    USB host support has been introduced by commit 9bf206a9d13be3 ("ARM: dts:
    imx51-babbage: Add USB Host1 support"), which landed in 3.16 and it seems that
    USB has only been functional due to previous bootloader initialization.

    With this patch applied we can get USB host to work without relying on the
    bootloader.

    Signed-off-by: Fabio Estevam
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Fabio Estevam
     
  • commit 7a87e9cbc3a2f0ff0955815335e08c9862359130 upstream.

    From Documentation/devicetree/bindings/clock/imx25-clock.txt:

    cspi1_ipg 78
    cspi2_ipg 79
    cspi3_ipg 80

    , so fix the SPI1 clocks accordingly to avoid a kernel hang when trying to
    access SPI1.

    Signed-off-by: Fabio Estevam
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Fabio Estevam
     
  • commit 7c168ed898931f6c3314d696e63cf993378ca192 upstream.

    The default qspi2_clk_sel field of register CCM_CS2CDR contains '110' which is
    marked as 'reserved', so we can't rely on the default value.

    Provide a proper parent for QSPI clocks to avoid a kernel oops:

    [ 1.037920] Division by zero in kernel.
    [ 1.041807] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc7-next-20141204-00002-g5aa23e1 #2143
    [ 1.050967] Hardware name: Freescale i.MX6 SoloX (Device Tree)
    [ 1.056853] Backtrace:
    [ 1.059360] [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
    [ 1.066982] r6:00000000 r5:00000000 r4:00000000 r3:00000000
    [ 1.072754] [] (show_stack) from [] (dump_stack+0x88/0xa4)
    [ 1.080038] [] (dump_stack) from [] (__div0+0x18/0x20)
    [ 1.086958] r5:be018500 r4:be017c00
    [ 1.090600] [] (__div0) from [] (Ldiv0+0x8/0x10)
    [ 1.097012] [] (clk_divider_set_rate) from [] (clk_change_rate+0x14c/0x17c)
    [ 1.105759] r7:00000000 r6:00000000 r5:be018500 r4:00000000
    [ 1.111516] [] (clk_change_rate) from [] (clk_set_rate+0x94/0x98)
    [ 1.119391] r8:be7e0368 r7:00000000 r6:be11a000 r5:be018500 r4:00000000 r3:00000000
    [ 1.127290] [] (clk_set_rate) from [] (fsl_qspi_probe+0x23c/0x75c)
    [ 1.135260] r5:be11a010 r4:be350010
    [ 1.138900] [] (fsl_qspi_probe) from [] (platform_drv_probe+0x50/0xac)

    Signed-off-by: Fabio Estevam
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Fabio Estevam
     
  • commit 40d1746d2eeec5e05956d749cca6364573b472b6 upstream.

    CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit bbcf071969b20f
    ("cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'")

    Use the renamed CONFIG_CPUFREQ_DT generic driver. It looks like with
    v3.18-rc1, commit bbcf071969b20f and fdc509b15eb3eb came in via
    different trees causing the resultant v3.18-rc1 to be non-functional for
    cpufreq as default supported with omap2plus_defconfig.

    Fixes: fdc509b15eb3eb ("ARM: omap2plus_defconfig: Add cpufreq to defconfig")
    Signed-off-by: Nishanth Menon
    Acked-by: Viresh Kumar
    Signed-off-by: Tony Lindgren
    Signed-off-by: Greg Kroah-Hartman

    Nishanth Menon
     
  • commit 9333caeaeae4f831054e0e127a6ed3948b604d3e upstream.

    When KBC is in active multiplexing mode the touchpad on this laptop does
    not work.

    Reported-by: Bilal Koc
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Greg Kroah-Hartman

    Dmitry Torokhov
     
  • commit 148e9a711e034e06310a8c36b64957934ebe30f2 upstream.

    On some laptops, keyboard needs to be reset in order to successfully detect
    touchpad (e.g., some Gigabyte laptop models with Elantech touchpads).
    Without resettin keyboard touchpad pretends to be completely dead.

    Based on the original patch by Mateusz Jończyk this version has been
    expanded to include DMI based detection & application of the fix
    automatically on the affected models of laptops. This has been confirmed to
    fix problem by three users already on three different models of laptops.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81331
    Signed-off-by: Srihari Vijayaraghavan
    Acked-by: Mateusz Jończyk
    Tested-by: Srihari Vijayaraghavan
    Tested by: Zakariya Dehlawi
    Tested-by: Guillaum Bouchard
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Greg Kroah-Hartman

    Srihari Vijayaraghavan
     
  • commit 810aa0918b2b032684c8cad13f73d6ba37ad11c0 upstream.

    This change allows the driver to recognize newer Elantech touchpads.

    Signed-off-by: Yi ju Hong
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Greg Kroah-Hartman

    Sam hung
     
  • commit 5e7e6e0c9b47a45576c38b4a72d67927a5e049f7 upstream.

    Recent Leaf firmware versions (>= 3.1.557) do not allow to send
    commands for non-existing channels. If a command is sent for a
    non-existing channel, the firmware crashes.

    Reported-by: Christopher Storah
    Signed-off-by: Olivier Sobrie
    Signed-off-by: Ahmed S. Darwish
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Greg Kroah-Hartman

    Ahmed S. Darwish
     
  • commit 889b77f7fd2bcc922493d73a4c51d8a851505815 upstream.

    Flooding the Kvaser CAN to USB dongle with multiple reads and
    writes in very high frequency (*), closing the CAN channel while
    all the transmissions are on (#), opening the device again (@),
    then sending a small number of packets would make the driver
    enter an almost infinite loop of:

    [....]
    [15959.853988] kvaser_usb 4-3:1.0 can0: cannot find free context
    [15959.853990] kvaser_usb 4-3:1.0 can0: cannot find free context
    [15959.853991] kvaser_usb 4-3:1.0 can0: cannot find free context
    [15959.853993] kvaser_usb 4-3:1.0 can0: cannot find free context
    [15959.853994] kvaser_usb 4-3:1.0 can0: cannot find free context
    [15959.853995] kvaser_usb 4-3:1.0 can0: cannot find free context
    [....]

    _dragging the whole system down_ in the process due to the
    excessive logging output.

    Initially, this has caused random panics in the kernel due to a
    buggy error recovery path. That got fixed in an earlier commit.(%)
    This patch aims at solving the root cause. -->

    16 tx URBs and contexts are allocated per CAN channel per USB
    device. Such URBs are protected by:

    a) A simple atomic counter, up to a value of MAX_TX_URBS (16)
    b) A flag in each URB context, stating if it's free
    c) The fact that ndo_start_xmit calls are themselves protected
    by the networking layers higher above

    After grabbing one of the tx URBs, if the driver noticed that all
    of them are now taken, it stops the netif transmission queue.
    Such queue is worken up again only if an acknowedgment was received
    from the firmware on one of our earlier-sent frames.

    Meanwhile, upon channel close (#), the driver sends a CMD_STOP_CHIP
    to the firmware, effectively closing all further communication. In
    the high traffic case, the atomic counter remains at MAX_TX_URBS,
    and all the URB contexts remain marked as active. While opening
    the channel again (@), it cannot send any further frames since no
    more free tx URB contexts are available.

    Reset all tx URB contexts upon CAN channel close.

    (*) 50 parallel instances of `cangen0 -g 0 -ix`
    (#) `ifconfig can0 down`
    (@) `ifconfig can0 up`
    (%) "can: kvaser_usb: Don't free packets when tight on URBs"

    Signed-off-by: Ahmed S. Darwish
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Greg Kroah-Hartman

    Ahmed S. Darwish
     
  • commit b442723fcec445fb0ae1104888dd22cd285e0a91 upstream.

    Flooding the Kvaser CAN to USB dongle with multiple reads and
    writes in high frequency caused seemingly-random panics in the
    kernel.

    On further inspection, it seems the driver erroneously freed the
    to-be-transmitted packet upon getting tight on URBs and returning
    NETDEV_TX_BUSY, leading to invalid memory writes and double frees
    at a later point in time.

    Note:

    Finding no more URBs/transmit-contexts and returning NETDEV_TX_BUSY
    is a driver bug in and out of itself: it means that our start/stop
    queue flow control is broken.

    This patch only fixes the (buggy) error handling code; the root
    cause shall be fixed in a later commit.

    Acked-by: Olivier Sobrie
    Signed-off-by: Ahmed S. Darwish
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Greg Kroah-Hartman

    Ahmed S. Darwish
     
  • commit 68693b8ea4e284c46bff919ac62bd9ccdfdbb6ba upstream.

    since the split of host+gadget mode in commit 74c2e9360058 ("usb: musb:
    factor out hcd initalization") we leak the usb_hcd struct. We call now
    musb_host_cleanup() which does basically usb_remove_hcd() and also sets
    the hcd variable to NULL. Doing so makes the finall call to
    musb_host_free() basically a nop and the usb_hcd remains around for ever
    without anowner.
    This patch drops that NULL assignment for that reason.

    Fixes: 74c2e9360058 ("usb: musb: factor out hcd initalization")
    Cc: Daniel Mack
    Signed-off-by: Sebastian Andrzej Siewior
    Signed-off-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Sebastian Andrzej Siewior
     
  • commit 6d89252a998a695ecb0348fc2d717dc33d90cae9 upstream.

    Commit c3ee9b76aa93 (EHCI: improved logic for isochronous scheduling)
    introduced the idea of using ehci->last_iso_frame as the origin (or
    base) for the circular calculations involved in modifying the
    isochronous schedule. However, the new code it added used
    ehci->last_iso_frame before the value was properly initialized. This
    patch rectifies the mistake by moving the initialization lines earlier
    in iso_stream_schedule().

    This fixes Bugzilla #72891.

    Signed-off-by: Alan Stern
    Fixes: c3ee9b76aa93
    Reported-by: Joe Bryant
    Tested-by: Joe Bryant
    Tested-by: Martin Long
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     
  • commit 32a4bf2e81ec378e5925d4e069e0677a6c86a6ad upstream.

    Use tty kref to release the fake tty in usb_console_setup to avoid use
    after free if the underlying serial driver has acquired a reference.

    Note that using the tty destructor release_one_tty requires some more
    state to be initialised.

    Fixes: 4a90f09b20f4 ("tty: usb-serial krefs")
    Signed-off-by: Johan Hovold
    Signed-off-by: Greg Kroah-Hartman

    Johan Hovold
     
  • commit d269d4434c72ed0da3a9b1230c30da82c4918c63 upstream.

    The USB console currently allocates a temporary fake tty which is used
    to pass terminal settings to the underlying serial driver.

    The tty struct is not fully initialised, something which can lead to a
    lockdep warning (or worse) if a serial driver tries to acquire a
    line-discipline reference:

    usbserial: USB Serial support registered for pl2303
    pl2303 1-2.1:1.0: pl2303 converter detected
    usb 1-2.1: pl2303 converter now attached to ttyUSB0
    INFO: trying to register non-static key.
    the code is fine but needs lockdep annotation.
    turning off the locking correctness validator.
    CPU: 0 PID: 68 Comm: udevd Tainted: G W 3.18.0-rc5 #10
    [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
    [] (show_stack) from [] (dump_stack+0x24/0x28)
    [] (dump_stack) from [] (__lock_acquire+0x1e50/0x2004)
    [] (__lock_acquire) from [] (lock_acquire+0xe4/0x18c)
    [] (lock_acquire) from [] (ldsem_down_read_trylock+0x78/0x90)
    [] (ldsem_down_read_trylock) from [] (tty_ldisc_ref+0x24/0x58)
    [] (tty_ldisc_ref) from [] (usb_serial_handle_dcd_change+0x48/0xe8)
    [] (usb_serial_handle_dcd_change) from [] (pl2303_read_int_callback+0x210/0x220 [pl2303])
    [] (pl2303_read_int_callback [pl2303]) from [] (__usb_hcd_giveback_urb+0x80/0x140)
    [] (__usb_hcd_giveback_urb) from [] (usb_giveback_urb_bh+0x98/0xd4)
    [] (usb_giveback_urb_bh) from [] (tasklet_hi_action+0x9c/0x108)
    [] (tasklet_hi_action) from [] (__do_softirq+0x148/0x42c)
    [] (__do_softirq) from [] (irq_exit+0xd8/0x114)
    [] (irq_exit) from [] (__handle_domain_irq+0x84/0xdc)
    [] (__handle_domain_irq) from [] (omap_intc_handle_irq+0xd8/0xe0)
    [] (omap_intc_handle_irq) from [] (__irq_svc+0x44/0x7c)
    Exception stack(0xdf4e7f08 to 0xdf4e7f50)
    7f00: debc0b80 df4e7f5c 00000000 00000000 debc0b80 be8da96c
    7f20: 00000000 00000128 c000fc84 df4e6000 00000000 df4e7f94 00000004 df4e7f50
    7f40: c038ebc0 c038d74c 600f0013 ffffffff
    [] (__irq_svc) from [] (___sys_sendmsg.part.29+0x0/0x2e0)
    [] (___sys_sendmsg.part.29) from [] (SyS_sendmsg+0x18/0x1c)
    [] (SyS_sendmsg) from [] (ret_fast_syscall+0x0/0x48)
    console [ttyUSB0] enabled

    Fixes: 36697529b5bb ("tty: Replace ldisc locking with ldisc_sem")
    Signed-off-by: Johan Hovold
    Signed-off-by: Greg Kroah-Hartman

    Johan Hovold
     
  • commit 5fb694f96e7c19e66b1c55124b98812e32e3efa5 upstream.

    When unloading the module 'g_hid.ko', the urb request will be dequeued and the
    completion routine will be excuted. If there is no urb packet, the urb request
    will not be added to the endpoint queue and the completion routine pointer in
    urb request is NULL.

    Accessing to this NULL function pointer will cause the Oops issue reported
    below.

    Add the code to check if the urb request is in the endpoint queue
    or not. If the urb request is not in the endpoint queue, a negative
    error code will be returned.

    Here is the Oops log:

    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = dedf0000
    [00000000] *pgd=3ede5831, *pte=00000000, *ppte=00000000
    Internal error: Oops: 80000007 [#1] ARM
    Modules linked in: g_hid(-) usb_f_hid libcomposite
    CPU: 0 PID: 923 Comm: rmmod Not tainted 3.18.0+ #2
    Hardware name: Atmel SAMA5 (Device Tree)
    task: df6b1100 ti: dedf6000 task.ti: dedf6000
    PC is at 0x0
    LR is at usb_gadget_giveback_request+0xc/0x10
    pc : [] lr : [] psr: 60000093
    sp : dedf7eb0 ip : df572634 fp : 00000000
    r10: 00000000 r9 : df52e210 r8 : 60000013
    r7 : df6a9858 r6 : df52e210 r5 : df6a9858 r4 : df572600
    r3 : 00000000 r2 : ffffff98 r1 : df572600 r0 : df6a9868
    Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
    Control: 10c53c7d Table: 3edf0059 DAC: 00000015
    Process rmmod (pid: 923, stack limit = 0xdedf6230)
    Stack: (0xdedf7eb0 to 0xdedf8000)
    7ea0: 00000000 c02adbbc df572580 deced608
    7ec0: df572600 df6a9868 df572634 c02aed3c df577c00 c01b8608 00000000 df6be27c
    7ee0: 00200200 00100100 bf0162f4 c000e544 dedf6000 00000000 00000000 bf010c00
    7f00: bf0162cc bf00159c 00000000 df572980 df52e218 00000001 df5729b8 bf0031d0
    [..]
    [] (usb_gadget_giveback_request) from [] (request_complete+0x64/0x88)
    [] (request_complete) from [] (usba_ep_dequeue+0x70/0x128)
    [] (usba_ep_dequeue) from [] (hidg_unbind+0x50/0x7c [usb_f_hid])
    [] (hidg_unbind [usb_f_hid]) from [] (remove_config.isra.6+0x98/0x9c [libcomposite])
    [] (remove_config.isra.6 [libcomposite]) from [] (__composite_unbind+0x34/0x98 [libcomposite])
    [] (__composite_unbind [libcomposite]) from [] (usb_gadget_remove_driver+0x50/0x78)
    [] (usb_gadget_remove_driver) from [] (usb_gadget_unregister_driver+0x64/0x94)
    [] (usb_gadget_unregister_driver) from [] (hidg_cleanup+0x10/0x34 [g_hid])
    [] (hidg_cleanup [g_hid]) from [] (SyS_delete_module+0x118/0x19c)
    [] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x30)
    Code: bad PC value

    Signed-off-by: Songjun Wu
    [nicolas.ferre@atmel.com: reworked the commit message]
    Signed-off-by: Nicolas Ferre
    Fixes: 914a3f3b3754 ("USB: add atmel_usba_udc driver")
    Signed-off-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Songjun Wu
     
  • commit 6785a1034461c2d2c205215f63a50a740896e55b upstream.

    When receive data, the RXRDY in status register set by hardware
    after a new packet has been stored in the endpoint FIFO. When it
    is copied from FIFO, this bit is cleared which make the FIFO can
    be accessed again.

    In the receive_data() function, this bit RXRDY has been cleared.
    So, after the receive_data() function return, this bit should
    not be cleared again, or else it may cause the accessing FIFO
    corrupt, which will make the data loss.

    Fixes: 914a3f3b3754 (USB: add atmel_usba_udc driver)
    Acked-by: Nicolas Ferre
    Signed-off-by: Bo Shen
    Signed-off-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Bo Shen
     
  • commit f40afdddeb6c54ffd1e2920a5e93e363d6748db6 upstream.

    According to the datasheet, when transfer using DMA, the control
    setting for IN packet only need END_BUF_EN, END_BUF_IE, CH_EN,
    while for OUT packet, need more two bits END_TR_EN and END_TR_IE
    to be configured.

    Fixes: 914a3f3b3754 (USB: add atmel_usba_udc driver)
    Acked-by: Nicolas Ferre
    Signed-off-by: Bo Shen
    Signed-off-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Bo Shen
     
  • commit b44be2462dbe3e23f0aedff64de52a1e8e47a1cd upstream.

    Commit 3b74c73f8d6f053f422e85fce955b61fb181cfe7 switched over to memdup_user()
    in ep_write() function and removed kfree (kbuf).
    memdup_user() function allocates memory which is never freed.

    Fixes: 3b74c73 (usb: gadget: inode: switch over to memdup_user())
    Signed-off-by: Mario Schuknecht
    Signed-off-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Mario Schuknecht
     
  • commit b5122236bba8d7ef62153da5b55cc65d0944c61e upstream.

    Fix null-pointer dereference during probe if the interface-status
    completion handler is called before the individual ports have been set
    up.

    Fixes: f79b2d0fe81e ("USB: keyspan: fix NULL-pointer dereferences and
    memory leaks")
    Reported-by: Richard
    Tested-by: Richard
    Signed-off-by: Johan Hovold
    Signed-off-by: Greg Kroah-Hartman

    Johan Hovold
     
  • commit d80c0d14183516f184a5ac88e11008ee4c7d2a2e upstream.

    As has been discussed in the thread starting with
    https://lkml.kernel.org/g/549748e9.d+SiJzqu50f1r4lSAL043YSc@arcor.de
    Sierra Wireless MC73xx devices with USB VID/PID 0x1199:0x68c0 require the
    option_send_setup() code to be used on the USB interface for the AT port
    to make unsolicited response codes work correctly. Move these devices from
    the qcserial driver where they have been added by commit
    70a3615fc07c2330ed7c1e922f3c44f4a67c0762 ("usb: qcserial: add Sierra Wireless
    MC73xx") to the option driver and add a MC73xx-specific blacklist
    to ensure that
    1. the sendsetup code is not used for the DIAG/DM and NMEA interfaces
    2. the option driver does not attach to the QMI/network interfaces

    Signed-off-by: Reinhard Speyerer
    Signed-off-by: Johan Hovold
    Signed-off-by: Greg Kroah-Hartman

    Reinhard Speyerer
     
  • commit 1ae78a4870989a354028cb17dabf819b595e70e3 upstream.

    Added virtual com port VID/PID entries for CEL USB sticks and MeshWorks
    devices.

    Signed-off-by: David Peterson
    Signed-off-by: Johan Hovold
    Signed-off-by: Greg Kroah-Hartman

    David Peterson
     
  • commit 90441b4dbe90ba0c38111ea89fa093a8c9627801 upstream.

    Fixing typo for MeshConnect IDs. The original PID (0x8875) is not in
    production and is not needed. Instead it has been changed to the
    official production PID (0x8857).

    Signed-off-by: Preston Fick
    Signed-off-by: Johan Hovold
    Signed-off-by: Greg Kroah-Hartman

    Preston Fick
     
  • commit 39e60635a01520e8c8ed3946a28c2b98e6a46f79 upstream.

    DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This
    means, the max TRBs that can be submitted for an EP is fixed to 32. Since the
    request queue for an EP is a linked list, any number of requests can be queued
    to it by the gadget layer. However, the dwc3 driver must not submit TRBs more
    than the pool it has created for. This limit wasn't respected when SG was used
    resulting in submitting more than the max TRBs, eventually leading to
    non-transfer of the TRBs submitted over the max limit.

    Root cause:
    When SG is used, there are two loops iterating to prepare TRBs:
    - Outer loop over the request_list
    - Inner loop over the SG list
    The code was missing break to get out of the outer loop.

    Fixes: eeb720fb21d6 (usb: dwc3: gadget: add support for SG lists)
    Signed-off-by: Amit Virdi
    Signed-off-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Amit Virdi
     
  • commit ec512fb8e5611fed1df2895f90317ce6797d6b32 upstream.

    When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
    request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
    only when it is the last TRB being prepared from the last dwc3_request entry.

    The current implementation uses list_is_last to check if the dwc3_request is the
    last entry from the request_list. However, list_is_last returns false for the
    last entry too. This is because, while preparing the first TRB from a request,
    the function dwc3_prepare_one_trb modifies the request's next and prev pointers
    while moving the URB to req_queued. Hence, list_is_last always returns false no
    matter what.

    The correct way is not to access the modified pointers of dwc3_request but to
    use list_empty macro instead.

    Fixes: e5ba5ec833aa (usb: dwc3: gadget: fix scatter gather implementation)
    Signed-off-by: Amit Virdi
    Signed-off-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Amit Virdi
     
  • commit 56abcab833fafcfaeb2f5b25e0364c1dec45f53e upstream.

    Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
    introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
    board. The code path that was previously specific to NVIDIA controllers
    had then become taken for all chips.

    However, the M5237 installed on the board wedges solid when accessing
    its base+OHCI_FMINTERVAL register, making it impossible to boot any
    kernel newer than 3.1.8 on this particular and apparently other similar
    machines.

    Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237.

    The patch is suitable for the -next tree as well as all maintained
    kernels up to 3.2 inclusive.

    Signed-off-by: Arseny Solokha
    Acked-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Greg Kroah-Hartman

    Arseny Solokha
     
  • commit 0915e6feb38de8d3601819992a5bd050201a56fa upstream.

    The gpio device attributes were never destroyed when the gpio was
    unexported (or on export failures).

    Use device_create_with_groups() to create the default device attributes
    of the gpio class device. Note that this also fixes the
    attribute-creation race with userspace for these attributes.

    Remove contingent attributes in export error path and on unexport.

    Fixes: d8f388d8dc8d ("gpio: sysfs interface")
    Signed-off-by: Johan Hovold
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Johan Hovold
     
  • commit 121b6a79955a3a3fd7bbb9b8cb88d5b9dad6283d upstream.

    The gpio-chip device attributes were never destroyed when the device was
    removed.

    Fix by using device_create_with_groups() to create the device attributes
    of the chip class device.

    Note that this also fixes the attribute-creation race with userspace.

    Fixes: d8f388d8dc8d ("gpio: sysfs interface")
    Signed-off-by: Johan Hovold
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Johan Hovold
     
  • commit 6798acaa0138d8b12f1c54402ebcb66fea3deb03 upstream.

    Move direct and indirect calls to gpiochip_remove_pin_ranges outside of
    spin lock as they can end up taking a mutex in pinctrl_remove_gpio_range.

    Note that the pin ranges are already added outside of the lock.

    Fixes: 9ef0d6f7628b ("gpiolib: call pin removal in chip removal function")
    Fixes: f23f1516b675 ("gpiolib: provide provision to register pin ranges")
    Signed-off-by: Johan Hovold
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Johan Hovold
     
  • commit 00acc3dc248063f982cfacfbe5e78c0d6797ffef upstream.

    Fix memory leak and sleep-while-atomic in gpiochip_remove.

    The memory leak was introduced by afa82fab5e13 ("gpio / ACPI: Move event
    handling registration to gpiolib irqchip helpers") that moved the
    release of acpi interrupt resources to gpiochip_irqchip_remove, but by
    then the resources are no longer accessible as the acpi_gpio_chip has
    already been freed by acpi_gpiochip_remove.

    Note that this also fixes a few potential sleep-while-atomics, which has
    been around since 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib")
    when the call to gpiochip_irqchip_remove while holding a spinlock was
    added (a couple of irq-domain paths can end up grabbing mutexes).

    Fixes: afa82fab5e13 ("gpio / ACPI: Move event handling registration to
    gpiolib irqchip helpers")
    Fixes: 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib")

    Signed-off-by: Johan Hovold
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Johan Hovold
     
  • commit 5539b3c938d64a60cb1fc442ac3ce9263d52de0c upstream.

    Memory allocated and references taken by of_gpiochip_add and
    acpi_gpiochip_add were never released on errors in gpiochip_add (e.g.
    failure to find free gpio range).

    Fixes: 391c970c0dd1 ("of/gpio: add default of_xlate function if device
    has a node pointer")
    Fixes: 664e3e5ac64c ("gpio / ACPI: register to ACPI events
    automatically")

    Signed-off-by: Johan Hovold
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Johan Hovold
     
  • commit e733a2fb8cbcff0747108cb529ffb4e4a00465ac upstream.

    The CrystalCove GPIO chip has can_sleep set so its demultiplexed irqs
    will have IRQ_NESTED_THREAD flag set, thus we should use the nested
    version handle_nested_irq in CrystalCove's irq handler instead of
    handle_generic_irq, or the following warning will be hit and the
    functionality is lost:

    [ 4089.639554] Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.313 08/13/2014
    [ 4089.639564] 00000002 00000000 c24fbdf4 c16e0257 c24fbe38 c24fbe28 c105390c c18ec480
    [ 4089.639596] c24fbe54 00000048 c18f8e3b 00000295 c10a60fc 00000295 c10a60fc f4464540
    [ 4089.639626] f446459c c278ad40 c24fbe40 c1053974 00000009 c24fbe38 c18ec480 c24fbe54
    [ 4089.639656] Call Trace:
    [ 4089.639685] [] dump_stack+0x41/0x52
    [ 4089.639707] [] warn_slowpath_common+0x8c/0xc0
    [ 4089.639727] [] ? irq_nested_primary_handler+0x2c/0x30
    [ 4089.639744] [] ? irq_nested_primary_handler+0x2c/0x30
    [ 4089.639763] [] warn_slowpath_fmt+0x34/0x40
    [ 4089.639781] [] irq_nested_primary_handler+0x2c/0x30
    [ 4089.639800] [] handle_irq_event_percpu+0x76/0x190
    [ 4089.639818] [] ? regmap_format_10_14_write+0x30/0x30
    [ 4089.639836] [] ? _regmap_bus_raw_write+0x4c/0x70
    [ 4089.639854] [] handle_irq_event+0x31/0x50
    [ 4089.639872] [] handle_simple_irq+0x4b/0x70
    [ 4089.639889] [] generic_handle_irq+0x24/0x40
    [ 4089.639908] [] crystalcove_gpio_irq_handler+0xa7/0xc0
    [ 4089.639927] [] handle_nested_irq+0x77/0x190
    [ 4089.639947] [] regmap_irq_thread+0x1b1/0x360
    [ 4089.639966] [] irq_thread_fn+0x18/0x30
    [ 4089.639983] [] irq_thread+0xf6/0x110
    [ 4089.640001] [] ? irq_finalize_oneshot.part.30+0x1b0/0x1b0
    [ 4089.640019] [] ? irq_forced_thread_fn+0x50/0x50
    [ 4089.640037] [] ? irq_thread_check_affinity+0xc0/0xc0
    [ 4089.640054] [] kthread+0xa9/0xc0
    [ 4089.640074] [] ret_from_kernel_thread+0x21/0x30
    [ 4089.640091] [] ? kthread_create_on_node+0x110/0x110
    [ 4089.640105] ---[ end trace dca7946ad31eba7d ]---

    Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=90521
    Reported-and-tested-by: Brian Loften
    Signed-off-by: Aaron Lu
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Aaron Lu
     
  • commit 7b8792bbdffdff3abda704f89c6a45ea97afdc62 upstream.

    of_get_named_gpiod_flags fails with -EPROBE_DEFER in cases
    where the gpio chip is available and the GPIO translation fails.

    This causes drivers to be re-probed erroneusly, and hides the
    real problem(i.e. the GPIO number being out of range).

    Signed-off-by: Hans Holmberg
    Reviewed-by: Alexandre Courbot
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Hans Holmberg
     
  • commit 41f632fe177bc4822c2e8236fe7c291e6e9eb6f8 upstream.

    Remove bogus call to of_gpiochip_add (and of_gpio_chip remove in error
    path) which is also called when adding the gpio chip.

    This prevents adding the same pinctrl range twice.

    Fixes: 3f8c50c9b110 ("OF: pinctrl: MIPS: lantiq: implement lantiq/xway
    pinctrl support")

    Signed-off-by: Johan Hovold
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Johan Hovold
     
  • commit 5138d5c562e3bfe30964e20ab46eec9f8b89225d upstream.

    The gpio4 and gpio5 are in 0xf7fc0000 apb which is located in the SM domain.
    This patch moves gpio4 and gpio5 to the correct location. This patch also
    renames them as the following to match the names we internally used in
    marvell:
    gpio4 -> sm_gpio1
    gpio5 -> sm_gpio0
    porte -> portf
    portf -> porte

    This also matches what we did for BG2 and BG2CD's SM GPIO.

    Fixes: cedf57fc4f2f ("ARM: dts: berlin: add the BG2Q GPIO nodes")
    Signed-off-by: Jisheng Zhang
    Signed-off-by: Sebastian Hesselbarth
    Signed-off-by: Greg Kroah-Hartman

    Jisheng Zhang
     
  • commit 41544f9f38f19cb46dc9a8fa37c58677a0300899 upstream.

    Call spin_lock_init() before the spinlocks are used, both in early init
    and probe functions preventing a lockdep splat.

    I have been observing lockdep complaining [1] during boot on my a80 optimus [2]
    when CONFIG_PROVE_LOCKING has been enabled. This patch resolves the splat,
    and has been tested on a few other sunxi platforms without issue.

    [1] http://storage.kernelci.org/next/next-20150107/arm-multi_v7_defconfig+CONFIG_PROVE_LOCKING=y/lab-tbaker/boot-sun9i-a80-optimus.html
    [2] http://kernelci.org/boot/?a80-optimus

    Signed-off-by: Tyler Baker
    Acked-by: Philipp Zabel
    Signed-off-by: Kevin Hilman
    Signed-off-by: Olof Johansson
    Signed-off-by: Greg Kroah-Hartman

    Tyler Baker
     
  • commit 3ca8c717429b90f621aed28af029da4c3da378bc upstream.

    Just like all previous UAS capable Seagate disk enclosures, these need the
    US_FL_NO_ATA_1X to not crash when udev probes them.

    Signed-off-by: Hans de Goede
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     
  • commit c6fa3945c8b5baf62f2e849104ecd6f3a1e5e407 upstream.

    Like the JMicron JMS567 enclosures with the JMS566 choke on report-opcodes,
    so avoid it.

    Tested-and-reported-by: Takeo Nakayama
    Signed-off-by: Hans de Goede
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     
  • commit e5797a3d079f3e5049140055d850691b5cc7d10a upstream.

    This is yet another Seagate device which needs the US_FL_NO_ATA_1X quirk

    Reported-by: Marcin Zajączkowski
    Signed-off-by: Hans de Goede
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     
  • commit b13a65ef190e488e2761d65bdd2e1fe8a3a125f5 upstream.

    H_RST bit in H_CSR register may be found lit before reset is started,
    for example if preceding reset flow hasn't completed.
    In that case asserting H_RST will be ignored, therefore we need to clean
    H_RST bit to start a successful reset sequence.

    Signed-off-by: Alexander Usyskin
    Signed-off-by: Tomas Winkler
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Greg Kroah-Hartman

    Alexander Usyskin