Hmmmm… OK, so let’s be clear about what you’re trying to accomplish, so I can be sure I’m answering your actual question:
You have an I2C Controller device that attaches to the system (dynamically) via USB. You want to write a I2C Controller Driver for this device using the standard Windows SPBCx… because that would enable “standard” Windows I2C client (that is, peripheral) device drivers (that also use SPBCx) to “just work” with your USB-connected I2C Controller.
Is that correct?
If so… This will be extremely tricky to accomplish, and perhaps impossible to do in any useful way.
Remember that the Controller and the Client (peripheral) devices both must be fully specified to ACPI via the SSDT. So, there’s really no useful way to specify a dynamically attached USB-based I2C controller that, in turn, has one or more devices (potentially dynamically) attached to it.
The Client driver is going to get a Connection ID and use the Resource Hub to resolve that into a Remote I/O Target to the (appropriate, specific) I2C Controller device and driver. This is all happens through the magic of SPBCx and ACPIEX.
So, at a minimum, you’ll need to specify a “dummy” static I2c Controller in the SSDT and load a (rather unconventional) driver over that client. When your USB-based I2C controller is dynamically enumerated, you’re going to load your rather conventional USB driver on that device (to talk to the real I2C Controller). Your “dummy” static I2C Controller driver will need to service requests from SPBCx by sending them to your USB-based driver.
You’ll also need to specify a static I2c Client device. If you know in advance the type of device, then at least THAT could (potentially) be rather conventional. It will connect to the “dummy” static I2C controller via the Resource Hub.
If you need to support the attachment of dynamic I2c CLIENT devices to your USB I2C controller, your job is even more complex. You need to ALSO create a “dummy” I2C Client device in your SSDT and load a dummy driver for that device. Your USB-based I2C controller driver will need to be a bus driver… and you’ll need to play some considerable games inject Connection ID resources for your enumerated Client devices. Of course, you’ll need to use the Connection ID from your dummy client device (because the Resource Hub needs to understand it). Ugh… it all gets very messy.
I hope that helps, and perhaps dissuades you from doing what you’ve described.
Peter