> SCCB helpers would work too. It would be easy to just move the functions > defined in this patch to helpers and be done with it. However, there are I2C > adapters that have native SCCB support, so to take advantage of that feature Ah, didn't notice that so far. Can't find it in drivers/i2c/busses. Where are those? > we need to forward native SCCB calls all the way down the stack in that case. And how is it done currently? > That's why I thought an implementation in the I2C subsystem would be better. > Furthermore, as SCCB is really a slightly mangled version of I2C, I think the > I2C subsystem would be a natural location for the implementation. It shouldn't Can be argued. But it can also be argues that it sits on top of I2C and doesn't need to live in i2c-folders itself (like PMBus). The implementation given in this patch looks a bit like the latter. However, this is not the main question currently. > be too much work, it's just a matter of deciding what the call stacks should > be for the native vs. emulated cases. I don't like it. We shouldn't use SMBus calls for SCCB because SMBus will very likely never support it. Or do you know of such a case? I think I really want sccb helpers. So, people immediately see that SCCB is used and not SMBus or I2C. And there, we can handle native support vs. I2C-SCCB-emulation. And maybe SMBus-SCCB emulation but I doubt we will ever need it.
Attachment:
signature.asc
Description: PGP signature
