History log of /openbmc/linux/drivers/base/platform.c (Results 151 – 175 of 503)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v3.7-rc3, v3.7-rc2, v3.7-rc1, v3.6, v3.6-rc7, v3.6-rc6, v3.6-rc5, v3.6-rc4
# 1b8cb929 23-Aug-2012 Peter Ujfalusi <peter.ujfalusi@ti.com>

driver core: Check if r->name is valid in platform_get_resource_byname()

Safety check for the validity of the resource name before calling strcmp().
If the resource name is NULL do not compare it, j

driver core: Check if r->name is valid in platform_get_resource_byname()

Safety check for the validity of the resource name before calling strcmp().
If the resource name is NULL do not compare it, just skip it.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


Revision tags: v3.6-rc3, v3.6-rc2
# bed2b42d 05-Aug-2012 Rafael J. Wysocki <rjw@sisk.pl>

PM / Runtime: Allow helpers to be called by early platform drivers

Runtime PM helper functions, like pm_runtime_get_sync(), cannot be
called by early platform device drivers, because the devices' po

PM / Runtime: Allow helpers to be called by early platform drivers

Runtime PM helper functions, like pm_runtime_get_sync(), cannot be
called by early platform device drivers, because the devices' power
management locks are not initialized at that time. This is quite
inconvenient, so modify early_platform_add_devices() to initialize
the devices power management locks as appropriate and make sure that
they won't be initialized more than once if an early platform
device is going to be used as a regular one later.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

show more ...


Revision tags: v3.6-rc1
# 689ae231 27-Jul-2012 Jean Delvare <khali@linux-fr.org>

platform: Add support for automatic device IDs

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. Ho

platform: Add support for automatic device IDs

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: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


Revision tags: v3.5, v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4, v3.5-rc3, v3.5-rc2, v3.5-rc1, v3.4, v3.4-rc7, v3.4-rc6, v3.4-rc5, v3.4-rc4, v3.4-rc3, v3.4-rc2, v3.4-rc1, v3.3, v3.3-rc7, v3.3-rc6, v3.3-rc5, v3.3-rc4, v3.3-rc3
# 07d57a32 01-Feb-2012 Grant Likely <grant.likely@secretlab.ca>

drivercore: Output common devicetree information in uevent

When userspace needs to find a specific device, it currently isn't easy to
resolve a /sys/devices/ path from a specific device tree node.

drivercore: Output common devicetree information in uevent

When userspace needs to find a specific device, it currently isn't easy to
resolve a /sys/devices/ path from a specific device tree node. Nor is it
easy to obtain the compatible list for devices.

This patch generalizes the code that inserts OF_* values into the uevent
device attribute so that any device that is attached to an OF node will
have that information exported to userspace. Without this patch only
platform devices and some powerpc-specific busses have access to this
data.

The original function also creates a MODALIAS property for the compatible
list, but that code has not been generalized into the common case because
it has the potential to break module loading on a lot of bus types. Bus
types are still responsible for their own MODALIAS properties.

Boot tested on ARM and compile tested on PowerPC and SPARC.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tobias Klauser <tklauser@distanz.ch>
Cc: Frederic Lambert <frdrc66@gmail.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Mark Brown <broonie@sirena.org.uk>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


Revision tags: v3.3-rc2, v3.3-rc1, v3.2, v3.2-rc7
# 9b39e73d 17-Dec-2011 Rafael J. Wysocki <rjw@sisk.pl>

PM / Sleep: Remove forward-only callbacks from platform bus type

The forward-only PM callbacks provided by the platform bus type are
not necessary any more, because the PM core executes driver callb

PM / Sleep: Remove forward-only callbacks from platform bus type

The forward-only PM callbacks provided by the platform bus type are
not necessary any more, because the PM core executes driver callbacks
when the corresponding subsystem callbacks are not present, so drop
them.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

show more ...


Revision tags: v3.2-rc6, v3.2-rc5
# 5a3072be 08-Dec-2011 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

drivers_base: make argument to platform_device_register_full const

platform_device_register_full doesn't modify *pdevinfo so it can be
marked as const without further adaptions.

Signed-off-by: Uwe

drivers_base: make argument to platform_device_register_full const

