u-boot.git/drivers/core/device-remove.c, branch v2016.09

dm: core: Rename DM_NAME_ALLOCED to DM_FLAG_NAME_ALLOCED

2016-07-15T02:40:24+00:00

This is a flag. Adjust the name to be consistent with the other flags.

Signed-off-by: Simon Glass

dm: core: Allow device names to be freed automatically

2016-05-17T15:54:43+00:00

Some devices have a name that is stored in allocated memory. At present
there is no mechanism to free this memory when the device is unbound.

Add a device flag to track whether a name is allocated and a function to
add the flag. Free the memory when the device is unbound.

Signed-off-by: Simon Glass

Revert "dm: Export device_remove_children / device_unbind_children"

2015-11-20T03:27:51+00:00

This reverts commit bb52b367f6ca4a3a918e77737f4ff6a1089912d9.

Signed-off-by: Simon Glass

devres: introduce Devres (Managed Device Resource) framework

2015-08-06T13:44:29+00:00

In U-Boot's driver model, memory is basically allocated and freed
in the core framework.  So, low level drivers generally only have
to specify the size of needed memory with .priv_auto_alloc_size,
.platdata_auto_alloc_size, etc.  Nevertheless, some drivers still
need to allocate/free memory on their own in case they cannot
statically know the necessary memory size.  So, I believe it is
reasonable enough to port Devres into U-boot.

Devres, which originates in Linux, manages device resources for each
device and automatically releases them on driver detach.  With devres,
device resources are guaranteed to be freed whether initialization
fails half-way or the device gets detached.

The basic idea is totally the same to that of Linux, but I tweaked
it a bit so that it fits in U-Boot's driver model.

In U-Boot, drivers are activated in two steps: binding and probing.
Binding puts a driver and a device together.  It is just data
manipulation on the system memory, so nothing has happened on the
hardware device at this moment.  When the device is really used, it
is probed.  Probing initializes the real hardware device to make it
really ready for use.

So, the resources acquired during the probing process must be freed
when the device is removed.  Likewise, what has been allocated in
binding should be released when the device is unbound.  The struct
devres has a member "probe" to remember when the resource was
allocated.

CONFIG_DEBUG_DEVRES is also supported for easier debugging.
If enabled, debug messages are printed each time a resource is
allocated/freed.

Signed-off-by: Masahiro Yamada 
Acked-by: Simon Glass

dm: add DM_FLAG_BOUND flag

2015-08-06T13:44:29+00:00

Currently, we only have DM_FLAG_ACTIVATED to indicate the device
status, but we still cannot know in which stage is in progress,
binding or probing.

This commit introduces a new flag, DM_FLAG_BOUND, which is set when
the device is really bound, and cleared when it is unbound.

Signed-off-by: Masahiro Yamada 
Acked-by: Simon Glass

dm: Export device_remove_children / device_unbind_children

2015-07-21T23:39:35+00:00

These functions are useful to remove all children from an usb bus before
rescanning the bus. Give them a better name and export them.

Signed-off-by: Hans de Goede 
Acked-by: Simon Glass

dm: core: Extend struct udevice by '.uclass_platdata' field.

2015-04-22T17:03:14+00:00

This commit adds 'uclass_platdata' field to 'struct udevice', which
can be automatically allocated at bind. The allocation size is defined
in 'struct uclass_driver' as 'per_device_platdata_auto_alloc_size'.

New device's flag is added: DM_FLAG_ALLOC_UCLASS_PDATA, which is used
for memory freeing at device unbind method.

As for other udevice's fields, a complementary function is added:
- dev_get_uclass_platdata()

Signed-off-by: Przemyslaw Marczak 
Cc: Simon Glass 
Acked-by: Simon Glass

dm: core: Convert driver_bind() to use const

2015-04-18T17:11:19+00:00

The driver is not modified by driver model, so update driver_bind() to
recognise that.

Signed-off-by: Simon Glass 
Reviewed-by: Marek Vasut

dm: core: Allow uclasses to specify private data for a device's children

2015-01-30T00:09:55+00:00

In many cases the per-child private data for a device's children is defined
by the uclass rather than the individual driver. For example, a SPI bus
needs to store information about each of its children, but all SPI drivers
store the same information. It makes sense to allow the uclass to define
this data.

If the driver provides a size value for its per-child private data, then use
it. Failng that, fall back to that provided by the uclass.

Signed-off-by: Simon Glass 
Reviewed-by: Masahiro Yamada

dm: core: Allow parents to have platform data for their children

2015-01-30T00:09:54+00:00

For buses it is common for parents to need to know the address of the child
on the bus, the bus speed to use for that child, and other information. This
can be provided in platform data attached to each child.

Add driver model support for this, including auto-allocation which can be
requested using a new property to specify the size of the data.

Signed-off-by: Simon Glass 
Reviewed-by: Masahiro Yamada