some thoughts having read this:

more should be said about how how 'smart' controllers should implement
certain types of commands.  (are you assuming that the command type
will be stuffed in the data, and that smart controller commands will
grovel it from there?  That seems like it might be more painful than
it needs to be.)

polling vs. interrupt driven operation: what are the assumptions about
each?

What about reentrancy?  i.e. command currently being processed by the
bus in interrupt-driven fashion, and some process sleeping for it, and
some other code needing to execute an op from an interrupt context?

This describes part of the interface used to issue commands, info
about the internal interfaces would be useful.  (i.e., for 'dumb'
drivers that need to hook into the generic framework.  for people
writing drivers in general there's not enough there, even if you know
about i2c...)

It makes sense to have a higher level interface, in addition to this
'drive these bytes' interface.  I.e., there are a bunch of standard
operations used by many/most devices, and it's silly to have to recode
them in each driver that needs them.

Read vs. write, and the array of i2o commands: How do you do a simple
addressed read command from a device?  It's not at all clear what
combination of operations you'd use for this, what the 'nops' are for,
why you would chain operations together.

If the goal is to indicate read vs write parts of a single command w/
multiple op structures, then why do you need all of those flags for
each?  (the flags seem like they're 'per-command'.)

Have you read the SMBus spec?


Alas, i'm going to be travelling most of this week, so i won't have
time to read much more you might write on this...  but from where i
sit, what you've presented here is fairly incoherent and doesn't
obviously correspond to my undstanding of i2c and smbus devices...



cgd