Changeset View
Standalone View
sys/kern/subr_bus.c
Show First 20 Lines • Show All 4,580 Lines • ▼ Show 20 Lines | |||||
{ | { | ||||
if (dev->parent) | if (dev->parent) | ||||
return (BUS_GET_DOMAIN(dev->parent, dev, domain)); | return (BUS_GET_DOMAIN(dev->parent, dev, domain)); | ||||
return (ENOENT); | return (ENOENT); | ||||
} | } | ||||
/** | /** | ||||
* @brief Helper function to implement normal BUS_GET_DEVICE_PATH() | |||||
* | |||||
* This function knows how to (a) pass the request up the tree if there's | |||||
* a parent and (b) Knows how to supply a FreeBSD locator. | |||||
* | |||||
* @param bus bus in the walk up the tree | |||||
* @param child leaf node to print information about | |||||
* @param locator BUS_LOCATOR_xxx string for locator | |||||
* @param sb Buffer to print information into | |||||
*/ | |||||
int | |||||
bus_generic_get_device_path(device_t bus, device_t child, const char *locator, | |||||
struct sbuf *sb) | |||||
{ | |||||
int rv = 0; | |||||
device_t parent; | |||||
parent = device_get_parent(bus); | |||||
if (parent != NULL) | |||||
rv = BUS_GET_DEVICE_PATH(parent, bus, locator, sb); | |||||
if (strcmp(locator, BUS_LOCATOR_FREEBSD) == 0) { | |||||
if (rv == 0) { | |||||
sbuf_printf(sb, "/%s", device_get_nameunit(child)); | |||||
} | |||||
return (rv); | |||||
} | |||||
/* | |||||
* Don't know what to do. So assume we do nothing. Not sure that's | |||||
* the right thing, but keeps us from having a big list here. | |||||
*/ | |||||
return (0); | |||||
jhb: I suspect we should at least return rv? I wonder what it would break in practice if we failed… | |||||
jhbUnsubmitted Not Done Inline ActionsSo I've looked ahead in the series and I do wonder if we want to support non-FreeBSD paths in this routine at all. My question about UEFI path inheritance in the UEFI review is probably relevant. I kind of find it surprising for child devices to inherit the parent UEFI path on non-UEFI-aware buses. I would rather expect that those child devices wouldn't really "exist" in UEFI, per se, but I could be wrong. Do you want the PCI bus devices to have a UEFI path for example, or just the bridges? If we don't want that UEFI inheritance, then I think the final version of this function can be something like: if (strcmp(locator, BUS_LOCATOR_FREEBSD) != 0) return (EINVAL); parent = device_get_parent(bus); if (parent != NULL) { rv = BUS_GET_DEVICE_PATH(parent, bus, locator, sb); if (rv != 0) return (rv); } sbuf_printf(sb, "/%s", device_get_nameunit(child)); return (0); If we do want UEFI inheritance (but not ACPI clearly), then maybe that inheritance should be explicit (vs ACPI opting out): int rv; device_t parent; parent = device_get_parent(bus); if (parent != NULL) { rv = BUS_GET_DEVICE_PATH(parent, bus, locator, sb); } else { if (strcmp(locator, BUS_LOCATOR_FREEBSD) == 0) rv = 0; else rv = EINVAL; } if (rv != 0) return (rv); if (strcmp(locator, BUS_LOCATOR_FREEBSD) == 0) sbuf_printf(sb, "/%s", device_get_nameunit(child)); return (0) (I would maybe call rv error instead as I think error is used more consistently for this in new-bus?) jhb: So I've looked ahead in the series and I do wonder if we want to support non-FreeBSD paths in… | |||||
impAuthorUnsubmitted Done Inline ActionsFor UEFI, we do want the inheritance. There's a number of differences between FreeBSD's device model and UEFI's device paths. Having the inheritance allows for arbitrary nesting seemlessly. imp: For UEFI, we do want the inheritance. There's a number of differences between FreeBSD's device… | |||||
impAuthorUnsubmitted Done Inline ActionsAlso, fwiw, I had tried to create some kind of 'mux' object where this sort of behavior could reside for the trip to the root. The dispatch was based on the locator type as well as the function method to call. Should we need it, I can dust that off, but it seems to be a lot of hacking to the roots of kobj to get only a slight gain in functionality here. imp: Also, fwiw, I had tried to create some kind of 'mux' object where this sort of behavior could… | |||||
jhbUnsubmitted Not Done Inline ActionsSince FDT will be like ACPI, you will have to hack this function yet again for FDT to opt-out of inheritance. I think instead that UEFI should opt-in to inheritance as it will be the exception rather than the rule. I don't consider this an objection to committing though. jhb: Since FDT will be like ACPI, you will have to hack this function yet again for FDT to opt-out… | |||||
impAuthorUnsubmitted Done Inline ActionsOK. I'll reconsider this when I get FDT done, because OFW acts more like UEFI in its paths and I'll do the pair of them together. imp: OK. I'll reconsider this when I get FDT done, because OFW acts more like UEFI in its paths and… | |||||
} | |||||
/** | |||||
* @brief Helper function for implementing BUS_RESCAN(). | * @brief Helper function for implementing BUS_RESCAN(). | ||||
* | * | ||||
* This null implementation of BUS_RESCAN() always fails to indicate | * This null implementation of BUS_RESCAN() always fails to indicate | ||||
* the bus does not support rescanning. | * the bus does not support rescanning. | ||||
*/ | */ | ||||
int | int | ||||
bus_null_rescan(device_t dev) | bus_null_rescan(device_t dev) | ||||
{ | { | ||||
▲ Show 20 Lines • Show All 1,428 Lines • Show Last 20 Lines |
I suspect we should at least return rv? I wonder what it would break in practice if we failed-close by returning an error instead (EINVAL perhaps)