There could be a need wherein, instead of the application directly sending command to the controller to control the peripheral beneath, there could be a KMDF or UMDF peripheral driver present for that peripheral device in the OS.
Well, that’s almost 100% different from your first use case… And it changes the design COMPLETELY. This is a MUCH harder ask.
If your goal is to allow “standard” WDF drivers to be recognized and loaded for devices that are attached to your controller, I don’t see any reasonable way of avoiding having the device described in the ACPI BIOS. The Client Driver is going to try to open a Remote I/O Target connection to the Controller Driver via the Resource Hub (ACPIEX). ACPIEX is going to try to determine which Controller the Client device is attached to by looking through the ACPI BIOS tables.
If you wanted to be really fancy and complex, I suppose you could:
-
Write a bus driver that enumerates the device(s) connected to your controller. Because there’s no standard way to dynamically enumerate the I2C bus, you’d have to create some method that users specify the device(s) connected to your I2C Controller’s bus (as well as the Client IDs associated with each of those devices). You’ll also need to be clever enough to “fake” a Connection ID for the Client driver to use when it enumerates its resources and attempt to open the connection to the Resource Hub.
-
Write a filter driver that intercepts Open requests that are sent to the Resource Hub, and redirect the open (via STATUS_REPARSE) to your Controller Driver.
-
Ensure your Controller Driver takes into account (that is, effectively “emulates”) the behavior that the Client Driver would expect if it were talking to a Controller Driver via the SPBCx. So, you’ll need to support the “standard” IOCTLs.
I think you’ll be able to avoid actual use of the SPB Controller Extensions entirely if you do the above. They don’t really provide any advantage or help in your case… and I suspect that once the Client Driver gets his Connection ID and has opened a Remote I/O Target to your Controller Driver, it’ll start sending you those standard IOCTLs.
The above ignores the case where the Client device has some other resources other than the I2C Connection. For example, this doesn’t allow you support for connections from the I2C device to a GPIO controller for interrupts (which is pretty common). I really don’t see how you could support interrupts on the Client devices you enumerate… GPIO controller isn’t under your control, after all.
ANYhow… having to load the standard driver (and not just allow an app to do write and read) really turns this from a simple project into what is basically a research project. You’re waaaay out of the standard ways of doing things.
Peter