Skip to content
Snippets Groups Projects
  1. May 03, 2014
    • Linus Torvalds's avatar
      Merge tag 'dt-for-linus' of git://git.secretlab.ca/git/linux · e981e795
      Linus Torvalds authored
      Pull driver core deferred probe fix from Grant Likely:
       "Drivercore race condition fix (exposed by devicetree)
      
        This branch fixes a bug where a device can get stuck in the deferred
        list even though all its dependencies are met.  The bug has existed
        for a long time, but new platform conversions to device tree have
        exposed it.  This patch is needed to get those platforms working.
      
        This was the pending bug fix I mentioned in my previous pull request.
        Normally this would go through Greg's tree seeing that it is a
        drivercore change, but devicetree exposes the problem.  I've discussed
        with Greg and he okayed me asking you to pull directly"
      
      * tag 'dt-for-linus' of git://git.secretlab.ca/git/linux:
        drivercore: deferral race condition fix
      e981e795
  2. May 02, 2014
  3. May 01, 2014
  4. Apr 30, 2014
  5. Apr 29, 2014
    • Takashi Iwai's avatar
      ALSA: hda - Suppress CORBRP clear on Nvidia controller chips · 6ba736dd
      Takashi Iwai authored
      
      The recent commit (ca460f86) changed the CORB RP reset procedure to
      follow the specification with a couple of sanity checks.
      Unfortunately, Nvidia controller chips seem not following this way,
      and spew the warning messages like:
        snd_hda_intel 0000:00:10.1: CORB reset timeout#1, CORBRP = 0
      
      This patch adds the workaround for such chips.  It just skips the new
      reset procedure for the known broken chips.
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6ba736dd
    • Mike Snitzer's avatar
      dm thin: use INIT_WORK_ONSTACK in noflush_work to avoid ODEBUG warning · fbcde3d8
      Mike Snitzer authored
      
      Use INIT_WORK_ONSTACK to silence "ODEBUG: object is on stack, but not
      annotated".
      
      Reported-by: default avatarZdeněk Kabeláč <zkabelac@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Acked-by: default avatarJoe Thornber <ejt@redhat.com>
      fbcde3d8
    • Grant Likely's avatar
      drivercore: deferral race condition fix · 58b116bc
      Grant Likely authored
      
      When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
      when all modules loaded but some driver still stuck in the deferred list
      and there is a need for external event to kick the deferred queue to probe
      these drivers.
      
      The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
      audio support built as modules and using nfsroot for root filesystem.
      
      The following log fragment shows such sequence when all audio modules
      were loaded but the sound card is not present since the machine driver has
      failed to probe due to missing dependency during it's probe.
      The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
      machine driver:
      
      ...
      [   12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
      [   12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
      [   12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
      [   12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
      [   12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
      [   12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
      [   12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
      [   13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
      [   13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
      [   13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
      [   13.346755] davinci_mcasp_driver_init: LEAVE
      [   13.377446] platform sound.3: Driver davinci_evm requests probe deferral
      [   13.592527] platform sound.3: really_probe: probe_count = 0
      
      In the log the machine driver enters it's probe at 12.719969 (this point it
      has been removed from the deferred lists). McASP driver already executing
      it's probing (since 12.615118).
      The machine driver tries to construct the sound card (12.950839) but did
      not found one of the components so it fails. After this McASP driver
      registers all the ASoC components (the machine driver still in it's probe
      function after it failed to construct the card) and the deferred work is
      prepared at 13.099026 (note that this time the machine driver is not in the
      lists so it is not going to be handled when the work is executing).
      Lastly the machine driver exit from it's probe and the core places it to
      the deferred list but there will be no other driver going to load and the
      deferred queue is not going to be kicked again - till we have external event
      like connecting USB stick, etc.
      
      The proposed solution is to try the deferred queue once more when the last
      driver is asking for deferring and we had drivers loaded while this last
      driver was probing.
      
      This way we can avoid drivers stuck in the deferred queue.
      
      Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
      Reviewed-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Tested-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Stable <stable@vger.kernel.org> # v3.4+
      58b116bc
    • Haibin Wang's avatar
      KVM: ARM: vgic: Fix the overlap check action about setting the GICD & GICC base address. · 30c21170
      Haibin Wang authored
      
      Currently below check in vgic_ioaddr_overlap will always succeed,
      because the vgic dist base and vgic cpu base are still kept UNDEF
      after initialization. The code as follows will be return forever.
      
      	if (IS_VGIC_ADDR_UNDEF(dist) || IS_VGIC_ADDR_UNDEF(cpu))
                      return 0;
      
      So, before invoking the vgic_ioaddr_overlap, it needs to set the
      corresponding base address firstly.
      
      Signed-off-by: default avatarHaibin Wang <wanghaibin.wang@huawei.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      30c21170
Loading