A registered driver without a probe callback doesn't make sense, so
refuse to register such a driver. (Otherwise i3c_device_probe() yields a
NULL pointer exception.)
A driver without remove is possible, e.g. when all resources are freed
using devm callbacks. So guard the call to driver->remove by a check
for being non-NULL.
Note that the only in-tree i3c driver
(drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i3c.c) doesn't have a remove
callback.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210128091048.17006-1-u.kleine-koenig@pengutronix.de
Some I3C device drivers need to know which entry matches the
i3c_device object passed to the probe function
Let's move i3c_device_match_id() to device.c and export it so it can be
used by drivers.
Signed-off-by: Vitor Soares <vitor.soares@synopsys.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Add core infrastructure to support I3C in Linux and document it.
This infrastructure adds basic I3C support. Advanced features will be
added afterwards.
There are a few design choices that are worth mentioning because they
impact the way I3C device drivers can interact with their devices:
- all functions used to send I3C/I2C frames must be called in
non-atomic context. Mainly done this way to ease implementation, but
this is not set in stone, and if anyone needs async support, new
functions can be added later on.
- the bus element is a separate object, but it's tightly coupled with
the master object. We thus have a 1:1 relationship between i3c_bus
and i3c_master_controller objects, and if 2 master controllers are
connected to the same bus and both exposed to the same Linux instance
they will appear as two distinct busses, and devices on this bus will
be exposed twice.
- I2C backward compatibility has been designed to be transparent to I2C
drivers and the I2C subsystem. The I3C master just registers an I2C
adapter which creates a new I2C bus. I'd say that, from a
representation PoV it's not ideal because what should appear as a
single I3C bus exposing I3C and I2C devices here appears as 2
different buses connected to each other through the parenting (the
I3C master is the parent of the I2C and I3C busses).
On the other hand, I don't see a better solution if we want something
that is not invasive.
Missing features:
- I3C HDR modes are not supported
- no support for multi-master and the associated concepts (mastership
handover, support for secondary masters, ...)
- I2C devices can only be described using DT because this is the only
use case I have. However, the framework can easily be extended with
ACPI and board info support
- I3C slave framework. This has been completely omitted, but shouldn't
have a huge impact on the I3C framework because I3C slaves don't see
the whole bus, it's only about handling master requests and generating
IBIs. Some of the struct, constant and enum definitions could be
shared, but most of the I3C slave framework logic will be different
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Uwe Kleine-König