platform_device_register_full doesn't modify *pdevinfo so it can be
marked as const without further adaptions.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


Revision tags: v3.2-rc4, v3.2-rc3, v3.2-rc2, v3.2-rc1, v3.1, v3.1-rc10, v3.1-rc9, v3.1-rc8, v3.1-rc7, v3.1-rc6, v3.1-rc5, v3.1-rc4
# 01dcc60a 25-Aug-2011 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

new helper to create platform devices with dma mask

compared to the most powerful and already existing helper (namely
platform_device_register_resndata) this allows to specify a dma_mask.
To make ev

new helper to create platform devices with dma mask

compared to the most powerful and already existing helper (namely
platform_device_register_resndata) this allows to specify a dma_mask.
To make eventual extensions later more easy, a struct holding the used
information is created instead of passing the information by function
parameters.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


Revision tags: v3.1-rc3
# 0a26813c 15-Aug-2011 Sebastian Andrzej Siewior <bigeasy@linutronix.de>

drivers_base: platform: use always ->name for uevent

If id_entry is available then it is used. However if we remove first the
driver followed by the device, then the id_entry is pointing to driver's

drivers_base: platform: use always ->name for uevent

If id_entry is available then it is used. However if we remove first the
driver followed by the device, then the id_entry is pointing to driver's
memory which is long gone.
Since id->name and plat->name are equal there is no point in
distinguishing them.

Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


Revision tags: v3.1-rc2, v3.1-rc1
# 7de636fa 27-Jul-2011 Randy Dunlap <rdunlap@xenotime.net>

driver core: fix kernel-doc warning in platform.c

Warning(drivers/base/platform.c:50): No description found for parameter 'pdev'
Warning(drivers/base/platform.c:50): Excess function parameter 'dev'

driver core: fix kernel-doc warning in platform.c

Warning(drivers/base/platform.c:50): No description found for parameter 'pdev'
Warning(drivers/base/platform.c:50): Excess function parameter 'dev' description in 'arch_setup_pdev_archdata'

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


Revision tags: v3.0, v3.0-rc7, v3.0-rc6, v3.0-rc5, v3.0-rc4, v3.0-rc3
# a77ce816 10-Jun-2011 Kumar Gala <galak@kernel.crashing.org>

driver core: Add ability for arch code to setup pdev_archdata

On some architectures we need to setup pdev_archdata before we add the
device. Waiting til a bus_notifier is too late since we might ne

driver core: Add ability for arch code to setup pdev_archdata

On some architectures we need to setup pdev_archdata before we add the
device. Waiting til a bus_notifier is too late since we might need the
pdev_archdata in the bus notifier. One example is setting up of dma_mask
pointers such that it can be used in a bus_notifier.

We add weak noop version of arch_setup_pdev_archdata() and allow the arch
code to override with access the full definitions of struct device,
struct platform_device, and struct pdev_archdata.

Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

show more ...


Revision tags: v3.0-rc2, v3.0-rc1
# bb2b43fe 23-May-2011 Andrew Morton <akpm@linux-foundation.org>

drivers/base/platform.c: don't mark platform_device_register_resndata() as __init_or_module

