https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223519
John Baldwin <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Works As Intended --- Comment #1 from John Baldwin <[email protected]> --- Unfortunately, this is inherent in the design of __BUS_ACCESSOR. There is no universal value to return to indicate an invalid ivar (e.g. ivars can have a value of -1). In essence, the assumption is that _BUS_ACCESSOR is a convenience wrapper for ivars that are always valid. One should use BUS_READ_IVAR() directly if one wishes to handle possibly invalid ivars. The ACPI ivars accessors use a different macro that returns a default value of 0 so that acpi_get_handle() will "fail" properly, but that is only ok for ACPI. I think it would perhaps be useful to extend the ACPI model slightly to have a __BUS_ACCESSOR_DEFAULT() that accepts an additional "default value" parameter which is returned if BUS_READ_IVAR fails perhaps? That could replace the ACPI macro and be useful for other cases since on an individual ivar you might be able to return a suitable value for error. In general with ivars I have wanted a way to name them by a tuple (group, index) (ACPI just starts indices at 100 to get around this) and then have a way to say "do you have this group". This would let you ask a given device "do you have PCI ivars" (i.e. are you a PCI device). However, this would require restructuring ivars a bit. That wouldn't help with your bug where a single ivar out of a group was not properly implemented either. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
