Polymorphic devices

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Hello....

I am in need of some advise and guidance.

I am working slowly on device support for a couple of USB chips that
have multiple, but somewhat mutually exclusive, behaviors.

The first is enhancements to ufdti to support the MPSSE engine that some
of the FTDI chip variants have.  This engine allows the chip to be a I2C
bus, SPI bus and provides some simple GPIO, and a bunch of other stuff,
as well as the normal USB UART.  It is not possible to use all of the
modes at the same time.  That is, these are not separate devices, but
modes within one device.  Or another way, depending on the mode of the
chip you get different child devices attached to it.  I am curious on
what the thoughts are on how this might be modeled.

I see a few options for doing this, such as simply matching all of the
possible children and using sysctl to enable the one you want.  Probably
followed by a rescan call.  That seems ugly, however.  The use of
'drvctl -r -a <attribute>' seemed to hold promise.  It seems like a
better idea to require the detachment of whatever followed by the rescan
with the attribute indicating which sort of thing you wanted to attach
(detach ucom in favor of i2c, for example).  But I do not completely
understand if this sort of thing is possible.


The second chip is the MCP2221 which provides some of the same features
as the FTDI MPSSE engine.  It has a built in UART which is a separate
USB device and then a USB device that can be programmed to provide I2C,
GPIO, some DAC a bit of ADC (low number of bits in both of those cases,
but still interesting enough).  You can probably always just provide the
I2C bus and then flip the behaviors of the GPIO pins by setting their
alt settings.  This chip may be a bit simpler to deal with with the
using gpio alt settings and such, but I also have not looked at this one
as much.


If I can get these to work, the end result will be that any system with
USB, including virtual systems with USB devices presented to it in some
way, can have I2C, simple GPIO and maybe SPI ... and this is the place I
want to end up for my own needs.


I have looked around the tree for other devices that do this sort of
thing and didn't really find any that tried to deal with this sort of
situation, but I will admit I looked mostly at the MI devices.






Any thoughts would be appreciated,


-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org