14 Feb, 2012

28 commits

  • commit 05df1f3c2afaef5672627f2b7095f0d4c4dbc3a0 upstream.

    Error handling in msm_iommu_unmap() is broken. On some error
    conditions retval is set to a non-zero value which causes
    the function to return 'len' at the end. This hides the
    error from the user. Zero should be returned in those error
    cases.

    Cc: David Brown
    Cc: Stepan Moskovchenko
    Signed-off-by: Joerg Roedel
    Acked-by: David Brown
    Signed-off-by: Greg Kroah-Hartman

    Joerg Roedel
     
  • commit af1be04901e27ce669b4ecde1c953d5c939498f5 upstream.

    On some systems the IVRS table does not contain all PCI
    devices present in the system. In case a device not present
    in the IVRS table is translated by the IOMMU no DMA is
    possible from that device by default.
    This patch fixes this by removing the DTE entry for every
    PCI device present in the system and not covered by IVRS.

    Signed-off-by: Joerg Roedel
    Signed-off-by: Greg Kroah-Hartman

    Joerg Roedel
     
  • commit 025e4ab3db07fcbf62c01e4f30d1012234beb980 upstream.

    This fixes a memory-corrupting bug: not only does it cause the warning,
    but as a result of dropping the refcount to zero, it causes the
    pcmcia_socket0 device structure to be freed while it still has
    references, causing slab caches corruption. A fatal oops quickly
    follows this warning - often even just a 'dmesg' following the warning
    causes the kernel to oops.

    While testing suspend/resume on an ARM device with PCMCIA support, and a
    CF card inserted, I found that after five suspend and resumes, the
    kernel would complain, and shortly die after with slab corruption.

    WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50()

    As the message doesn't give a clue about which kobject, and the built-in
    debugging in drivers/base/power/main.c happens too late, this was added
    right before each get_device():

    printk("%s: %p [%s] %u\n", __func__, dev, kobject_name(&dev->kobj), atomic_read(&dev->kobj.kref.refcount));

    and on the 3rd s2ram cycle, the following behaviour observed:

    On the 3rd suspend/resume cycle:

    dpm_prepare: c1a0d998 [pcmcia_socket0] 3
    dpm_suspend: c1a0d998 [pcmcia_socket0] 3
    dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 3
    dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 3
    dpm_resume: c1a0d998 [pcmcia_socket0] 3
    dpm_complete: c1a0d998 [pcmcia_socket0] 2

    4th:

    dpm_prepare: c1a0d998 [pcmcia_socket0] 2
    dpm_suspend: c1a0d998 [pcmcia_socket0] 2
    dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 2
    dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 2
    dpm_resume: c1a0d998 [pcmcia_socket0] 2
    dpm_complete: c1a0d998 [pcmcia_socket0] 1

    5th:

    dpm_prepare: c1a0d998 [pcmcia_socket0] 1
    dpm_suspend: c1a0d998 [pcmcia_socket0] 1
    dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 1
    dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 1
    dpm_resume: c1a0d998 [pcmcia_socket0] 1
    dpm_complete: c1a0d998 [pcmcia_socket0] 0
    ------------[ cut here ]------------
    WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50()
    Modules linked in: ucb1x00_core
    Backtrace:
    [] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c)
    [] (dump_stack+0x0/0x1c) from [] (warn_slowpath_common+0x50/0x68)
    [] (warn_slowpath_common+0x0/0x68) from [] (warn_slowpath_null+0x24/0x28)
    [] (warn_slowpath_null+0x0/0x28) from [] (kobject_get+0x28/0x50)
    [] (kobject_get+0x0/0x50) from [] (get_device+0x1c/0x24)
    [] (dpm_complete+0x0/0x1a0) from [] (dpm_resume_end+0x1c/0x20)
    ...

    Looking at commit 7b24e7988263 ("pcmcia: split up central event handler"),
    the following change was made to cs.c:

    return 0;
    }
    #endif
    -
    - send_event(skt, CS_EVENT_PM_RESUME, CS_EVENT_PRI_LOW);
    + if (!(skt->state & SOCKET_CARDBUS) && (skt->callback))
    + skt->callback->early_resume(skt);
    return 0;
    }

    And the corresponding change in ds.c is from:

    -static int ds_event(struct pcmcia_socket *skt, event_t event, int priority)
    -{
    - struct pcmcia_socket *s = pcmcia_get_socket(skt);
    ...
    - switch (event) {
    ...
    - case CS_EVENT_PM_RESUME:
    - if (verify_cis_cache(skt) != 0) {
    - dev_dbg(&skt->dev, "cis mismatch - different card\n");
    - /* first, remove the card */
    - ds_event(skt, CS_EVENT_CARD_REMOVAL, CS_EVENT_PRI_HIGH);
    - mutex_lock(&s->ops_mutex);
    - destroy_cis_cache(skt);
    - kfree(skt->fake_cis);
    - skt->fake_cis = NULL;
    - s->functions = 0;
    - mutex_unlock(&s->ops_mutex);
    - /* now, add the new card */
    - ds_event(skt, CS_EVENT_CARD_INSERTION,
    - CS_EVENT_PRI_LOW);
    - }
    - break;
    ...
    - }

    - pcmcia_put_socket(s);

    - return 0;
    -} /* ds_event */

    to:

    +static int pcmcia_bus_early_resume(struct pcmcia_socket *skt)
    +{
    + if (!verify_cis_cache(skt)) {
    + pcmcia_put_socket(skt);
    + return 0;
    + }

    + dev_dbg(&skt->dev, "cis mismatch - different card\n");

    + /* first, remove the card */
    + pcmcia_bus_remove(skt);
    + mutex_lock(&skt->ops_mutex);
    + destroy_cis_cache(skt);
    + kfree(skt->fake_cis);
    + skt->fake_cis = NULL;
    + skt->functions = 0;
    + mutex_unlock(&skt->ops_mutex);

    + /* now, add the new card */
    + pcmcia_bus_add(skt);
    + return 0;
    +}

    As can be seen, the original function called pcmcia_get_socket() and
    pcmcia_put_socket() around the guts, whereas the replacement code
    calls pcmcia_put_socket() only in one path. This creates an imbalance
    in the refcounting.

    Testing with pcmcia_put_socket() put removed shows that the bug is gone:

    dpm_suspend: c1a10998 [pcmcia_socket0] 5
    dpm_suspend_noirq: c1a10998 [pcmcia_socket0] 5
    dpm_resume_noirq: c1a10998 [pcmcia_socket0] 5
    dpm_resume: c1a10998 [pcmcia_socket0] 5
    dpm_complete: c1a10998 [pcmcia_socket0] 5

    Tested-by: Russell King
    Signed-off-by: Russell King
    Cc: Dominik Brodowski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Russell King
     
  • commit 2f9bc894c67dbacae5a6a9875818d2a18a918d18 upstream.

    This patch addresses a bug with sendtargets discovery where INADDR_ANY (0.0.0.0)
    + IN6ADDR_ANY_INIT ([0:0:0:0:0:0:0:0]) network portals where incorrectly being
    reported back to initiators instead of the address of the connecting interface.
    To address this, save local socket ->getname() output during iscsi login setup,
    and makes iscsit_build_sendtargets_response() return these TargetAddress keys
    when INADDR_ANY or IN6ADDR_ANY_INIT portals are in use.

    Reported-by: Dax Kelson
    Reported-by: Andy Grover
    Cc: David S. Miller
    Signed-off-by: Nicholas Bellinger
    Signed-off-by: Greg Kroah-Hartman

    Nicholas Bellinger
     
  • commit cd931ee62fd0258fc85c76a7c5499fe85e0f3436 upstream.

    This patch fixes a bug where the iscsit_add_reject_from_cmd() call
    from a failure to iscsit_alloc_buffs() was incorrectly passing
    add_to_conn=1 and causing a double list_add after iscsi_cmd->i_list
    had already been added in iscsit_handle_scsi_cmd().

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

    Nicholas Bellinger
     
  • commit c1ce4bd56f2846de55043374598fd929ad3b711b upstream.

    This patch addresses a bug where iscsit_free_cmd() was incorrectly calling
    iscsit_release_cmd() for ISCSI_OP_REJECT because iscsi_add_reject*() will
    overwrite the original iscsi_cmd->iscsi_opcode assignment. This bug was
    introduced with the following commit:

    commit 0be67f2ed8f577d2c72d917928394c5885fa9134
    Author: Nicholas Bellinger
    Date: Sun Oct 9 01:48:14 2011 -0700

    iscsi-target: Remove SCF_SE_LUN_CMD flag abuses

    and was manifesting itself as list corruption with the following:

    [ 131.191092] ------------[ cut here ]------------
    [ 131.191092] WARNING: at lib/list_debug.c:53 __list_del_entry+0x8d/0x98()
    [ 131.191092] Hardware name: VMware Virtual Platform
    [ 131.191092] list_del corruption. prev->next should be ffff880022d3c100, but was 6b6b6b6b6b6b6b6b
    [ 131.191092] Modules linked in: tcm_vhost ib_srpt ib_cm ib_sa ib_mad ib_core tcm_qla2xxx qla2xxx tcm_loop tcm_fc libfc scsi_transport_fc crc32c iscsi_target_mod target_core_stgt scsi_tgt target_core_pscsi target_core_file target_core_iblock target_core_mod configfs ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi sr_mod cdrom sd_mod e1000 ata_piix libata mptspi mptscsih mptbase [last unloaded: scsi_wait_scan]
    [ 131.191092] Pid: 2250, comm: iscsi_ttx Tainted: G W 3.2.0-rc4+ #42
    [ 131.191092] Call Trace:
    [ 131.191092] [] warn_slowpath_common+0x80/0x98
    [ 131.191092] [] warn_slowpath_fmt+0x41/0x43
    [ 131.191092] [] __list_del_entry+0x8d/0x98
    [ 131.191092] [] transport_lun_remove_cmd+0x9b/0xb7 [target_core_mod]
    [ 131.191092] [] transport_generic_free_cmd+0x5d/0x71 [target_core_mod]
    [ 131.191092] [] iscsit_free_cmd+0x1e/0x27 [iscsi_target_mod]
    [ 131.191092] [] iscsit_close_connection+0x14d/0x5b2 [iscsi_target_mod]
    [ 131.191092] [] iscsit_take_action_for_connection_exit+0xdb/0xe0 [iscsi_target_mod]
    [ 131.191092] [] iscsi_target_tx_thread+0x15cb/0x1608 [iscsi_target_mod]
    [ 131.191092] [] ? check_preempt_wakeup+0x121/0x185
    [ 131.191092] [] ? __dequeue_entity+0x2e/0x33
    [ 131.191092] [] ? iscsit_send_text_rsp+0x25f/0x25f [iscsi_target_mod]
    [ 131.191092] [] ? iscsit_send_text_rsp+0x25f/0x25f [iscsi_target_mod]
    [ 131.191092] [] ? schedule+0x55/0x57
    [ 131.191092] [] kthread+0x7d/0x85
    [ 131.191092] [] kernel_thread_helper+0x4/0x10
    [ 131.191092] [] ? kthread_worker_fn+0x16d/0x16d
    [ 131.191092] [] ? gs_change+0x13/0x13

    Reported-by:
    Signed-off-by: Nicholas Bellinger
    Signed-off-by: Greg Kroah-Hartman

    Nicholas Bellinger
     
  • commit 9f1065032ceb7e86c7c9f16bb86518857e88a172 upstream.

    An error was existing in the saving of CONTRAST_CTR register
    across suspend/resume.

    Signed-off-by: Hubert Feurstein
    Signed-off-by: Nicolas Ferre
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD
    Signed-off-by: Florian Tobias Schandinat
    Signed-off-by: Greg Kroah-Hartman

    Hubert Feurstein
     
  • commit 585c0fd8216e0c9f98e2434092af7ec0f999522d upstream.

    NCT6776F can select fan input pins for fans 3 to 5 with a secondary set of
    chip register bits. Check that second set of bits in addition to the first set
    to detect if fans 3..5 are monitored.

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

    Guenter Roeck
     
  • commit 9f1f46a45a681d357d1ceedecec3671a5ae957f4 upstream.

    The problem this patch solves is that the forcewake accounting
    necessary for register reads is protected by dev->struct_mutex. But the
    hangcheck and error_capture code need to access registers without
    grabbing this mutex because we hold it while waiting for the gpu.
    So a new lock is required. Because currently the error_state capture
    is called from the error irq handler and the hangcheck code runs from
    a timer, it needs to be an irqsafe spinlock (note that the registers
    used by the irq handler (neglecting the error handling part) only uses
    registers that don't need the forcewake dance).

    We could tune this down to a normal spinlock when we rework the
    error_state capture and hangcheck code to run from a workqueue. But
    we don't have any read in a fastpath that needs forcewake, so I've
    decided to not care much about overhead.

    This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my
    snb on recent kernels - something must have slightly changed the
    timings. On previous kernels it only trigger a WARN about the broken
    locking.

    v2: Drop the previous patch for the register writes.

    v3: Improve the commit message per Chris Wilson's suggestions.

    Signed-Off-by: Daniel Vetter
    Reviewed-by: Chris Wilson
    Reviewed-by: Eugeni Dodonov
    Signed-off-by: Keith Packard
    Signed-off-by: Eugeni Dodonov
    Signed-off-by: Greg Kroah-Hartman

    Daniel Vetter
     
  • commit 8109021313c7a3d8947677391ce6ab9cd0bb1d28 upstream.

    This was forgotten in the original multi-threaded forcewake
    conversion:

    commit 8d715f0024f64ad1b1be85d8c081cf577944c847
    Author: Keith Packard
    Date: Fri Nov 18 20:39:01 2011 -0800

    drm/i915: add multi-threaded forcewake support

    Signed-off-by: Daniel Vetter
    Reviewed-by: Eugeni Dodonov
    Signed-off-by: Keith Packard
    Signed-off-by: Eugeni Dodonov
    Signed-off-by: Greg Kroah-Hartman

    Daniel Vetter
     
  • commit 07c1e8c1462fa7324de4c36ae9e55da2abd79cee upstream.

    We don't need to check 3rd pipe specifically, as it shares PLL with some
    other one.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41977
    Signed-off-by: Eugeni Dodonov
    Reviewed-by: Jesse Barnes
    Signed-off-by: Keith Packard
    Signed-off-by: Greg Kroah-Hartman

    Eugeni Dodonov
     
  • commit 23bd15ec662344dc10e9918fdd0dbc58bc71526d upstream.

    TV Out refresh rate was half of the specification for almost all modes.
    Due to this reason pixel clock was so low for some modes causing flickering screen.

    Signed-off-by: Rodrigo Vivi
    Reviewed-by: Jesse Barnes
    Signed-off-by: Keith Packard
    Signed-off-by: Eugeni Dodonov
    Signed-off-by: Greg Kroah-Hartman

    Rodrigo Vivi
     
  • commit 097354eb14fa94d31a09c64d640643f58e4a5a9a upstream.

    Otherwise hangcheck spuriously fires when running blitter/bsd-only
    workloads.

    Contrary to a similar patch by Ben Widawsky this does not check
    INSTDONE of the other rings. Chris Wilson implied that in a failure to
    detect a hang, most likely because INSTDONE was fluctuating. Thus only
    check ACTHD, which as far as I know is rather reliable. Also, blitter
    and bsd rings can't launch complex tasks from a single instruction
    (like 3D_PRIM on the render with complex or even infinite shaders).

    This fixes spurious gpu hang detection when running
    tests/gem_hangcheck_forcewake on snb/ivb.

    Signed-Off-by: Daniel Vetter
    Reviewed-by: Chris Wilson
    Signed-off-by: Keith Packard
    Signed-off-by: Eugeni Dodonov
    Signed-off-by: Greg Kroah-Hartman

    Daniel Vetter
     
  • commit 832afda6a7d7235ef0e09f4ec46736861540da6d upstream.

    On DP monitor hot remove, clear DP_AUDIO_OUTPUT_ENABLE accordingly,
    so that the audio driver will receive hot plug events and take action
    to refresh its device state and ELD contents.

    Note that the DP_AUDIO_OUTPUT_ENABLE bit may be enabled or disabled
    only when the link training is complete and set to "Normal".

    Tested OK for both hot plug/remove and DPMS on/off.

    Signed-off-by: Wu Fengguang
    Signed-off-by: Keith Packard
    Signed-off-by: Eugeni Dodonov
    Signed-off-by: Greg Kroah-Hartman

    Wu Fengguang
     
  • commit 2deed761188d7480eb5f7efbfe7aa77f09322ed8 upstream.

    On HDMI monitor hot remove, clear SDVO_AUDIO_ENABLE accordingly, so that
    the audio driver will receive hot plug events and take action to refresh
    its device state and ELD contents.

    The cleared SDVO_AUDIO_ENABLE bit needs to be restored to prevent losing
    HDMI audio after DPMS on.

    CC: Wang Zhenyu
    Signed-off-by: Wu Fengguang
    Signed-off-by: Keith Packard
    Signed-off-by: Eugeni Dodonov
    Signed-off-by: Greg Kroah-Hartman

    Wu Fengguang
     
  • commit b189e810619a676e6b931a942a3e8387f3d39c21 upstream.

    The driver uses __napi_complete and napi_gro_receive. Without it, the
    driver hits the BUG_ON(n->gro_list) assertion hard in __napi_complete.

    Signed-off-by: Francois Romieu
    Tested-by: Marin Glibic
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Francois Romieu
     
  • commit 304a48400d9718f74ec35ae46f30868a5f4c4516 upstream.

    Different versions of the DP to LVDS bridge chip
    need different panel mode settings depending on
    the chip version used.

    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=41569

    Signed-off-by: Alex Deucher
    Signed-off-by: Dave Airlie
    Signed-off-by: Greg Kroah-Hartman

    Alex Deucher
     
  • commit 86698c20f71d488b32c49ed4687fb3cf8a88a5ca upstream.

    Polling the outputs when the device is suspended can result in erroneous
    status updates. Disable output polling during suspend to prevent this
    from happening.

    Signed-off-by: Seth Forshee
    Reviewed-by: Alex Deucher
    Signed-off-by: Dave Airlie
    Signed-off-by: Greg Kroah-Hartman

    Seth Forshee
     
  • commit 525895ba388c949aa906f26e3ec5cb1ab041f56b upstream.

    Due to a race it was possible for a fence to be destroyed while another
    thread was trying to synchronise with it. If this happened in the fallback
    non-semaphore path, it lead to the following oops due to fence->channel
    being NULL.

    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [] nouveau_fence_update+0xe/0xe0 [nouveau]
    *pde = a649c067
    SMP
    Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi]

    Pid: 2255, comm: gnome-shell Tainted: G O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM
    EIP: 0060:[] EFLAGS: 00010296 CPU: 1
    EIP is at nouveau_fence_update+0xe/0xe0 [nouveau]
    EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000
    ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8
    DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000)
    Stack:
    7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f
    00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0
    00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000
    Call Trace:
    [] __nouveau_fence_signalled+0x1f/0x30 [nouveau]
    [] __nouveau_fence_wait+0x43/0xd0 [nouveau]
    [] nouveau_fence_sync+0x1a0/0x1c0 [nouveau]
    [] validate_list+0x176/0x300 [nouveau]
    [] ? ttm_bo_mem_put+0x30/0x30 [ttm]
    [] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau]
    [] ? die+0x31/0x80
    [] drm_ioctl+0x388/0x490 [drm]
    [] ? die+0x31/0x80
    [] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau]
    [] ? file_has_perm+0xcb/0xe0
    [] ? drm_copy_field+0x80/0x80 [drm]
    [] do_vfs_ioctl+0x86/0x5b0
    [] ? die+0x31/0x80
    [] ? selinux_file_ioctl+0x62/0x130
    [] ? fget_light+0x30/0x340
    [] sys_ioctl+0x6f/0x80
    [] syscall_call+0x7/0xb
    [] ? die+0x31/0x80
    [] ? die+0x31/0x80

    Signed-off-by: Ben Skeggs
    Signed-off-by: Greg Kroah-Hartman

    Ben Skeggs
     
  • commit 1b61925061660009f5b8047f93c5297e04541273 upstream.

    The value of this register is transferred to the V_COUNTER register at the
    beginning of vertical blank. V_COUNTER is the reference for VLINE waits and
    goes from VIEWPORT_Y_START to VIEWPORT_Y_START+VIEWPORT_HEIGHT during scanout,
    so if VIEWPORT_Y_START is not 0, V_COUNTER actually went backwards at the
    beginning of vertical blank, and VLINE waits excluding the whole scanout area
    could never finish (possibly only if VIEWPORT_Y_START is larger than the length
    of vertical blank in scanlines). Setting DESKTOP_HEIGHT to the framebuffer
    height should prevent this for any kind of VLINE wait.

    Fixes https://bugs.freedesktop.org/show_bug.cgi?id=45329 .

    Signed-off-by: Michel Dänzer
    Reviewed-by: Alex Deucher
    Signed-off-by: Dave Airlie
    Signed-off-by: Greg Kroah-Hartman

    Michel Dänzer
     
  • commit bda3a47c886664e86ee14eb79e9072b9e341f575 upstream.

    commit 463894705e4089d0ff69e7d877312d496ac70e5b deleted redundant
    chan_id and chancnt initialization in dma drivers as this is done
    in dma_async_device_register().

    However, atc_enable_irq() relied on chan_id set before registering
    the device, what left only channel 0 functional for this driver.

    This patch introduces atc_enable/disable_chan_irq() as a variant
    of atc_enable/disable_irq() with the channel as explicit argument.

    Signed-off-by: Nikolaus Voss
    Signed-off-by: Nicolas Ferre
    Signed-off-by: Vinod Koul
    Signed-off-by: Greg Kroah-Hartman

    Nikolaus Voss
     
  • commit 500823195d0c9eec2a4637484f30cc93ec633d4a upstream.

    This reverts commit fb5427508abbd635e877fabdf55795488119c2d6.

    The reason is that it breaks 16 bits NAND flash as it was reported by
    Nikolaus Voss and confirmed by Eric Bénard.

    Nicolas Ferre alco confirmed:
    "After double checking with designers, I must admit that I misunderstood
    the way of optimizing accesses to SMC. 16 bit nand is not so common
    those days..."

    Reported-by: Nikolaus Voss
    Acked-by: Nicolas Ferre
    Signed-off-by: Artem Bityutskiy
    Signed-off-by: David Woodhouse
    Signed-off-by: Greg Kroah-Hartman

    Artem Bityutskiy
     
  • commit 9398d1ce09b9009996f7d2468e1d3c785fa6feda upstream.

    In MX28, if we do not reset the BCH module. The BCH module may
    becomes unstable when the board reboots for several thousands times.
    This bug has been catched in customer's production.

    The patch adds some comments (some from Wolfram Sang), and fixes it now.

    Also change gpmi_reset_block() to static.

    Signed-off-by: Huang Shijie
    Acked-by: Marek Vasut
    Signed-off-by: Artem Bityutskiy
    Signed-off-by: David Woodhouse
    Signed-off-by: Greg Kroah-Hartman

    Huang Shijie
     
  • commit e47e321a35c741ee41b67976f8c6a3a7a42bc5c0 upstream.

    We have just been investigating kernel panics related to
    cq->ibcq.event_handler() completion calls. The problem is that
    ib_destroy_qp() fails with -EBUSY.

    Further investigation revealed qp->usecnt is not initialized. This
    counter was introduced in linux-3.2 by commit 0e0ec7e0638e
    ("RDMA/core: Export ib_open_qp() to share XRC TGT QPs") but it only
    gets initialized for IB_QPT_XRC_TGT, but it is checked in
    ib_destroy_qp() for any QP type.

    Fix this by initializing qp->usecnt for every QP we create.

    Signed-off-by: Bernd Schubert
    Signed-off-by: Sven Breuner

    [ Initialize qp->usecnt in uverbs too. - Sean ]

    Signed-off-by: Sean Hefty
    Signed-off-by: Roland Dreier
    Signed-off-by: Greg Kroah-Hartman

    Bernd Schubert
     
  • commit a6f7feae6d19e84253918d88b04153af09d3a243 upstream.

    In the current code, vendor-specific MADs (e.g with the FDR-10
    attribute) are silently dropped by the driver, resulting in timeouts
    at the sending side and inability to query/configure the relevant
    feature. However, the ConnectX firmware is able to handle such MADs.
    For unsupported attributes, the firmware returns a GET_RESPONSE MAD
    containing an error status.

    For example, for a FDR-10 node with LID 11:

    # ibstat mlx4_0 1

    CA: 'mlx4_0'
    Port 1:
    State: Active
    Physical state: LinkUp
    Rate: 40 (FDR10)
    Base lid: 11
    LMC: 0
    SM lid: 24
    Capability mask: 0x02514868
    Port GUID: 0x0002c903002e65d1
    Link layer: InfiniBand

    Extended Port Query (EPI) vendor mad timeouts before the patch:

    # smpquery MEPI 11 -d

    ibwarn: [4196] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
    ibwarn: [4196] _do_madrpc: retry 1 (timeout 1000 ms)
    ibwarn: [4196] _do_madrpc: retry 2 (timeout 1000 ms)
    ibwarn: [4196] _do_madrpc: timeout after 3 retries, 3000 ms
    ibwarn: [4196] mad_rpc: _do_madrpc failed; dport (Lid 11)
    smpquery: iberror: [pid 4196] main: failed: operation EPI: ext port info query failed

    EPI query works OK with the patch:

    # smpquery MEPI 11 -d

    ibwarn: [6548] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
    ibwarn: [6548] mad_rpc: data offs 64 sz 64
    mad data
    0000 0000 0000 0001 0000 0001 0000 0001
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    # Ext Port info: Lid 11 port 0
    StateChangeEnable:...............0x00
    LinkSpeedSupported:..............0x01
    LinkSpeedEnabled:................0x01
    LinkSpeedActive:.................0x01

    Signed-off-by: Jack Morgenstein
    Signed-off-by: Or Gerlitz
    Acked-by: Ira Weiny
    Signed-off-by: Roland Dreier
    Signed-off-by: Greg Kroah-Hartman

    Jack Morgenstein
     
  • commit 320cfa6ce0b3dc794fedfa4bae54c0f65077234d upstream.

    The PCIe device

    FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd FireWire Host Controller
    [1180:e832] (prog-if 10 [OHCI])

    is unable to access attached FireWire devices when MSI is enabled but
    works if MSI is disabled.
    http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28251.html

    Hence add the "disable MSI" quirks flag for this device, or in fact for
    safety and simplicity for all current (R5U230, R5U231, R5U240) and
    future Ricoh PCIe 1394 controllers.

    Reported-by: Stefan Thomas
    Signed-off-by: Stefan Richter
    Signed-off-by: Greg Kroah-Hartman

    Stefan Richter
     
  • commit d1bb399ad03c11e792f6dea198d3b1e23061f094 upstream.

    The Audigy's SB1394 controller is actually from Texas Instruments
    and has the same bus reset packet generation bug, so it needs the
    same quirk entry.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Stefan Richter
    Signed-off-by: Greg Kroah-Hartman

    Clemens Ladisch
     
  • commit cbcb8346054073d000ecac324763372d6abd44ac upstream.

    KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland
    with a 64bit kernel if the font width is not 8.

    This is because of the setting of the KD_FONT_FLAG_OLD flag, which makes
    con_font_get return EIO in such case.

    This flag should *not* be set for KDFONTOP, since it's actually the whole
    point of this flag (see comment in con_font_set for instance).

    Signed-off-by: Samuel Thibault
    Reviewed-by: Arnd Bergmann
    Cc: Arthur Taylor
    Cc: Jiri Slaby
    Cc: Jiri Olsa
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Samuel Thibault
     

