1. 07 12月, 2013 2 次提交
    • R
      ACPI / bind: Rework struct acpi_bus_type · e3f02c52
      Rafael J. Wysocki 提交于
      Replace the .find_device function pointer in struct acpi_bus_type
      with a new one, .find_companion, that is supposed to point to a
      function returning struct acpi_device pointer (instead of an int)
      and takes one argument (instead of two).  This way the role of
      this callback is more clear and the implementation of it can
      be more straightforward.
      
      Update all of the users of struct acpi_bus_type (PCI, PNP/ACPI and
      USB) to reflect the structure change.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: Lan Tianyu <tianyu.lan@intel.com> # for USB/ACPI
      e3f02c52
    • L
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      Lv Zheng 提交于
      Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
      <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
      inclusions and remove some inclusions of those files that aren't
      necessary.
      
      First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
      should not be included directly from any files that are built for
      CONFIG_ACPI unset, because that generally leads to build warnings about
      undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
      <linux/acpi.h> includes those files and for CONFIG_ACPI unset it
      provides stub ACPI symbols to be used in that case.
      
      Second, there are ordering dependencies between those files that always
      have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
      prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
      latter depends on are always there.  And <acpi/acpi.h> which provides
      basic ACPICA type declarations should always be included prior to any other
      ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
      <linux/acpi.h> as appropriate.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8b48463f
  2. 05 12月, 2013 1 次提交
  3. 15 11月, 2013 1 次提交
  4. 17 10月, 2013 1 次提交
  5. 24 9月, 2013 1 次提交
  6. 12 9月, 2013 1 次提交
    • S
      pnp: change pnp bus pm_ops to invoke pnp driver dev_pm_ops if specified · 729377d5
      Shuah Khan 提交于
      pnp_bus_suspend() and pnp_bus_resume() invoke legacy pm_ops from
      pnp_driver.  Changed pnp_bus_suspend() and pnp_bus_resume() to check if
      pnp driver has dev_pm_ops and call.  If dev_pm_ops don't exist, then call
      use legacy pm_ops.  Without this change, pnp_driver dev_pm_ops will not
      get called.
      
      In addition to the pnp driver bus pm_ops change to invoke driver
      dev_pm_ops, this patch set contains changes to rtc-cmos, tpm_tis, and
      apple-gmux pnp drivers to convert from legacy pm_ops to dev_pm_ops.
      
      This patch (of 4):
      
      pnp_bus_suspend() and pnp_bus_resume() invoke legacy pm_ops from
      pnp_driver.  Changed pnp_bus_suspend() and pnp_bus_resume() to check if
      pnp driver has dev_pm_ops and call.  If dev_pm_ops don't exist, then call
      use legacy pm_ops.  Without this change, pnp_driver dev_pm_ops will not
      get called.
      Signed-off-by: NShuah Khan <shuah.kh@samsung.com>
      Cc: Matthew Garrett <matthew.garrett@nebula.com>
      Cc: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
      Cc: Ashley Lai <ashley@ashleylai.com>
      Cc: Rajiv Andrade <mail@srajiv.net>
      Cc: Marcel Selhorst <tpmdd@selhorst.net>
      Cc: Sirrix AG <tpmdd@sirrix.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Peter Hüwe <PeterHuewe@gmx.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      729377d5
  7. 30 7月, 2013 1 次提交
  8. 27 7月, 2013 1 次提交
  9. 18 7月, 2013 1 次提交
  10. 29 6月, 2013 1 次提交
  11. 22 5月, 2013 1 次提交
    • D
      pnp: restore automatic resolution of DMA conflicts · bdf0eb3a
      David Flater 提交于
      To fix a 5-year-old regression, reverse changes made by commit
      7ef36390 (PNP: don't fail device init if no DMA channel available).
      
      As an example to show the problem, my sound card provides a
      prioritized list of PnP "dependent sets" of requested resources:
      
        dependent set 0 (preferred) wants DMA 5.
        dependent set 1 (acceptable) will take DMA 5, 6, or 7.
        ...
        dependent set 4 (acceptable) doesn't request a high DMA.
      
      If DMA 5 is not available, pnp_assign_dma has to fail on set 0 so that
      pnp_auto_config_dev will move on to set 1 and get DMA 6 or 7.
      Instead, pnp_assign_dma adds the resource with flags |=
      IORESOURCE_DISABLED and returns success.  pnp_auto_config_dev just
      sees success and therefore chooses set 0 with a disabled DMA and never
      tries the sets that would have resolved the conflict.
      
      Furthermore, this mode of "success" is unexpected and unhandled in
      sound/isa/sb and probably other drivers.  sb assumes that the returned
      DMA is enabled and obliviously uses the invalid DMA number.  Observed
      consequences were sb successfully grabbing a DMA that was expressly
      forbidden by the kernel parameter pnp_reserve_dma.
      
      The only upside to the original change would be as a kludge for
      devices that can operate in degraded mode without a DMA but that don't
      provide the corresponding non-preferred dependent set.  The right
      workaround for those devices is to synthesize the missing set in
      quirks.c; otherwise, you're reinventing PnP fallback functionality at
      the driver level for that device and all others.
      Signed-off-by: NDavid Flater <dave@flaterco.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bdf0eb3a
  12. 02 5月, 2013 1 次提交
  13. 23 4月, 2013 2 次提交
  14. 18 4月, 2013 1 次提交
  15. 10 4月, 2013 1 次提交
    • A
      procfs: new helper - PDE_DATA(inode) · d9dda78b
      Al Viro 提交于
      The only part of proc_dir_entry the code outside of fs/proc
      really cares about is PDE(inode)->data.  Provide a helper
      for that; static inline for now, eventually will be moved
      to fs/proc, along with the knowledge of struct proc_dir_entry
      layout.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d9dda78b
  16. 24 3月, 2013 1 次提交
  17. 04 3月, 2013 1 次提交
    • R
      ACPI / glue: Add .match() callback to struct acpi_bus_type · 53540098
      Rafael J. Wysocki 提交于
      USB uses the .find_bridge() callback from struct acpi_bus_type
      incorrectly, because as a result of the way it is used by USB every
      device in the system that doesn't have a bus type or parent is
      passed to usb_acpi_find_device() for inspection.
      
      What USB actually needs, though, is to call usb_acpi_find_device()
      for USB ports that don't have a bus type defined, but have
      usb_port_device_type as their device type, as well as for USB
      devices.
      
      To fix that replace the struct bus_type pointer in struct
      acpi_bus_type used for matching devices to specific subsystems
      with a .match() callback to be used for this purpose and update
      the users of struct acpi_bus_type, including USB, accordingly.
      Define the .match() callback routine for USB, usb_acpi_bus_match(),
      in such a way that it will cover both USB devices and USB ports
      and remove the now redundant .find_bridge() callback pointer from
      usb_acpi_bus.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NJeff Garzik <jgarzik@pobox.com>
      53540098
  18. 23 2月, 2013 1 次提交
  19. 01 2月, 2013 1 次提交
  20. 26 1月, 2013 1 次提交
  21. 03 1月, 2013 2 次提交
  22. 08 12月, 2012 1 次提交
  23. 30 11月, 2012 1 次提交
    • R
      ACPI / PNP: Do not crash due to stale pointer use during system resume · a6b5e88c
      Rafael J. Wysocki 提交于
      During resume from system suspend the 'data' field of
      struct pnp_dev in pnpacpi_set_resources() may be a stale pointer,
      due to removal of the associated ACPI device node object in the
      previous suspend-resume cycle.  This happens, for example, if a
      dockable machine is booted in the docking station and then suspended
      and resumed and suspended again.  If that happens,
      pnpacpi_build_resource_template() called from pnpacpi_set_resources()
      attempts to use that pointer and crashes.
      
      However, pnpacpi_set_resources() actually checks the device's ACPI
      handle, attempts to find the ACPI device node object attached to it
      and returns an error code if that fails, so in fact it knows what the
      correct value of dev->data should be.  Use this observation to update
      dev->data with the correct value if necessary and dump a call trace
      if that's the case (once).
      
      We still need to fix the root cause of this issue, but preventing
      systems from crashing because of it is an improvement too.
      Reported-and-tested-by: NZdenek Kabelac <zdenek.kabelac@gmail.com>
      References: https://bugzilla.kernel.org/show_bug.cgi?id=51071
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a6b5e88c
  24. 29 11月, 2012 1 次提交
  25. 24 11月, 2012 1 次提交
  26. 15 11月, 2012 1 次提交
  27. 22 9月, 2012 1 次提交
    • L
      ACPI: Allow ACPI binding with USB-3.0 hub · 1033f904
      Lan Tianyu 提交于
      A USB port's position and connectability can't be identified on some boards
      via USB hub registers. ACPI _UPC and _PLD can help to resolve this issue
      and so it is necessary to bind USB with ACPI. This patch is to allow ACPI
      binding with USB-3.0 hub.
      
      Current ACPI only can bind one struct-device to one ACPI device node.
      This can not work with USB-3.0 hub, because the USB-3.0 hub has two logical
      devices. Each works for USB-2.0 and USB-3.0 devices. In the Linux USB subsystem,
      those two logical hubs are treated as two seperate devices that have two struct
      devices. But in the ACPI DSDT, these two logical hubs share one ACPI device
      node. So there is a requirement to bind multi struct-devices to one ACPI
      device node. This patch is to resolve such problem.
      
      Following is the ACPI device nodes' description under xhci hcd.
      
      Device (XHC)
                  Device (RHUB)
                      Device (HSP1)
                      Device (HSP2)
                      Device (HSP3)
                      Device (HSP4)
                      Device (SSP1)
                      Device (SSP2)
                      Device (SSP3)
                      Device (SSP4)
      
      Topology in the Linux
      
      	device XHC
      	   USB-2.0 logical hub    USB-3.0 logical hub
      		HSP1			SSP1
      		HSP2			SSP2
      		HSP3			SSP3
      		HSP4			SSP4
      
      This patch also modifies the output of /proc/acpi/wakeup. One ACPI node
      can be associated with multiple devices:
      
      XHC		S4	*enabled	pci:0000:00:14.0
      RHUB	S0	disabled	usb:usb1
      			disabled	usb:usb2
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      1033f904
  28. 24 6月, 2012 1 次提交
  29. 30 3月, 2012 1 次提交
  30. 29 3月, 2012 1 次提交
  31. 07 1月, 2012 1 次提交
  32. 07 11月, 2011 1 次提交
  33. 01 11月, 2011 1 次提交
  34. 26 7月, 2011 1 次提交
    • W
      pnpacpi: register disabled resources · 29df8d8f
      Witold Szczeponik 提交于
      When parsing PnP ACPI resource structures, it may happen that some of
      the resources are disabled (in which case "the size" of the resource
      equals zero).
      
      The current solution is to skip these resources completely - with the
      unfortunate side effect that they are not registered despite the fact
      that they exist, after all.  (The downside of this approach is that
      these resources cannot be used as templates for setting the actual
      device's resources because they are missing from the template.) The
      kernel's APM implementation does not suffer from this problem and
      registers all resources regardless of "their size".
      
      This patch fixes a problem with (at least) the vintage IBM ThinkPad 600E
      (and most likely also with the 600, 600X, and 770X which have a very
      similar layout) where some of its PnP devices support options where
      either an IRQ, a DMA, or an IO port is disabled.  Without this patch,
      the devices can not be configured using the
      "/sys/bus/pnp/devices/*/resources" interface.
      
      The manipulation of these resources is important because the 600E has
      very demanding requirements.  For instance, the number of IRQs is not
      sufficient to support all devices of the 600E.  Fortunately, some of the
      devices, like the sound card's MPU-401 UART, can be configured to not
      use any IRQ, hence freeing an IRQ for a device that requires one.
      (Still, the device's "ResourceTemplate" requires an IRQ resource
      descriptor which cannot be created if the resource has not been
      registered in the first place.)
      
      As an example, the dependent sets of the 600E's CSC0103 device (the
      MPU-401 UART) are listed, with the patch applied, as:
      
        Dependent: 00 - Priority preferred
          port 0x300-0x330, align 0xf, size 0x4, 16-bit address decoding
          irq <none> High-Edge
        Dependent: 01 - Priority acceptable
          port 0x300-0x330, align 0xf, size 0x4, 16-bit address decoding
          irq 5,7,2/9,10,11,15 High-Edge
      
      (The same result is obtained when PNPBIOS is used instead of PnP ACPI.)
      Without the patch, the IRQ resource in the preferred option is not
      listed at all:
      
        Dependent: 00 - Priority preferred
          port 0x300-0x330, align 0xf, size 0x4, 16-bit address decoding
        Dependent: 01 - Priority acceptable
          port 0x300-0x330, align 0xf, size 0x4, 16-bit address decoding
          irq 5,7,2/9,10,11,15 High-Edge
      
      And in fact, the 600E's DSDT lists the disabled IRQ as an option, as can
      be seen from the following excerpt from the DSDT:
      
      	Name (_PRS, ResourceTemplate ()
      	{
              StartDependentFn (0x00, 0x00)
              {
                  IO (Decode16, 0x0300, 0x0330, 0x10, 0x04)
                  IRQNoFlags () {}
              }
              StartDependentFn (0x01, 0x00)
              {
                  IO (Decode16, 0x0300, 0x0330, 0x10, 0x04)
                  IRQNoFlags () {5,7,9,10,11,15}
              }
              EndDependentFn ()
      	})
      
      With this patch applied, a user space program - or maybe even the kernel
      - can allocate all devices' resources optimally.  For the 600E, this
      means to find optimal resources for (at least) the serial port, the
      parallel port, the infrared port, the MWAVE modem, the sound card, and
      the MPU-401 UART.
      
      The patch applies the idea to register disabled resources to all types
      of resources, not just to IRQs, DMAs, and IO ports.  At the same time,
      it mimics the behavior of the "pnp_assign_xxx" functions from
      "drivers/pnp/manager.c" where resources with "no size" are considered
      disabled.
      
      No regressions were observed on hardware that does not require this
      patch.
      
      The patch is applied against 2.6.39.
      
      NB: The kernel's current PnP interface does not allow for disabling individual
      resources using the "/sys/bus/pnp/devices/$device/resources" file.  Assuming
      this could be done, a device could be configured to use a disabled resource
      using a simple series of calls:
      
        echo disable > /sys/bus/pnp/devices/$device/resources
        echo clear > /sys/bus/pnp/devices/$device/resources
        echo set irq disabled > /sys/bus/pnp/devices/$device/resources
        echo fill > /sys/bus/pnp/devices/$device/resources
        echo activate > /sys/bus/pnp/devices/$device/resources
      
      This patch addresses only the parsing of PnP ACPI devices.
      
      ChangeLog (v1 -> v2):
       - extend patch description
       - fix typo in patch itself
      Signed-off-by: NWitold Szczeponik <Witold.Szczeponik@gmx.net>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Adam Belay <abelay@mit.edu>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Matthew Garrett <mjg@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      29df8d8f
  35. 10 6月, 2011 1 次提交
  36. 31 3月, 2011 1 次提交
  37. 23 3月, 2011 1 次提交
    • D
      pnp: only assign IORESOURCE_DMA if CONFIG_ISA_DMA_API is enabled · 586f83e2
      David Rientjes 提交于
      IORESOURCE_DMA cannot be assigned without utilizing the interface
      provided by CONFIG_ISA_DMA_API, specifically request_dma() and
      free_dma().  Thus, there's a strict dependency on the config option and
      limits IORESOURCE_DMA only to architectures that support ISA-style DMA.
      
      ia64 is not one of those architectures, so pnp_check_dma() no longer
      needs to be special-cased for that architecture.
      
      pnp_assign_resources() will now return -EINVAL if IORESOURCE_DMA is
      attempted on such a kernel.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      586f83e2