linux_dsm_epyc7002/drivers/i3c/Kconfig

# SPDX-License-Identifier: GPL-2.0

menuconfig I3C
	tristate "I3C support"
	select I2C
	help
	  I3C is a serial protocol standardized by the MIPI alliance.

	  It's supposed to be backward compatible with I2C while providing
	  support for high speed transfers and native interrupt support
	  without the need for extra pins.

	  The I3C protocol also standardizes the slave device types and is
	  mainly designed to communicate with sensors.

	  If you want I3C support, you should say Y here and also to the
	  specific driver for your bus adapter(s) below.

	  This I3C support can also be built as a module.  If so, the module
	  will be called i3c.

if I3C
source "drivers/i3c/master/Kconfig"
endif # I3C
i3c: Add core I3C infrastructure 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> 2017-07-19 16:52:29 +07:00			`# SPDX-License-Identifier: GPL-2.0`

			`menuconfig I3C`
			`tristate "I3C support"`
			`select I2C`
			`help`
			`I3C is a serial protocol standardized by the MIPI alliance.`

			`It's supposed to be backward compatible with I2C while providing`
			`support for high speed transfers and native interrupt support`
			`without the need for extra pins.`

			`The I3C protocol also standardizes the slave device types and is`
			`mainly designed to communicate with sensors.`

			`If you want I3C support, you should say Y here and also to the`
			`specific driver for your bus adapter(s) below.`

			`This I3C support can also be built as a module. If so, the module`
			`will be called i3c.`

			`if I3C`
			`source "drivers/i3c/master/Kconfig"`
			`endif # I3C`