smbus read help needed

[Alison Schofield <amsfield22@gmail.com>]

I'm blocked on this smbus read problem. 

hdc100x triggered buffer review feedback pointed out that I cannot rely
on i2c_master_recv() since this driver currently only requires smbus funcs. 
That led me to create an alternative path using smbus byte reads like the
driver was doing in direct mode.

I found the reads don't work.  hdc100x does not expect a stop condition
after sending the first byte which is what smbus_read_byte gives you. So,
when you do the second read, you are getting the first byte again.  Net
effect is that of the 14 bits used for the measurement, the 8 most
significant bits are correct, the lower 6 are not.

hdc100x only wants this:
	S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P 

I tried by testing, and by inspection, each flavor of smbus read and none 
match the pattern that hdc100x wants.  (read_byte, read_word_data, 
read_word_swapped, read_block_data, read_i2c_block_data all fail) 
The read_byte is actually the only smbus read command the sensor accepts.

Texas Instruments publishes this doc explaining its SMBus (in)compatibility.
http://www.ti.com/lit/an/sloa132/sloa132.pdf
I did get one lead out of it.  It suggests using the write block protocol,
with the READ bit set. That does look like it could work.  I tried using
i2c_smbus_xfer() directly, thinking maybe I could fool it, but that doesn't
get me down to the low level of control I think I would need to pull this off. 

I see flags for i2c_msg that might be helpful...if they worked at the
smbus level: 
I2C_M_REV_DIR_ADDR reverses r/w bit 
I2C_M_NOSTART strips off that beginning segment we don't want

If we could use a NOSTOP flag on the read byte command then i could
go back and get the next byte.  I don't see such a flag.  I don't see
any flags, other than for PEC, on smbus.

Also, saw an MDELAY flag that seemed interesting, as if I could program
the delay between starting and reading the measurement, so it could all
be done in one block data command. Again, not smbus.

I guess these ideas are all breaking the idea of being smbus compliant
anyway. 

Is this fixable with smbus? 
If not, how do you 'graciously' change a drivers requirements?

Thanks,
alisons