1. 29 4月, 2008 1 次提交
  2. 28 4月, 2008 1 次提交
  3. 07 2月, 2008 1 次提交
    • R
      PNP: do not test PNP_DRIVER_RES_DO_NOT_CHANGE on suspend/resume · 5d38998e
      Rene Herman 提交于
      The PNP_DRIVER_RES_DO_NOT_CHANGE flag is meant to signify that the PNP core
      should not change resources for the device -- not that it shouldn't
      disable/enable the device on suspend/resume.
      
      ALSA ISAPnP drivers set PNP_DRIVER_RES_DO_NOT_CHANAGE (0x0001) through
      setting PNP_DRIVER_RES_DISABLE (0x0003).  The latter including the former
      may in itself be considered rather unexpected but doesn't change that
      suspend/resume wouldn't seem to have any business testing the flag.
      
      As reported by Ondrej Zary for snd-cs4236, ALSA driven ISAPnP cards don't
      survive swsusp hibernation with the resume skipping setting the resources
      due to testing the flag -- the same test in the suspend path isn't enough
      to keep hibernation from disabling the card it seems.
      
      These tests were added (in 2005) by Piere Ossman in commit
      68094e32, "alsa: Improved PnP suspend
      support" who doesn't remember why.  This deletes them.
      Signed-off-by: NRene Herman <rene.herman@gmail.com>
      Tested-by: NOndrej Zary <linux@rainbow-software.org>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Pierre Ossman <drzeus@drzeus.cx>
      Cc: Adam Belay <ambx1@neo.rr.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5d38998e
  4. 17 10月, 2007 1 次提交
  5. 24 8月, 2007 2 次提交
  6. 27 7月, 2007 2 次提交
  7. 22 7月, 2007 1 次提交
  8. 01 7月, 2006 1 次提交
  9. 28 3月, 2006 1 次提交
  10. 14 1月, 2006 1 次提交
  11. 03 1月, 2006 2 次提交
  12. 07 11月, 2005 1 次提交
    • A
      [PATCH] drivers/pnp/: cleanups · b449f63c
      Adrian Bunk 提交于
      This patch contains the following possible cleanups:
      - make needlessly global code static
      - #if 0 the following unused global function:
        - core.c: pnp_remove_device
      - #if 0 the following unneeded EXPORT_SYMBOL's:
        - card.c: pnp_add_card
        - card.c: pnp_remove_card
        - card.c: pnp_add_card_device
        - card.c: pnp_remove_card_device
        - card.c: pnp_add_card_id
        - core.c: pnp_register_protocol
        - core.c: pnp_unregister_protocol
        - core.c: pnp_add_device
        - core.c: pnp_remove_device
        - pnpacpi/core.c: pnpacpi_protocol
        - driver.c: pnp_add_id
        - isapnp/core.c: isapnp_read_byte
        - manager.c: pnp_auto_config_dev
        - resource.c: pnp_register_dependent_option
        - resource.c: pnp_register_independent_option
        - resource.c: pnp_register_irq_resource
        - resource.c: pnp_register_dma_resource
        - resource.c: pnp_register_port_resource
        - resource.c: pnp_register_mem_resource
      
      Note that this patch #if 0's exactly one functions and removes no
      functions.  Most it does is the #if 0 of EXPORT_SYMBOL's, so if any modular
      code will use any of them, re-adding will be trivial.
      
      Modular ISAPnP might be interesting in some cases, but this is more legacy
      code.  If someone would work on it to sort all the issues out (starting
      with the point that most users of __ISAPNP__ will have to be fixed)
      re-enabling the required EXPORT_SYMBOL's won't be hard for him.
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Cc: Adam Belay <ambx1@neo.rr.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b449f63c
  13. 08 9月, 2005 1 次提交
  14. 21 6月, 2005 1 次提交
  15. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4