1. 04 6月, 2013 1 次提交
  2. 30 3月, 2013 1 次提交
  3. 18 1月, 2013 1 次提交
  4. 21 11月, 2012 1 次提交
    • R
      ACPI / platform: Initialize ACPI handles of platform devices in advance · 863f9f30
      Rafael J. Wysocki 提交于
      The current platform device creation and registration code in
      acpi_create_platform_device() is quite convoluted.  This function
      takes an ACPI device node as an argument and eventually calls
      platform_device_register_resndata() to create and register a
      platform device object on the basis of the information contained
      in that code.  However, it doesn't associate the new platform
      device with the ACPI node directly, but instead it relies on
      acpi_platform_notify(), called from within device_add(), to find
      that ACPI node again with the help of acpi_platform_find_device()
      and acpi_platform_match() and then attach the new platform device
      to it.  This causes an additional ACPI namespace walk to happen and
      is clearly suboptimal.
      
      Use the observation that it is now possible to initialize the ACPI
      handle of a device before calling device_add() for it to make this
      code more straightforward.  Namely, add a new field to struct
      platform_device_info allowing us to pass the ACPI handle of interest
      to platform_device_register_full(), which will then use it to
      initialize the new device's ACPI handle before registering it.
      This will cause acpi_platform_notify() to use the ACPI handle from
      the device structure directly instead of using the .find_device()
      routine provided by the device's bus type.  In consequence,
      acpi_platform_bus, acpi_platform_find_device(), and
      acpi_platform_match() are not necessary any more, so remove them.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      863f9f30
  5. 17 8月, 2012 1 次提交
    • J
      platform: Add support for automatic device IDs · 689ae231
      Jean Delvare 提交于
      Right now we have support for explicit platform device IDs, as well as
      ID-less platform devices when a given device type can only have one
      instance. However there are cases where multiple instances of a device
      type can exist, and their IDs aren't (and can't be) known in advance
      and do not matter. In that case we need automatic device IDs to avoid
      device name collisions.
      
      I am using magic ID value -2 (PLATFORM_DEVID_AUTO) for this, similar
      to -1 for ID-less devices. The automatically allocated device IDs are
      global (to avoid an additional per-driver cost.) We keep note that the
      ID was automatically allocated so that it can be freed later.
      
      Note that we also restore the ID to PLATFORM_DEVID_AUTO on error and
      device deletion, to avoid avoid unexpected behavior on retry. I don't
      really expect retries on platform device addition, but better safe
      than sorry.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      689ae231
  6. 22 12月, 2011 1 次提交
  7. 10 12月, 2011 1 次提交
  8. 18 11月, 2011 1 次提交
  9. 25 10月, 2011 1 次提交
  10. 27 8月, 2011 1 次提交
  11. 08 7月, 2011 1 次提交
  12. 17 5月, 2011 1 次提交
  13. 29 4月, 2011 1 次提交
  14. 12 4月, 2011 1 次提交
  15. 19 2月, 2011 1 次提交
  16. 23 10月, 2010 1 次提交
    • K
      driver core: platform_bus: allow runtime override of dev_pm_ops · c64a0926
      Kevin Hilman 提交于
      Currently, the platform_bus allows customization of several of the
      busses dev_pm_ops methods by using weak symbols so that platform code
      can override them.  The weak-symbol approach is not scalable when
      wanting to support multiple platforms in a single kernel binary.
      
      Instead, provide __init methods for platform code to customize the
      dev_pm_ops methods at runtime.
      
      NOTE: after these dynamic methods are merged, the weak symbols should
            be removed from drivers/base/platform.c.  AFAIK, this will only
            affect SH and sh-mobile which should be converted to use this
            runtime approach instead of the weak symbols.  After SH &
            sh-mobile are converted, the weak symobols could be removed.
      
      Tested on OMAP3.
      
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c64a0926
  17. 06 8月, 2010 1 次提交
  18. 18 5月, 2010 1 次提交
  19. 08 3月, 2010 3 次提交
  20. 12 12月, 2009 1 次提交
    • M
      Driver Core: Early platform driver buffer · c60e0504
      Magnus Damm 提交于
      Add early_platform_init_buffer() support and update the
      early platform driver code to allow passing parameters
      to the driver on the kernel command line.
      
      early_platform_init_buffer() simply allows early platform
      drivers to provide a pointer and length to a memory area
      where the remaining part of the kernel command line option
      will be stored.
      
      Needed to pass baud rate and other serial port options
      to the reworked early serial console code on SuperH.
      Signed-off-by: NMagnus Damm <damm@opensource.se>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c60e0504
  21. 22 7月, 2009 2 次提交
  22. 16 6月, 2009 1 次提交
  23. 09 5月, 2009 1 次提交
    • 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
  24. 17 4月, 2009 1 次提交
    • M
      Driver Core: early platform driver · 13977091
      Magnus Damm 提交于
      V3 of the early platform driver implementation.
      
      Platform drivers are great for embedded platforms because we can separate
      driver configuration from the actual driver.  So base addresses,
      interrupts and other configuration can be kept with the processor or board
      code, and the platform driver can be reused by many different platforms.
      
      For early devices we have nothing today.  For instance, to configure early
      timers and early serial ports we cannot use platform devices.  This
      because the setup order during boot.  Timers are needed before the
      platform driver core code is available.  The same goes for early printk
      support.  Early in this case means before initcalls.
      
      These early drivers today have their configuration either hard coded or
      they receive it using some special configuration method.  This is working
      quite well, but if we want to support both regular kernel modules and
      early devices then we need to have two ways of configuring the same
      driver.  A single way would be better.
      
      The early platform driver patch is basically a set of functions that allow
      drivers to register themselves and architecture code to locate them and
      probe.  Registration happens through early_param().  The time for the
      probe is decided by the architecture code.
      
      See Documentation/driver-model/platform.txt for more details.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NMagnus Damm <damm@igel.co.jp>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Tejun Heo <htejun@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      13977091
  25. 25 3月, 2009 2 次提交
    • M
      driver core: move platform_data into platform_device · 006f4571
      Ming Lei 提交于
      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.
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      006f4571
    • E
      platform: introduce module id table for platform devices · 57fee4a5
      Eric Miao 提交于
      Now platform_device is being widely used on SoC processors where the
      peripherals are attached to the system bus, which is simple enough.
      
      However, silicon IPs for these SoCs are usually shared heavily across
      a family of processors, even products from different companies.  This
      makes the original simple driver name based matching insufficient, or
      simply not straight-forward.
      
      Introduce a module id table for platform devices, and makes it clear
      that a platform driver is able to support some shared IP and handle
      slight differences across different platforms (by 'driver_data').
      Module alias is handled automatically when a MODULE_DEVICE_TABLE()
      is defined.
      
      To not disturb the current platform drivers too much, the matched id
      entry is recorded and can be retrieved by platform_get_device_id().
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      57fee4a5
  26. 07 1月, 2009 1 次提交
    • R
      PM: Simplify the new suspend/hibernation framework for devices · adf09493
      Rafael J. Wysocki 提交于
      PM: Simplify the new suspend/hibernation framework for devices
      
      Following the discussion at the Kernel Summit, simplify the new
      device PM framework by merging 'struct pm_ops' and
      'struct pm_ext_ops' and removing pointers to 'struct pm_ext_ops'
      from 'struct platform_driver' and 'struct pci_driver'.
      
      After this change, the suspend/hibernation callbacks will only
      reside in 'struct device_driver' as well as at the bus type/
      device class/device type level.  Accordingly, PCI and platform
      device drivers are now expected to put their suspend/hibernation
      callbacks into the 'struct device_driver' embedded in
      'struct pci_driver' or 'struct platform_driver', respectively.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      adf09493
  27. 17 10月, 2008 1 次提交
  28. 11 6月, 2008 1 次提交
  29. 25 1月, 2008 1 次提交
  30. 13 10月, 2007 1 次提交
  31. 14 12月, 2006 1 次提交
  32. 02 12月, 2006 1 次提交
    • D
      Driver core: platform_driver_probe(), can save codespace · c67334fb
      David Brownell 提交于
      This defines a new platform_driver_probe() method allowing the driver's
      probe() method, and its support code+data, to safely live in __init
      sections for typical system configurations.
      
      Many system-on-chip processors could benefit from this API, to the tune
      of recovering hundreds to thousands of bytes per driver.  That's memory
      which is currently wasted holding code which can never be called after
      system startup, yet can not be removed.   It can't be removed because of
      the linkage requirement that pointers to init section code (like, ideally,
      probe support) must not live in other sections (like driver method tables)
      after those pointers would be invalid.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c67334fb
  33. 26 9月, 2006 1 次提交
  34. 05 1月, 2006 1 次提交
  35. 10 11月, 2005 1 次提交
    • R
      [DRIVER MODEL] Add platform_driver · 00d3dcdd
      Russell King 提交于
      Introduce struct platform_driver.  This allows the platform device
      driver methods to be passed a platform_device structure instead of
      instead of a plain device structure, and therefore requiring casting
      in every platform driver.
      
      We introduce this in such a way that any existing platform drivers
      registered directly via driver_register continue to work as before,
      thereby allowing a gradual conversion to the new platform_driver
      methods.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      00d3dcdd
  36. 06 11月, 2005 1 次提交