DtIoLookup first translates the ASCII DT path to an EFI_DEVICE_PATH_PROTOCOL, then uses DtPathToHandle to lookup/connect the handle. DtPathToHandle uses LocateDevicePath.
Glancing at LocateDevicePath, this seems rather suboptimal, as it can iterate over potentially quite a lot of handles (esp. if LocateDevicePath is successively called as controllers are connected).
Another issue is that LocateDevicePath has no notion of "fuzzy" matching, e.g. when we want /soc/pci to match /soc/pci@3000000 (dropping the unit address in unambiguous situations).
This should be fixed by directly traversing the ASCII DT path. DT_DEVICE has a Parent already, and could be made to keep a linked list of children as well.
The other place DtPathToHandle is used is inside DtDeviceCreate, to avoid creating duplicates. Again, if a DtDevice knows what children it has, this problem becomes much cheaper to solve.
DtIoLookup first translates the ASCII DT path to an EFI_DEVICE_PATH_PROTOCOL, then uses DtPathToHandle to lookup/connect the handle. DtPathToHandle uses LocateDevicePath.
Glancing at LocateDevicePath, this seems rather suboptimal, as it can iterate over potentially quite a lot of handles (esp. if LocateDevicePath is successively called as controllers are connected).
Another issue is that LocateDevicePath has no notion of "fuzzy" matching, e.g. when we want /soc/pci to match /soc/pci@3000000 (dropping the unit address in unambiguous situations).
This should be fixed by directly traversing the ASCII DT path. DT_DEVICE has a Parent already, and could be made to keep a linked list of children as well.
The other place DtPathToHandle is used is inside DtDeviceCreate, to avoid creating duplicates. Again, if a DtDevice knows what children it has, this problem becomes much cheaper to solve.