1. 11 10月, 2007 1 次提交
  2. 29 9月, 2007 1 次提交
  3. 11 9月, 2007 2 次提交
  4. 25 8月, 2007 1 次提交
  5. 24 8月, 2007 2 次提交
    • L
      ACPI: Schedule /proc/acpi/event for removal · 14e04fb3
      Len Brown 提交于
      Schedule /proc/acpi/event for removal in 6 months.
      
      Re-name acpi_bus_generate_event() to acpi_bus_generate_proc_event()
      to make sure there is no confusion that it is for /proc/acpi/event only.
      
      Add CONFIG_ACPI_PROC_EVENT to allow removal of /proc/acpi/event.
      There is no functional change if CONFIG_ACPI_PROC_EVENT=y
      Signed-off-by: NLen Brown <len.brown@intel.com>
      14e04fb3
    • Z
      ACPI: don't duplicate input events on netlink · 962ce8ca
      Zhang Rui 提交于
      The previous events patch added a netlink event for every
      user of the legacy /proc/acpi/event interface.
      
      However, some users of /proc/acpi/event are really input events,
      and they already report their events via the input layer.
      
      Introduce a new interface, acpi_bus_generate_netlink_event(),
      which is explicitly called by devices that want to repoprt
      events via netlink.  This allows the input-like events
      to opt-out of generating netlink events.  In summary:
      
      events that are sent via netlink:
      	ac/battery/sbs
      	thermal
      	processor
      	thinkpad_acpi dock/bay
      
      events that are sent via input layer:
      	button
      	video hotkey
      	thinkpad_acpi hotkey
      	asus_acpi/asus-laptop hotkey
      	sonypi/sonylaptop
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      962ce8ca
  6. 23 8月, 2007 8 次提交
    • J
      PCI: Run k8t_sound_hostbridge quirk only when needed · 18166c1a
      Jean Delvare 提交于
      The k8t_sound_hostbridge PCI quick fires on my motherboard (Jetway
      K8M8MS) while it shouldn't: the on-board sound chip is not disabled
      and is working just fine. Looking at the code, I see that we are
      running the quirk for two distinct register values (0x88 and 0xc8)
      and then clear bit 6 (0x40). However value 0x88 already has bit 6
      cleared so this is a no-op. This is what happens on my board. Thus I
      believe that the quirk should only be run for register value 0xc8.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      18166c1a
    • T
      PCI: disable MSI on RX790 · f122392f
      Tejun Heo 提交于
      RX790 can't do MSI like its predecessors.  Disable MSI on RX790.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      f122392f
    • T
      PCI: disable MSI on RD580 · aea6a433
      Tejun Heo 提交于
      RD580 can't do MSI like its predecessors.  Disable MSI on RD580.
      Signed-off-by: NTejun Heo <teheo@suse.de>
      CC: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      aea6a433
    • T
      PCI: disable MSI on RS690 · 4be8f906
      Tejun Heo 提交于
      RS690 can't do MSI like its predecessors.  Disable MSI on RS690.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Cc: Henry Su <henry.su@amd.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4be8f906
    • B
      PCI: lets kill the 'PCI hidden behind bridge' message · d55bef51
      Bernhard Kaindl 提交于
      Adrian Bunk wrote:
      > Alois Nešpor wrote
      >> PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0b) (try 'pci=assign-busses')
      >> Please report the result to linux-kernel to fix this permanently"
      >>
      >> dmesg:
      >> "Yenta: Raising subordinate bus# of parent bus (#0a) from #0b to #0e"
      >> without pci=assign-busses and nothing with pci=assign-busses.
      > 
      > Bernhard?
      
      Ok, lets kill the message. As Alois Nešpor also saw, that's fixed up by Yenta,
      so PCI does not have to warn about it. PCI could still warn about it if
      is_cardbus is 0 in that instance of pci_scan_bridge(), but so far I have
      not seen a report where this would have been the case so I think we can
      spare the kernel of that check (removes ~300 lines of asm) unless debugging
      is done.
      
      History: The whole check was added in the days before we had the fixup
      for this in Yenta and pci=assign-busses was the only way to get CardBus
      cards detected on many (not all) of the machines which give this warning.
      
      In theory, there could be cases when this warning would be triggered and
      it's not cardbus, then the warning should still apply, but I think this
      should only be the case when working on a completely broken PCI setup,
      but one may have already enabled the debug code in drivers/pci and the
      patched check would then trigger.
      
      I do not sign this off yet because it's completely untested so far, but
      everyone is free to test it (with the #ifdef DEBUG replaced by #if 1 and
      pr_debug( changed to printk(.
      
      We may also dump the whole check (remove everything within the #ifdef from
      the source) if that's perferred.
      
      On Alois Nešpor's machine this would then (only when debugging) this message:
      
      "PCI: Bus #0b (-#0e) is partially hidden behind transparent bridge #0a (-#0b)"
      
      "partially" should be in the message on his machine because #0b of #0b-#0e 
      is reachable behind #0a-#0b, but not #0c-#0e.
      
      But that differentiation is now moot anyway because the fixup in Yenta takes
      care of it as far as I could see so far, which means that unless somebody
      is debugging a totally broken PCI setup, this message is not needed anymore,
      not even for debugging PCI.
      
      
      Ok, here the patch with the following changes:
      
      * Refined to say that the bus is only partially hidden when the parent
        bus numbers are not totally way off (outside of) the child bus range
      * remove the reference to pci=assign-busses and the plea to report it
      
      We could add a pure source code-only comment to keep a reference to
      pci=assign-busses the in case when this is triggered by someone who
      is debugging the cause of this message and looking the way to solve it.
      
      From: Bernhard Kaindl <bk@suse.de>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d55bef51
    • I
      pci/hotplug/cpqphp_ctrl.c: remove stale BKL use · 60ac8f20
      Ingo Molnar 提交于
      remove stale BKL use from drivers/pci/hotplug/cpqphp_ctrl.c.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      60ac8f20
    • M
      PCI: quirk_e100_interrupt() called too early · 4e68fc97
      Marian Balakowicz 提交于
      quirk_e100_interrupts() is called after PCI controller is initialized
      and before PCI bus enumeration is performed. On some powerpc platforms
      which modify PCI controller configuration and set different MEM and IO
      windows than those set by firmware quirk_e100_interrupt() is causing
      kernel panic as it tries to read from device BAR0 offets which at this
      time points to a invalid PCI window (set by firmware).
      
      This patch delays the quirk_100_interrupt() to pci_fixup_final phase,
      which happens after bus enumeration and before PCI enable and
      device driver initialization.
      Signed-off-by: NMarian Balakowicz <m8@semihalf.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4e68fc97
    • K
      PCI: Move prototypes for pci_bus_find_capability to include/linux/pci.h · ce5ccdef
      Kumar Gala 提交于
      We need pci_bus_find_capability() in some arch/powerpc code so move
      the prototype into a header accessible to it.
      
      Also kill the duplicate prototype for pci_bus_alloc_resource().
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ce5ccdef
  7. 01 8月, 2007 1 次提交
  8. 31 7月, 2007 1 次提交
  9. 30 7月, 2007 1 次提交
  10. 25 7月, 2007 1 次提交
  11. 22 7月, 2007 2 次提交
  12. 20 7月, 2007 1 次提交
  13. 17 7月, 2007 3 次提交
  14. 12 7月, 2007 15 次提交