Commit 4a1db6d8ab4d5e4565bda079710a028ada12ddbe

Authored by Simon Glass
1 parent 4dc5259ac7

dm: mmc: Try to honour the sequence order

At present we add driver-model MMC devices in the order we find them. The
'alias' order is not honoured.

It is difficult to fix this for the case where we have holes in the
sequence. But for the common case where the devices are numbered from 0
without any gaps, we can add the devices to the internal data structures
in this order.

Signed-off-by: Simon Glass <sjg@chromium.org>

Showing 1 changed file with 15 additions and 5 deletions Side-by-side Diff

... ... @@ -1780,18 +1780,28 @@
1780 1780 #elif defined(CONFIG_DM_MMC)
1781 1781 static int mmc_probe(bd_t *bis)
1782 1782 {
1783   - int ret;
  1783 + int ret, i;
1784 1784 struct uclass *uc;
1785   - struct udevice *m;
  1785 + struct udevice *dev;
1786 1786  
1787 1787 ret = uclass_get(UCLASS_MMC, &uc);
1788 1788 if (ret)
1789 1789 return ret;
1790 1790  
1791   - uclass_foreach_dev(m, uc) {
1792   - ret = device_probe(m);
  1791 + /*
  1792 + * Try to add them in sequence order. Really with driver model we
  1793 + * should allow holes, but the current MMC list does not allow that.
  1794 + * So if we request 0, 1, 3 we will get 0, 1, 2.
  1795 + */
  1796 + for (i = 0; ; i++) {
  1797 + ret = uclass_get_device_by_seq(UCLASS_MMC, i, &dev);
  1798 + if (ret == -ENODEV)
  1799 + break;
  1800 + }
  1801 + uclass_foreach_dev(dev, uc) {
  1802 + ret = device_probe(dev);
1793 1803 if (ret)
1794   - printf("%s - probe failed: %d\n", m->name, ret);
  1804 + printf("%s - probe failed: %d\n", dev->name, ret);
1795 1805 }
1796 1806  
1797 1807 return 0;