1. 26 3月, 2013 1 次提交
  2. 26 1月, 2013 1 次提交
  3. 22 9月, 2012 1 次提交
  4. 10 8月, 2012 1 次提交
  5. 01 7月, 2012 2 次提交
  6. 17 7月, 2011 1 次提交
  7. 12 1月, 2011 1 次提交
  8. 16 10月, 2010 1 次提交
  9. 30 9月, 2010 1 次提交
  10. 10 6月, 2010 1 次提交
    • L
      ACPI: fan: fix unbalanced code block · 934231de
      Liang Li 提交于
      The code block braced with CONFIG_ACPI_PROCFS is unblanced. When
      CONFIG_ACPI_PROCFS=n, kernel trace will be produced like:
      
      Call Trace:
       [<c111637d>] ? remove_proc_entry+0x20d/0x290
       [<c111637d>] ? remove_proc_entry+0x20d/0x290
       [<c103b02c>] warn_slowpath_common+0x6c/0xc0
       [<c111637d>] ? remove_proc_entry+0x20d/0x290
       [<c103b0c6>] warn_slowpath_fmt+0x26/0x30
       [<c111637d>] remove_proc_entry+0x20d/0x290
       [<c1116bd7>] ? proc_register+0x117/0x1f0
       [<c1116e83>] ? proc_mkdir_mode+0x33/0x50
       [<c14f483c>] ? acpi_fan_init+0x0/0x2c
       [<c14f485f>] acpi_fan_init+0x23/0x2c
       [<c1001123>] do_one_initcall+0x23/0x180
       [<c107dcf7>] ? init_irq_proc+0x67/0x80
       [<c14d43bd>] kernel_init+0x13c/0x20e
       [<c1030e50>] ? schedule_tail+0x20/0x90
       [<c1389e06>] ? syscall_exit+0x5/0x16
       [<c14d4281>] ? kernel_init+0x0/0x20e
       [<c14d4281>] ? kernel_init+0x0/0x20e
       [<c10032f6>] kernel_thread_helper+0x6/0x30
      ---[ end trace a7919e7f17c0a725 ]---
      
      Then also bracket later error checking code with ACPI_PROCFS
      option to avoid mismatch problem.
      Signed-off-by: NLiang Li <liang.li@windriver.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      934231de
  11. 16 12月, 2009 1 次提交
  12. 29 8月, 2009 1 次提交
  13. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan 提交于
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
      as correctly noted at bug #12454. Someone can lookup entry with NULL
      ->owner, thus not pinning enything, and release it later resulting
      in module refcount underflow.
      
      We can keep ->owner and supply it at registration time like ->proc_fops
      and ->data.
      
      But this leaves ->owner as easy-manipulative field (just one C assignment)
      and somebody will forget to unpin previous/pin current module when
      switching ->owner. ->proc_fops is declared as "const" which should give
      some thoughts.
      
      ->read_proc/->write_proc were just fixed to not require ->owner for
      protection.
      
      rmmod'ed directories will be empty and return "." and ".." -- no harm.
      And directories with tricky enough readdir and lookup shouldn't be modular.
      We definitely don't want such modular code.
      
      Removing ->owner will also make PDE smaller.
      
      So, let's nuke it.
      
      Kudos to Jeff Layton for reminding about this, let's say, oversight.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  14. 20 2月, 2009 1 次提交
  15. 08 11月, 2008 1 次提交
  16. 23 10月, 2008 1 次提交
  17. 11 10月, 2008 1 次提交
  18. 22 7月, 2008 1 次提交
  19. 17 7月, 2008 1 次提交
    • Y
      ACPI: fix acpi fan state set error · 6594d87e
      Yi Yang 提交于
      Under /proc/acpi, there is a fan control interface, a user can
      set 0 or 3 to /proc/acpi/fan/*/state, 0 denotes D0 state, 3
      denotes D3 state, but in current implementation, a user can
      set a fan to D1 state by any char excluding '1', '2' and '3'.
      
      For example:
      
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "xxxxx" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  on
      
      Obviously, such inputs as "" and "xxxxx" are invalid for fan state.
      
      This patch fixes this issue, it strictly limits fan state only to
      accept 0, 1, 2 and 3, any other inputs are invalid.
      
      Before applying this patch, the test result is:
      
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "xxxxx" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "3x" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost acpi]# echo "-1x" > /proc/acpi/fan/C31B/state
      [root@localhost acpi]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost acpi]#
      
      After applying this patch, the test result is:
      
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "" > /proc/acpi/fan/C31B/state
      -bash: echo: write error: Invalid argument
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "3" > /proc/acpi/fan/C31B/state
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "xxxxx" > /proc/acpi/fan/C31B/state
      -bash: echo: write error: Invalid argument
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "-1x" > /proc/acpi/fan/C31B/state
      -bash: echo: write error: Invalid argument
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "0" > //proc/acpi/fan/C31B/state
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost ~]# echo "4" > //proc/acpi/fan/C31B/state
      -bash: echo: write error: Invalid argument
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost ~]# echo "3" > //proc/acpi/fan/C31B/state
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  off
      [root@localhost ~]# echo "0" > //proc/acpi/fan/C31B/state
      [root@localhost ~]# cat /proc/acpi/fan/C31B/state
      status:                  on
      [root@localhost ~]# echo "3x" > //proc/acpi/fan/C31B/state
      -bash: echo: write error: Invalid argument
      [root@localhost ~]#
      Signed-off-by: NYi Yang <yi.y.yang@intel.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      6594d87e
  20. 29 4月, 2008 2 次提交
  21. 29 3月, 2008 1 次提交
    • I
      revert "ACPI: drivers/acpi: elide a non-zero test on a result that is never 0" · 48d3d826
      Ingo Molnar 提交于
      Revert commit 1192aeb9 ("ACPI:
      drivers/acpi: elide a non-zero test on a result that is never 0")
      because it turns out that thermal_cooling_device_register() does
      actually return NULL if CONFIG_THERMAL is turned off (then the routine
      turns into a dummy inline routine in the header files that returns NULL
      unconditionally).
      
      This was found with randconfig testing, causing a crash during bootup:
      
        initcall 0x78878534 ran for 13 msecs: acpi_button_init+0x0/0x51()
        Calling initcall 0x78878585: acpi_fan_init+0x0/0x2c()
        BUG: unable to handle kernel NULL pointer dereference at 00000000
        IP: [<782b8ad0>] acpi_fan_add+0x7d/0xfd
        *pde = 00000000
        Oops: 0000 [#1]
        Modules linked in:
      
        Pid: 1, comm: swapper Not tainted (2.6.25-rc7-sched-devel.git-x86-latest.git #14)
        EIP: 0060:[<782b8ad0>] EFLAGS: 00010246 CPU: 0
        EIP is at acpi_fan_add+0x7d/0xfd
        EAX: b787c718 EBX: b787c400 ECX: b782ceb4 EDX: 00000007
        ESI: 00000000 EDI: b787c6f4 EBP: b782cee0 ESP: b782cecc
         DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
        Process swapper (pid: 1, ti=b782c000 task=b7846000 task.ti=b782c000)
        Stack: b787c459 00000000 b787c400 78790888 b787c60c b782cef8 782b6fb8 ffffffda
               b787c60c 00000000 78790958 b782cf0c 783005d7 b787c60c 78790958 78790584
               b782cf1c 783007f6 b782cf28 00000000 b782cf40 782ffc4a 78790958 b794d558
        Call Trace:
         [<782b6fb8>] ? acpi_device_probe+0x3e/0xdb
         [<783005d7>] ? driver_probe_device+0x82/0xfc
         [<783007f6>] ? __driver_attach+0x3a/0x70
         [<782ffc4a>] ? bus_for_each_dev+0x3e/0x60
         [<7830048c>] ? driver_attach+0x14/0x16
         [<783007bc>] ? __driver_attach+0x0/0x70
         [<7830006a>] ? bus_add_driver+0x9d/0x1b0
         [<783008c3>] ? driver_register+0x47/0xa3
         [<7813db00>] ? timespec_to_ktime+0x9/0xc
         [<782b7331>] ? acpi_bus_register_driver+0x3a/0x3c
         [<78878592>] ? acpi_fan_init+0xd/0x2c
         [<78863656>] ? kernel_init+0xac/0x1f9
         [<788635aa>] ? kernel_init+0x0/0x1f9
         [<78114563>] ? kernel_thread_helper+0x7/0x10
         =======================
        Code: 6e 78 e8 57 44 e7 ff 58 e9 93 00 00 00 8b 55 f0 8d bb f4 02 00 00 80 4b 2d 10 8b 03 e8 87 cb ff ff 8d 83 18 03 00 00 80 63 2d ef <ff> 35 00 00 00 00 50 68 e8 9c 6e 78 e8 22 44 e7 ff b9 b6 9c 6e
        EIP: [<782b8ad0>] acpi_fan_add+0x7d/0xfd SS:ESP 0068:b782cecc
        ---[ end trace 778e504de7e3b1e3 ]---
        Kernel panic - not syncing: Attempted to kill init!
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      48d3d826
  22. 27 3月, 2008 1 次提交
  23. 16 2月, 2008 1 次提交
  24. 02 2月, 2008 2 次提交
  25. 24 1月, 2008 1 次提交
  26. 26 10月, 2007 2 次提交
  27. 24 7月, 2007 1 次提交
  28. 13 2月, 2007 3 次提交
    • L
      ACPI: delete extra #defines in /drivers/acpi/ drivers · 7cda93e0
      Len Brown 提交于
      Cosmetic only.
      
      Except in a single case, #define ACPI_*_DRIVER_NAME
      were invoked 0 or 1 times.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      7cda93e0
    • L
      ACPI: fix acpi_driver.name usage · c2b6705b
      Len Brown 提交于
      It was erroneously used as a description rather than a name.
      
      ie. turn this:
      
      lenb@se7525gp2:/sys> ls bus/acpi/drivers
      ACPI AC Adapter Driver  ACPI Embedded Controller Driver  ACPI Power Resource Driver
      ACPI Battery Driver     ACPI Fan Driver                  ACPI Processor Driver
      ACPI Button Driver      ACPI PCI Interrupt Link Driver   ACPI Thermal Zone Driver
      ACPI container driver   ACPI PCI Root Bridge Driver      hpet
      
      into this:
      
      lenb@se7525gp2:~> ls /sys/bus/acpi/drivers
      ac  battery  button  container  ec  fan  hpet  pci_link  pci_root  power  processor  thermal
      Signed-off-by: NLen Brown <len.brown@intel.com>
      c2b6705b
    • L
      ACPI: clean up ACPI_MODULE_NAME() use · f52fd66d
      Len Brown 提交于
      cosmetic only
      
      Make "module name" actually match the file name.
      Invoke with ';' as leaving it off confuses Lindent and gcc doesn't care.
      Fix indentation where Lindent did get confused.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      f52fd66d
  29. 21 12月, 2006 1 次提交
  30. 16 12月, 2006 1 次提交
  31. 14 10月, 2006 1 次提交
  32. 10 7月, 2006 1 次提交
  33. 30 6月, 2006 2 次提交