On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
[off-list ref] wrote:

On Tue, 1 Aug 2017 15:34:14 +0200
Boris Brezillon [off-list ref] wrote:

quoted

On Tue, 1 Aug 2017 15:11:44 +0200
Arnd Bergmann [off-list ref] wrote:

quoted

On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
[off-list ref] wrote:

I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
entry. Indeed, I'm unconditionally calling functions provided by the
I2C framework which have no dummy wrapper when I2C support is disabled.
I could of course conditionally compile some portion of the I3C
framework so that it still builds when I2C is disabled but I'm not sure
it's worth the trouble.

This "depends on I2C" should also solve the I2C+I3C driver issue, since
I2C is necessarily enabled when I3C is.

Am I missing something?

That should solve another part of the problem, as a combined driver then
just needs 'depends on I3C'.

On top of that, the i3c_driver structure could also contain callback
pointers for the i2c subsystem, e.g. i2c_probe(), i2c_remove() etc.
When the i2c_probe() callback exists, the i3c layer could construct
a 'struct i2c_driver' with those callbacks and register that under the
cover. This would mean that combined drivers no longer need to
register two driver objects.

         Arnd