07 Feb, 2012

1 commit

  • commit 3c076351c4027a56d5005a39a0b518a4ba393ce2 upstream.

    Right now we forcibly clear ASPM state on all devices if the BIOS indicates
    that the feature isn't supported. Based on the Microsoft presentation
    "PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
    that this may be an error. The implication is that unless the platform
    grants full control via _OSC, Windows will not touch any PCIe features -
    including ASPM. In that case clearing ASPM state would be an error unless
    the platform has granted us that control.

    This patch reworks the ASPM disabling code such that the actual clearing
    of state is triggered by a successful handoff of PCIe control to the OS.
    The general ASPM code undergoes some changes in order to ensure that the
    ability to clear the bits isn't overridden by ASPM having already been
    disabled. Further, this theoretically now allows for situations where
    only a subset of PCIe roots hand over control, leaving the others in the
    BIOS state.

    It's difficult to know for sure that this is the right thing to do -
    there's zero public documentation on the interaction between all of these
    components. But enough vendors enable ASPM on platforms and then set this
    bit that it seems likely that they're expecting the OS to leave them alone.

    Measured to save around 5W on an idle Thinkpad X220.

    Signed-off-by: Matthew Garrett
    Signed-off-by: Jesse Barnes
    Signed-off-by: Greg Kroah-Hartman

    Matthew Garrett
     

