summaryrefslogtreecommitdiff
path: root/drivers/core/uclass.c
Commit message (Collapse)AuthorAgeLines
* dm: do not check the existence of uclass operationMasahiro Yamada2014-10-22-4/+0
| | | | | | | | | | | | | | | | | | The function uclass_add() checks uc_drv->ops as follows: if (uc_drv->ops) { dm_warn("No ops for uclass id %d\n", id); return -EINVAL; } It seems odd because it warns "No ops" when uc_drv->ops has non-NULL pointer. (Looks opposite.) Anyway, most of UCLASS_DRIVER entries have no .ops member. This check makes no sense. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: Avoid accessing uclasses before they are readySimon Glass2014-07-23-0/+2
| | | | | | Don't allow access to uclasses before they have been initialised. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Allow a device to be found by its FDT offsetSimon Glass2014-07-23-0/+35
| | | | | | | | Each device that was bound from a device tree has an node that caused it to be bound. Add functions that find and return a device based on a device tree offset. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Introduce device sequence numberingSimon Glass2014-07-23-0/+78
| | | | | | | | | | | | | | | | | | | | | | | | | In U-Boot it is pretty common to number devices from 0 and access them on the command line using this numbering. While it may come to pass that we will move away from this numbering, the possibility seems remote at present. Given that devices within a uclass will have an implied numbering, it makes sense to build this into driver model as a core feature. The cost is fairly small in terms of code and data space. With each uclass having numbered devices we can ask for SPI port 0 or serial port 1 and receive a single device. Devices typically request a sequence number using aliases in the device tree. These are resolved when the device is probed, to deal with conflicts. Sequence numbers need not be sequential and holes are permitted. At present there is no support for sequence numbers using static platform data. It could easily be added to 'struct driver_info' if needed, but it seems better to add features as we find a use for them, and the use of -1 to mean 'no sequence' makes the default value somewhat painful. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Move uclass error checking/probing into a functionSimon Glass2014-07-23-6/+22
| | | | | | Several functions will use this same pattern, so bring it into a function. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Cast away the const-ness of the global_data pointerSimon Glass2014-06-20-1/+1
| | | | | | | In a very few cases we need to adjust the driver model root device, such as when setting it up at initialisation. Add a macro to make this easier. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: rename device struct to udeviceHeiko Schocher2014-05-27-15/+16
| | | | | | | | | | | | using UBI and DM together leads in compiler error, as both define a "struct device", so rename "struct device" in include/dm/device.h to "struct udevice", as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux "struct device" Signed-off-by: Heiko Schocher <hs@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Marek Vasut <marex@denx.de>
* dm: Add base driver model supportSimon Glass2014-03-04-0/+285
Add driver model functionality for generic board. This includes data structures and base code for registering devices and uclasses (groups of devices with the same purpose, e.g. all I2C ports will be in the same uclass). The feature is enabled with CONFIG_DM. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>