1. 16 9月, 2009 2 次提交
    • G
      Driver core: move dev_get/set_drvdata to drivers/base/dd.c · b4028437
      Greg Kroah-Hartman 提交于
      No one should directly access the driver_data field, so remove the field
      and make it private.  We dynamically create the private field now if it
      is needed, to handle drivers that call get/set before they are
      registered with the driver core.
      
      Also update the copyright notices on these files while we are there.
      
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b4028437
    • A
      Driver core: add new device to bus's list before probing · 2023c610
      Alan Stern 提交于
      This patch (as1271) affects when new devices get linked into their
      bus's list of devices.  Currently this happens after probing, and it
      doesn't happen at all if probing fails.  Clearly this is wrong,
      because at that point quite a few symbolic links have already been
      created in sysfs.  We are committed to adding the device, so it should
      be linked into the bus's list regardless.
      
      In addition, this needs to happen before the uevent announcing the new
      device gets issued.  Otherwise user programs might try to access the
      device before it has been added to the bus.
      
      To fix both these problems, the patch moves the call to
      klist_add_tail() forward from bus_attach_device() to bus_add_device().
      Since bus_attach_device() now does nothing but probe for drivers, it
      has been renamed to bus_probe_device().  And lastly, the kerneldoc is
      updated.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      
      
      2023c610
  2. 15 9月, 2009 2 次提交
  3. 23 8月, 2009 2 次提交
  4. 11 8月, 2009 1 次提交
    • M
      PM / Driver Core: Kill dev_pm_ops platform warning for now · 651b1f12
      Magnus Damm 提交于
      Commit 783ea7d4
      (Driver Core: Rework platform suspend/resume, print warning)
      added a warning message printed for platform drivers that use the
      legacy PM callbacks rather than struct dev_pm_ops.  Unfortunately,
      this resulted in some confusion and made some people try to convert
      drivers by replacing the old callbacks with struct dev_pm_ops in
      automatic way, which generally is not a good idea.
      
      Remove the platform device runtime dev_pm_ops warning for now,
      because it's annoying to users and it's not really necessary right
      now.
      
      [rjw: Modified the changelog to be more informative.]
      Signed-off-by: NMagnus Damm <damm@igel.co.jp>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      651b1f12
  5. 29 7月, 2009 2 次提交
  6. 25 7月, 2009 1 次提交
  7. 24 7月, 2009 1 次提交
  8. 22 7月, 2009 1 次提交
  9. 13 7月, 2009 2 次提交
  10. 09 7月, 2009 1 次提交
  11. 08 7月, 2009 1 次提交
  12. 17 6月, 2009 1 次提交
  13. 16 6月, 2009 10 次提交
  14. 13 6月, 2009 7 次提交
  15. 29 5月, 2009 1 次提交
  16. 25 5月, 2009 1 次提交
    • R
      PM: Do not hold dpm_list_mtx while disabling/enabling nonboot CPUs · 32bdfac5
      Rafael J. Wysocki 提交于
      We shouldn't hold dpm_list_mtx while executing
      [disable|enable]_nonboot_cpus(), because theoretically this may lead
      to a deadlock as shown by the following example (provided by Johannes
      Berg):
      
      CPU 3       CPU 2                     CPU 1
                                            suspend/hibernate
                  something:
                  rtnl_lock()               device_pm_lock()
                                             -> mutex_lock(&dpm_list_mtx)
      
                  mutex_lock(&dpm_list_mtx)
      
      linkwatch_work
       -> rtnl_lock()
                                            disable_nonboot_cpus()
                                             -> flush CPU 3 workqueue
      
      Fortunately, device drivers are supposed to stop any activities that
      might lead to the registration of new device objects way before
      disable_nonboot_cpus() is called, so it shouldn't be necessary to
      hold dpm_list_mtx over the entire late part of device suspend and
      early part of device resume.
      
      Thus, during the late suspend and the early resume of devices acquire
      dpm_list_mtx only when dpm_list is going to be traversed and release
      it right after that.
      
      This patch is reported to fix the regressions tracked as
      http://bugzilla.kernel.org/show_bug.cgi?id=13245.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NMiles Lane <miles.lane@gmail.com>
      Tested-by: NMing Lei <tom.leiming@gmail.com>
      32bdfac5
  17. 15 5月, 2009 1 次提交
    • D
      firmware: speed up request_firmware(), v3 · 6e03a201
      David Woodhouse 提交于
      Rather than calling vmalloc() repeatedly to grow the firmware image as
      we receive data from userspace, just allocate and fill individual pages.
      Then vmap() the whole lot in one go when we're done.
      
      A quick test with a 337KiB iwlagn firmware shows the time taken for
      request_firmware() going from ~32ms to ~5ms after I apply this patch.
      
      [v2: define PAGE_KERNEL_RO as PAGE_KERNEL where necessary, use min_t()]
      [v3: kunmap() takes the struct page *, not the virtual address]
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Tested-by: NSachin Sant <sachinp@in.ibm.com>
      6e03a201
  18. 09 5月, 2009 3 次提交
    • G
      Revert driver core: move platform_data into platform_device · e67c8562
      Greg Kroah-Hartman 提交于
      This reverts commit 006f4571:
      
      	This patch moves platform_data from struct device into
      	struct platform_device, based on the two ideas:
      
      	1. Now all platform_driver is registered by platform_driver_register,
      	   which makes probe()/release()/... of platform_driver passed parameter
      	   of platform_device *, so platform driver can get platform_data from
      	   platform_device;
      
      	2. Other kind of devices do not need to use platform_data, we can
      	   decrease size of device if moving it to platform_device.
      
      	Taking into consideration of thousands of files to be fixed and they
      	can't be finished in one night(maybe it will take a long time), so we
      	keep platform_data in device to allow two kind of cases coexist until
      	all platform devices pass its platfrom data from
      	platform_device->platform_data.
      
      	All patches to do this kind of conversion are welcome.
      
      As we don't really want to do it, it was a bad idea.
      
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Ming Lei <tom.leiming@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      e67c8562
    • M
      Revert driver core: fix passing platform_data · bee86321
      Ming Lei 提交于
      This reverts commit ce21c7bc:
      	We will remove platform_data field from struct device until
      	all platform devices pass its specific data from platfom_device
      	and all platform drivers use platform specific data passed by
      	platform_device->platform_data. This kind of conversion will
      	need a long time, for thousands of files is affected.
      
      	To make the conversion easily, we allow platform specific data
      	passed by struct device or struct platform_device and platform
      	driver may use it from struct device or struct platform_device.
      
      As we really don't want to do this at all.
      
      
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Ming Lei <tom.leiming@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bee86321
    • R
      Driver core: platform: fix kernel-doc warnings · d86c1302
      Randy Dunlap 提交于
      Fix function parameter notation in platform.c;
      fixes kernel-doc warnings.
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d86c1302