1. 12 Dec, 2013 17 commits
  2. 11 Dec, 2013 5 commits
    • José Miguel Gonçalves's avatar
      hwmon: HIH-6130: Support I2C bus drivers without I2C_FUNC_SMBUS_QUICK · efabcc21
      José Miguel Gonçalves authored
      Some I2C bus drivers do not allow zero-length data transfers which are
      required to start a measurement with the HIH6130/1 sensor. Nevertheless,
      we can overcome this limitation by writing a zero dummy byte. This byte
      is ignored by the sensor and was verified to be working with the OMAP
      I2C bus driver in a BeagleBone board.
      Signed-off-by: default avatarJosé Miguel Gonçalves <jose.goncalves@inov.pt>
      [Guenter Roeck: Simplified complexity of write_length initialization]
      Cc: stable@vger.kernel.org # v3.10+
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      efabcc21
    • Takashi Iwai's avatar
      ALSA: hda - Add static DAC/pin mapping for AD1986A codec · 3690739b
      Takashi Iwai authored
      AD1986A codec is a pretty old codec and has really many hidden
      restrictions.  One of such is that each DAC is dedicated to certain
      pin although there are possible connections.  Currently, the generic
      parser tries to assign individual DACs as much as possible, and this
      lead to two bad situations: connections where the sound actually
      doesn't work, and connections conflicting other channels.
      
      We may fix this by trying to find the best connections more harder,
      but as of now, it's easier to give some hints for paired DAC/pin
      connections and honor them if available, since such a hint is needed
      only for specific codecs (right now only AD1986A, and there will be
      unlikely any others in future).
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3690739b
    • Hui Wang's avatar
      ALSA: hda - One more Dell headset detection quirk · 7dca4bc6
      Hui Wang authored
      On the Dell machines with codec whose Subsystem Id is 0x10280624,
      no external microphone can be detected when plugging a 3-ring
      headset. If we add "model=dell-headset-multi" for the
      snd-hda-intel.ko, the problem will disappear.
      
      BugLink: https://bugs.launchpad.net/bugs/1259790
      Cc: David Henningsson <david.henningsson@canonical.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7dca4bc6
    • Anssi Hannula's avatar
      ALSA: hda - hdmi: Fix IEC958 ctl indexes for some simple HDMI devices · c9a6338a
      Anssi Hannula authored
      In case a single HDA card has both HDMI and S/PDIF outputs, the S/PDIF
      outputs will have their IEC958 controls created starting from index 16
      and the HDMI controls will be created starting from index 0.
      
      However, HDMI simple_playback_build_controls() as used by old VIA and
      NVIDIA codecs incorrectly requests the IEC958 controls to be created
      with an S/PDIF type instead of HDMI.
      In case the card has other codecs that have HDMI outputs, the controls
      will be created with wrong index=16, causing them to e.g. be unreachable
      by the ALSA "hdmi" alias.
      
      Fix that by making simple_playback_build_controls() request controls
      with HDMI indexes.
      
      Not many cards have an affected configuration, but e.g. ASUS M3N78-VM
      contains an integrated NVIDIA HDA "card" with:
      - a VIA codec that has, among others, an S/PDIF pin incorrectly
        labelled as an HDMI pin, and
      - an NVIDIA MCP7x HDMI codec.
      
      Reported-by: MysterX on #openelec
      Tested-by: MysterX on #openelec
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@iki.fi>
      Cc: <stable@vger.kernel.org> # 3.8+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c9a6338a
    • Jeff Layton's avatar
      nfsd: when reusing an existing repcache entry, unhash it first · 781c2a5a
      Jeff Layton authored
      The DRC code will attempt to reuse an existing, expired cache entry in
      preference to allocating a new one. It'll then search the cache, and if
      it gets a hit it'll then free the cache entry that it was going to
      reuse.
      
      The cache code doesn't unhash the entry that it's going to reuse
      however, so it's possible for it end up designating an entry for reuse
      and then subsequently freeing the same entry after it finds it.  This
      leads it to a later use-after-free situation and usually some list
      corruption warnings or an oops.
      
      Fix this by simply unhashing the entry that we intend to reuse. That
      will mean that it's not findable via a search and should prevent this
      situation from occurring.
      
      Cc: stable@vger.kernel.org # v3.10+
      Reported-by: default avatarChristoph Hellwig <hch@infradead.org>
      Reported-by: default avatarg. artim <gartim@gmail.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      781c2a5a
  3. 10 Dec, 2013 18 commits