1. 09 3月, 2012 2 次提交
    • G
      drivercore: Add driver probe deferral mechanism · d1c3414c
      Grant Likely 提交于
      Allow drivers to report at probe time that they cannot get all the resources
      required by the device, and should be retried at a later time.
      
      This should completely solve the problem of getting devices
      initialized in the right order.  Right now this is mostly handled by
      mucking about with initcall ordering which is a complete hack, and
      doesn't even remotely handle the case where device drivers are in
      modules.  This approach completely sidesteps the issues by allowing
      driver registration to occur in any order, and any driver can request
      to be retried after a few more other drivers get probed.
      
      v4: - Integrate Manjunath's addition of a separate workqueue
          - Change -EAGAIN to -EPROBE_DEFER for drivers to trigger deferral
          - Update comment blocks to reflect how the code really works
      v3: - Hold off workqueue scheduling until late_initcall so that the bulk
            of driver probes are complete before we start retrying deferred devices.
          - Tested with simple use cases.  Still needs more testing though.
            Using it to get rid of the gpio early_initcall madness, or to replace
            the ASoC internal probe deferral code would be ideal.
      v2: - added locking so it should no longer be utterly broken in that regard
          - remove device from deferred list at device_del time.
          - Still completely untested with any real use case, but has been
            boot tested.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Dilan Lee <dilee@nvidia.com>
      Cc: Manjunath GKondaiah <manjunath.gkondaiah@linaro.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1c3414c
    • R
  2. 25 2月, 2012 3 次提交
  3. 16 2月, 2012 2 次提交
  4. 14 2月, 2012 3 次提交
  5. 11 2月, 2012 1 次提交
    • L
      drivers/base: add bus for System-on-Chip devices · 74d1d82c
      Lee Jones 提交于
      Traditionally, any System-on-Chip based platform creates a flat list
      of platform_devices directly under /sys/devices/platform.
      
      In order to give these some better structure, this introduces a new
      bus type for soc_devices that are registered with the new
      soc_device_register() function.  All devices that are on the same
      chip should then be registered as child devices of the soc device.
      
      The soc bus also exports a few standardised device attributes which
      allow user space to query the specific type of soc.
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      74d1d82c
  6. 10 2月, 2012 4 次提交
  7. 09 2月, 2012 1 次提交
    • Y
      ACPI: remove duplicated lines of merging problems with acpi_processor_start · 976a0be0
      Yinghai Lu 提交于
      When checking driver-core tree, found crazying warnings on my setups.
      
      [  216.025849] calling  acpi_processor_init+0x0/0x81 @ 1
      [  216.045332] ACPI: Requesting acpi_cpufreq
      [  216.047454] Monitor-Mwait will be used to enter C-1 state
      [  216.047912] Monitor-Mwait will be used to enter C-3 state
      [  216.065270] ACPI: acpi_idle registered with cpuidle
      [  216.068241] kobject (ffff8870364a1940): tried to init an initialized object, something is seriously wrong.
      [  216.085287] Pid: 1, comm: swapper/0 Not tainted 3.3.0-rc2-tip-yh-02428-ge663840-dirty #247
      [  216.105041] Call Trace:
      [  216.105192]  [<ffffffff813a9c06>] kobject_init+0x33/0x83
      [  216.124880]  [<ffffffff813aa1f8>] kobject_init_and_add+0x23/0x57
      [  216.125158]  [<ffffffff819f3a08>] cpuidle_add_sysfs+0x49/0x62
      [  216.144850]  [<ffffffff819f2a28>] __cpuidle_register_device+0xe6/0x10e
      [  216.145182]  [<ffffffff819f2ea4>] cpuidle_register_device+0x25/0x4d
      [  216.164912]  [<ffffffff81cb5774>] acpi_processor_power_init+0x13e/0x16c
      [  216.165205]  [<ffffffff81427620>] ? acpi_processor_get_throttling_info+0x128/0x158
      [  216.185012]  [<ffffffff81c68ae5>] acpi_processor_start+0x62/0x11d
      [  216.204861]  [<ffffffff81cb55ff>] acpi_processor_add+0x1b0/0x1e7
      [  216.205144]  [<ffffffff81402a7e>] acpi_device_probe+0x4e/0x11c
      [  216.225063]  [<ffffffff8148f0e7>] really_probe+0x99/0x126
      [  216.225328]  [<ffffffff8148f2a3>] driver_probe_device+0x3b/0x56
      [  216.244846]  [<ffffffff8148f31d>] __driver_attach+0x5f/0x82
      [  216.245101]  [<ffffffff8148f2be>] ? driver_probe_device+0x56/0x56
      [  216.264668]  [<ffffffff8148db80>] bus_for_each_dev+0x5c/0x88
      [  216.264942]  [<ffffffff8148eea7>] driver_attach+0x1e/0x20
      [  216.284639]  [<ffffffff8148eaec>] bus_add_driver+0xca/0x21d
      [  216.284903]  [<ffffffff81095827>] ? local_clock+0xf/0x3c
      [  216.304580]  [<ffffffff82814177>] ? acpi_fan_init+0x18/0x18
      [  216.304849]  [<ffffffff8148f79b>] driver_register+0x91/0xfe
      [  216.324545]  [<ffffffff82814177>] ? acpi_fan_init+0x18/0x18
      [  216.324813]  [<ffffffff81403705>] acpi_bus_register_driver+0x43/0x45
      [  216.344563]  [<ffffffff828141a7>] acpi_processor_init+0x30/0x81
      [  216.344845]  [<ffffffff82814177>] ? acpi_fan_init+0x18/0x18
      [  216.364590]  [<ffffffff810001e7>] do_one_initcall+0x57/0x134
      [  216.364868]  [<ffffffff827e6f8c>] kernel_init+0x146/0x1c0
      [  216.384512]  [<ffffffff81d03aa4>] kernel_thread_helper+0x4/0x10
      [  216.384819]  [<ffffffff81cfbb5d>] ? retint_restore_args+0xe/0xe
      [  216.404578]  [<ffffffff827e6e46>] ? start_kernel+0x3ab/0x3ab
      [  216.424530]  [<ffffffff81d03aa0>] ? gs_change+0xb/0xb
      [  216.424793] ------------[ cut here ]------------
      [  216.425038] WARNING: at fs/sysfs/dir.c:502 sysfs_add_one+0x97/0xab()
      [  216.444480] Hardware name: Sun Fire X4800
      [  216.444668] sysfs: cannot create duplicate filename '/devices/system/cpu/cpu0/cpuidle'
      ...
      
      It turns out acpi_processor_power_init() get called two time in acpi_processor_add and acpi_processor_start.
      
      Found several lines are duplicated in those two functions even related commit move them.
      
      The related patches are ok.  Not sure how it could happen, looks like git problem.
      
      -v2: add back acpi_processor_load_module(pr) to acpi_processor_load_start
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NThomas Renninger <trenn@suse.de>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      976a0be0
  8. 03 2月, 2012 3 次提交
  9. 30 1月, 2012 6 次提交
  10. 28 1月, 2012 4 次提交
  11. 27 1月, 2012 11 次提交