Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Oct 21, 2012
  1. @gregkh

    Linux 3.6.3

    gregkh authored
  2. @mcdebugger @gregkh

    ALSA: emu10k1: add chip details for E-mu 1010 PCIe card

    mcdebugger authored gregkh committed
    commit 10f571d upstream.
    Add chip details for E-mu 1010 PCIe card. It has the same
    chip as found in E-mu 1010b but it uses different PCI id.
    Signed-off-by: Maxim Kachur <>
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
  3. @tiwai @gregkh

    ALSA: ac97 - Fix missing NULL check in snd_ac97_cvol_new()

    tiwai authored gregkh committed
    commit 733a48e upstream.
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
  4. @gregkh

    ASoC: omap-abe-twl6040: Fix typo of Vibrator

    Peter Ujfalusi authored gregkh committed
    commit 034940a upstream.
    It is not Vinrator but Vibrator.
    Signed-off-by: Peter Ujfalusi <>
    Signed-off-by: Mark Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
  5. @broonie @gregkh

    ASoC: wm2200: Fix non-inverted OUT2 mute control

    broonie authored gregkh committed
    commit a1b98e1 upstream.
    Signed-off-by: Mark Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
  6. @broonie @gregkh

    ASoC: wm2200: Use rev A register patches on rev B

    broonie authored gregkh committed
    commit 5ae9eb4 upstream.
    Signed-off-by: Mark Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
  7. @lyakh @gregkh

    ASoC: fsi: don't reschedule DMA from an atomic context

    lyakh authored gregkh committed
    commit 57451e4 upstream.
    shdma doesn't support transfer re-scheduling or triggering from callbacks
    or from atomic context. The fsi driver issues DMA transfers from a tasklet
    context, which is a bug. To fix it convert tasklet to a work.
    Reported-by: Do Q.Thang <>
    Tested-by: Do Q.Thang <>
    Signed-off-by: Guennadi Liakhovetski <>
    Signed-off-by: Mark Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
  8. @diwic @gregkh

    ALSA: hda - Always check array bounds in alc_get_line_out_pfx

    diwic authored gregkh committed
    commit 71aa5eb upstream.
    Even when CONFIG_SND_DEBUG is not enabled, we don't want to
    return an arbitrary memory location when the channel count is
    larger than we expected.
    Signed-off-by: David Henningsson <>
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
  9. @tiwai @gregkh

    ALSA: hda - Stop LPIB delay counting on broken hardware

    tiwai authored gregkh committed
    commit 1f04661 upstream.
    If LPIB reports a pretty bad value, we can't trust such hardware for
    calculating the PCM delay.  Automatically turn off the delay counting
    when such a problem is encountered.
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
  10. @tiwai @gregkh

    ALSA: hda - Fix registration race of VGA switcheroo

    tiwai authored gregkh committed
    commit 128960a upstream.
    Delay the registration of VGA switcheroo client to the end of the
    probing.  Otherwise a too quick switching may result in Oops during
    Also add the check of the return value from snd_hda_lock_devices().
    Reported-and-tested-by: Daniel J Blueman <>
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
  11. @fabio-porcedda @gregkh

    usb: gadget: at91_udc: fix dt support

    fabio-porcedda authored gregkh committed
    commit 9c6d196 upstream.
    Don't fail the initialization check for the platform_data
    if there is avaiable an associated device tree node.
    Signed-off-by: Fabio Porcedda <>
    Signed-off-by: Felipe Balbi <>
    Signed-off-by: Greg Kroah-Hartman <>
  12. @PeterHueweIFX @gregkh

    tpm: Propagate error from tpm_transmit to fix a timeout hang

    PeterHueweIFX authored gregkh committed
    commit abce9ac upstream.
    tpm_write calls tpm_transmit without checking the return value and
    assigns the return value unconditionally to chip->pending_data, even if
    it's an error value.
    This causes three bugs.
    So if we write to /dev/tpm0 with a tpm_param_size bigger than
    TPM_BUFSIZE=0x1000 (e.g. 0x100a)
    and a bufsize also bigger than TPM_BUFSIZE (e.g. 0x100a)
    tpm_transmit returns -E2BIG which is assigned to chip->pending_data as
    -7, but tpm_write returns that TPM_BUFSIZE bytes have been successfully
    been written to the TPM, altough this is not true (bug #1).
    As we did write more than than TPM_BUFSIZE bytes but tpm_write reports
    that only TPM_BUFSIZE bytes have been written the vfs tries to write
    the remaining bytes (in this case 10 bytes) to the tpm device driver via
    tpm_write which then blocks at
     /* cannot perform a write until the read has cleared
     either via tpm_read or a user_read_timer timeout */
     while (atomic_read(&chip->data_pending) != 0)
    for 60 seconds, since data_pending is -7 and nobody is able to
    read it (since tpm_read luckily checks if data_pending is greater than
    0) (#bug 2).
    After that the remaining bytes are written to the TPM which are
    interpreted by the tpm as a normal command. (bug #3)
    So if the last bytes of the command stream happen to be a e.g.
    tpm_force_clear this gets accidentally sent to the TPM.
    This patch fixes all three bugs, by propagating the error code of
    tpm_write and returning -E2BIG if the input buffer is too big,
    since the response from the tpm for a truncated value is bogus anyway.
    Moreover it returns -EBUSY to userspace if there is a response ready to be
    Signed-off-by: Peter Huewe <>
    Signed-off-by: Kent Yoder <>
    Signed-off-by: Greg Kroah-Hartman <>
  13. @gregkh

    e1000e: Change wthresh to 1 to avoid possible Tx stalls

    Hiroaki SHIMODA authored gregkh committed
    commit 8edc0e6 upstream.
    This patch originated from Hiroaki SHIMODA but has been modified
    by Intel with some minor cleanups and additional commit log text.
    Denys Fedoryshchenko and others reported Tx stalls on e1000e with
    BQL enabled.  Issue was root caused to hardware delays. They were
    introduced because some of the e1000e hardware with transmit
    writeback bursting enabled, waits until the driver does an
    explict flush OR there are WTHRESH descriptors to write back.
    Sometimes the delays in question were on the order of seconds,
    causing visible lag for ssh sessions and unacceptable tx
    completion latency, especially for BQL enabled kernels.
    To avoid possible Tx stalls, change WTHRESH back to 1.
    The current plan is to investigate a method for re-enabling
    WTHRESH while not harming BQL, but those patches will be later
    for net-next if they work.
    please enqueue for stable since v3.3 as this bug was introduced in
    commit 3f0cfa3
    Author: Tom Herbert <>
    Date:   Mon Nov 28 16:33:16 2011 +0000
        e1000e: Support for byte queue limits
        Changes to e1000e to use byte queue limits.
    Reported-by: Denys Fedoryshchenko <>
    Tested-by: Denys Fedoryshchenko <>
    Signed-off-by: Hiroaki SHIMODA <>
    Signed-off-by: Jesse Brandeburg <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
  14. @computersforpeace @gregkh

    mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

    computersforpeace authored gregkh committed
    commit bf7a01b upstream.
    The NAND_CHIPOPTIONS_MSK has limited utility and is causing real bugs. It
    silently masks off at least one flag that might be set by the driver
    (NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver and possibly
    Really, as long as driver writers exercise a small amount of care with
    NAND_* options, this mask is not necessary at all; it was only here to
    prevent certain options from accidentally being set by the driver. But the
    original thought turns out to be a bad idea occasionally. Thus, kill it.
    Note, this patch fixes some major gpmi-nand breakage.
    Signed-off-by: Brian Norris <>
    Tested-by: Huang Shijie <>
    Signed-off-by: Artem Bityutskiy <>
    Signed-off-by: David Woodhouse <>
    Signed-off-by: Greg Kroah-Hartman <>
    index a11253a..c429abd 100644
  15. @jankara @gregkh

    jbd: Fix assertion failure in commit code due to lacking transaction …

    jankara authored gregkh committed
    commit 09e05d4 upstream.
    ext3 users of data=journal mode with blocksize < pagesize were occasionally
    hitting assertion failure in journal_commit_transaction() checking whether the
    transaction has at least as many credits reserved as buffers attached.  The
    core of the problem is that when a file gets truncated, buffers that still need
    checkpointing or that are attached to the committing transaction are left with
    buffer_mapped set. When this happens to buffers beyond i_size attached to a
    page stradding i_size, subsequent write extending the file will see these
    buffers and as they are mapped (but underlying blocks were freed) things go
    awry from here.
    The assertion failure just coincidentally (and in this case luckily as we would
    start corrupting filesystem) triggers due to journal_head not being properly
    cleaned up as well.
    Under some rare circumstances this bug could even hit data=ordered mode users.
    There the assertion won't trigger and we would end up corrupting the
    We fix the problem by unmapping buffers if possible (in lots of cases we just
    need a buffer attached to a transaction as a place holder but it must not be
    written out anyway). And in one case, we just have to bite the bullet and wait
    for transaction commit to finish.
    Reviewed-by: Josef Bacik <>
    Signed-off-by: Jan Kara <>
    Signed-off-by: Greg Kroah-Hartman <>
  16. @gregkh

    mcs7830: Fix link state detection

    Ondrej Zary authored gregkh committed
    commit dabdaf0 upstream.
    The device had an undocumented "feature": it can provide a sequence of
    spurious link-down status data even if the link is up all the time.
    A sequence of 10 was seen so update the link state only after the device
    reports the same link state 20 times.
    Signed-off-by: Ondrej Zary <>
    Reported-by: Michael Leun <>
    Tested-by: Michael Leun <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
  17. @jnikula @gregkh

    drm/i915: use adjusted_mode instead of mode for checking the 6bpc for…

    jnikula authored gregkh committed
    …ce flag
    commit 0c96c65 upstream.
    The dithering introduced in
    commit 3b5c78a
    Author: Adam Jackson <>
    Date:   Tue Dec 13 15:41:00 2011 -0800
        drm/i915/dp: Dither down to 6bpc if it makes the mode fit
    stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
    adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use
    the original mode, without the flag, so it would never have any
    effect. However, the BPC was clamped by VBT settings, making things work by
    coincidence, until that part was removed in
    commit 4344b81
    Author: Daniel Vetter <>
    Date:   Fri Aug 10 11:10:20 2012 +0200
    Use adjusted_mode instead of mode when checking for
    INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.
    v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by
    Daniel both before and after sending the first patch.
    CC: Adam Jackson <>
    Signed-off-by: Jani Nikula <>
    Reviewed-by: Adam Jackson <>
    Signed-off-by: Daniel Vetter <>
    Signed-off-by: Greg Kroah-Hartman <>
  18. @kaydenl @gregkh

    drm/i915: Set guardband clipping workaround bit in the right register.

    kaydenl authored gregkh committed
    commit 26b6e44 upstream.
    A previous patch, namely:
    commit bf97b27
    Author: Daniel Vetter <>
    Date:   Wed Apr 11 20:42:41 2012 +0200
        drm/i915: implement w/a for incorrect guarband clipping
    accidentally set bit 5 in 3D_CHICKEN, which has nothing to do with
    clipping.  This patch changes it to be set in 3D_CHICKEN3, where it
    The game "Dante" demonstrates random clipping issues when guardband
    clipping is enabled and bit 5 of 3D_CHICKEN3 isn't set.  So the
    workaround is actually necessary.
    Acked-by: Paul Menzel <>
    Cc: Daniel Vetter <>
    Cc: Oliver McFadden <>
    Signed-off-by: Kenneth Graunke <>
    Reviewed-by: Mika Kuoppala <>
    Signed-off-by: Daniel Vetter <>
    Signed-off-by: Greg Kroah-Hartman <>
  19. @gregkh

    drm/i915: remove useless BUG_ON which caused a regression in 3.5.

    Willy Tarreau authored gregkh committed
    commit c77d716 upstream.
    starting an old X server causes a kernel BUG since commit 1b50247:
    ------------[ cut here ]------------
    kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3661!
    invalid opcode: 0000 [#1] SMP
    Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss uvcvideo
    +videobuf2_core videodev videobuf2_vmalloc videobuf2_memops uhci_hcd ath9k mac80211 snd_hda_codec_realtek ath9k_common microcode
    +ath9k_hw psmouse serio_raw sg ath cfg80211 atl1c lpc_ich mfd_core ehci_hcd snd_hda_intel snd_hda_codec snd_hwdep snd_pcm rtc_cmos
    +snd_timer snd evdev eeepc_laptop snd_page_alloc sparse_keymap
    Pid: 2866, comm: X Not tainted 3.5.6-rc1-eeepc #1 ASUSTeK Computer INC. 1005HA/1005HA
    EIP: 0060:[<c12dc291>] EFLAGS: 00013297 CPU: 0
    EIP is at i915_gem_entervt_ioctl+0xf1/0x110
    EAX: f5941df4 EBX: f5940000 ECX: 00000000 EDX: 00020000
    ESI: f5835400 EDI: 00000000 EBP: f51d7e38 ESP: f51d7e20
     DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
    CR0: 8005003b CR2: b760e0a0 CR3: 351b6000 CR4: 000007d0
    DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
    DR6: ffff0ff0 DR7: 00000400
    Process X (pid: 2866, ti=f51d6000 task=f61af8d0 task.ti=f51d6000)
     00000001 00000000 f5835414 f51d7e84 f5835400 f54f85c0 f51d7f10 c12b530b
     00000001 c151b139 c14751b6 c152e030 00000b32 00006459 00000059 0000e200
     00000001 00000000 00006459 c159ddd0 c12dc1a0 ffffffea 00000000 00000000
    Call Trace:
     [<c12b530b>] drm_ioctl+0x2eb/0x440
     [<c12dc1a0>] ? i915_gem_init+0xe0/0xe0
     [<c1052b2b>] ? enqueue_hrtimer+0x1b/0x50
     [<c1053321>] ? __hrtimer_start_range_ns+0x161/0x330
     [<c10530b3>] ? lock_hrtimer_base+0x23/0x50
     [<c1053163>] ? hrtimer_try_to_cancel+0x33/0x70
     [<c12b5020>] ? drm_version+0x90/0x90
     [<c10ca171>] vfs_ioctl+0x31/0x50
     [<c10ca2e4>] do_vfs_ioctl+0x64/0x510
     [<c10535de>] ? hrtimer_nanosleep+0x8e/0x100
     [<c1052c20>] ? update_rmtp+0x80/0x80
     [<c10ca7c9>] sys_ioctl+0x39/0x60
     [<c1433949>] syscall_call+0x7/0xb
    Code: 83 c4 0c 5b 5e 5f 5d c3 c7 44 24 04 2c 05 53 c1 c7 04 24 6f ef 47 c1 e8 6e e0 fd ff c7 83 38 1e 00 00 00 00 00 00 e9 3f ff ff
    +ff <0f> 0b eb fe 0f 0b eb fe 8d b4 26 00 00 00 00 0f 0b eb fe 8d b6
    EIP: [<c12dc291>] i915_gem_entervt_ioctl+0xf1/0x110 SS:ESP 0068:f51d7e20
    ---[ end trace dd332ec083cbd513 ]---
    The crash happens here in i915_gem_entervt_ioctl() :
        3659          BUG_ON(!list_empty(&dev_priv->mm.active_list));
        3660          BUG_ON(!list_empty(&dev_priv->mm.flushing_list));
     -> 3661          BUG_ON(!list_empty(&dev_priv->mm.inactive_list));
        3662          mutex_unlock(&dev->struct_mutex);
    Quoting Chris :
      "That BUG_ON there is silly and can simply be removed. The check is to
       verify that no batches were submitted to the kernel whilst the UMS/GEM
       client was suspended - to which the BUG_ONs are a crude approximation.
       Furthermore, the checks are too late, since it means we attempted to
       program the hardware whilst it was in an invalid state, the BUG_ONs are
       the least of your concerns at that point."
    Note that this regression has been introduced in
    commit 1b50247
    Author: Chris Wilson <>
    Date:   Tue Apr 24 15:47:30 2012 +0100
        drm/i915: Remove the list of pinned inactive objects
    Signed-off-by: Willy Tarreau <>
    Cc: Chris Wilson <>
    [danvet: Added note about the regressing commit and cc: stable.]
    Signed-off-by: Daniel Vetter <>
    Signed-off-by: Greg Kroah-Hartman <>
  20. @e4t @gregkh

    drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy().

    e4t authored gregkh committed
    commit 0829184 upstream.
    radeon_i2c_fini() walks thru the list of I2C bus recs rdev->i2c_bus[]
    to destroy each of them.
    radeon_ext_tmds_enc_destroy() however also has code to destroy it's
    associated I2C bus rec which has been obtained by radeon_i2c_lookup()
    and is therefore also in the i2c_bus[] list.
    This causes a double free resulting in a kernel panic when unloading
    the radeon driver.
    Removing destroy code from radeon_ext_tmds_enc_destroy() fixes this
    agd5f: fix compiler warning
    Signed-off-by: Egbert Eich <>
    Signed-off-by: Alex Deucher <>
    Signed-off-by: Greg Kroah-Hartman <>
  21. @sashalevin @gregkh

    fs: prevent use after free in auditing when symlink following was denied

    sashalevin authored gregkh committed
    commit ffd8d10 upstream.
    Commit "fs: add link restriction audit reporting" has added auditing of failed
    attempts to follow symlinks. Unfortunately, the auditing was being done after
    the struct path structure was released earlier.
    Signed-off-by: Sasha Levin <>
    Signed-off-by: Al Viro <>
    Cc: Dave Jones <>
    Signed-off-by: Greg Kroah-Hartman <>
  22. @sashalevin @gregkh

    fs: handle failed audit_log_start properly

    sashalevin authored gregkh committed
    commit d1c7d97 upstream.
    audit_log_start() may return NULL, this is unchecked by the caller in
    audit_log_link_denied() and could cause a NULL ptr deref.
    Introduced by commit a51d9ea ("fs: add link restriction audit reporting").
    Signed-off-by: Sasha Levin <>
    Signed-off-by: Al Viro <>
    Cc: Dave Jones <>
    Signed-off-by: Greg Kroah-Hartman <>
  23. @jcdr @gregkh

    Add CDC-ACM support for the CX93010-2x UCMxx USB Modem

    jcdr authored gregkh committed
    commit e7d491a upstream.
    This USB V.92/V.32bis Controllered Modem have the USB vendor ID 0x0572
    and device ID 0x1340. It need the NO_UNION_NORMAL quirk to be recognized.
    See idVendor and idProduct in table 6-1. Device Descriptors
    Signed-off-by: Jean-Christian de Rivaz <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
  24. @michal42 @gregkh

    kbuild: Fix accidental revert in commit fe04ddf

    michal42 authored gregkh committed
    commit 3ce9e53 upstream.
    Commit fe04ddf ("kbuild: Do not package /boot and /lib in make
    tar-pkg") accidentally reverted two previous kbuild commits.  I don't
    know what I was thinking.
    This brings back changes made by commits 24cc7fb ("x86/kbuild:
    archscripts depends on scripts_basic") and c1c1a59 ("firmware: fix
    directory creation rule matching with make 3.80")
    Reported-by: Jan Beulich <>
    Signed-off-by: Michal Marek <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  25. @gregkh

    MIPS: ath79: Fix CPU/DDR frequency calculation for SRIF PLLs

    Gabor Juhos authored gregkh committed
    commit 97541cc upstream.
    Besides the CPU and DDR PLLs, the CPU and DDR frequencies
    can be derived from other PLLs in the SRIF block on the
    AR934x SoCs. The current code does not checks if the SRIF
    PLLs are used and this can lead to incorrectly calculated
    CPU/DDR frequencies.
    Fix it by calculating the frequencies from SRIF PLLs if
    those are used on a given board.
    Signed-off-by: Gabor Juhos <>
    Signed-off-by: Ralf Baechle <>
    Signed-off-by: Greg Kroah-Hartman <>
  26. @gregkh

    pktgen: fix crash when generating IPv6 packets

    Amerigo Wang authored gregkh committed
    commit 5aa8b57 upstream.
    For IPv6, sizeof(struct ipv6hdr) = 40, thus the following
    expression will result negative:
            datalen = pkt_dev->cur_pkt_size - 14 -
                      sizeof(struct ipv6hdr) - sizeof(struct udphdr) -
    And,  the check "if (datalen < sizeof(struct pktgen_hdr))" will be
    passed as "datalen" is promoted to unsigned, therefore will cause
    a crash later.
    This is a quick fix by checking if "datalen" is negative. The following
    patch will increase the default value of 'min_pkt_size' for IPv6.
    This bug should exist for a long time, so Cc -stable too.
    Signed-off-by: Cong Wang <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
  27. @jwessel @gregkh

    kdb,vt_console: Fix missed data due to pager overruns

    jwessel authored gregkh committed
    commit 17b572e upstream.
    It is possible to miss data when using the kdb pager.  The kdb pager
    does not pay attention to the maximum column constraint of the screen
    or serial terminal.  This result is not incrementing the shown lines
    correctly and the pager will print more lines that fit on the screen.
    Obviously that is less than useful when using a VGA console where you
    cannot scroll back.
    The pager will now look at the kdb_buffer string to see how many
    characters are printed.  It might not be perfect considering you can
    output ASCII that might move the cursor position, but it is a
    substantially better approximation for viewing dmesg and trace logs.
    This also means that the vt screen needs to set the kdb COLUMNS
    Signed-off-by: Jason Wessel <>
    Signed-off-by: Greg Kroah-Hartman <>
  28. @gregkh

    md/raid10: use correct limit variable

    Dan Carpenter authored gregkh committed
    commit 91502f0 upstream.
    Clang complains that we are assigning a variable to itself.  This should
    be using bad_sectors like the similar earlier check does.
    Bug has been present since 3.1-rc1.  It is minor but could
    conceivably cause corruption or other bad behaviour.
    Signed-off-by: Dan Carpenter <>
    Signed-off-by: NeilBrown <>
    Signed-off-by: Greg Kroah-Hartman <>
  29. @nbd168 @gregkh

    mac80211: use ieee80211_free_txskb to fix possible skb leaks

    nbd168 authored gregkh committed
    commit c3e7724 upstream.
    A few places free skbs using dev_kfree_skb even though they're called
    after ieee80211_subif_start_xmit might have cloned it for tracking tx
    status. Use ieee80211_free_txskb here to prevent skb leaks.
    Signed-off-by: Felix Fietkau <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
  30. @nbd168 @gregkh

    ath9k: use ieee80211_free_txskb

    nbd168 authored gregkh committed
    commit 249ee72 upstream.
    Using ieee80211_free_txskb for tx frames is required, since mac80211 clones
    skbs for which socket tx status is requested.
    Signed-off-by: Felix Fietkau <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
  31. @fweisbec @gregkh

    nohz: Fix one jiffy count too far in idle cputime

    fweisbec authored gregkh committed
    commit 2b17c54 upstream.
    When we stop the tick in idle, we save the current jiffies value
    in ts->idle_jiffies. This snapshot is substracted from the later
    value of jiffies when the tick is restarted and the resulting
    delta is accounted as idle cputime. This is how we handle the
    idle cputime accounting without the tick.
    But sometimes we need to schedule the next tick to some time in
    the future instead of completely stopping it. In this case, a
    tick may happen before we restart the periodic behaviour and
    from that tick we account one jiffy to idle cputime as usual but
    we also increment the ts->idle_jiffies snapshot by one so that
    when we compute the delta to account, we substract the one jiffy
    we just accounted.
    To prepare for stopping the tick outside idle, we introduced a
    check that prevents from fixing up that ts->idle_jiffies if we
    are not running the idle task. But we use idle_cpu() for that
    and this is a problem if we run the tick while another CPU
    remotely enqueues a ttwu to our runqueue:
    CPU 0:                            CPU 1:
    tick_sched_timer() {              ttwu_queue_remote()
           if (idle_cpu(CPU 0))
    Here, idle_cpu() notes that &rq->wake_list is not empty and
    hence won't consider the CPU as idle. As a result,
    ts->idle_jiffies won't be incremented. But this is wrong because
    we actually account the current jiffy to idle cputime. And that
    jiffy won't get substracted from the nohz time delta. So in the
    end, this jiffy is accounted twice.
    Fix this by changing idle_cpu(smp_processor_id()) with
    is_idle_task(current). This way the jiffy is substracted
    correctly even if a ttwu operation is enqueued on the CPU.
    Signed-off-by: Frederic Weisbecker <>
    Cc: Peter Zijlstra <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
  32. @gregkh

    timers: Fix endless looping between cascade() and internal_add_timer()

    Hildner, Christian authored gregkh committed
    commit 26cff4e upstream.
    Adding two (or more) timers with large values for "expires" (they have
    to reside within tv5 in the same list) leads to endless looping
    between cascade() and internal_add_timer() in case CONFIG_BASE_SMALL
    is one and jiffies are crossing the value 1 << 18. The bug was
    introduced between 2.6.11 and 2.6.12 (and survived for quite some
    This patch ensures that when cascade() is called timers within tv5 are
    not added endlessly to their own list again, instead they are added to
    the next lower tv level tv4 (as expected).
    Signed-off-by: Christian Hildner <>
    Reviewed-by: Jan Kiszka <>
    Signed-off-by: Thomas Gleixner <>
    Signed-off-by: Greg Kroah-Hartman <>
  33. @gregkh

    timekeeping: Cast raw_interval to u64 to avoid shift overflow

    Dan Carpenter authored gregkh committed
    commit 5b3900c upstream.
    We fixed a bunch of integer overflows in timekeeping code during the 3.6
    cycle.  I did an audit based on that and found this potential overflow.
    Signed-off-by: Dan Carpenter <>
    Acked-by: John Stultz <>
    Signed-off-by: Thomas Gleixner <>
    Signed-off-by: Greg Kroah-Hartman <>
  34. @gregkh

    viafb: don't touch clock state on OLPC XO-1.5

    Daniel Drake authored gregkh committed
    commit 012a121 upstream.
    As detailed in the thread titled "viafb PLL/clock tweaking causes XO-1.5
    instability," enabling or disabling the IGA1/IGA2 clocks causes occasional
    stability problems during suspend/resume cycles on this platform.
    This is rather odd, as the documentation suggests that clocks have two
    states (on/off) and the default (stable) configuration is configured to
    enable the clock only when it is needed. However, explicitly enabling *or*
    disabling the clock triggers this system instability, suggesting that there
    is a 3rd state at play here.
    Leaving the clock enable/disable registers alone solves this problem.
    This fixes spurious reboots during suspend/resume behaviour introduced by
    commit b692a63.
    Signed-off-by: Daniel Drake <>
    Signed-off-by: Florian Tobias Schandinat <>
    Signed-off-by: Greg Kroah-Hartman <>
  35. @aholler @gregkh

    video/udlfb: fix line counting in fb_write

    aholler authored gregkh committed
    commit b8c4321 upstream.
    Line 0 and 1 were both written to line 0 (on the display) and all subsequent
    lines had an offset of -1. The result was that the last line on the display
    was never overwritten by writes to /dev/fbN.
    Signed-off-by: Alexander Holler <>
    Acked-by: Bernie Thompson <>
    Signed-off-by: Florian Tobias Schandinat <>
    Signed-off-by: Greg Kroah-Hartman <>
Something went wrong with that request. Please try again.