04 Feb, 2012

11 commits

  • commit d1620ca9e7bb0030068c3b45b653defde8839dac upstream.

    Allow more baud rates to be set in [1M,2M] baud.

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

    Johan Hovold
     
  • commit cdc32fd6f7b2b2580d7f1b74563f888e4dd9eb8a upstream.

    The newer cp2104 devices require the baud rate to be initialised after
    power on. Make sure it is set when port is opened.

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

    Johan Hovold
     
  • commit e5990874e511d5bbca23b3396419480cb2ca0ee7 upstream.

    Clean up and refactor speed handling.
    Document baud rate handling for CP210{1,2,4,5,10}.

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

    Johan Hovold
     
  • commit 34b76fcaee574017862ea3fa0efdcd77a9d0e57d upstream.

    [Based on a patch from Johan, mangled by gregkh to keep things in line]

    Fix up the variable usage in the set_termios call.

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

    Johan Hovold
     
  • commit be125d9c8d59560e7cc2d6e2b65c8fd233498ab7 upstream.

    We do not implement B0 hangup yet so map low baudrates to 300bps.

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

    Johan Hovold
     
  • commit 7f482fc88ac47662228d6b1f05759797c8936a30 upstream.

    This fix changes the way baudrates are set on the CP210x devices from
    Silicon Labs. The CP2101/2/3 will respond to both a GET/SET_BAUDDIV
    command, and GET/SET_BAUDRATE command, while CP2104 and higher devices
    only respond to GET/SET_BAUDRATE. The current cp210x.ko driver in
    kernel version 3.2.0 only implements the GET/SET_BAUDDIV command.

    This patch implements the two new codes for the GET/SET_BAUDRATE
    commands. Then there is a change in the way that the baudrate is
    assigned or retrieved. This is done according to the CP210x USB
    specification in AN571. This document can be found here:
    http://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/AN571.pdf&src=DocumentationWebPart

    Sections 5.3/5.4 describe the USB packets for the old baudrate method.
    Sections 5.5/5.6 describe the USB packets for the new method. This
    patch also implements the new request scheme, and eliminates the
    unnecessary baudrate calculations since it uses the "actual baudrate"
    method.

    This patch solves the problem reported for the CP2104 in bug 42586,
    and also keeps support for all other devices (CP2101/2/3).

    This patchfile is also attached to the bug report on
    bugzilla.kernel.org. This patch has been developed and test on the
    3.2.0 mainline kernel version under Ubuntu 10.11.

    Signed-off-by: Preston Fick
    [duplicate patch also sent by Johan - gregkh]
    Signed-off-by: Johan Hovold
    Signed-off-by: Greg Kroah-Hartman

    Preston Fick
     
  • commit 55b2afbb92ad92e9f6b0aa4354eb1c94589280c3 upstream.

    Make sure port is fully initialised before calling generic open.

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

    Johan Hovold
     
  • commit 791b7d7cf69de11275e4dccec2f538eec02cbff6 upstream.

    This device is a Oscilloscope/Logic Analizer/Pattern Generator/TDR,
    using a Silabs CP2103 USB to UART Bridge.

    Signed-off-by: Renato Caldas
    Signed-off-by: Greg Kroah-Hartman

    Renato Caldas
     
  • [ Upstream commit 4ec7ac1203bcf21f5e3d977c9818b1a56c9ef40d ]

    Commit bc416d9768 (macvlan: handle fragmented multicast frames) added a
    possible use after free in macvlan_handle_frame(), since
    ip_check_defrag() uses pskb_may_pull() : skb header can be reallocated.

    Signed-off-by: Eric Dumazet
    Cc: Ben Greear
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Eric Dumazet
     
  • [ Upstream commit b924551bed09f61b64f21bffe241afc5526b091a ]

    bond_alb_init_slave() is called from bond_enslave() and sets the slave's MAC
    address. This is done differently for TLB and ALB modes.
    bond->alb_info.rlb_enabled is used to discriminate between the two modes but
    this flag may be uninitialized if the slave is being enslaved prior to calling
    bond_open() -> bond_alb_initialize() on the master.

    It turns out all the callers of alb_set_slave_mac_addr() pass
    bond->alb_info.rlb_enabled as the hw parameter.

    This patch cleans up the unnecessary parameter of alb_set_slave_mac_addr() and
    makes the function decide based on the bonding mode instead, which fixes the
    above problem.

    Reported-by: Narendra K
    Signed-off-by: Jiri Bohac
    Signed-off-by: Jay Vosburgh
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Jiri Bohac
     
  • commit 15699e6fafc3a90e5fdc2ef30555a04dee62286f upstream.

    The probe does not strictly require the USB_CDC_DMM_TYPE
    descriptor, which is a good thing as it makes the driver
    usable on non-conforming interfaces. A user could e.g.
    bind to it to a CDC ECM interface by using the new_id and
    bind sysfs files. But this would fail with a 0 buffer length
    due to the missing descriptor.

    Fix by defining a reasonable fallback size: The minimum
    device receive buffer size required by the CDC WMC standard,
    revision 1.1

    Signed-off-by: Bjørn Mork
    Signed-off-by: Greg Kroah-Hartman

    Bjørn Mork