1. 11 2月, 2014 5 次提交
  2. 05 2月, 2014 5 次提交
  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 14 次提交