This reverts 737a3bb9416ce2a7c7a4 ("Driver core: move platform device
creation helpers to .init.text (if M

drivers/base/platform.c: don't mark platform_device_register_resndata() as __init_or_module

This reverts 737a3bb9416ce2a7c7a4 ("Driver core: move platform device
creation helpers to .init.text (if MODULE=n)"). That patch assumed that
platform_device_register_resndata() is only ever called from __init code
but that isn't true in the case ioctl->drm_ioctl->radeon_cp_init().

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=35192

Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reported-by: Anthony Basile <blueness@gentoo.org>
Cc: Greg KH <gregkh@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


Revision tags: v2.6.39, v2.6.39-rc7, v2.6.39-rc6
# 2064af91 28-Apr-2011 Kevin Hilman <khilman@ti.com>

PM: Revert "driver core: platform_bus: allow runtime override of dev_pm_ops"

The platform_bus_set_pm_ops() operation is deprecated in favor of the
new device power domain infrastructre implemented i

PM: Revert "driver core: platform_bus: allow runtime override of dev_pm_ops"

The platform_bus_set_pm_ops() operation is deprecated in favor of the
new device power domain infrastructre implemented in commit
7538e3db6e015e890825fbd9f8659952896ddd5b (PM: add support for device
power domains)

Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

show more ...


# 8b313a38 28-Apr-2011 Rafael J. Wysocki <rjw@sisk.pl>

PM / Platform: Use generic runtime PM callbacks directly

Once shmobile platforms have been converted to using power domains
for overriding the platform bus type's PM callbacks, it isn't
necessary to

PM / Platform: Use generic runtime PM callbacks directly

Once shmobile platforms have been converted to using power domains
for overriding the platform bus type's PM callbacks, it isn't
necessary to use the __weakly defined wrappers around the generinc
runtime PM callbacks in the platform bus type any more.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

show more ...


# 69c9dd1e 28-Apr-2011 Rafael J. Wysocki <rjw@sisk.pl>

PM: Export platform bus type's default PM callbacks

Export the default PM callbacks defined for the platform bus type so
that they can be used by power domains for suspending and resuming
platform d

PM: Export platform bus type's default PM callbacks

Export the default PM callbacks defined for the platform bus type so
that they can be used by power domains for suspending and resuming
platform devices in the future.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

show more ...


Revision tags: v2.6.39-rc5
# 4a03d6f7 20-Apr-2011 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

driver core/platform_device_add_resources: free resource before overwriting

Reviewed-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-of

driver core/platform_device_add_resources: free resource before overwriting

Reviewed-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


# cea89623 20-Apr-2011 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

driver core/platform_device_add_resources: set resource to NULL if !res

This makes the res = NULL case more consistant to the res != NULL case
as now both overwrite pdev->resource.

Reviewed-by: Vir

driver core/platform_device_add_resources: set resource to NULL if !res

This makes the res = NULL case more consistant to the res != NULL case
as now both overwrite pdev->resource.

Reviewed-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


# 251e031d 20-Apr-2011 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

driver core/platform_device_add_data: free platform data before overwriting

Reviewed-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-of

driver core/platform_device_add_data: free platform data before overwriting

Reviewed-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


# 27a33f9e 20-Apr-2011 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

driver core/platform_device_add_data: set platform_data to NULL if !data

This makes the data = NULL case more consistent to the data != NULL case.
The functional change is that now

platform_device

driver core/platform_device_add_data: set platform_data to NULL if !data

This makes the data = NULL case more consistent to the data != NULL case.
The functional change is that now

platform_device_add_data(somepdev, NULL, somesize)

sets pdev->dev.platform_data to NULL instead of not touching it.

Reviewed-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


Revision tags: v2.6.39-rc4, v2.6.39-rc3
# e710d7d5 07-Apr-2011 Samuel Ortiz <sameo@linux.intel.com>

mfd: Fetch cell pointer from platform_device->mfd_cell

In order for MFD drivers to fetch their cell pointer but also their
platform data one, an mfd cell pointer is added to the platform_device
stru

mfd: Fetch cell pointer from platform_device->mfd_cell

In order for MFD drivers to fetch their cell pointer but also their
platform data one, an mfd cell pointer is added to the platform_device
structure.
That allows all MFD sub devices drivers to be MFD agnostic, unless
they really need to access their MFD cell data. Most of them don't,
especially the ones for IPs used by both MFD and non MFD SoCs.

Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg KH <gregkh@suse.de>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

show more ...


# 1f112cee 11-Apr-2011 Rafael J. Wysocki <rjw@sisk.pl>

PM / Hibernate: Introduce CONFIG_HIBERNATE_CALLBACKS

Xen save/restore is going to use hibernate device callbacks for
quiescing devices and putting them back to normal operations and it
would need to

PM / Hibernate: Introduce CONFIG_HIBERNATE_CALLBACKS

Xen save/restore is going to use hibernate device callbacks for
quiescing devices and putting them back to normal operations and it
would need to select CONFIG_HIBERNATION for this purpose. However,
that also would cause the hibernate interfaces for user space to be
enabled, which might confuse user space, because the Xen kernels
don't support hibernation. Moreover, it would be wasteful, as it
would make the Xen kernels include a substantial amount of code that
they would never use.

To address this issue introduce new power management Kconfig option
CONFIG_HIBERNATE_CALLBACKS, such that it will only select the code
that is necessary for the hibernate device callbacks to work and make
CONFIG_HIBERNATION select it. Then, Xen save/restore will be able to
select CONFIG_HIBERNATE_CALLBACKS without dragging the entire
hibernate code along with it.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Tested-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

show more ...


Revision tags: v2.6.39-rc2, v2.6.39-rc1, v2.6.38, v2.6.38-rc8, v2.6.38-rc7, v2.6.38-rc6, v2.6.38-rc5, v2.6.38-rc4, v2.6.38-rc3, v2.6.38-rc2, v2.6.38-rc1, v2.6.37, v2.6.37-rc8, v2.6.37-rc7, v2.6.37-rc6, v2.6.37-rc5, v2.6.37-rc4, v2.6.37-rc3, v2.6.37-rc2, v2.6.37-rc1, v2.6.36, v2.6.36-rc8, v2.6.36-rc7, v2.6.36-rc6, v2.6.36-rc5, v2.6.36-rc4
# 807508c8 07-Sep-2010 Anton Vorontsov <cbouatmailru@gmail.com>

base/platform: Simplifications for NULL platform data/resources handling

There's no need to explicitly check for data and resources being NULL,
as platform_device_add_{data,resources}() do this inte

base/platform: Simplifications for NULL platform data/resources handling

There's no need to explicitly check for data and resources being NULL,
as platform_device_add_{data,resources}() do this internally nowadays.

This makes the code more linear and less indented.

Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


# 5cfc64ce 07-Sep-2010 Anton Vorontsov <cbouatmailru@gmail.com>

base/platform: Safe handling for NULL platform data and resources

Some users of platform_device_add_{data,resources}() assume that
NULL data and resources will be handled specially, i.e. just ignore

base/platform: Safe handling for NULL platform data and resources

Some users of platform_device_add_{data,resources}() assume that
NULL data and resources will be handled specially, i.e. just ignored.

But the platform core ends up calling kmemdup(NULL, 0, ...), which
returns a non-NULL result (i.e. ZERO_SIZE_PTR), which causes drivers
to oops on a valid code, something like:

if (platform_data)
stuff = platform_data->stuff;

This patch makes the platform core a bit more safe for such cases.

Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


Revision tags: v2.6.36-rc3
# c64a0926 25-Aug-2010 Kevin Hilman <khilman@ti.com>

driver core: platform_bus: allow runtime override of dev_pm_ops

Currently, the platform_bus allows customization of several of the
busses dev_pm_ops methods by using weak symbols so that platform co

driver core: platform_bus: allow runtime override of dev_pm_ops

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: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


Revision tags: v2.6.36-rc2, v2.6.36-rc1
# d79d3244 06-Aug-2010 Patrick Pannuto <ppannuto@codeaurora.org>

driver core: platform: Use drv->driver.bus instead of assuming platform_bus_type

In theory (although not *yet* in practice), a driver being passed
to platform_driver_probe might have driver.bus set

driver core: platform: Use drv->driver.bus instead of assuming platform_bus_type

In theory (although not *yet* in practice), a driver being passed
to platform_driver_probe might have driver.bus set to something
other than platform_bus_type. Locking drv->driver.bus is always
correct.

Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

show more ...


# 7096d042 20-Oct-2010 Grant Likely <grant.likely@secretlab.ca>

of/device: Rework to use common platform_device_alloc() for allocating devices

The current code allocates and manages platform_devices created from
the device tree manually. It also uses an unsafe

of/device: Rework to use common platform_device_alloc() for allocating devices

The current code allocates and manages platform_devices created from
the device tree manually. It also uses an unsafe shortcut for
allocating the platform_device and the resource table at the same
time. (which I added in the last rework; sorry).

This patch refactors the code to use platform_device_alloc() for
allocating new devices. This reduces the amount of custom code
implemented by of_platform, eliminates the unsafe alloc trick, and has
the side benefit of letting the platform_bus code manage freeing the
device data and resources when the device is freed.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michal Simek <monstr@monstr.eu>

show more ...


12345678910>>...21