Since you're parsing out the capability flags, you may as well drop caps from the softc and simply read the value to a local variable for parsing.

ChipCommon should implement the bus_* methods directly, rather than having a chipcbus intermediary that will need access to the ChipCommon's driver's internals and bhnd_* bus APIs anyway.

This inverts the usual newbus behavior of using DEVICE_PROBE/DEVICE_IDENTIFY to probe and attach drivers for bus devices.

I lean towards DEVICE_IDENTIFY, as that'd isolate ChipCommon from what may be SoC-specific drivers, but using DEVICE_PROBE with a BUS_PROBE_NOWILDCARD return value would also work.

If you then instead expose the chipc_capabilities structure via bhnd_chipc_if.m (and some mechanism for requesting the flash config from chipc), you can implement this driver selection through the standard newbus methods by inspecting the capability flags in device_probe and/or device_identify for these drivers.

device_get_class() can be used with direct pointer comparison against the result of devclass_find("mx25l")

However, I'd suggest just defining driver-specific entry points to chipc_slicer_walk() and registering the appropriate one when you first introspect the ChipCommon flash configuration.

Could we add these flash configuration options to the chipc_caps structure? I was thinking we could use a union {} over a set of flash-type-specific structures, and then let chipc abstract the actual fetching/parsing of flash configuration.

Since driver loading/unloading can result in DEVICE_IDENTIFY being called multiple times, drivers have to manually check for an existing device node to prevent registering a duplicate.

(see DEVICE_IDENTIFY(4) for an example)

This is triggering a linker error in module builds due to the bhnd(4) module providing the bhnd_chipc_if interface, but bhnd_chipc_generic_get_caps() being defined in chipc.

Since the bhnd_chipc interface is meant to define an explicit target device's interface (e.g. the intention is to implement this interface for the EXTIF core on earlier pre-ChipCommon devices), and not a bus interface delegated to parent device, I think it's safe to not provide a _generic_ implementation here, and ideal to not delegate to the parent device.