1. 07 2月, 2014 2 次提交
    • R
      ACPI / hotplug / PCI: Rework the handling of eject requests · dd2151be
      Rafael J. Wysocki 提交于
      To avoid the need to install a hotplug notify handler for each ACPI
      namespace node representing a device and having a matching scan
      handler, move the check whether or not the ejection of the given
      device is enabled through its scan handler from acpi_hotplug_notify_cb()
      to acpi_generic_hotplug_event().  Also, move the execution of
      ACPI_OST_SC_EJECT_IN_PROGRESS _OST to acpi_generic_hotplug_event(),
      because in acpi_hotplug_notify_cb() or in acpi_eject_store() we really
      don't know whether or not the eject is going to be in progress (for
      example, acpi_hotplug_execute() may still fail without queuing up the
      work item).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      dd2151be
    • R
      ACPI / hotplug / PCI: Consolidate ACPIPHP with ACPI core hotplug · 3c2cc7ff
      Rafael J. Wysocki 提交于
      The ACPI-based PCI hotplug (ACPIPHP) code currently attaches its
      hotplug context objects directly to ACPI namespace nodes representing
      hotplug devices.  However, after recent changes causing struct
      acpi_device to be created for every namespace node representing a
      device (regardless of its status), that is not necessary any more.
      Moreover, it's vulnerable to the theoretical issue that the ACPI
      handle passed in the context between handle_hotplug_event() and
      hotplug_event_work() may become invalid in the meantime (as a
      result of a concurrent table unload).
      
      In principle, this issue might be addressed by adding a non-empty
      release handler for ACPIPHP hotplug context objects analogous to
      acpi_scan_drop_device(), but that would duplicate the code in that
      function and in acpi_device_del_work_fn().  For this reason, it's
      better to modify ACPIPHP to attach its device hotplug contexts to
      struct device objects representing hotplug devices and make it
      use acpi_hotplug_notify_cb() as its notify handler.  At the same
      time, acpi_device_hotplug() can be modified to dispatch the new
      .hp.event() callback pointing to acpiphp_hotplug_event() from ACPI
      device objects associated with PCI devices or use the generic
      ACPI device hotplug code for device objects with matching scan
      handlers.
      
      This allows the existing code duplication between ACPIPHP and the
      ACPI core to be reduced too and makes further ACPI-based device
      hotplug consolidation possible.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3c2cc7ff
  2. 06 2月, 2014 3 次提交
    • R
      ACPI / hotplug / PCI: Define hotplug context lock in the core · e525506f
      Rafael J. Wysocki 提交于
      Subsequent changes will require the ACPI core to acquire the lock
      protecting the ACPIPHP hotplug contexts, so move the definition of
      the lock to the core and change its name to be more generic.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      e525506f
    • R
      ACPI / hotplug: Fix potential race in acpi_bus_notify() · 78ea4639
      Rafael J. Wysocki 提交于
      There is a slight possibility for the ACPI device object pointed to
      by adev in acpi_hotplug_notify_cb() to become invalid between the
      acpi_bus_get_device() that it comes from and the subsequent dereference
      of that pointer under get_device().  Namely, if acpi_scan_drop_device()
      runs in parallel with acpi_hotplug_notify_cb(), acpi_device_del_work_fn()
      queued up by it may delete the device object in question right after
      a successful execution of acpi_bus_get_device() in acpi_bus_notify().
      
      An analogous problem is present in acpi_bus_notify() where the device
      pointer coming from acpi_bus_get_device() may become invalid before
      it subsequent dereference in the "if" block.
      
      To prevent that from happening, introduce a new function,
      acpi_bus_get_acpi_device(), working analogously to acpi_bus_get_device()
      except that it will grab a reference to the ACPI device object returned
      by it and it will do that under the ACPICA's namespace mutex.  Then,
      make both acpi_hotplug_notify_cb() and acpi_bus_notify() use
      acpi_bus_get_acpi_device() instead of acpi_bus_get_device() so as to
      ensure that the pointers used by them will not become stale at one
      point.
      
      In addition to that, introduce acpi_bus_put_acpi_device() as a wrapper
      around put_device() to be used along with acpi_bus_get_acpi_device()
      and make the (new) users of the latter use acpi_bus_put_acpi_device()
      too.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      78ea4639
    • R
      ACPICA: Introduce acpi_get_data_full() and rework acpi_get_data() · 7c2e1771
      Rafael J. Wysocki 提交于
      Introduce a new function, acpi_get_data_full(), working in analogy
      with acpi_get_data() except that it can execute a callback provided
      as its 4th argument right after acpi_ns_get_attached_data() has
      returned a success.
      
      That will allow Linux to reference count the object pointed to by
      *data before the namespace mutex is released so as to ensure that it
      will not be freed going forward until the reference to it acquired
      by acpi_get_data_full() is dropped.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      7c2e1771
  3. 29 1月, 2014 2 次提交
    • R
      ACPI / scan: Clear match_driver flag in acpi_bus_trim() · a951c773
      Rafael J. Wysocki 提交于
      Drivers should not bind to struct acpi_device objects that
      acpi_bus_trim() has been called for, so make that function
      clear flags.match_driver for those objects.
      
      If that is not done, an ACPI driver may theoretically try to operate
      a device that is not physically present.
      
      Fixes: 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      a951c773
    • M
      ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API · 49a12877
      Mark Brown 提交于
      There is currently no facility in ACPI to express the hookup of voltage
      regulators, the expectation is that the regulators that exist in the
      system will be handled transparently by firmware if they need software
      control at all. This means that if for some reason the regulator API is
      enabled on such a system it should assume that any supplies that devices
      need are provided by the system at all relevant times without any software
      intervention.
      
      Tell the regulator core to make this assumption by calling
      regulator_has_full_constraints(). Do this as soon as we know we are using
      ACPI so that the information is available to the regulator core as early
      as possible. This will cause the regulator core to pretend that there is
      an always on regulator supplying any supply that is requested but that has
      not otherwise been mapped which is the behaviour expected on a system with
      ACPI.
      
      Should the ability to specify regulators be added in future revisions of
      ACPI then once we have support for ACPI mappings in the kernel the same
      assumptions will apply. It is also likely that systems will default to a
      mode of operation which does not require any interpretation of these
      mappings in order to be compatible with existing operating system releases
      so it should remain safe to make these assumptions even if the mappings
      exist but are not supported by the kernel.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      49a12877
  4. 28 1月, 2014 4 次提交
  5. 18 1月, 2014 1 次提交
  6. 17 1月, 2014 2 次提交
    • Z
      ACPI: add module autoloading support for ACPI enumerated devices · 6eb2451f
      Zhang Rui 提交于
      An ACPI enumerated device may have its compatible id strings.
      
      To support the compatible ACPI ids (acpi_device->pnp.ids),
      we introduced acpi_driver_match_device() to match
      the driver->acpi_match_table and acpi_device->pnp.ids.
      
      For those drivers, MODULE_DEVICE_TABLE(acpi, xxx) is used to
      exports the driver module alias in the format of
      "acpi:device_compatible_ids".
      But in the mean time, the current code does not export the
      ACPI compatible strings as part of the module_alias for the
      ACPI enumerated devices, which will break the module autoloading.
      
      Take the following piece of code for example,
      static const struct acpi_device_id xxx_acpi_match[] = {
              { "INTABCD", 0 },
              { }
      };
      MODULE_DEVICE_TABLE(acpi, xxx_acpi_match);
      
      If this piece of code is used in a platform driver for
      an ACPI enumerated platform device, the platform driver module_alias
      is "acpi:INTABCD", but the uevent attribute of its platform device node
      is "platform:INTABCD:00" (PREFIX:platform_device->name).
      If this piece of code is used in an i2c driver for an ACPI enumerated
      i2c device, the i2c driver module_alias is "acpi:INTABCD", but
      the uevent of its i2c device node is "i2c:INTABCD:00" (PREFIX:i2c_client->name).
      If this piece of code is used in an spi driver for an ACPI enumerated
      spi device, the spi driver module_alias is "acpi:INTABCD", but
      the uevent of its spi device node is "spi:INTABCD" (PREFIX:spi_device->modalias).
      
      The reason why the module autoloading is not broken for now is that
      the uevent file of the ACPI device node is "acpi:INTABCD".
      Thus it is the ACPI device node creation that loads the platform/i2c/spi driver.
      
      So this is a problem that will affect us the day when the ACPI bus
      is removed from device model.
      
      This patch introduces two new APIs,
      one for exporting ACPI ids in uevent MODALIAS field,
      and another for exporting ACPI ids in device' modalias sysfs attribute.
      
      For any bus that supports ACPI enumerated devices, it needs to invoke
      these two functions for their uevent and modalias attribute.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6eb2451f
    • Z
      ACPI: fix create_modalias() return value handling · 3d8e0090
      Zhang Rui 提交于
      Currently, create_modalias() handles the output truncated case in
      an improper way (return -EINVAL).
      Plus, acpi_device_uevent() and acpi_device_modalias_show() do
      improper check for the create_modalias() return value as well.
      
      This patch fixes create_modalias() to
      return -EINVAL if there is an output error,
      return -ENOMEM if the output is truncated,
      and also fixes both acpi_device_uevent() and acpi_device_modalias_show()
      to do proper return value check.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3d8e0090
  7. 16 1月, 2014 1 次提交
    • P
      ACPI / memhotplug: add parameter to disable memory hotplug · 00159a20
      Prarit Bhargava 提交于
      When booting a kexec/kdump kernel on a system that has specific memory
      hotplug regions the boot will fail with warnings like:
      
       swapper/0: page allocation failure: order:9, mode:0x84d0
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-65.el7.x86_64 #1
       Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011
        0000000000000000 ffff8800341bd8c8 ffffffff815bcc67 ffff8800341bd950
        ffffffff8113b1a0 ffff880036339b00 0000000000000009 00000000000084d0
        ffff8800341bd950 ffffffff815b87ee 0000000000000000 0000000000000200
       Call Trace:
        [<ffffffff815bcc67>] dump_stack+0x19/0x1b
        [<ffffffff8113b1a0>] warn_alloc_failed+0xf0/0x160
        [<ffffffff815b87ee>] ?  __alloc_pages_direct_compact+0xac/0x196
        [<ffffffff8113f14f>] __alloc_pages_nodemask+0x7ff/0xa00
        [<ffffffff815b417c>] vmemmap_alloc_block+0x62/0xba
        [<ffffffff815b41e9>] vmemmap_alloc_block_buf+0x15/0x3b
        [<ffffffff815b1ff6>] vmemmap_populate+0xb4/0x21b
        [<ffffffff815b461d>] sparse_mem_map_populate+0x27/0x35
        [<ffffffff815b400f>] sparse_add_one_section+0x7a/0x185
        [<ffffffff815a1e9f>] __add_pages+0xaf/0x240
        [<ffffffff81047359>] arch_add_memory+0x59/0xd0
        [<ffffffff815a21d9>] add_memory+0xb9/0x1b0
        [<ffffffff81333b9c>] acpi_memory_device_add+0x18d/0x26d
        [<ffffffff81309a01>] acpi_bus_device_attach+0x7d/0xcd
        [<ffffffff8132379d>] acpi_ns_walk_namespace+0xc8/0x17f
        [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90
        [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90
        [<ffffffff81323c8c>] acpi_walk_namespace+0x95/0xc5
        [<ffffffff8130a6d6>] acpi_bus_scan+0x8b/0x9d
        [<ffffffff81a2019a>] acpi_scan_init+0x63/0x160
        [<ffffffff81a1ffb5>] acpi_init+0x25d/0x2a6
        [<ffffffff81a1fd58>] ? acpi_sleep_proc_init+0x2a/0x2a
        [<ffffffff810020e2>] do_one_initcall+0xe2/0x190
        [<ffffffff819e20c4>] kernel_init_freeable+0x17c/0x207
        [<ffffffff819e18d0>] ? do_early_param+0x88/0x88
        [<ffffffff8159fea0>] ? rest_init+0x80/0x80
        [<ffffffff8159feae>] kernel_init+0xe/0x180
        [<ffffffff815cca2c>] ret_from_fork+0x7c/0xb0
        [<ffffffff8159fea0>] ? rest_init+0x80/0x80
       Mem-Info:
       Node 0 DMA per-cpu:
       CPU    0: hi:    0, btch:   1 usd:   0
       Node 0 DMA32 per-cpu:
       CPU    0: hi:   42, btch:   7 usd:   0
       active_anon:0 inactive_anon:0 isolated_anon:0
        active_file:0 inactive_file:0 isolated_file:0
        unevictable:0 dirty:0 writeback:0 unstable:0
        free:872 slab_reclaimable:13 slab_unreclaimable:1880
        mapped:0 shmem:0 pagetables:0 bounce:0
        free_cma:0
      
      because the system has run out of memory at boot time.  This occurs
      because of the following sequence in the boot:
      
      Main kernel boots and sets E820 map.  The second kernel is booted with a
      map generated by the kdump service using memmap= and memmap=exactmap.
      These parameters are added to the kernel parameters of the kexec/kdump
      kernel.   The kexec/kdump kernel has limited memory resources so as not
      to severely impact the main kernel.
      
      The system then panics and the kdump/kexec kernel boots (which is a
      completely new kernel boot).  During this boot ACPI is initialized and the
      kernel (as can be seen above) traverses the ACPI namespace and finds an
      entry for a memory device to be hotadded.
      
      ie)
      
        [<ffffffff815a1e9f>] __add_pages+0xaf/0x240
        [<ffffffff81047359>] arch_add_memory+0x59/0xd0
        [<ffffffff815a21d9>] add_memory+0xb9/0x1b0
        [<ffffffff81333b9c>] acpi_memory_device_add+0x18d/0x26d
        [<ffffffff81309a01>] acpi_bus_device_attach+0x7d/0xcd
        [<ffffffff8132379d>] acpi_ns_walk_namespace+0xc8/0x17f
        [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90
        [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90
        [<ffffffff81323c8c>] acpi_walk_namespace+0x95/0xc5
        [<ffffffff8130a6d6>] acpi_bus_scan+0x8b/0x9d
        [<ffffffff81a2019a>] acpi_scan_init+0x63/0x160
        [<ffffffff81a1ffb5>] acpi_init+0x25d/0x2a6
      
      At this point the kernel adds page table information and the the kexec/kdump
      kernel runs out of memory.
      
      This can also be reproduced by using the memmap=exactmap and mem=X
      parameters on the main kernel and booting.
      
      This patchset resolves the problem by adding a kernel parameter,
      acpi_no_memhotplug, to disable ACPI memory hotplug.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Acked-by: NVivek Goyal <vgoyal@redhat.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      00159a20
  8. 15 1月, 2014 1 次提交
  9. 11 1月, 2014 5 次提交
  10. 08 1月, 2014 16 次提交
  11. 07 1月, 2014 1 次提交
  12. 06 1月, 2014 2 次提交