01 Mar, 2012

40 commits

  • Greg Kroah-Hartman
     
  • commit 822bfa51ce44f2c63c300fdb76dc99c4d5a5ca9f upstream.

    "nframes" comes from the user and "nframes * CD_FRAMESIZE_RAW" can wrap
    on 32 bit systems. That would have been ok if we used the same wrapped
    value for the copy, but we use a shifted value. We should just use the
    checked version of copy_to_user() because it's not going to make a
    difference to the speed.

    Signed-off-by: Dan Carpenter
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     
  • commit 28d82dc1c4edbc352129f97f4ca22624d1fe61de upstream.

    The current epoll code can be tickled to run basically indefinitely in
    both loop detection path check (on ep_insert()), and in the wakeup paths.
    The programs that tickle this behavior set up deeply linked networks of
    epoll file descriptors that cause the epoll algorithms to traverse them
    indefinitely. A couple of these sample programs have been previously
    posted in this thread: https://lkml.org/lkml/2011/2/25/297.

    To fix the loop detection path check algorithms, I simply keep track of
    the epoll nodes that have been already visited. Thus, the loop detection
    becomes proportional to the number of epoll file descriptor and links.
    This dramatically decreases the run-time of the loop check algorithm. In
    one diabolical case I tried it reduced the run-time from 15 mintues (all
    in kernel time) to .3 seconds.

    Fixing the wakeup paths could be done at wakeup time in a similar manner
    by keeping track of nodes that have already been visited, but the
    complexity is harder, since there can be multiple wakeups on different
    cpus...Thus, I've opted to limit the number of possible wakeup paths when
    the paths are created.

    This is accomplished, by noting that the end file descriptor points that
    are found during the loop detection pass (from the newly added link), are
    actually the sources for wakeup events. I keep a list of these file
    descriptors and limit the number and length of these paths that emanate
    from these 'source file descriptors'. In the current implemetation I
    allow 1000 paths of length 1, 500 of length 2, 100 of length 3, 50 of
    length 4 and 10 of length 5. Note that it is sufficient to check the
    'source file descriptors' reachable from the newly added link, since no
    other 'source file descriptors' will have newly added links. This allows
    us to check only the wakeup paths that may have gotten too long, and not
    re-check all possible wakeup paths on the system.

    In terms of the path limit selection, I think its first worth noting that
    the most common case for epoll, is probably the model where you have 1
    epoll file descriptor that is monitoring n number of 'source file
    descriptors'. In this case, each 'source file descriptor' has a 1 path of
    length 1. Thus, I believe that the limits I'm proposing are quite
    reasonable and in fact may be too generous. Thus, I'm hoping that the
    proposed limits will not prevent any workloads that currently work to
    fail.

    In terms of locking, I have extended the use of the 'epmutex' to all
    epoll_ctl add and remove operations. Currently its only used in a subset
    of the add paths. I need to hold the epmutex, so that we can correctly
    traverse a coherent graph, to check the number of paths. I believe that
    this additional locking is probably ok, since its in the setup/teardown
    paths, and doesn't affect the running paths, but it certainly is going to
    add some extra overhead. Also, worth noting is that the epmuex was
    recently added to the ep_ctl add operations in the initial path loop
    detection code using the argument that it was not on a critical path.

    Another thing to note here, is the length of epoll chains that is allowed.
    Currently, eventpoll.c defines:

    /* Maximum number of nesting allowed inside epoll sets */
    #define EP_MAX_NESTS 4

    This basically means that I am limited to a graph depth of 5 (EP_MAX_NESTS
    + 1). However, this limit is currently only enforced during the loop
    check detection code, and only when the epoll file descriptors are added
    in a certain order. Thus, this limit is currently easily bypassed. The
    newly added check for wakeup paths, stricly limits the wakeup paths to a
    length of 5, regardless of the order in which ep's are linked together.
    Thus, a side-effect of the new code is a more consistent enforcement of
    the graph depth.

    Thus far, I've tested this, using the sample programs previously
    mentioned, which now either return quickly or return -EINVAL. I've also
    testing using the piptest.c epoll tester, which showed no difference in
    performance. I've also created a number of different epoll networks and
    tested that they behave as expectded.

    I believe this solves the original diabolical test cases, while still
    preserving the sane epoll nesting.

    Signed-off-by: Jason Baron
    Cc: Nelson Elhage
    Cc: Davide Libenzi
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Jason Baron
     
  • commit 971316f0503a5c50633d07b83b6db2f15a3a5b00 upstream.

    signalfd_cleanup() ensures that ->signalfd_wqh is not used, but
    this is not enough. eppoll_entry->whead still points to the memory
    we are going to free, ep_unregister_pollwait()->remove_wait_queue()
    is obviously unsafe.

    Change ep_poll_callback(POLLFREE) to set eppoll_entry->whead = NULL,
    change ep_unregister_pollwait() to check pwq->whead != NULL under
    rcu_read_lock() before remove_wait_queue(). We add the new helper,
    ep_remove_wait_queue(), for this.

    This works because sighand_cachep is SLAB_DESTROY_BY_RCU and because
    ->signalfd_wqh is initialized in sighand_ctor(), not in copy_sighand.
    ep_unregister_pollwait()->remove_wait_queue() can play with already
    freed and potentially reused ->sighand, but this is fine. This memory
    must have the valid ->signalfd_wqh until rcu_read_unlock().

    Reported-by: Maxime Bizon
    Signed-off-by: Oleg Nesterov
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Oleg Nesterov
     
  • commit d80e731ecab420ddcb79ee9d0ac427acbc187b4b upstream.

    This patch is intentionally incomplete to simplify the review.
    It ignores ep_unregister_pollwait() which plays with the same wqh.
    See the next change.

    epoll assumes that the EPOLL_CTL_ADD'ed file controls everything
    f_op->poll() needs. In particular it assumes that the wait queue
    can't go away until eventpoll_release(). This is not true in case
    of signalfd, the task which does EPOLL_CTL_ADD uses its ->sighand
    which is not connected to the file.

    This patch adds the special event, POLLFREE, currently only for
    epoll. It expects that init_poll_funcptr()'ed hook should do the
    necessary cleanup. Perhaps it should be defined as EPOLLFREE in
    eventpoll.

    __cleanup_sighand() is changed to do wake_up_poll(POLLFREE) if
    ->signalfd_wqh is not empty, we add the new signalfd_cleanup()
    helper.

    ep_poll_callback(POLLFREE) simply does list_del_init(task_list).
    This make this poll entry inconsistent, but we don't care. If you
    share epoll fd which contains our sigfd with another process you
    should blame yourself. signalfd is "really special". I simply do
    not know how we can define the "right" semantics if it used with
    epoll.

    The main problem is, epoll calls signalfd_poll() once to establish
    the connection with the wait queue, after that signalfd_poll(NULL)
    returns the different/inconsistent results depending on who does
    EPOLL_CTL_MOD/signalfd_read/etc. IOW: apart from sigmask, signalfd
    has nothing to do with the file, it works with the current thread.

    In short: this patch is the hack which tries to fix the symptoms.
    It also assumes that nobody can take tasklist_lock under epoll
    locks, this seems to be true.

    Note:

    - we do not have wake_up_all_poll() but wake_up_poll()
    is fine, poll/epoll doesn't use WQ_FLAG_EXCLUSIVE.

    - signalfd_cleanup() uses POLLHUP along with POLLFREE,
    we need a couple of simple changes in eventpoll.c to
    make sure it can't be "lost".

    Reported-by: Maxime Bizon
    Signed-off-by: Oleg Nesterov
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Oleg Nesterov
     
  • commit c1c1a3d012fe5e82a9a025fb4b5a4f8ee67a53f6 upstream.

    By hwmon sysfs interface convention, setting pwm_enable to zero sets a fan
    to full speed. In the f75375s driver, this need be done by enabling
    manual fan control, plus duty mode for the F875387 chip, and then setting
    the maximum duty cycle. Fix a bug where the two necessary register writes
    were swapped, effectively discarding the setting to full-speed.

    Signed-off-by: Nikolaus Schulz
    Cc: Riku Voipio
    Signed-off-by: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Nikolaus Schulz
     
  • commit 8791d63af0cf113725ae4cb8cba9492814c59a93 upstream.

    This patch is just a minor update to one titled "imon: Input from ffdc
    device type ignored" from Corinna Vinschen. An earlier patch to prevent
    an oops when we got early callbacks also has the nasty side-effect of
    wedging imon hardware, as we don't acknowledge the urb. Rework the check
    slightly here to bypass processing the packet, as the driver isn't yet
    fully initialized, but still acknowlege the urb and submit a new rx_urb.
    Do this for both interfaces -- irrelevant for ffdc hardware, but
    relevant for newer hardware, though newer hardware doesn't spew the
    constant stream of data as soon as the hardware is initialized like the
    older ffdc devices, so they'd be less likely to trigger this anyway...

    Tested with both an ffdc device and an 0042 device.

    Reported-by: Corinna Vinschen
    Signed-off-by: Jarod Wilson
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Jarod Wilson
     
  • commit afa159538af61f1a65d48927f4e949fe514fb4fc upstream.

    status has to be set to STREAMING before the streaming worker is
    queued. hdpvr_transmit_buffers() will exit immediately otherwise.

    Reported-by: Joerg Desch
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Janne Grunau
     
  • commit a7762b10c12a70c5dbf2253142764b728ac88c3a upstream.

    In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
    hardware can cause an infinite loop in the common sja1000 isr.

    Use the already retrieved status register to indicate a possible hardware
    removal and double check by reading the mode register in sja1000_is_absent.

    Signed-off-by: Oliver Hartkopp
    Acked-by: Wolfgang Grandegger
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Greg Kroah-Hartman

    Oliver Hartkopp
     
  • commit 6c635224602d760c1208ada337562f40d8ae93a5 upstream.

    The current use of /tmp for file lists is insecure. Put them under
    $objtree/debian instead.

    Signed-off-by: Ben Hutchings
    Acked-by: maximilian attems
    Signed-off-by: Michal Marek
    Signed-off-by: Greg Kroah-Hartman

    Ben Hutchings
     
  • commit 5d69703263d588dbb03f4e57091afd8942d96e6d upstream.

    This patch fixes a regression that was introduced by

    commit 0a5f38467765ee15478db90d81e40c269c8dda20
    davinci_emac: Add Carrier Link OK check in Davinci RX Handler

    Said commit adds a check whether the carrier link is ok. If the link is
    not ok, the skb is freed and no new dma descriptor added to the rx dma
    channel. This causes trouble during initialization when the carrier
    status has not yet been updated. If a lot of packets are received while
    netif_carrier_ok returns false, all dma descriptors are freed and the
    rx dma transfer is stopped.

    The bug occurs when the board is connected to a network with lots of
    traffic and the ifconfig down/up is done, e.g., when reconfiguring
    the interface with DHCP.

    The bug can be reproduced by flood pinging the davinci board while doing
    ifconfig eth0 down
    ifconfig eth0 up
    on the board.

    After that, the rx path stops working and the overrun value reported
    by ifconfig is counting up.

    This patch reverts commit 0a5f38467765ee15478db90d81e40c269c8dda20
    and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.

    Signed-off-by: Christian Riesch
    Cc: Cyril Chemparathy
    Cc: Sascha Hauer
    Tested-by: Rajashekhara, Sudhakar
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Christian Riesch
     
  • commit ba9adbe67e288823ac1deb7f11576ab5653f833e upstream.

    Set the RX FIFO flush watermark lower.
    According to Federico and JMicron's reply,
    setting it to 16QW would be stable on most platforms.
    Otherwise, user might experience packet drop issue.

    Reported-by: Federico Quagliata
    Fixed-by: Federico Quagliata
    Signed-off-by: Guo-Fu Tseng
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Guo-Fu Tseng
     
  • commit e0aac52e17a3db68fe2ceae281780a70fc69957f upstream.

    Commit f11017ec2d1859c661f4e2b12c4a8d250e1f47cf (2.6.37)
    moved the fwmark variable in subcontext that is invalidated before
    reaching the ip_vs_ct_in_get call. As vaddr is provided as pointer
    in the param structure make sure the fwmark variable is in
    same context. As the fwmark templates can not be matched,
    more and more template connections are created and the
    controlled connections can not go to single real server.

    Signed-off-by: Julian Anastasov
    Signed-off-by: Simon Horman
    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: Greg Kroah-Hartman

    Simon Horman
     
  • commit fea6d607e154cf96ab22254ccb48addfd43d4cb5 upstream.

    This patch (as1520) fixes a bug in the SCSI layer's power management
    implementation.

    LUN scanning can be carried out asynchronously in do_scan_async(), and
    sd uses an asynchronous thread for the time-consuming parts of disk
    probing in sd_probe_async(). Currently nothing coordinates these
    async threads with system sleep transitions; they can and do attempt
    to continue scanning/probing SCSI devices even after the host adapter
    has been suspended. As one might expect, the outcome is not ideal.

    This is what the "prepare" stage of system suspend was created for.
    After the prepare callback has been called for a host, target, or
    device, drivers are not allowed to register any children underneath
    them. Currently the SCSI prepare callback is not implemented; this
    patch rectifies that omission.

    For SCSI hosts, the prepare routine calls scsi_complete_async_scans()
    to wait until async scanning is finished. It might be slightly more
    efficient to wait only until the host in question has been scanned,
    but there's currently no way to do that. Besides, during a sleep
    transition we will ultimately have to wait until all the host scanning
    has finished anyway.

    For SCSI devices, the prepare routine calls async_synchronize_full()
    to wait until sd probing is finished. The routine does nothing for
    SCSI targets, because asynchronous target scanning is done only as
    part of host scanning.

    Signed-off-by: Alan Stern
    Signed-off-by: James Bottomley
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     
  • commit 267a6ad4aefaafbde607804c60945bcf97f91c1b upstream.

    In do_scan_async(), calling scsi_autopm_put_host(shost) may reference
    freed shost, and cause Posison overwitten warning.
    Yes, this case can happen, for example, an USB is disconnected just
    when do_scan_async() thread starts to run, then scsi_host_put() called
    in scsi_finish_async_scan() will lead to shost be freed(because the
    refcount of shost->shost_gendev decreases to 1 after USB disconnects),
    at this point, if references shost again, system will show following
    warning msg.

    To make scsi_autopm_put_host(shost) always reference a valid shost,
    put it just before scsi_host_put() in function
    scsi_finish_async_scan().

    [ 299.281565] =============================================================================
    [ 299.281634] BUG kmalloc-4096 (Tainted: G I ): Poison overwritten
    [ 299.281682] -----------------------------------------------------------------------------
    [ 299.281684]
    [ 299.281752] INFO: 0xffff880056c305d0-0xffff880056c305d0. First byte
    0x6a instead of 0x6b
    [ 299.281816] INFO: Allocated in scsi_host_alloc+0x4a/0x490 age=1688
    cpu=1 pid=2004
    [ 299.281870] __slab_alloc+0x617/0x6c1
    [ 299.281901] __kmalloc+0x28c/0x2e0
    [ 299.281931] scsi_host_alloc+0x4a/0x490
    [ 299.281966] usb_stor_probe1+0x5b/0xc40 [usb_storage]
    [ 299.282010] storage_probe+0xa4/0xe0 [usb_storage]
    [ 299.282062] usb_probe_interface+0x172/0x330 [usbcore]
    [ 299.282105] driver_probe_device+0x257/0x3b0
    [ 299.282138] __driver_attach+0x103/0x110
    [ 299.282171] bus_for_each_dev+0x8e/0xe0
    [ 299.282201] driver_attach+0x26/0x30
    [ 299.282230] bus_add_driver+0x1c4/0x430
    [ 299.282260] driver_register+0xb6/0x230
    [ 299.282298] usb_register_driver+0xe5/0x270 [usbcore]
    [ 299.282337] 0xffffffffa04ab03d
    [ 299.282364] do_one_initcall+0x47/0x230
    [ 299.282396] sys_init_module+0xa0f/0x1fe0
    [ 299.282429] INFO: Freed in scsi_host_dev_release+0x18a/0x1d0 age=85
    cpu=0 pid=2008
    [ 299.282482] __slab_free+0x3c/0x2a1
    [ 299.282510] kfree+0x296/0x310
    [ 299.282536] scsi_host_dev_release+0x18a/0x1d0
    [ 299.282574] device_release+0x74/0x100
    [ 299.282606] kobject_release+0xc7/0x2a0
    [ 299.282637] kobject_put+0x54/0xa0
    [ 299.282668] put_device+0x27/0x40
    [ 299.282694] scsi_host_put+0x1d/0x30
    [ 299.282723] do_scan_async+0x1fc/0x2b0
    [ 299.282753] kthread+0xdf/0xf0
    [ 299.282782] kernel_thread_helper+0x4/0x10
    [ 299.282817] INFO: Slab 0xffffea00015b0c00 objects=7 used=7 fp=0x
    (null) flags=0x100000000004080
    [ 299.282882] INFO: Object 0xffff880056c30000 @offset=0 fp=0x (null)
    [ 299.282884]
    ...

    Signed-off-by: Huajun Li
    Acked-by: Alan Stern
    Signed-off-by: James Bottomley
    Signed-off-by: Greg Kroah-Hartman

    Huajun Li
     
  • commit b4bc724e82e80478cba5fe9825b62e71ddf78757 upstream.

    An interrupt might be pending when irq_startup() is called, but the
    startup code does not invoke the resend logic. In some cases this
    prevents the device from issuing another interrupt which renders the
    device non functional.

    Call the resend function in irq_startup() to keep things going.

    Reported-and-tested-by: Russell King
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     
  • commit ac5637611150281f398bb7a47e3fcb69a09e7803 upstream.

    When the primary handler of an interrupt which is marked IRQ_ONESHOT
    returns IRQ_HANDLED or IRQ_NONE, then the interrupt thread is not
    woken and the unmask logic of the interrupt line is never
    invoked. This keeps the interrupt masked forever.

    This was not noticed as most IRQ_ONESHOT users wake the thread
    unconditionally (usually because they cannot access the underlying
    device from hard interrupt context). Though this behaviour was nowhere
    documented and not necessarily intentional. Some drivers can avoid the
    thread wakeup in certain cases and run into the situation where the
    interrupt line s kept masked.

    Handle it gracefully.

    Reported-and-tested-by: Lothar Wassmann
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     
  • commit 2504a6423b9ab4c36df78227055995644de19edb upstream.

    Rate control algorithms are supposed to stop processing when they
    encounter a rate with the index -1. Checking for rate->count not being
    zero is not enough.

    Allowing a rate with negative index leads to memory corruption in
    ath_debug_stat_rc().

    One consequence of the bug is discussed at
    https://bugzilla.redhat.com/show_bug.cgi?id=768639

    Signed-off-by: Pavel Roskin
    Signed-off-by: John W. Linville
    Signed-off-by: Greg Kroah-Hartman

    Pavel Roskin
     
  • commit 32c3233885eb10ac9cb9410f2f8cd64b8df2b2a1 upstream.

    For L1 instruction cache and L2 cache the shared CPU information
    is wrong. On current AMD family 15h CPUs those caches are shared
    between both cores of a compute unit.

    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=42607

    Signed-off-by: Andreas Herrmann
    Cc: Petkov Borislav
    Cc: Dave Jones
    Link: http://lkml.kernel.org/r/20120208195229.GA17523@alberich.amd.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Andreas Herrmann
     
  • commit d980e0f8d858c6963d676013e976ff00ab7acb2b upstream.

    When the PMIC is not found, voltdm->pmic will be NULL. vp.c's
    initialization function tries to dereferences this, which causes an
    oops:

    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = c0004000
    [00000000] *pgd=00000000
    Internal error: Oops: 5 [#1] PREEMPT
    Modules linked in:
    CPU: 0 Not tainted (3.3.0-rc2+ #204)
    PC is at omap_vp_init+0x5c/0x15c
    LR is at omap_vp_init+0x58/0x15c
    pc : [] lr : [] psr: 60000013
    sp : c181ff30 ip : c181ff68 fp : c181ff64
    r10: c0407808 r9 : c040786c r8 : c0407814
    r7 : c0026868 r6 : c00264fc r5 : c040ad6c r4 : 00000000
    r3 : 00000040 r2 : 000032c8 r1 : 0000fa00 r0 : 000032c8
    Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
    Control: 10c5387d Table: 80004019 DAC: 00000015
    Process swapper (pid: 1, stack limit = 0xc181e2e8)
    Stack: (0xc181ff30 to 0xc1820000)
    ff20: c0381d00 c02e9c6d c0383582 c040786c
    ff40: c040ad6c c00264fc c0026868 c0407814 00000000 c03d9de4 c181ff8c c181ff68
    ff60: c03db448 c03db830 c02e982c c03fdfb8 c03fe004 c0039988 00000013 00000000
    ff80: c181ff9c c181ff90 c03d9df8 c03db390 c181ffdc c181ffa0 c0008798 c03d9df0
    ffa0: c181ffc4 c181ffb0 c0055a44 c0187050 c0039988 c03fdfb8 c03fe004 c0039988
    ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03d1284 c0008708
    ffe0: 00000000 c03d1208 00000000 c181fff8 c0039988 c03d1214 1077ce40 01f7ee08
    Backtrace:
    [] (omap_vp_init+0x0/0x15c) from [] (omap_voltage_late_init+0xc4/0xfc)
    [] (omap_voltage_late_init+0x0/0xfc) from [] (omap2_common_pm_late_init+0x14/0x54)
    r8:00000000 r7:00000013 r6:c0039988 r5:c03fe004 r4:c03fdfb8
    [] (omap2_common_pm_late_init+0x0/0x54) from [] (do_one_initcall+0x9c/0x164)
    [] (do_one_initcall+0x0/0x164) from [] (kernel_init+0x7c/0x120)
    [] (kernel_init+0x0/0x120) from [] (do_exit+0x0/0x2cc)
    r5:c03d1208 r4:00000000
    Code: e5ca300b e5900034 ebf69027 e5994024 (e5941000)
    ---[ end trace aed617dddaf32c3d ]---
    Kernel panic - not syncing: Attempted to kill init!

    Signed-off-by: Russell King
    Cc: Igor Grinberg
    Signed-off-by: Greg Kroah-Hartman

    Russell King
     
  • commit 40410715715178ec196314dd0c19150c06901f80 upstream.

    When a PMIC is not found, this driver is unable to obtain its
    'vdds_dsi_reg' regulator. Even through its initialization function
    fails, other code still calls its enable function, which fails to
    check whether it has this regulator before asking for it to be enabled.

    This fixes the oops, however a better fix would be to sort out the
    upper layers to prevent them calling into a module which failed to
    initialize.

    Unable to handle kernel NULL pointer dereference at virtual address 00000038
    pgd = c0004000
    [00000038] *pgd=00000000
    Internal error: Oops: 5 [#1] PREEMPT
    Modules linked in:
    CPU: 0 Not tainted (3.3.0-rc2+ #228)
    PC is at regulator_enable+0x10/0x70
    LR is at omapdss_dpi_display_enable+0x54/0x15c
    pc : [] lr : [] psr: 60000013
    sp : c181fd90 ip : c181fdb0 fp : c181fdac
    r10: c042eff0 r9 : 00000060 r8 : c044a164
    r7 : c042c0e4 r6 : c042bd60 r5 : 00000000 r4 : c042bd60
    r3 : c084de48 r2 : c181e000 r1 : c042bd60 r0 : 00000000
    Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
    Control: 10c5387d Table: 80004019 DAC: 00000015
    Process swapper (pid: 1, stack limit = 0xc181e2e8)
    Stack: (0xc181fd90 to 0xc1820000)
    fd80: c001754c c042bd60 00000000 c042bd60
    fda0: c181fdcc c181fdb0 c01af994 c01b9a04 c0016104 c042bd60 c042bd60 c044a338
    fdc0: c181fdec c181fdd0 c01b5ed0 c01af94c c042bd60 c042bd60 c1aa8000 c1aa8a0c
    fde0: c181fe04 c181fdf0 c01b5f54 c01b5ea8 c02fc18c c042bd60 c181fe3c c181fe08
    fe00: c01b2a18 c01b5f48 c01aed14 c02fc160 c01df8ec 00000002 c042bd60 00000003
    fe20: c042bd60 c1aa8000 c1aa8a0c c042eff8 c181fe84 c181fe40 c01b3874 c01b29fc
    fe40: c042eff8 00000000 c042f000 c0449db8 c044ed78 00000000 c181fe74 c042eff8
    fe60: c042eff8 c0449db8 c0449db8 c044ed78 00000000 00000000 c181fe94 c181fe88
    fe80: c01e452c c01b35e8 c181feb4 c181fe98 c01e2fdc c01e4518 c042eff8 c0449db8
    fea0: c0449db8 c181fef0 c181fecc c181feb8 c01e3104 c01e2f48 c042eff8 c042f02c
    fec0: c181feec c181fed0 c01e3190 c01e30c0 c01e311c 00000000 c01e311c c0449db8
    fee0: c181ff14 c181fef0 c01e1998 c01e3128 c18330a8 c1892290 c04165e8 c0449db8
    ff00: c0449db8 c1ab60c0 c181ff24 c181ff18 c01e2e28 c01e194c c181ff54 c181ff28
    ff20: c01e2218 c01e2e14 c039afed c181ff38 c04165e8 c041660c c0449db8 00000013
    ff40: 00000000 c03ffdb8 c181ff7c c181ff58 c01e384c c01e217c c181ff7c c04165e8
    ff60: c041660c c003a37c 00000013 00000000 c181ff8c c181ff80 c01e488c c01e3790
    ff80: c181ff9c c181ff90 c03ffdcc c01e484c c181ffdc c181ffa0 c0008798 c03ffdc4
    ffa0: c181ffc4 c181ffb0 c0056440 c0187810 c003a37c c04165e8 c041660c c003a37c
    ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03ea284 c0008708
    ffe0: 00000000 c03ea208 00000000 c181fff8 c003a37c c03ea214 1073cec0 01f7ee08
    Backtrace:
    [] (regulator_enable+0x0/0x70) from [] (omapdss_dpi_display_enable+0x54/0x15c)
    r6:c042bd60 r5:00000000 r4:c042bd60
    [] (omapdss_dpi_display_enable+0x0/0x15c) from [] (generic_dpi_panel_power_on+0x34/0x78)
    r6:c044a338 r5:c042bd60 r4:c042bd60
    [] (generic_dpi_panel_power_on+0x0/0x78) from [] (generic_dpi_panel_enable+0x18/0x28)
    r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:c042bd60
    [] (generic_dpi_panel_enable+0x0/0x28) from [] (omapfb_init_display+0x28/0x150)
    r4:c042bd60
    [] (omapfb_init_display+0x0/0x150) from [] (omapfb_probe+0x298/0x318)
    r8:c042eff8 r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:00000003
    [] (omapfb_probe+0x0/0x318) from [] (platform_drv_probe+0x20/0x24)
    [] (platform_drv_probe+0x0/0x24) from [] (really_probe+0xa0/0x178)
    [] (really_probe+0x0/0x178) from [] (driver_probe_device+0x50/0x68)
    r7:c181fef0 r6:c0449db8 r5:c0449db8 r4:c042eff8
    [] (driver_probe_device+0x0/0x68) from [] (__driver_attach+0x74/0x98)
    r5:c042f02c r4:c042eff8
    [] (__driver_attach+0x0/0x98) from [] (bus_for_each_dev+0x58/0x98)
    r6:c0449db8 r5:c01e311c r4:00000000
    [] (bus_for_each_dev+0x0/0x98) from [] (driver_attach+0x20/0x28)
    r7:c1ab60c0 r6:c0449db8 r5:c0449db8 r4:c04165e8
    [] (driver_attach+0x0/0x28) from [] (bus_add_driver+0xa8/0x22c)
    [] (bus_add_driver+0x0/0x22c) from [] (driver_register+0xc8/0x154)
    [] (driver_register+0x0/0x154) from [] (platform_driver_register+0x4c/0x60)
    r8:00000000 r7:00000013 r6:c003a37c r5:c041660c r4:c04165e8
    [] (platform_driver_register+0x0/0x60) from [] (omapfb_init+0x14/0x34)
    [] (omapfb_init+0x0/0x34) from [] (do_one_initcall+0x9c/0x164)
    [] (do_one_initcall+0x0/0x164) from [] (kernel_init+0x7c/0x120)
    [] (kernel_init+0x0/0x120) from [] (do_exit+0x0/0x2d8)
    r5:c03ea208 r4:00000000
    Code: e1a0c00d e92dd870 e24cb004 e24dd004 (e5906038)
    ---[ end trace 9e2474c2e193b223 ]---

    Acked-by: Tony Lindgren
    Signed-off-by: Russell King
    Cc: Igor Grinberg
    Signed-off-by: Greg Kroah-Hartman

    Russell King
     
  • commit 363434b5dc352464ac7601547891e5fc9105f124 upstream.

    An error while creating sysfs attribute files in the driver's probe function
    results in an error abort, but already created files are not removed. This patch
    fixes the problem.

    Signed-off-by: Guenter Roeck
    Cc: Dirk Eibach
    Acked-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Guenter Roeck
     
  • commit 2f2da1ac0ba5b6cc6e1957c4da5ff20e67d8442b upstream.

    Initialize PPR register for both channels, and set correct PPR register bits.
    Also remove unnecessary variable initializations.

    Signed-off-by: Chris D Schimp
    [guenter.roeck@ericsson.com: Merged two patches into one]
    Signed-off-by: Guenter Roeck
    Acked-by: Roland Stigge
    Signed-off-by: Greg Kroah-Hartman

    Chris D Schimp
     
  • commit b63d97a36edb1aecf8c13e5f5783feff4d64c24b upstream.

    RPM calculation from tachometer value does not depend on PPR.
    Also, do not report negative RPM values.

    Signed-off-by: Chris D Schimp
    [guenter.roeck@ericsson.com: do not report negative RPM values]
    Signed-off-by: Guenter Roeck
    Acked-by: Roland Stigge
    Signed-off-by: Greg Kroah-Hartman

    Chris D Schimp
     
  • commit 918e556ec214ed2f584e4cac56d7b29e4bb6bf27 upstream.

    Lock i_mmap_mutex for access to the VMA prio list to prevent concurrent
    access. Currently, certain parts of the mmap handling are protected by
    the region mutex, but not all.

    Reported-by: Al Viro
    Signed-off-by: David Howells
    Acked-by: Al Viro
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit ef8d60fb79614a86a82720dc2402631dbcafb315 upstream.

    The previous fix for the speaker on Acer Aspire 59135 introduced
    another problem for surround outputs. It changed the connections on
    the line-in/mic pins for limiting the routes, but it left the modified
    connections. Thus wrong connection indices were written when set to
    4ch or 6ch mode.

    This patch fixes it by restoring the right connections just after
    parsing the tree but before the initialization.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42740

    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit c14c95f62ecb8710af14ae0d48e01991b70bb6f4 upstream.

    The bitmap introduced in the commit [527e4d73: ALSA: hda/realtek - Fix
    missing volume controls with ALC260] is too narrow for some codecs,
    which may have more NIDs than 0x20, thus it may overflow the bitmap
    array on them.

    Just double the number to cover all and also add a sanity-check code
    to be safer.

    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 31794bc37bf2db84f085da52b72bfba65739b2d2 upstream.

    The sidetone enumeration texts have left and right swapped.

    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Mark Brown
     
  • commit 4949314c7283ea4f9ade182ca599583b89f7edd6 upstream.

    We need to handle >1 page control cdbs, so extend the code to do a vmap
    if bigger than 1 page. It seems like kmap() is still preferable if just
    a page, fewer TLB shootdowns(?), so keep using that when possible.

    Rename function pair for their new scope.

    Signed-off-by: Andy Grover
    Signed-off-by: Nicholas Bellinger
    Signed-off-by: Greg Kroah-Hartman

    Andy Grover
     
  • commit bb94a406682770a35305daaa241ccdb7cab399de upstream.

    This patch (as1521b) fixes the interaction between usb-storage's
    scanning thread and the freezer. The current implementation has a
    race: If the device is unplugged shortly after being plugged in and
    just as a system sleep begins, the scanning thread may get frozen
    before the khubd task. Khubd won't be able to freeze until the
    disconnect processing is complete, and the disconnect processing can't
    proceed until the scanning thread finishes, so the sleep transition
    will fail.

    The implementation in the 3.2 kernel suffers from an additional
    problem. There the scanning thread calls set_freezable_with_signal(),
    and the signals sent by the freezer will mess up the thread's I/O
    delays, which are all interruptible.

    The solution to both problems is the same: Replace the kernel thread
    used for scanning with a delayed-work routine on the system freezable
    work queue. Freezable work queues have the nice property that you can
    cancel a work item even while the work queue is frozen, and no signals
    are needed.

    The 3.2 version of this patch solves the problem in Bugzilla #42730.

    Signed-off-by: Alan Stern
    Acked-by: Seth Forshee
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     
  • commit a45aa3b30583e7d54e7cf4fbcd0aa699348a6e5c upstream.

    The superspeed device attached to a USB 3.0 hub(such as VIA's)
    doesn't respond the address device command after resume. The
    root cause is the superspeed hub will miss the Hub Depth value
    that is used as an offset into the route string to locate the
    bits it uses to determine the downstream port number after
    reset, and all packets can't be routed to the device attached
    to the superspeed hub.

    Hub driver sends a Set Hub Depth request to the superspeed hub
    except for USB 3.0 root hub when the hub is initialized and
    doesn't send the request again after reset due to the resume
    process. So moving the code that sends the Set Hub Depth request
    to the superspeed hub from hub_configure() to hub_activate()
    is to cover those situations include initialization and reset.

    The patch should be backported to kernels as old as 2.6.39.

    Signed-off-by: Elric Fu
    Signed-off-by: Sarah Sharp
    Acked-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    Elric Fu
     
  • commit 68d07f64b8a11a852d48d1b05b724c3e20c0d94b upstream.

    Intel has a PCI USB xhci host controller on a new platform. It doesn't
    have a line IRQ definition in BIOS. The Linux driver refuses to
    initialize this controller, but Windows works well because it only depends
    on MSI.

    Actually, Linux also can work for MSI. This patch avoids the line IRQ
    checking for USB3 HCDs in usb core PCI probe. It allows the xHCI driver
    to try to enable MSI or MSI-X first. It will fail the probe if MSI
    enabling failed and there's no legacy PCI IRQ.

    This patch should be backported to kernels as old as 2.6.32.

    Signed-off-by: Alex Shi
    Signed-off-by: Sarah Sharp
    Signed-off-by: Greg Kroah-Hartman

    Sarah Sharp
     
  • commit 340a3504fd39dad753ba908fb6f894ee81fc3ae2 upstream.

    The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must
    be encoded as an exponent of two number of microframes. The endpoint
    descriptor has the NAK rate encoded in number of microframes. We were
    just copying the value from the endpoint descriptor into the endpoint
    context interval field, which was not correct. This lead to the VIA
    host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass
    storage device.

    The fix is to use the correct encoding. Refactor the code to convert
    number of frames to an exponential number of microframes, and make sure
    we convert the number of microframes in HS bulk and control endpoints to
    an exponent.

    This should be back ported to kernels as old as 2.6.31, that contain the
    commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math
    in xhci_get_endpoint_interval"

    Signed-off-by: Sarah Sharp
    Tested-by: Felipe Contreras
    Suggested-by: Andiry Xu
    Signed-off-by: Greg Kroah-Hartman

    Sarah Sharp
     
  • commit 3278a55a1aebe2bbd47fbb5196209e5326a88b56 upstream.

    The code to set the device removable bits in the USB 2.0 roothub
    descriptor was accidentally looking at the USB 3.0 port registers
    instead of the USB 2.0 registers. This can cause an oops if there are
    more USB 2.0 registers than USB 3.0 registers.

    This should be backported to kernels as old as 2.6.39, that contain the
    commit 4bbb0ace9a3de8392527e3c87926309d541d3b00 "xhci: Return a USB 3.0
    hub descriptor for USB3 roothub."

    Signed-off-by: Sarah Sharp
    Signed-off-by: Greg Kroah-Hartman

    Sarah Sharp
     
  • commit cab928ee1f221c9cc48d6615070fefe2e444384a upstream.

    On some systems with an Intel Panther Point xHCI host controller, the
    BIOS disables the xHCI PCI device during boot, and switches the xHCI
    ports over to EHCI. This allows the BIOS to access USB devices without
    having xHCI support.

    The downside is that the xHCI BIOS handoff mechanism will fail because
    memory mapped I/O is not enabled for the disabled PCI device.
    Jesse Barnes says this is expected behavior. The PCI core will enable
    BARs before quirks run, but it will leave it in an undefined state, and
    it may not have memory mapped I/O enabled.

    Make the generic USB quirk handler call pci_enable_device() to re-enable
    MMIO, and call pci_disable_device() once the host-specific BIOS handoff
    is finished. This will balance the ref counts in the PCI core. When
    the PCI probe function is called, usb_hcd_pci_probe() will call
    pci_enable_device() again.

    This should be back ported to kernels as old as 2.6.31. That was the
    first kernel with xHCI support, and no one has complained about BIOS
    handoffs failing due to memory mapped I/O being disabled on other hosts
    (EHCI, UHCI, or OHCI).

    Signed-off-by: Sarah Sharp
    Acked-by: Oliver Neukum
    Cc: Jesse Barnes
    Signed-off-by: Greg Kroah-Hartman

    Sarah Sharp
     
  • commit d9f5343e35d9138432657202afa8e3ddb2ade360 upstream.

    Somehow we ended up with duplicate hub feature #defines in ch11.h.
    Tatyana Brokhman first created the USB 3.0 hub feature macros in 2.6.38
    with commit 0eadcc09203349b11ca477ec367079b23d32ab91 "usb: USB3.0 ch11
    definitions". In 2.6.39, I modified a patch from John Youn that added
    similar macros in a different place in the same file, and committed
    dbe79bbe9dcb22cb3651c46f18943477141ca452 "USB 3.0 Hub Changes".

    Some of the #defines used different names for the same values. Others
    used exactly the same names with the same values, like these gems:

    #define USB_PORT_FEAT_BH_PORT_RESET 28
    ...
    #define USB_PORT_FEAT_BH_PORT_RESET 28

    According to my very geeky husband (who looked it up in the C99 spec),
    it is allowed to have object-like macros with duplicate names as long as
    the replacement list is exactly the same. However, he recalled that
    some compilers will give warnings when they find duplicate macros. It's
    probably best to remove the duplicates in the stable tree, so that the
    code compiles for everyone.

    The macros are now fixed to move the feature requests that are specific
    to USB 3.0 hubs into a new section (out of the USB 2.0 hub feature
    section), and use the most common macro name.

    This patch should be backported to 2.6.39.

    Signed-off-by: Sarah Sharp
    Cc: Tatyana Brokhman
    Cc: John Youn
    Cc: Jamey Sharp
    Signed-off-by: Greg Kroah-Hartman

    Sarah Sharp
     
  • commit 7fd25702ba616d9ba56e2a625472f29e5aff25ee upstream.

    This USB-serial cable with mini stereo jack enumerates as:
    Bus 001 Device 004: ID 1a61:3410 Abbott Diabetes Care

    It is a TI3410 inside.

    Signed-off-by: Andrew Lunn
    Signed-off-by: Greg Kroah-Hartman

    Andrew Lunn
     
  • commit b9e44fe5ecda4158c22bc1ea4bffa378a4f83f65 upstream.

    1. Remove all old mass-storage ids's pid:
    0x0026,0x0053,0x0098,0x0099,0x0149,0x0150,0x0160;
    2. As the pid from 0x1401 to 0x1510 which have not surely assigned to
    use for serial-port or mass-storage port,so i think it should be
    removed now, and will re-add after it have assigned in future;
    3. sort the pid to WCDMA and CDMA.

    Signed-off-by: Rui li
    Signed-off-by: Greg Kroah-Hartman

    Rui li
     
  • commit c6c1e4491dc8d1ed2509fa6aacffa7f34614fc38 upstream.

    Signed-off-by: Bruno Thomsen
    Signed-off-by: Greg Kroah-Hartman

    Bruno Thomsen
     
  • [ Upstream commit 0af2a0d0576205dda778d25c6c344fc6508fc81d ]

    This commit ensures that lost_cnt_hint is correctly updated in
    tcp_shifted_skb() for FACK TCP senders. The lost_cnt_hint adjustment
    in tcp_sacktag_one() only applies to non-FACK senders, so FACK senders
    need their own adjustment.

    This applies the spirit of 1e5289e121372a3494402b1b131b41bfe1cf9b7f -
    except now that the sequence range passed into tcp_sacktag_one() is
    correct we need only have a special case adjustment for FACK.

    Signed-off-by: Neal Cardwell
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Neal Cardwell