summaryrefslogtreecommitdiffstats
path: root/test/dm/test-fdt.c
diff options
context:
space:
mode:
authorSimon Glass <sjg@chromium.org>2014-07-23 06:55:12 -0600
committerSimon Glass <sjg@chromium.org>2014-07-23 14:07:25 +0100
commit5a66a8ff86d923367ca9a1f6168e976fbde27391 (patch)
tree429ae5e3e439c59972c845673ee3d48ef23d416e /test/dm/test-fdt.c
parent4e8bc211703d3c93689367745e8c07dc22c68dfc (diff)
downloadtalos-obmc-uboot-5a66a8ff86d923367ca9a1f6168e976fbde27391.tar.gz
talos-obmc-uboot-5a66a8ff86d923367ca9a1f6168e976fbde27391.zip
dm: Introduce device sequence numbering
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>
Diffstat (limited to 'test/dm/test-fdt.c')
-rw-r--r--test/dm/test-fdt.c54
1 files changed, 53 insertions, 1 deletions
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index d284f7fa05..d8e94d8570 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -94,7 +94,7 @@ UCLASS_DRIVER(testfdt) = {
/* Test that FDT-based binding works correctly */
static int dm_test_fdt(struct dm_test_state *dms)
{
- const int num_drivers = 3;
+ const int num_drivers = 4;
struct udevice *dev;
struct uclass *uc;
int ret;
@@ -163,3 +163,55 @@ static int dm_test_fdt_pre_reloc(struct dm_test_state *dms)
return 0;
}
DM_TEST(dm_test_fdt_pre_reloc, 0);
+
+/* Test that sequence numbers are allocated properly */
+static int dm_test_fdt_uclass_seq(struct dm_test_state *dms)
+{
+ struct udevice *dev;
+
+ /* A few basic santiy tests */
+ ut_assertok(uclass_find_device_by_seq(UCLASS_TEST_FDT, 3, true, &dev));
+ ut_asserteq_str("b-test", dev->name);
+
+ ut_assertok(uclass_find_device_by_seq(UCLASS_TEST_FDT, 0, true, &dev));
+ ut_asserteq_str("a-test", dev->name);
+
+ ut_asserteq(-ENODEV, uclass_find_device_by_seq(UCLASS_TEST_FDT, 5,
+ true, &dev));
+ ut_asserteq_ptr(NULL, dev);
+
+ /* Test aliases */
+ ut_assertok(uclass_get_device_by_seq(UCLASS_TEST_FDT, 6, &dev));
+ ut_asserteq_str("e-test", dev->name);
+
+ ut_asserteq(-ENODEV, uclass_find_device_by_seq(UCLASS_TEST_FDT, 7,
+ true, &dev));
+
+ /* Note that c-test is not probed since it is not a top-level node */
+ ut_assertok(uclass_get_device_by_seq(UCLASS_TEST_FDT, 3, &dev));
+ ut_asserteq_str("b-test", dev->name);
+
+ /*
+ * d-test wants sequence number 3 also, but it can't have it because
+ * b-test gets it first.
+ */
+ ut_assertok(uclass_get_device(UCLASS_TEST_FDT, 2, &dev));
+ ut_asserteq_str("d-test", dev->name);
+
+ /* d-test actually gets 0 */
+ ut_assertok(uclass_get_device_by_seq(UCLASS_TEST_FDT, 0, &dev));
+ ut_asserteq_str("d-test", dev->name);
+
+ /* initially no one wants seq 1 */
+ ut_asserteq(-ENODEV, uclass_get_device_by_seq(UCLASS_TEST_FDT, 1,
+ &dev));
+ ut_assertok(uclass_get_device(UCLASS_TEST_FDT, 0, &dev));
+ ut_assertok(uclass_get_device(UCLASS_TEST_FDT, 1, &dev));
+
+ /* But now that it is probed, we can find it */
+ ut_assertok(uclass_get_device_by_seq(UCLASS_TEST_FDT, 1, &dev));
+ ut_asserteq_str("a-test", dev->name);
+
+ return 0;
+}
+DM_TEST(dm_test_fdt_uclass_seq, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
OpenPOWER on IntegriCloud