Messages in this thread | | | From | Arnd Bergmann <> | Date | Tue, 1 Aug 2017 16:22:21 +0200 | Subject | Re: [RFC 2/5] i3c: Add core I3C infrastructure |
| |
On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > On Tue, 1 Aug 2017 15:34:14 +0200 > Boris Brezillon <boris.brezillon@free-electrons.com> wrote: >> On Tue, 1 Aug 2017 15:11:44 +0200 >> Arnd Bergmann <arnd@arndb.de> wrote: >> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon >> > <boris.brezillon@free-electrons.com> 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
| |