1. 17 6月, 2015 1 次提交
    • P
      platform_device: better support builtin boilerplate avoidance · f309d444
      Paul Gortmaker 提交于
      We have macros that help reduce the boilerplate for modules
      that register with no extra init/exit complexity other than the
      most standard use case.  However we see an increasing number of
      non-modular drivers using these modular_driver() type register
      functions.
      
      There are several downsides to this:
      1) The code can appear modular to a reader of the code, and they
         won't know if the code really is modular without checking the
         Makefile and Kconfig to see if compilation is governed by a
         bool or tristate.
      2) Coders of drivers may be tempted to code up an __exit function
         that is never used, just in order to satisfy the required three
         args of the modular registration function.
      3) Non-modular code ends up including the <module.h> which increases
         CPP overhead that they don't need.
      4) It hinders us from performing better separation of the module
         init code and the generic init code.
      
      Here we introduce similar macros, with the mapping from module_driver
      to builtin_driver and similar, so that simple changes of:
      
        module_platform_driver()       --->  builtin_platform_driver()
        module_platform_driver_probe() --->  builtin_platform_driver_probe().
      
      can help us avoid #3 above, without having to code up the same
      __init functions and device_initcall() boilerplate.
      
      For non modular code, module_init becomes __initcall.  But direct use
      of __initcall is discouraged, vs. one of the priority categorized
      subgroups.  As __initcall gets mapped onto device_initcall, our
      use of device_initcall directly in this change means that the
      runtime impact is zero -- drivers will remain at level 6 in the
      initcall ordering.
      
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      f309d444
  2. 17 3月, 2015 1 次提交
  3. 07 11月, 2014 2 次提交
  4. 09 7月, 2014 1 次提交
  5. 27 9月, 2013 1 次提交
    • J
      driver core: prevent deferred probe with platform_driver_probe · 3f9120b0
      Johan Hovold 提交于
      Prevent drivers relying on platform_driver_probe from requesting
      deferred probing in order to avoid further futile probe attempts (either
      the driver has been unregistered or its probe function has been set to
      platform_drv_probe_fail when probing is retried).
      
      Note that several platform drivers currently return subsystem errors
      from probe and that these can include -EPROBE_DEFER (e.g. if a gpio
      request fails).
      
      Add a warning to platform_drv_probe that can be used to catch drivers
      that inadvertently request probe deferral while using
      platform_driver_probe.
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f9120b0
  6. 12 6月, 2013 1 次提交
  7. 04 6月, 2013 1 次提交
  8. 30 3月, 2013 1 次提交
  9. 18 1月, 2013 1 次提交
  10. 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
  11. 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
  12. 22 12月, 2011 1 次提交
  13. 10 12月, 2011 1 次提交
  14. 18 11月, 2011 1 次提交
  15. 25 10月, 2011 1 次提交
  16. 27 8月, 2011 1 次提交
  17. 08 7月, 2011 1 次提交
  18. 17 5月, 2011 1 次提交
  19. 29 4月, 2011 1 次提交
  20. 12 4月, 2011 1 次提交
  21. 19 2月, 2011 1 次提交
  22. 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
  23. 06 8月, 2010 1 次提交
  24. 18 5月, 2010 1 次提交
  25. 08 3月, 2010 3 次提交
  26. 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
  27. 22 7月, 2009 2 次提交
  28. 16 6月, 2009 1 次提交
  29. 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
  30. 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
  31. 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
  32. 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
  33. 17 10月, 2008 1 次提交
  34. 11 6月, 2008 1 次提交
  35. 25 1月, 2008 1 次提交